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)
Related
I am trying to create a script that targets all the servers in one of my SCCM device collections and remotely restarts a few services and runs a couple of SCCM client actions.
I discovered that the invoke-command is failing to run on my localhost due to an access denied error. However, this command works without issue on a normal PowerShell window. I have also tried running the script against my domain controller and it also works, so the issue is with running it on the localhost.
Screenshot of lab and script failures
You can see in the PowerShell window, I am currently running the script on a server called DP01. The invoke-command sent in that window runs without trouble. In the PowerShell ISE window, you can see that it receives access denied on DP01, but it is a success on my domain controller DC01.
No matter where the script is saved the error is the same, I have full administrator (Domain Admins) rights to the server and the folders have sufficient access. I am not sure what the problem here is.
Running PowerShell ISE in administrator mode first then opening the scripts solved the issue.
I'm automating windows updates for a set of SQL servers, mostly running on Windows Server 2016. Typically after you install updates you have to reboot, and there is a period of time after rebooting where the server is applying updates and users can't remote into the server. In my automation, I would like to wait until that period of time is over before reporting a successful update. Is there an indicator that I can check remotely through powershell that will determine whether a user can remote in?
I've checked the main RDP services (termservice, SessionEnv and UmRdpService) during this period and they are all running, so if there's some sort of indicator, it isn't them. Maybe there is a field somewhere that states that windows is applying updates? All of the servers are virtualized through VMWare if it matters.
Thanks for reading!
How about testing the port that the remote desktop service listens on?
test-netconnection server -port 3389
I didn't have any luck on ServerFault either, but I did eventually find a solution myself, posting here in case anyone finds this thread looking for help.
The isn't actually a service that changes states when you can RDP back into a server; that's probably determined somewhere in the windows code and there's no way you could find the flag. However, the TIWorker program runs after a reboot to install windows, and in my experience recently, when that exe completes, you can RDP 100% of the time, which is good enough for my automation.
I loop over this piece of code in 5 second intervals until it returns 0 rows, then finish.
Get-Process -ComputerName $server | ? {$_.ProcessName -match 'TiWorker'}
I've created a ps1 file that runs on our UTIL server for all workstations on our domain that checks if the computer is online, skips offline computers, checks bitlocker status, formats results, and writes to a CSV file.
The script essentially uses manage-bde -cn $Computer -status C: and works great on most machines. However, there are a few machines that are confirmed on the network and online that do not reply with the status.
I ran the same command manually in powershell on the UTIL server to the affected machines and get the result "ERROR: An error occurred while connecting to the Bitlocker management interface. Check that you have administrative rights on the computer and the computer name is correct" If I connect to the computer and check status on the computer itself, it displays results no problem.
I'm logged into the UTIL server as an admin running powershell as admin. My question is, what would cause some computers to return results successfully and others to have an issue connecting to the Bitlocker management interface? Has anyone seen this before?
What process is executing your script when you're not in an interactive session? A scheduled task, a service? What security context does that process run in?
Based on some other threads I have seen on this, you should check these items:
Not running the command as an admin
Not having a compatible TPM
The TPM being disabled in the BIOS (it is on many computers)
The TPM or BitLocker services not being started.
A TPM reporting as a 1.2 TPM when in fact it is a 1.1 TPM.
I had the same issue in my net.
Solved by setting up one rule for remote client Windows firewall. Ther rule is intended to allow WMI (Windows Management Instrumentation) access to Remote Machine (see this link for further info https://social.technet.microsoft.com/Forums/lync/en-US/a2f2abb3-35f6-4c1a-beee-d09f311b4507/group-policy-to-allow-wmi-access-to-remote-machine?forum=winservergen )
Regards
Andrea
I have a test bed in my lab consisting of a windows server 2008 running powershell 2.0. I am using that server to manage 50 clients that are connected wired and wireless with the server. I am running windows Active Directory on the server and all the clients are in the domain I created and I am using the AD to push different policies. I have a lot of basic scripts running (shutting down all interfaces on the clients, shutting down clients, fetching logs from clients etc.). But there is one Task in particular that is extremely important for my setup and I am facing a lot of issues with it. Here are the details:
I want to start some applications like windows media player or a VLC player on all the clients through a script. The script will be run on the server and it should try and establish connection with all the clients and bring up the UI.
What has been tried?
Method 1:
New-Pssession -computername -credential
Enter Pssession -id
(brings up the prompt on the remote machine)
start-process wmplayer.exe
Everything runs correctly. A process gets created on the client, but I do not see the UI.
Method 2:
I created a batch file on the remote machine that runs the wmplayer.exe. It works fine and brings up the UI if executed manually from the client, but again if triggered remotely it only creates a process and does not bring up the UI.
Am I missing something while running the commands? Do I need to configure something more to get the UI up and running?
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.