How to Set Up XP Remote Destop to Log Previous User Back In?
January 26, 2005 7:36 AM Subscribe
Remote Desktop for XP: When I log into a remote computer using RD, it logs out the current user. When I end my remote session, the remote user is logged out but the original user (the only other user on the remote machine) is not logged back in. How can I set up XP or Remote Desktop so that, when a Remote Desktop session ends, the remote computer logs a specific user back in?
Best answer: There are two approaches you could take:
1. Cheating
• Setup an auto-login in the registry or with TweakUI
• When you're done your RD session, reboot the box (not logoff)
When the system comes back up, it will be logged on as the user you specify. This is insecure because the password for the account is stored in clear text in the registry.
2. Local group policy + scripting
Run GPEDIT.MSC and find the policy that fires off a script when someone logs off. That's the easy part. Now you have to create a script that does what you want. Your script may have to schedule another script to run a few minutes after logoff to logon the other account in question so as to
avoid any service conflicts.
posted by AlexReynolds at 8:04 AM on January 26, 2005
1. Cheating
• Setup an auto-login in the registry or with TweakUI
• When you're done your RD session, reboot the box (not logoff)
When the system comes back up, it will be logged on as the user you specify. This is insecure because the password for the account is stored in clear text in the registry.
2. Local group policy + scripting
Run GPEDIT.MSC and find the policy that fires off a script when someone logs off. That's the easy part. Now you have to create a script that does what you want. Your script may have to schedule another script to run a few minutes after logoff to logon the other account in question so as to
avoid any service conflicts.
posted by AlexReynolds at 8:04 AM on January 26, 2005
Best answer: I'm not sure what you could put in a script that would automatically log a user in. You could run services, even delete files, but I believe the first option is the only likely solution.
You could setup start-up scripts that would automatically populate the registry entry for automated login, that way it would not be stored in clear-text beyond the startup process (set a login script to delete the entry once you have successfully logged-in).
It is insecure, and something I would not recommend. Why not just have the other user (assuming it's a person) log back in themselves? Or, is something running under this user's credentials that require the machine to stay logged-on?
If that's the case, you could look into something like FireDaemon which will run applications as services. This means the console does not have to remain in a logged-in state for the application to run successfully.
posted by purephase at 8:31 AM on January 26, 2005
You could setup start-up scripts that would automatically populate the registry entry for automated login, that way it would not be stored in clear-text beyond the startup process (set a login script to delete the entry once you have successfully logged-in).
It is insecure, and something I would not recommend. Why not just have the other user (assuming it's a person) log back in themselves? Or, is something running under this user's credentials that require the machine to stay logged-on?
If that's the case, you could look into something like FireDaemon which will run applications as services. This means the console does not have to remain in a logged-in state for the application to run successfully.
posted by purephase at 8:31 AM on January 26, 2005
You could try running mstsc with the -console switch so it directly controls the console. Maybe that way it will not logout the user?
posted by internal at 9:01 AM on January 26, 2005
posted by internal at 9:01 AM on January 26, 2005
Best answer: This is an interesting question, so I did some more research on it.
A pre-release version of SP2 allowed an existing session to be run without being disturbed while another user logged on to the computer remotely, though. You can still turn this on by using the old DLL (termserv.dll build 2055 from Beta 1) and change registry settings but this could be against the Windows license since the reason Microsoft didn't implement this feature was that it was allowing two distinct users to use an OS at the same time with a single lincense.
Setting EnableConcurrentSessions to 1 will allow the current session running, with the combination of the old DLL:
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Terminal Server\Licensing Core] "EnableConcurrentSessions"=dword:00000001
posted by AlexReynolds at 10:09 AM on January 26, 2005
A pre-release version of SP2 allowed an existing session to be run without being disturbed while another user logged on to the computer remotely, though. You can still turn this on by using the old DLL (termserv.dll build 2055 from Beta 1) and change registry settings but this could be against the Windows license since the reason Microsoft didn't implement this feature was that it was allowing two distinct users to use an OS at the same time with a single lincense.
Setting EnableConcurrentSessions to 1 will allow the current session running, with the combination of the old DLL:
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Terminal Server\Licensing Core] "EnableConcurrentSessions"=dword:00000001
posted by AlexReynolds at 10:09 AM on January 26, 2005
The only other options I know of would be the use of Windows Terminal Server (a considerably expensive product which allows multiple user logins) or VNC (free).
VNC will leave the current user logged in; however, both screens (yours and the end user's) will show the same display. This may or may not be a concern, depending on your application.
posted by AlexReynolds at 10:15 AM on January 26, 2005
VNC will leave the current user logged in; however, both screens (yours and the end user's) will show the same display. This may or may not be a concern, depending on your application.
posted by AlexReynolds at 10:15 AM on January 26, 2005
I was going to say what AlexReynolds said, but I was going to prefix it with "If you don't mind breaking your EULA..." instead.
posted by krisjohn at 2:20 PM on January 26, 2005
posted by krisjohn at 2:20 PM on January 26, 2005
Response by poster: Okay, using Alex's first suggestion, I've gotten this working, but do force the remote computer to reboot, I have to do a "shutdown -r -f". Nothing else works, which is odd because I can turn the computer off from, say, the task manager, but not reboot it.
Will forcibly rebooting the computer like that do any long-term damage to the stability of my computer, do you think?
I'm still experimenting with Alex's second suggestion. I'm also looking into FireDaemon as that may solve my problem more efficiently.
The remote computer in question, by the way, is just my personal home computer. I leave it set up to download/upload files during the day, but I need periodically to be able to access it remotely. I've got VNC set up, but it's quite a bit slower than RDC, and then there's the inconvenience of having mismatched screen resolutions.
Thanks for all the suggestions!
posted by gd779 at 2:59 PM on January 26, 2005
Will forcibly rebooting the computer like that do any long-term damage to the stability of my computer, do you think?
I'm still experimenting with Alex's second suggestion. I'm also looking into FireDaemon as that may solve my problem more efficiently.
The remote computer in question, by the way, is just my personal home computer. I leave it set up to download/upload files during the day, but I need periodically to be able to access it remotely. I've got VNC set up, but it's quite a bit slower than RDC, and then there's the inconvenience of having mismatched screen resolutions.
Thanks for all the suggestions!
posted by gd779 at 2:59 PM on January 26, 2005
gd779, try "shutdown -r -f -t 0".
posted by AlexReynolds at 3:08 PM on January 26, 2005
posted by AlexReynolds at 3:08 PM on January 26, 2005
This thread is closed to new comments.
How to setup Windows XP for automatic login.
posted by purephase at 7:53 AM on January 26, 2005