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 have a Windows application that must run under a certain user/pass in a server running Windows Server 2000 and another in a Windows Server 2003. This is a critical application and it must be running 24/7.

Everytime I need to manage the server I need to login using this account credentials to avoid close the application, since it's a windows form application showing a lot of information and cannot run as service and, as it's a third-party application, I can't change its code to work as a service neither.

Due this, the account needed to run the application is local administrator what's not safe at all, and every Sys Ad need to have its credentials, what also not safe since I can't keep track on who did what.

I need to find a way to keep an account always connected and running the application [until someone explicity logs this off, of course :)] and everytime I need to check something on the application I can log with this account and open this same session. But when someone needs to manage the server, he/she can connect using his/her admin account which will not logoff the other account.

How can I achieve that?

Just to make it clear:

I need a way to login two sessions on the server (Windows Server 2000 or above).

One of these sessions will be using a regular account credential to run the application. This session can only be logged off by the user it self, or forcedly by the Enterprise Admin. If someone logins to the server, even locally, it will not logoff this session.

Other accounts, like local administrators, domain admins or even regular users can opne a new session and/or logon locally on the server without closing the other connection at all.

This is the scenario. :)

share|improve this question
Can't believe no one has asked this yet...What OS you are running? You keep mentioning "server" in your question, but do not mention the exact OS version or if it is really a "server OS" or a XP machine that acts as a "server". It looks like people are assuming it is XP or some version of Windows Server... – August Aug 18 '09 at 16:34
OK, now I think all the details are there – homemdelata Aug 18 '09 at 16:48

12 Answers 12

Have you considered running the app as a service? The service could then be set to use your certain user/pass and you'd no longer have to juggle around sessions to keep it specifically running.

share|improve this answer
As i said: it's a windows form application. It has windows that shows some status and other information so we can't run it as a service :( That was the first idea I had. – homemdelata Aug 18 '09 at 14:55
Is this an app you've built in-house? Why not change it to generate logs or events instead of writing to windows forms? – Chris_K Aug 18 '09 at 15:10
I thought someone would aks that so I included in the questions that this is a third-party application – homemdelata Aug 18 '09 at 16:22

Depending on the main method used to interact with the server (either locally via the console or via RDP) there are 2 options. Keep in mind that Windows Server typically has 3 total interactive sessions - the console session and 2 remote sessions (unless it is a terminal server in which case you are limited by your CALs, but I don't think you are using a terminal server in this case)

I think the true root-cause resolution of the issue is to communicate to everyone who has the ability to log that user off to NOT log them off. Any administrator interacting with the server will be shown a message when they log in if your "service user" is currently using that session or not, and they will have the option to log them off or not. It really boils down to them clicking "Yes" or "No" since if they are admins on the server they have other means to log off the "service user" without interacting directly with a logon box if they really want to, and there is absolutely no way to get around this. Admins can log off other admins and users and regular users can only log themselves on or off - this is by design.

Given that you don't want people accidentally doing this or at least seeing that "Yes" or "No" dialog as infrequently as possible you can log the user in using either the console session or a RDP session using remote desktop depending on how other admins access the servers.

1) If admins usually connect to the servers via remote desktop, then you will want to use the console session for the "service user" since most admins will connect without using the /console or /admin switch (depending on the version of the RDP client). They can log on and off without ever coming into contact with the "service user's" session. If there are already 2 remote connections to the server, they will not be able to login and will not be presented with the opportunity to log the "service user" off. However, if they use the /console or /admin switch with their RDP session they will be presented with the window to log the "service user" off.

2) If admins usually interact with the servers directly using the console session, then it may be best to use one of the RDP sessions to log the "service user" in. Be careful of your Terminal Services Configuration though on the server locally or in Group Policy, since it can be configured with maximum session limits to log the remote session off after a set amount of time whether the user is idle or not.

share|improve this answer
Wow, great response. It seems to be the way to go. I'll just test it before accepting as an answer. Thank you – homemdelata Aug 18 '09 at 17:47

You could log in to the account that runs the application using a remote (RDP) session, then disconnecting the session.

share|improve this answer
But how do I make sure the account will never be logged off? – homemdelata Aug 18 '09 at 14:58
To my knowledge, there's no real way to be assured of that. Somebody with the right priveledges could always log the user off. It becomes more of a procedural thing at that time. You could perhaps write some sort of script that monitors the logged-on sessions to send a notification if the account is logged off, but that's probably about as close as you'll get. – palehorse Aug 18 '09 at 21:59

