We have a daily procedure when operator logs on via RDP to Windows hosts to ensure the operation is successful so other users can logon at the later stage and to their work.
Putting aside question why this is done this way, is it possible to automate this procedure?Can it be scripted?
Logically the procedure is getting expected output from the operation so it must be possible to automate it using some combination of tools. I can think about AutoIT and powershell to start with.
Has anyone came across this ( unusual ) request before?
The check could then be ran as part of monitoring framework (Zabbix, Nagios, SCOM)
-
doesn't scom have a managment pack for this, would think that both zabbix and nagios would also have this somewhere.– tony rothApr 5, 2013 at 16:36
-
Hi Tony, if you have a link for any of these, this would constitute as an answer ;)– SergeiApr 5, 2013 at 16:50
-
don't know if RDP virtual channels could be used for this but take a look at msdn.microsoft.com/en-us/library/windows/desktop/…– tony rothApr 5, 2013 at 17:23
-
also msdn.microsoft.com/en-us/library/windows/desktop/…– tony rothApr 5, 2013 at 17:26
-
so the answer is that there is no builtin mp for rdp from scom but I'd think the above links would give a start as to a scriptable interface.– tony rothApr 5, 2013 at 17:27
1 Answer
If I were going to script this I'd look at using an RDP client to connect to the server, authenticate, and execute a program that emits some kind of machine-readable "flag".
Using the Microsoft RDP client, you could create an RDP parameter file with the alternate shell:s:
setting set to run a script that touches a flag file and performs a logoff should be sufficient. Saving credentials is going to be your biggest pain.
I found an article with some discussion about using the free rdesktop
client to do this which would be feasible to do from a non-Windows based monitoring machine.
Actually, you could even look at putting a script in the the user's "Startup" folder and using the scripted logon to "exercise" explorer.exe
, too. That might be an even better way than using the alternate shell functionality. You'd want some timeout functionality to detect a hung session and kill the RDP client (along with alerting a failure). You wouldn't want to start stacking-up a bunch of hung RDP logons.