I am trying to run some of the SQL SERVER command using Powershell script by enabling Integrate Security on (Expecting to connect SQL server using Winodows Access) and calling that powershell script into Jenkins Pipeline but its throwing me error as "Unable to connect to target server 'ABC\SQL17'. Please verify the connection information such as the server name, login credentials, and firewall"
I have followed following steps as try
1. Created Jenkins Job as "Jenkins Pipeline"
2. Called Groovy script under Pipeline script to call Powershell script.
3. Added Credentials my windows login details as Global and linked this credentials with Jenkins logged in user.
4. And scheduled job with same user.
I want Jenkins to use my windows credentials to run this powershell but that is not using the same which I have given and its throwing error as User do not have access
Following is sample script I have used to call powershell using batch file in groovy script
node {
stage('Deploy Dacpac to SQL Server') {
script{
bat 'start cmd.exe /c D:\\Source\\Test.bat'
}
}
}
Please advise how can I use my credentials to run such script.
Thank you in advance for your responses !
After hunting few articles and blogs I got solution for this, I have changed project type from Pipeline to Free Style project and directly called power shell script under Build Step tab.
And Used Secret Key from build Environment and provided two variable to stored user name and password with encryption(Use Credential plugin for encryption and masked password ).
Snapshot for configuration
You can use script as below
$SrvPassword = ConvertTo-SecureString "$($ENV:SrvPassword)" -AsPlainText -Force
$Credential = New-Object System.Management.Automation.PSCredential ("$ENV:SrvUser", $SrvPassword)
$SessionDetails = New-PSSession -ComputerName "ServerName" -Credential $Credential
Invoke-Command -Session $SessionDetails -Command {
C:\Test.ps1
}
Powershell cmdlet Write-Host partnered w/ Test-Connection cmdlet in a Do/Until loop to output lines of when a server machine is shut down and NIC re-initializes. Once Service Control Manager fires up after reboot, I want to then restart a computer service.
How exactly can I know when SCM is up and happy as I'm currently trying to restart computer service just after the NIC initializes to start replying to ICMP ping which SCM is not alive yet thus craps out on Restart-Service cmdlet?
If you are initiating reboot using Restart-Computer you can use the -Wait with -For winrm , that means , once the winrm service is up, Restart-computer cmdlet will complete its execution.
Get-Help Restart-Computer -online
AWS Recently announced Lambda Support for PowerShell Core.
Reference URL https://aws.amazon.com/blogs/developer/announcing-lambda-support-for-powershell-core/
Followed the steps given in the URL and deployed below Powershell Core script as a Lambda Function.
Script:
#Requires -Modules #{ModuleName='AWSPowerShell.NetCore';ModuleVersion='3.3.335.0'}
$pw = convertto-securestring -AsPlainText -Force -String "Password"
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist "UserID",$pw
$s = new-pssession -computername "AWSECS2DNS" -credential $cred
Invoke-Command -Session $s -ScriptBlock {Get-Service}
When I trigger the Lambda function it fails. This Powershell script tries to remote connect a Windows EC2 Instance and run Commandlet "Get-Service". It fails at the Commandlet "new-pssession". Same script runs fine in Windows Computer powershell. But fails when run as AWS Lambda function. This happens as AWS Lambda function runs in Linux environment. Please help.
Error:
{
"errorType": "DllNotFoundException",
"errorMessage": "Unable to load shared library 'libpsrpclient' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: liblibpsrpclient: cannot open shared object file: No such file or directory",
"stackTrace": [
"at Amazon.Lambda.PowerShellHost.PowerShellFunctionHost.ExecuteFunction(Stream inputStream, ILambdaContext context)",
"at lambda_method(Closure , Stream , Stream , LambdaContextInternal )"
]
}
Worked with the AWS support team and got the following response:
"After further testing, Lambda service team has confirmed that New-PSSession is currently not supported in lambda environment. This has to do with the way PS Remoting works on PowerShell core for Linux."
Apparently it's a feature on the roadmap, so we may see it eventually.
Currently i am working on taskpads for delegating some permissions to remote admins.I have following questions;
-> For Importing active directory module in powershell , shopuld it be locally installed or can it be imported remotely from a windows 2008 R2 DC?
-> For taskpads to work on remote workstations, should the administrative tools be installed on all the remote machines or is there a centralized way of maintaining them?
Please do let me know if anymore clarifications/questions regarding my efforts.
You can import remote module in this way (remoting must be enabled on remote server):
Create a Powershell remote session to a server with the activedirectory module installed.
$Session = New-PSsession -Computername Server1
Use the newly created remote Powershell session to import the module to that session
Invoke-Command -Command {Import-Module ActiveDirectory} -Session $Session
Use that session with the modules to add the available commandlets from the activedirectory module to your local Powershell session adding a name prefix.
Import-PSSession -Session $Session -Module ActiveDirectory -Prefix RM
The code above enables the use of Active Directory commandlets on a computer that doesn’t have this module installed.
Use AD commandlets in the Powershell command shell with modified names based on the -Prefix set above:
Get-RMAdUser instead of the standard Get-ADUser
Get-RMAdComputer instead of the standard Get-ADComputer
You can avoid the -Prefix RM but it's handy for remember that are imported from remote.
For taskpad I'm pretty sure that must be present on each client installing RSAT with the ADUC mmc snap-in.
I have a windows 2003 box setup with virtual box and I can't powershell to work with it.
I try this on my windows 7 machine
Get-Service –ComputerName myserver
I get back
Get-Service : Cannot open Service Control Manager on computer 'myserver'. This operation might require other privileges.
At Script1.ps1:2 char:4
+ gsv <<<< -cn myserver
+ CategoryInfo : NotSpecified: (:) [Get-Service], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.GetServiceCommand
While searching around I found I should try and use Enable-PSRemoting.
I did this and now when I try to use it I get
WinRM already is set up to receive requests on this machine. WinRM
already is set up for remote management on this machine.
Yet I still get the same error. Is this because I am using a virtual machine? I setup the virtual OS to be on my domain and I can even use my AD account credentials to log in.
I can get other information back from it.
So it is not like I can't connect to it with powershell.
With PowerShell V2 you've got two approachs for remote commands.
Commands with built-in remoting :
A small set of commands in PowerShell v2 have a -ComputerName parameter, which allows you to specify the target machine to access.
Get-Process
Get-Service
Set-Service
Clear-EventLog
Get-Counter
Get-EventLog
Show-EventLog
Limit-EventLog
New-EventLog
Remove-EventLog
Write-EventLog
Restart-Computer
Stop-Computer
Get-HotFix
These commands do their own remoting either because the underlying infrastructure already supports remoting or they address scenarios that are of particular importance to system management. They are built on the top of DCOM and, on the access point of view, you can use them when you can establish a session with the remote machine with commands like NET.exe or PSExec.exe.
You are trying to use one of them and you've got a problem with credentials (-cred parameter), because your token credentials can't be used to establish an admin session to the remote machine.
The PowerShell remoting subsystem :
Before you can use PowerShell remoting to access a remote computer, the remoting service on that computer has to be explicitly enabled. You do so using the Enable-PSRemoting cmdlet. If you are working in workgroup you also need to enable the server to enter on your client computer with this command (on your client computer as administrator):
Set-Item WSMan:\localhost\Client\TrustedHosts *
Then, you will use New-PSSession Cmdlet (with -computername and -credentials) to create a session object. Then Invoke-Command (with -session and -scriptblock) cmdlet allows you to remotely invoke a scriptblock on another computer. This is the base element for most of the features in remoting. You can also use Enter-PSSession to establish an interactive (SSL like) PowerShell command line with the server.
Useful link : Layman’s guide to PowerShell 2.0 remoting
Test this :
$sess = New-PSSession -ComputerName myServer-Credential (Get-Credential)
Invoke-Command -Session $sess -ScriptBlock {get-service}
...
Remove-PSSession -Session $sess
If it is still important, here is my workaround:
I got an unprivileged user called 'usser' who wants powershell(v2) remoting from client A to server B.
Steps:
enable-psremoting on Targetserver B as admin
Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI on Targetserver B as admin
Add "usser" with full privileges
Now comes the exciting part:
sc sdshow scmanager on Targetserver B as admin
Copy the SDDL output
sc sdset scmanager (f.e.:)"D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)" , in the Output you have to fill after this part (A;;CCLCRPWPRC;;;SY) this = (A;;KA;;;SID)
SID stands of course for the SID of the unprivileged "usser"-user
when everything should be fine, it will similiar looks like this :
D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;S-1-5-21-4233383628-1788409597-1873130553-1161)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
Hope you will enjoy that little but complicated workaround.
Viewing and manipulating services requires administrative privileges on the target machine.
I was able to duplicate your error message by attempting to run Get-Service -ComputerName MyServer while logged in as a user account that doesn't have administrative rights to the server in question.
You can resolve this by either granting the workstation user account administrative privileges on the target server or by creating a a local group on the server and granting invocation privileges to members of that group. If you want to do the latter, see the following article.
msgoodies: Using a PS Session without having Administrative Permissions
Building on #scusi marcus's brilliant answer here:
Let's say I have an unprivileged/limited user called 'user1' who wants powershell(v2+) remoting from client machine A to targetserver B.
Steps:
From elevated powershell prompt on targetserver B, run enable-psremoting. Accept several Y/N dialog confirmations or else run with -force switch.
In same elevated prompt as step 1, Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI
In the resulting dialog, add "user1". Read privileges should be sufficient unless you are planning on remotely manipulating services, in which case you will want Full Control.
On targetserver B, from an elevated (non-powershell) prompt or as an administrator, run sc sdshow scmanager. Copy the SDDL output. May look something like this: D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
UPDATE: If we add the limited user to the target computer's Remote Management Users group, we can add (A;;LCRPWPDTLO;;;RM) to the D: portion of the above SDDL string, and skip steps 5 and 6 below.
Determine the SID of the underprivileged user account (in our case, "user1"). (Hint: try wmic useraccount where name='user1' get sid)
Insert the following text into the output we copied in step 5: (A;;KA;;;*SID*) where *SID* is the SID of the user determined in step 5. Insert it somewhere in a place before the S: part of the SDDL string retrieved in step 4. So now you should have a string looking something like this: D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;S-1-5-21-4233383628-1788409597-1873130553-1161)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
On targetserver B, run sc sdset scmanager followed by our new modified SDDL string. So the entire command would look something like this:
sc sdset scmanager D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;S-1-5-21-4233383628-1788409597-1873130553-1161)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
You should now be able to remotely access the Service Control Manager on the remote server while logged into client machine A as "user1".
On client machine A, you may find that when you run Get-Service –ComputerName remoteserver not all services are listed. You may need to repeat the above process (starting at step 4) for a specific service that you need remote access to, but which is not listed in your Get-Service output on client machine A. For instance, if the sqlserveragent service is not listed (but you know it is present on the targetserver), you would again log in to targetserver B and execute sc sdshow but this time not for scmanager but for the sqlserveragent service, so sc sdshow sqlserveragent. You would again receive some SDDL output that would need to be manipulated as above. At this point, it may be worth learning more about SDDL (Google it - this link was helpful for me), with the main caveat to watch for the D: and S: portions of the SDDL string and make sure you aren't messing with the S: part.
I know that this isn't the ideal answer to this question, but I was having a similar issue trying to use PowerShell to talk to a Windows 7 box. Turns out, WMI hadn't been installed with the native PSv2 that comes with Win7.
As soon as I installed v3 as part of the WMI 3.0 package, the problem solved itself. I'd suggest making sure that all the relevant WMI services are running on your server. Unless you have conflicts, I'd also recommend upgrading to WMI 3.0.