Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm running a legacy network app on an antiquated server OS(Win2k Web Server) running off-site. The app is a commercial(i.e. I don't have the source) product that's been discontinued by the developer but my company is still reliant on it because there's no better product in the marketplace for this extremely niche product. The problem is that it crashes every few days and always at the worst times(weekends,3am etc) and I have to log into the server via RDC and reboot the server and manually restart the app once the server comes back up. The server does nothing but host this app. I've tried it on win2k3 and it still crashes so a change of OS won't help.

I'm trying to automate this server to reboot and then restart the app when it finds that the app has died. I have a method of detecting when this app has died and have the ability to run any kind of script/exe at that time. The app cannot run as a service(I've tried like heck to get this working but there's no chance). It's got to run on the desktop of the RDC user and there's no way around this because I need to interact with it on the desktop frequently. So:

1: Recognize when the app is dead(done) 2: Reboot the server automatically when this is done (simple, done) 3: When the server finishes rebooting open this app on the RDC desktop of an admin level user.

My formal question is: How do I do #3?

Any advice would be extremely welcome and appreciated.

share|improve this question
@Travis: Why do you spend 90% of your post describing things that are not part of the problem? Wouldn't asking just #3 have been enough? – Tomalak Jun 27 '09 at 7:38
@Travis: Verbosity doesn't hurt my eyes. I like to hear background because sometimes communicating subtle nuances of the situation can get you a better answer. Keep up the verbosity. – Evan Anderson Jun 27 '09 at 8:13
Could you infect yourself with the Sasser virus? ;) – Mark Henderson Jun 27 '09 at 8:53
@Tomalak: Sometimes when I post questions like this in forums I get a lot of responses that do not answer my question but try to redefine my question because of a lack of given detail. This is a waste of time. – Travis Jun 27 '09 at 9:13
@Farseeker: "Snow Crash" much? smile – Evan Anderson Jun 27 '09 at 14:04
up vote 2 down vote accepted

