I'm having an amazing amount of trouble starting and stopping a service on my remote server from my msbuild script.
SC.EXE and the ServiceController MSBuild task don't provide switches to allow a username/password so they won't authenticate, so I'm using RemoteService.exe from www.intelliadmin.com
-Authenticating with \xx.xx.xx.xxx
-Authentication complete
-Stopping service
-Error: Access Denied
The user account details I'm specifying are for a local admin on the server, so whats up?! I'm tearing my hair out!
Update:
OK here's a bit more background. I have an an XP machine in the office running the CI server. The build script connects a VPN to the datacentre, where I have a Server 2008 machine. Neither of them are on a domain.
Often, you can connect to the IPC$ "pseudo-share" on the machine to help establish the credentials before running commands like SC.EXE. Use a command like:
C:\> net use \\xx.xx.xx.xx\ipc$ * /user:username
The * tells it to prompt you for the password.
I've disabled UAC and now it seems to work.
If I understand your scenario correctly, it could help running the script with a domain account which is administrator on your remote machine (or better: has the right to start and stop the service).
Quick followup question - can you use the "runas" command from an MSBuild script? If so, wouldn't you be able to simply impersonate another user with runas /user:dsfsdf /password:dfdf sc.exe ... (or similiar - I haven't researched the command-line options)?
Related
In my workplace, we administer hospital intensive care PCs (Windows 7 desktop clients) that are meant to be on and running a particular program in near-perpetuity. To that end we've developed a few powershell scripts that run every 5 minutes and alert us whenever the PCs drop off the network or the processes / programs we require crash.
Our program monitoring script relies on the powershell cmdlet "get-process" run remotely by an admin-credentialed account. The script works on all of our PCs except one and we haven't been able to determine what's causing the failure.
At its most basic, the command looks something like
get-process -computername [hostname]
When pointing toward our problem PC we get the error
Get-Process : Couldn't connect to remote machine
Our research indicates that this is likely caused by permissions, firewall, or remote registry service problems. We've triple-checked and on this PC and
the monitoring account has admin privileges, no firewall is active, and remote registry service is on and set to start automatically. The code works when run on the local machine but not when run remotely.
Similar powershell cmdlets run remotely, like "get-service", work with no issues. As noted above "get-process" runs successfully on our other PCs. Any insight into this strange issue would be appreciated.
One thing to note is that the Invoke-Command workaround that has been offered in answer to other, similar questions doesn't work on this PC or any of our others.
Have you tried validating the all RPC services are up?
1.Remote Procedure Call(RPC)
2.Remote Procecure Call(RPC) Locator
3.Remote Registry (You said it's up though)
EDIT: I overlooked "Prerequisites for executing build definitions is to have your build agent ready, here are steps to setup your build agent, you can find more details in this blog ." from these steps. I'm currently trying to get that build agent up and running on an Azure VM and will report back.
I'm following these steps to try and get CD and Selenium tests running through my Visual Studio Online TFbuild. I've had some helpful hints after sending some feedback via email, but I'm still not able to get past the file copy step.
I've created a Windows 10 Enterprise VM.
I've correctly set the ip address in my build test machines and am able to RDP into the machine.
I've successfully (after several attempts) gotten Remote Power shell working (though I'm not 100% certain winrm s winrm/config/client '#{TrustedHosts="Hosted Agent"}'). I got the name from https://{}.visualstudio.com/DefaultCollection/_admin/_AgentQueue or Build > edit build > General > Default Queue > Manage.
PS C:\users\cdd\Desktop> winrm quickconfig
WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
This seems to be ready after
PS remoting is not supported when network connection type is public. Please check http://blogs.msdn.com/b/powershell/archive/2009/04/03/setting-network-location-to-private.aspx.
and echo "setting executionpolicy"
powershell -command "& Set-ExecutionPolicy -executionpolicy unrestricted -force"
echo "setting remoting"
powershell -command "& Enable-PSRemoting -force"
That's a lot of details, but I'm still stuck after that:
Copy started for - '{ip}:5985'
Copy status for machine '{ip}:5985' : 'Failed'
Failed to execute the powershell script. Consult the logs below for details of the error.
Failed to connect to the path \{ip} with the user cdd for copying.System error 53 has occurred.
The network path was not found.
For more info please refer to http://aka.ms/windowsfilecopyreadme
I have a few questions:
Do I have the correct name of the VM?
Do you have steps on how to get the VM setup to allow FileCopy?
I'm probably missing something else, I'm not familiar with PowerShell or getting this setup. What can I try to get the path available for my cdd adminstration user that I setup when I created the VM?
To copy files to an Azure VM machine, you should use the "Azure File Copy" step that provided in VSO build definition. It provides detailed setting for you to access to your Azure VM machine.
How can i write a powershell script that opens and runs cmdlets on a 64bit remote powershell executable.
I am having a tough time finding any resources, examples or tutorials that show how to write a powershell script that connects to a remote server, opens up the 64-bit Powershell.exe and runs cmdlets from it. I will be running this script from a 32-bit machine. If anyone has any examples or ideas ?
Update:
I have found that i can on the remote machine first execute a trusted host command and enable remote-ps
Enable-PSRemoting
cd wsman:
cd localhost\client
set-item trustedhosts *
After doing this, my attempt to connect to my server
Enter-PSSession servername
gives this error
The following error occured while using Kerberos authentication: The network path was not found.
If a 64-bit machine has PowerShell remoting configured, the default PowerShell endpoint will be 64-bit. There is also an x86 endpoint registered, but that is not the default.
In regards to the updated question, what type of environment are you in? Workgroup or domain?
If you are in a domain, things are a bit simpler. If both sides have enabled PowerShell remoting (via Enable-PSRemoting), You should be able to Enter-PSSession servername as you attempted. Do you have administrative rights on the remote machine?
Since Kerberos was failing you can specify other authentication types using the -Authentication parameter. Valid options are NTLM, CredSSP, and Kerberos. The default is Negotiate, which might use Kerberos or NTLM.
You can specify specific credentials with the -Credential parameter.
In regards to the Kerberos error, you might want to check if the host has the proper SPN's registered.
Don Jones and Tobias Weltner authored a great guide to PowerShell Remoting - Found Here It walks through a number of the configuration scenarios for PowerShell Remoting.
I have the following batch script on a Windows 2008 R2 server:
#echo off
djoin.exe /provision /domain my.domain.com /machine test /savefile savefile.txt
echo %ERRORLEVEL%
If I run the script on the server itself, either through command prompt or PowerShell, it works perfectly fine and returns "0".
The problem is that I need to execute it from a remote computer, so I do the following (an example just for testing):
Invoke-Command -ComputerName remotehost -ScriptBlock {.\script.cmd}
The output is "-1073740940", which is probably error code C0000374, which could have something to do with heap corruption.
This seems to be a problem with the djoin command itself. I can comment out djoin and run other binaries, like ping, with no issues using the same Invoke-Command.
Keeping in mind that the script works perfectly fine when executed from PowerShell on the target computer, what issues could the act of remoting be introducing?
In both cases, the script is executed with the same privileges using my account, which is a member of Domain Admins. I doubt that it's a permissions issue and have no idea where else to look.
[edit]
Gave up on the whole thing. This is either a bug in djoin or some obscure problem in the interaction between djoin and PS remoting.
I managed to run djoin directly on the client, using 'runas /netonly ...' to provide domain credentials. It's a very messy solution (and I have yet to figure out how to get the exit status of a process started by runas), but gets the job done.
This is almost certainly a classic "double-hop" authentication issue. Remember that when you use PowerShell Remoting you're using up one of those hops. Anything you execute on that remote machine that accesses a third remote machine is unlikely to work if it requires authentication.
To get around that, you can use an authentication method which allows you to Delegate Credentials such as CredSSP. It's a bit more involved than simply changing your authentication type as you have to make changes on the client side and the server side of the transaction. Refer to this blog post on MSDN, PowerShell Remoting and the “Double-Hop” Problem and this "Hey, Scripting Guy!" post, Enable PowerShell "Second-Hop" Functionality with CredSSP.
I've recently upgraded a number of servers from 2003 to 2008R2. Since the upgrade I've started to see the following error:
[servername] Connecting to remote server failed with the following error message : The WSMan service could not launch a host process to process the given request. Make sure the WSMan provider host server and proxy are properly registered. For more information, see the about_Remote_Troubleshooting Help topic.
The error is seemingly random. The script will work and then fail. The command to create the session is in a loop (create session, remove session) and is called numerous times as part of a set of deployment scripts. When the script fails, it fails at different points.
I've checked the event log on the local workstation (win7) destination server (win2008R2) but there are no errors that I can see.
This is the lines that randomly fails:
$session = New-PSSession -ComputerName $serverName -Credential $credential
I did not see this issue on Win2003. The scripts have not changed. I'm assuming the problem is on the destination server but cannot find any errors or logs to look at. It will work once and then fail so my deployment scripts will sometimes succeed and then fail at different points.
Any guidance on tracking down this problem would be much appreciated.
You can get this error when trying to connect to localhost with an account that's not an administrator.
It used to be possible to use accounts that weren't an administrator, but a Windows Update in January 2019 disabled the functionality for security reasons. From the patch notes:
By default, PowerShell remoting only works with administrator accounts, but can be configured to work with non-administrator accounts. Starting with this release, you cannot configure PowerShell remote endpoints to work with non-administrator accounts. When attempting to use a non-administrator account, the following error will appear:“New-PSSession: [computerName] Connecting to remote server localhost failed with the following error message: The WSMan service could not launch a host process to process the given request. Make sure the WSMan provider host server and proxy are properly registered. For more information, see the about_Remote_Troubleshooting Help topic.”
You need to be setting the WSMan TrustedHosts. If you want, you can set it to everything using wildcards (*).
You can do it via PowerShell: Set-Item WSMan:\localhost\Client\TrustedHosts -Value *.
Keep in mind that you also need to enable the Windows Remote service. Use the native winrm qc command for this. Enable-PSRemoting -Force might do it as well.
You can also use the PSExec Tools from Sysinternals. Keep in mind that these tools will likely be blocked by your EndPoint Security, so don't forget to white list it.
Is there a specific reason you migrate your old OSes to a newer, but still EOL OS? You can do a lot via PowerShell in 2008R2, but it's still pretty limited. IMO, Using PowerShell is best starting from 2012R2 and onwards.
Are you hitting the number of processes limit by creating pssessions that are crashing and leaving processes open?
Default limit is 15. I'd agree with the above comment and not use sessions, instead use invoke-command like:
invoke-command -scriptblock $scriptBlock -ArgumentList $args -computername $compName -Credential $encodedRemoteCredentials
to Check your limit:
PS C:\aws> ls WSMan:\localhost\Shell
WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Shell
Name Value
---- ----
MaxProcessesPerShell 15
As a quick and dirty test - next time your pssession version of your script fails, increase the maxProcessesPerShell limit using set-item cmdlet to 50 and retry. If the script no longer fails, you know that's the issue (and should consider moving to invoke-command!).