I regularly connect to a server running Windows 2003 R2 using Remote Desktop. This server is used as a gateway to the production machines. Recently whenever I log on I receive a message saying that Automatic Update has installed updates and the server needs to be restarted. If I select the Restart Now option I always get a message saying that other users are connected and a restart may cause them to lose data.

My questions are:

  • Will I always receive this message when I am connected through remote desktop because I am classed as an "other user"?
  • Is there any way I can tell whether there really are any other users logged on?
  • If I execute the restart from Remote Desktop will I still be able to log back on after the machine has restarted?
  • I decided to err on the side of caution and arranged for an out-of-hours restart instead. Thanks to everyone for all the advice and information. Nov 17 '09 at 17:07

I'm not 100% on this one, but I think so.

Terminal Services Manager will let you know which terminals are in use.

Yep - we do it often but you have to be careful because sometimes the system hangs when rebooting remotely. It seems to happen less if you use the dos shutdown command with the /r /f switches.

  • If it hangs while rebooting is physical access to the server required to recover? How often does this happen? Aug 20 '09 at 11:24
  • If you don't have any kind of IP KVM or remote management card, then yes, physical access is required if it hangs.
    – phuzion
    Aug 20 '09 at 11:36

You'll get this message if there is another RDP session active, or if someone is logged on locally to the server.

You will be able to log in after the restart, as long as the server doesn't hang up during the boot, or at the BIOS or anything else of that matter.

  • I am the only user in Active state, but there are a number of other users listed in a state of Disconnected. Would these disconnected users cause the "other users" warning to be displayed? Can I just log them off with no repercussions? Aug 20 '09 at 11:28
  • As long as they do not have any open unsaved information they don't mind losing, then yeah, you can close their sessions.
    – phuzion
    Aug 20 '09 at 11:37

To get around this problem I script the updates to install on Saturday night of each week. They are rebooted early Sunday morning. The reboot script uses shutdown.exe. First it logs off any users who may be on, then it performs the actual reboot. It makes no difference whether it's a Terminal Server or not. Users know that between 3AM and 4AM on Sunday is my maintenance window (agreed upon at a management meeting), so if they insist on being connected they will be forcibly disconnected, with no apologies given. May not work for everyone but it sure works for me.

  • It's just a necessary evil - solves/avoids a lot of hassles. Aug 20 '09 at 12:31

Restarting from an RDP session can always be a bit ropey, but to minimize the risk I always take a run through services.msc and stop as many services as possible before doing the actual restart. You'll need to be familiar with which services it is safe to stop in this manner though, but some experience will tell you that. Most hangs on the way down seem to be as a result of a misbehaving service not stopping cleanly, so taking this approach is always advisable.

  • I used to do that as well, having had the same experiences with hung reboots. I've since learned that by using shutdown.exe I no longer need to. The Terminal Servers under my control have been rebooting reliably every week for at least the last 5 years. Aug 20 '09 at 12:04
  • Generally I would use -f as a last resort, e.g. if the clean stop from services.msc didn't work. Aug 20 '09 at 12:27

Open Task Manager and check the Users tab for logged-on interactive users. You can also log them off from here if so wanted.

  • There are a number of users with status of Disconnected but the Logoff and Send Message buttons are still enabled. Is this because they closed a Remote Desktop session without logging off? Aug 20 '09 at 11:19
  • Yes. One of the WORST aspects of having terminals available to users who aren't tech-savvy (and some who are) is that they'll just disconnect a client without logging off, meaning the programs they left running...AV components, desktop shell, etc...are still chewing resources. The system (rightly) counts them as logged in. Aug 20 '09 at 11:24
  • Thats why we normally insist on having session timeouts on disconnected sessions, to avoid just this. Cos users are annoying!
    – Kip
    Aug 20 '09 at 11:27
  • Should I just log them off then? Aug 20 '09 at 11:30
  • Yes but you should inform them of this if they were working with something, at least for the future. They may have unsaved documents open that will be lost if you force the logoff... a good policy is good as well ^^ Aug 20 '09 at 12:56

The warning that you receive is a warning that other sessions (besides the one you're receiving the warning in) are active.

In general, servers that don't have trouble rebooting when you simply reboot them from Terminal Services without a WSUS update pending will reboot succcessfully through an RDP connection with a WSUS update pending.

However, you will generally find better results when using the "shutdown" command from another server on the same network (domain). (shutdown /r /f /m \computername /t 0)

And don't forget that you can use a third method to reboot a remote computer.

  1. Open the Computer Management MMC,
  2. Connect to the target computer (that is, the one you want to reboot),
  3. Right click on the computer name,
  4. Click the Advanced tab,
  5. Click the Startup and Recovery button,
  6. Click the Shutdown button

You'll be prompted as to whether you want to shutdown or restart the machine.

When I'm doing work remotely (and interactively) I almost always use the command-line method, rather than rebooting within the RDP session.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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