I'm going to say what others have said, but a little differently, as I've done this very thing with a couple of god-awful programs (both of which are polling programs for time clocks-- what is it with programs that poll time clocks being sucky crap?):

  • Logon to the server computer as the user who will run the application. Set the user's screensaver to be secure (i.e. require a password). You should probably use "blank screen" to save CPU.

  • Place shortcuts to your script to start the application and test for its "aliveness" into the "All Users" "Startup" group. (Be sure that your script gives the application ample time to actually start before checking whether it's "dead".)

  • Grab a copy of "nircmd" from and throw it into the %SystemRoot%\System32 directory (or anywhere, really). Add a shortcut to the "All Users" "Startup" group to call:

    %SystemRoot%\system32\nircmd.exe screensaver

  • Add the following registry values, substituting in the appropriate username and password.

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
    AutoAdminLogon - REG_SZ - 1
    DefaultUsername - REG_SZ - Set to user name to logon with
    DefaultPassword - REG_SZ - Set to password to logon with
    DefaultDomain - REG_SZ - Set to either local machine's name if a local account is used to logon, or domain's name if a domain account is used to logon.
    ForceAutoLogon - REG_SZ - 1
  • Modify the permission on the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon key (using REGEDT32) to remove the "Power Users" and "Users" groups from the ACL on that key. (I just tested this on a W2K machine, and it does not disrupt the autologon). This will prevent the plaintext password from being read by a limited-access user on the box.

At this point, the computer will boot and automatically logon as the user you've specified, start the application and your "deadness" script, and immediately go into a locked screensaver. The key being held during boot won't stop the auto-logon (but, since this is off-site, hopefully they keyboard / mouse are secured anyway).

If you can run it on W2K3, you can use the "/admin" or "/console" argument on the Remote Desktop client (depending on which version you have-- do a "/?" to see) to connect to the console session. You will need to logon with the same username and password used by the autologon account, and anybody w/o that username and password won't be able to connect to the console session.

If you have to stick to running it on W2K, install something like VNC so that you can take remote control of the console session. If you do use VNC, be sure to modify the permission on the registry key where the machine VNC configuration is stored (HKEY_LOCAL_MACHINE\Software\ORL\Winvnc for older versions, other places for newer versions) to remove "Users" and "Power Users" from the key's ACL. This will prevent limted-access users from reading the VNC password hash, which can easily be reversed back into the VNC password.

That's how I'd do it.

share|improve this answer
Of course the DefaultPassword registry value is limited-user-readable, which is an advantage of TweakUI in that there's some degree of password encryption. A limited user can't read the registry remotely, but any process running locally can. – nray Jun 27 '09 at 7:01
Phh-- TweakUI encodes the password-- it's not encrypted. Anyway, I've got you covered in my edit. smile – Evan Anderson Jun 27 '09 at 7:15
Evan: Thanks for the extremely detailed response. It's getting late but I'm going to give this a shot in the morning on a dev machine. THANK YOU. – Travis Jun 27 '09 at 9:20
Ok after a few wrong turns this worked and everything is running great. Evan, seriously thank you. You're awesome. – Travis Jun 27 '09 at 23:20
No problem, Travis. Sorry to hear you're stuck with such a crappy application that you even need to do this. Hopefully a better app. will come along, but until then at least you've got a good way to keep it running. (One of them that we have to support like this requires buttons to be clicked to "start automated processing". We ended up having to use a macro scripting language to get the stupid thing to start running once the EXE started. It's like the people that wrote the software never actually USED it. Morons... smile) – Evan Anderson Jun 28 '09 at 22:37

The key here is security - in short you aren't going to have any if you follow these instructions.

Steps are: 1. Auto-login. 2. Run a (cmd) batch file that kicks off your program when you login.

For auto-login - just use TweakUI - it's just a bunch of registry files, but TweakUI is the best way to write these nicely.

For the batch file, just write a cmd file that runs your program and put it in the "Start up" folder in the "All users" directory.

There will be more sophisticated ways of doing this, but this low-tech mechanism will work but will 100% compromise security of the server!


share|improve this answer
Thanks for your reply Mike! Unfortunately, this server is a normal dedicated web server and running on an open network at the host(the people using the app are all over the place). I'm coming from a linux background and have never used TweakUI but I'm assuming that this will allow ANYONE to log in through RDC. No password required correct? – Travis Jun 27 '09 at 6:00
TweakUI will automate the logon of the console session (session 0), not the RDP sessions (session > 0), see renniej's answer, adding a shortcut to that user's startup group will run the app. Connecting to this session will require the /console switch after the hostname in the Remote Desktop GUI, and you will be prompted for that user's password on connect, so no, not anyone can connect. In fact ONLY the autologon account can connect, or the autologon account get's logged off when another admin logs on (don't worry, you get a prompt). – nray Jun 27 '09 at 6:49

We have to do this at a couple of sites and we use the auto-login that Mike suggested.

Since you're from a Linux background maybe it's worth emphasising that the auto-login automatically supplies a username and password for the interactive session when the server starts i.e. it is as though someone has sat own at the server, pressed ctrl-alt-delete and logged in at the server. The app then runs from the Startup folder just as it does for any interactive user.

NB RDC is not involved. It is an interactive logon.

Obviously security is now non-existant because anyone can walk up to the server and start typing. However you can set the screen saver to a very short timeout so it rapidly locks the interactive session. The only security risk is if someone is watching the server restart and can grab it in the time between the autologin and the screen saver cutting in.


share|improve this answer
Ah, ok I understand. That makes a lot more sense to me. Thank you. – Travis Jun 27 '09 at 9:23

How about putting your app on a virtual server; either VMWare or Hyper-V and using the auto-login described by Mike?

I only thought of this after posting my first reply, but if you put your app in a virtual server you can have it running in the interactive session and there's no security risk because the virtual machine has no keyboard and mouse.


share|improve this answer
This occurred to me about 10 min after posting the original question and I've been working on it since then. For a while I thought it would do the trick but the app has some subtle issues when running this way. I'll keep on it tomorrow to see if I can hack my way around it. Good suggestion though. – Travis Jun 27 '09 at 9:26

A popular alternative to RDP in this scenario is VNC, which allows you to connect to the console session whether it's logged in or not.

I believe VNC can be moderately secure, depending on which version you go with, and it's FLOSS.

  • Use TweakUI to create an autologon, a local account not a domain account.
  • Add a shortcut to the app to the startup group in the autologon account's start menu.

You can try TightVNC, UltraVNC, RealVNC, WinVNC...

share|improve this answer
Good suggestion and thanks. This will likely be part of the end solution it seems. – Travis Jun 27 '09 at 9:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.