I'm a Powershell newbie and am trying to use this article to create a way for another user to kick off an SSIS package on a remote server.
The Powershell code I'm using is:
$pass = convertto-securestring "myPassword" -asplaintext -force
$mycred = new-object -typename System.Management.Automation.PSCredential -argumentlist "myUsername",$pass
invoke-command -computername myServer -scriptblock { dtexec.exe /File "d:\myPath.dtsx" } -credential $mycred
Even though I've tried passing my credentials in Powershell, the SSIS package doesn't seem to be executing with them and is executing as an Anonymous user. The package is failing validation for a number of reasons -
The package can not connect to a remote file that requires permission to access (I have permission but the Anonymous User does not). The user that I would like to have run this script does have permission to the folder.
The SQL Server login is failing. I tried forcing a SQL user in the connection details of the package but that doesn't seem to have worked.
Can I use change the Powershell code to use Windows Authentication? How do I execute the SSIS package using those permissions?
you need to enable CredSSP first (see this), and use invoke-command -Authentication Credssp
Related
I have a script that runs as SYSTEM, if i try to start-process notepad.exe it's working fine. if i add -credentials $cred it shows Access Denied. The credentials i pass over has local admin access, so why is there Access Denied? with procmon on powershell.exe i can not identify any access denied operation, i can see that powershell access notepad.exe with success result.
any ideas?
in one forum-post I read that it's not possible to execute a command with -credentials as SYSTEM. is that so?
if so, is there any workaround?
to my background, i use a software distribution where any installation runs as SYSTEM, from there i want to execute a powershell script as different user.
i found a solution:
$secpasswd = ConvertTo-SecureString 'password' -AsPlainText -Force
$mycreds = New-Object System.Management.Automation.PSCredential ('domain\user', $secpasswd)
Invoke-Command -ScriptBlock { Start-Process powershell c:\temp\mmc.ps1 -verb runas -wait} -ComputerName localhost -Credential $mycreds -Verbose
its not exactly what i want because here you need to enable psremoting first. but its like a workaround.
any idea how this is possible without invoke-command would be appreciated
I'm writing an 'Action Script' in VMWare AppDirector 'AppD' which installs MS Dynamics. (My action script is actually a powershell script). The way this works is that AppD will execute a powershell script on a newly deployed server, using a builtin administrator account. This script is one of the last steps in a highly orchestrated deployment. At this stage my SQL server has been deployed, the databases loaded, and I'm performing the final deployment.
When I run my script logged in as myself, everything works great. But of course that's executing under 'mydomain\myusername' which has access to the SQL server etc. However, when AppD executes this script under a local builtin account, it doesn't have the credentials needed by setup to authenticate against SQL, and make proper connections for install to succeed.
My first attempt was to just call a script, that invokes my actual deployment script, so I can pass credentials;
$user = "mydomain\myusername"
$pword = ConvertTo-SecureString -String "mypassword" -AsPlainText -Force
$credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, $pword
Invoke-Command -FilePath "C:\Scripts\DeployAOS.ps1" -Credential $credential -Computer localhost
This looked like it might have worked, but when reviewing the install log I see the following error;
2015-03-09 13:15:19Z Property DbSqlServer set to: 'SQLSERVER001'
2015-03-09 13:15:23Z Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
My original DeployAOS.ps1 script contains this line, which kicks off the install;
# Perform AOS Installation
Start-Process -FilePath $exeAOSSetup -ArgumentList $cfgAOS -Wait
I have also tried just modifying my DeployAOS.ps1 to set the 'System.Management.Automation.PSCredential' object w\ Username\Password, and doing something like this;
# Perform AOS Installation
Start-Process -FilePath $exeAOSSetup -ArgumentList $cfgAOS -Credential $credentials -Wait
And it really didn't like that. It feels like the AOS setup needs to be executed under a domain user, that has access to the SQL server, and maybe even have a user profile loaded while setup runs (So it can create a desktop shortcut, etc.)
Any ideas how I might go about solving this problem? I'm fairly new to scripting in powershell, so any help would be appreciated.
TeamCity executes builds using the build agents. The build agent I have is an agent on Windows that is running as a service under domain credentials.
I need to Invoke-Command on a remote web server in one of my build steps.
When I do this (lot's of stuff removed for simplicities sake):
$password = ConvertTo-SecureString "actualpasswordhere" -AsPlainText -Force
$credentials = New-Object System.Management.Automation.PsCredential("domain\teamcityagent1",$password)
...
Invoke-Command -computername $IISComputerName -Credential $credentials -ScriptBlock ${function:BackupSite} -ArgumentList $IISSiteName, $IISBackupDirectory
It works. But when I provide credentials for currently executing user like this:
$credentials = [System.Net.NetworkCredential]::DefaultCredentials
(surrounding code is the same)
I get the internal waiting and not execution at the point of Invoke-Command. I haven't waited too long, but nothing happens even in 5 minutes.
I would like not to have to provide login and password explicitly in the script, since the credentials are basically for the same user that the build agent is running under. How can I work around the need to provide the login and password in script code?
I did two things and it worked:
Unchecked -NoProfile argument in PowerShell runner parameters. (Didn't help alone)
Removed -Credentail parameter from Invoke-Command.
This executed my code as current user - service user.
I have a TFSserver and a QAserver. I am using autodeployment using TFS and have a powershell script that do the requirement.
But I have a issue in restarting the QA server IIS from the same power shell script.
i am doing the following set of commands for restarting the IIS.
/*struser is in the administrator group of the QAserver
$cred = New-Object System.Management.Automation.PSCredential ("$QAserver$struser", $password )
$session = new-pssession $oceane_server -Auth Negotiate -Credential $cred
/* Some deployment script */
invoke-command -session $session -ScriptBlock {iisreset /stop}
Following error appears :
Access denied, you must be an administrator of the remote computer to use this
command. Either have your account added to the administrator local group of
the remote computer or to the domain administrator global group.
I could not find the solution for this. Any help would be appreciable.
The quick work around is to open all the ports of your server and run iisreset [MACHINENAME] /stop.
For powershell remoting, I use credssp because it allows the double-hop. Also, did you set your execution policy to bypass?
Set-ExecutionPolicy Bypass
I'm receive the following error when I run Connect-MsolService -
Exception of type 'Microsoft.Online.Administration.Automation.MicrosoftOnlineException' was thrown.
+ CategoryInfo : OperationStopped: (:) [Connect-MsolService], MicrosoftOnlineException
+ FullyQualifiedErrorId : 0x80090345,Microsoft.Online.Administration.Automation.ConnectMsolService
+ PSComputerName : xxxxx
Background -
I am using powershell to manage Active Directory, Exchange and Sharepoint Online user data. I have an SSIS package that dynamically builds arguments passed to powershell scripts for creating new and updating existing AD user data, adding/updating necessary security and distribution groups for each user, enabling exchange mailboxes, and passing custom attribute data to Sharepoint online user profiles.
In effort to maintain the purity of the SQL server running the SSIS package, dynamic sessions are created to servers having the modules necessary for import. This allows me to do all of the things mentioned above without having to install the different modules on my SQL server.
My final hurdle is automating the Office 365 licensing. To script licensing assignments I create a session to our server having the necessary MSOnline module and import it giving me access to the Cmdlets, like Set-MsolUserLicense. However, before I can use the Cmdlets I have to connect to the MSOLService.
When I run Connect-MsolService, the credentials modal pops as expected, the appropriate credentials are entered (which have been verified a thousand times over), and I receive the error shown above.
These commands all work fine when I run them from the server where the MSOnline cmdlets are installed, but return the error when run post successful import-module on my SQL server.
Here are the commands used for establishing the session and importing the MSOnline module -
$securePassword = ConvertTo-SecureString $Password -AsPlainText -Force
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $Username, $securePassword
$outputSession = $Null
foreach($session in Get-PSSession){
if(($session.ComputerName -eq $Server) -and ($session.Availability -eq "Available")){
$outputSession = $session
}
}
if ($outputSession -eq $Null){
$outputSession = New-PSSession -ComputerName $Server -Credential $cred -Name 'MSOnline'
Invoke-Command -Session $outputSession -ScriptBlock {Import-Module MSOnline}
Import-PSSession -session $outputSession -module MSOnline -AllowClobber
}
Connect-MSOLService is the only Cmdlet giving me an issues using these methods. Any help you can provide will be appreciated.
Sigh. This appears to be a bug with single sign on assistant and MSOL module. I have had this issue reproduced reliably and had it reported to Office 365 support. It went nowhere. To state it simply, Connect-MSOnline works only in local sessions.
Mind you, MSOL module is a very strange beast, it is not using PSSession to maintain connection with Azure but uses some internal mechanisms that must rely on single sign-on assistant. This may be why in remote session MSOL commandlet cannot connect to Azure AD.
It was a dead end for me, and the only way to work around it is to write an application that runs on the server using MSOL module and accepts commands from the client or is invoked on server directly via service or scheduled task.