I use TweakUI to log the user into the server automatically, then only allow one Remote Desktop session. Instead of logging off, just close your RDP window, keeping the user logged in.

share|improve this answer
thats how i do it. it works good enough for a Java shell process that needs to run 24x7. we also use JavaService.exe to register the java shell as a service in the case that the system is accidentally rebooted then it comes up as a service until we can get in to save it. – djangofan Aug 18 '09 at 16:30

As Chris_K said, what you most likely actually want is to run the program as a service - that will allow it to run in the background with the assigned username/password without needing an active login, and without going away when people log on/off the server.

You'll need a program called SrvAny which is capable of running arbitrary programs as services. It's available directly from Microsoft as part of the Windows Server Resource Toolkit.

Once SrvAny is installed, you'd use the command "InstSrv NameOfYourProgram c:\Path\To\YourProgram.exe". It will then be found on the Services screen. You can go into Services and set options for it, such as username and password.

share|improve this answer
As i comment on Chris_K answer, the aaplication has a lot of windows showning information and stuff. Sometimes we need to check this or also interact with the application, so i don't think it's an option :( – homemdelata Aug 18 '09 at 14:57
Yeah, if it's running as a service, you won't be able to access any UI. The standard way to do it is have the service implement the back end of the application, then write a UI that connects to it - in that case, you could log in with another account and use the connector app to interface with the running service, but that would require some rewriting, assuming you have access to the source in the first place. – matthock Aug 18 '09 at 16:05
Yeah, but it's a third party application :( I added this info on the question now to avoid miscommunication – homemdelata Aug 18 '09 at 16:24

I agree that running the process as a service would be ideal, since it would not require a full logged on session at all. However, being a form-based application, this could give rise to interactivity issues (even when selecting the option to allow the service to interact with the desktop), especially in more recent versions of Windows where such forms insist on presenting themselves in an isolated desktop environment (for security reasons).

So if your application does not respond well when running in a service context, one way around this on more recent versions (Vista, Windows Server 2008, etc.) is to set the application to run as a scheduled task, where the task is set to occur "at startup".

And if running the task at startup still does not work properly for your particular application, then you could try setting the task to occur "at log on", in which case you could combine that with the autologon setup suggested by Bård (see MS KB article 315231 for more info... unfortunately I can only post a single hyperlink in my responses)

share|improve this answer
Hey Jessica, you're the only one until now that remembered that form-based app will not run properly as a service ;). Your second idea does not actually resolve my problem. I don't have problem on running the application. I have problems keeping it running with the same user without being closed, hehe. – homemdelata Aug 18 '09 at 15:04

Another possible answer:

Use Group Policy Editor to disable logout and shutdown. That should make it so that you can only disconnect from RDP, not terminate the session (I can't test it here to be sure, so ymmv here)

User Configuration -> Administrative Templates -> Start Menu and Taskbar

Look for the options "Remove Logoff on start menu" and "Remove and prevent access to Shut Down command". It will still be possible to do it from the command line, though - if you REALLY want to block it, you can also block the command line.


share|improve this answer

we set up autologon on some computers that does very special stuff (screengrabs). Can be done with TweakUI on xp and some registry setting on vista.

share|improve this answer

Start -> Run -> "control userpasswords2"

There you will find an option to automatically log a user on to Windows.

This user will get the console session, so an administrator can log in via RDP using their own username/password and not disturb the automatically logged-in session.

Just checked and this isn't in Windows 7 any more :-(

share|improve this answer

Use a Remote Interactive session as described at

The great thing about this setup is, that it automatically logs in after a PC or server reboot.

share|improve this answer

There are some actions you can take that may serve as a work-around to the solution you are looking for. SOme have been mentioned here, such as enabling autologin.

I suppose you could also remove the logoff and shutdown buttons. You can also configure the machine to immediately log back in to the desired account if its ever logged off. We have some machines setup like this. Its very doable.

share|improve this answer

We have a similar situation.

Windows server editions already have 3 sessions, two remote and one console (which can still be accessed using /admin in rdp). The remote sessions won't log another user off but sometimes when someone disconnects rather than logging off it will block other users from connecting. The /admin session always allows someone to connect but will logoff any existing user of that console session, so it is good to keep spare to let you go in and kick a dormant user off.

(If you want more users then you can enable terminal services)

In addition to making it known to everyone not to log the app user off we have nagios monitoring setup to check that the app exe is a running process on that machine. So if it does inadvertantly get shutdown we get a warning and can go start it again.

share|improve this answer

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.