December 30, 2015 at 3:42 am #33375
I want to know if a server is not allowing RDP connections after a Hung/Patching/High Mem/CPU usage situation. Ping and Port 3389 checks might be working but, server wont allow RDP connections.
Is there any cmdlet or powershell way through which we can identify
Already tried – Test-NetConnection -ComputerName $Connection -CommonTCPPort RDP).TcpTestSucceeded – But, it is just a port test.
Any other help please
December 30, 2015 at 6:41 am #33379
you could check the Remote Desktop Services service state to see if it's running
get-service -computername $computer -Name TermService
December 30, 2015 at 6:53 am #33380
Thanks for the reply, I am looking for options beyond service checks.
I was referring to any check we can perform beyond remote service checks.
RDP wont respond or not login even the server is managed remotely.
December 30, 2015 at 1:54 pm #33392
Check out the Win32_TerminalServiceSetting Class, specifically the AllowTSConnections property.
gwmi -Namespace root\cimv2\TerminalServices -class Win32_TerminalServiceSetting
That plus the service and port check might be as good as you're going to get. Past that you'd have to actually try to create an RDP session, which would probably take some C# or something to emulate.
December 30, 2015 at 5:07 pm #33394
Thanks again. I know that is enabled in my enterprise environment by default. During patching, I need to check 1000+ servers, so establishing a session will not be a feasible option.
December 31, 2015 at 8:35 am #33401
Kris, what we're missing here is what you are definitively looking for when you say "I want to know if a server is not allowing RDP connections ...."
Terminal Service is a GUI environment and PowerShell will not play there. If the combination of 1) the server did actually reboot, verified by the uptime, and 2) the service is running, and 3) the port is active is not enough for you to get a good feeling that TS is up, I don't think there is much else PowerShell can do for you.
So if there is some other metric that you just don't know how to query, please let us know.
December 31, 2015 at 10:56 am #33402
I think I have an idea what you're talking about... Is it that the server is responding to ping, but when attempting to connect via RDP you're unable to successfully log on because of low resources (CPU/Memory/etc is high/100%)?
I've encountered these situations before and this usually causes issues with the services that these servers are providing as well, and typically you may not find out until someone calls in saying 'service A is not working!' and upon trying to check the server you notice that you can't RDP and resources are being used up for whatever reason. Typically this would mean having to hard reboot the server in many cases.
The only thing I can recall from my experience with this that might be helpful is that a powershell remoting (PSSession) sessions will also fail (usually) so you could possibly try something with a try/catch statement and New-PSSession perhaps.
December 31, 2015 at 11:50 am #33403
Are you just attempting to verify that the RDP service is up and listening? I would start by trying to write a check that uses the telnet client to try and connect to a list of servers on 3389. If the service is hung or dead, it should return a connection refused or similar. There might be a fancier way of doing it with System.Net.Sockets if you don't want to rely on telnet.
December 31, 2015 at 8:11 pm #33407
Bob – I am referring to the scenarios what Peter has mentioned. I like to know if there is any real metric in powershell through which we can derive RDP not working when Ping, Port 3389, Remore Mgmt (Accessing via .msc consoles) and RDC service are working fine – But, mstsc session wont just establish.
Peter – In our enterprise, we have multiple flavors of Windows OS and got no PowerShell installed or PS Remoting enabled on multiple servers. Can we still try PSSession ? I also like to know will it be an alternative of creating mstsc /v:ServerName session – because running mstsc via script to 1000s of servers is not practical and resource consuming
Brian – My current script already checking Port 3389 and RDP Service status. Yes, I am using the same System.Net.Sockets.
Happy New Year
January 1, 2016 at 1:49 am #33408
Peter – In our enterprise, we have multiple flavors of Windows OS and got no PowerShell installed or PS Remoting enabled on multiple servers. Can we still try PSSession ?
If you have at least Windows Server 2008 R2 which ships with PSv2 you can use Powershell Remoting. You'd need to enable it first though. As long as you don't enable CredSSP powershell remoting itself is secure even if you run it without TLS encrypted connections. Have a look at this guide: https://www.penflip.com/powershellorg/secrets-of-powershell-remoting . I've created a GPO in our company to configure the winrm listener for our machines and linked it to the root of our domain so that remoting is available for clients and servers.
I also like to know will it be an alternative of creating mstsc /v:ServerName session – because running mstsc via script to 1000s of servers is not practical and resource consuming.
Unfortunately, running mstsc is the only way to go (from what I know) to really verify the status of the remote desktop service on the remote machine. You could run the connection attempts in parallel with jobs and throttling or use the faster runspace jobs module from Boe Prox https://github.com/proxb/PoshRSJob .
You could try this module to get rds listener information from the remote host https://gallery.technet.microsoft.com/scriptcenter/e8c3af96-db10-45b0-88e3-328f087a8700 .Let us know if that works for you 🙂
January 1, 2016 at 4:37 am #33410
1. Due to App Compatiility requirements, we still have 2K3 servers. No plans to go to Grouppolicy wide changes at this stage.
2. Looks like PoshRSJob is still not the alternative for the check we want to perform
3. I like to know RDS-Manager.psm1 perform similar checks like RD service, port 3389 and then create a RDP session ?
Thanks for your time
You must be logged in to reply to this topic.