How to disable the Windows Shutdown Tracker Dialog

Rick Strahl posted a great tip on how to disable the Windows Shutdown Tracker Dialog. That’s the dialog that Serer 2003 and Server 2008 make you respond to when you reboot or power down the server.  As Rick noted, usually the only time that you need to reboot a Windows Server is when you install an update from Microsoft.  It’s collecting information that you’ll never use.  You can disable that dialog by making a change in the local computer Group Policy.

To disable the dialog, do the following:

• Run the Group Policy Object Editor by typing “gpedit.msc” from the “Run…” dialog.
• Navigate down to Local Computer Policy\Computer Configuration\Administrative Templates\System
• Double-click on “Display Shutdown Event Tracker” and click on the “Disabled” radio button
• Click the “Ok” button to close the dialog with the new setting.
• Close the Group Policy Object Editor.

This will work for both Server 2008 and Server 2003.

Ack! The Windows Installer does not permit installation from a Remote Desktop Connection

I'm testing a installer that I had migrated from Wise For Windows to InstallAware. I testing the installer from inside a virtual machine. I used do it with VMware Workstation, but now I'm using virtual machines hosted on our ESX server. That's usually much faster and doesn't my bog down my development machine.

I connected to a virtual Server 2003 session using Terminals. If you spend anymore of time using Remote Desktop, then you'll want Terminals. It lets you have multiple sessions open in a single instance of the client by displaying each session in a tab. In addition to RDP, it supports VNC, Telnet/SSH, and a few other protocols. And it's an open source project, you can't beat the price tag.

With a RDP connection, you have the ability to automagically have the remote connection access your local resources (drives, printers, serial ports, etc). I was using the local access to disks to allow the remote connection to access my hard drive. I figured that would be a quick way to compile the installer on my local machine and run it remotely through the RDP connection.

Or so I thought. As a prerequisite for this app, I need to install the ASP.NET 2.0 AJAX Extensions. That comes as a Windows Installer .msi files. When I ran that .msi, I got the following error message:

In other words: FAIL. To add insult to injury, that's not even a standard Windows error dialog. With most Windows error dialog boxes, you can press Ctrl-C and the contents of the dialog box will be copied to the clipboard. You'll get all of the information from the dialog, something like this (from a different installer):

---------------------------
Microsoft .NET Framework 2.0 SP1 Setup
---------------------------
The Windows Installer package:

c:\c6b28b8b6e56383fbc455e9977dd00\vs_setup.msi
could not be opened.
 
Choose Retry to try again. Choose Cancel for exit setup.
---------------------------
Retry   Cancel
---------------------------

That's very handy for reporting errors or for researching with the text from the dialog. I hate it when I see a bug logged in our internal bug tracking system that has embedded a screen shot of an error message. They screen shot the whole page (hello? Alt-Prtscn anyone), save the image, then attach it as a file attachment. Instead, they have press CTRL-C and then CTRL-V and be done with it. Rant over, back to original rant.

For some reason, the AJAX installer team chose not to follow that convention. So I went to Google and manually typed in the text of the error message (Oh, the huge manatee!) and start viewing the results. Sure enough, it's in the MS Knowledge base as 927063. Windows Installer does not allow installs in Server 2003 from a RDP connection shared drive. When you allow access to your local C: drive to the remote session, it sees it as \\TSClient\c and flat out disallows installs from anything in the \\TSClient namespace. This was determined to be a security risk and the tssclient blocking was added Windows Installer 2.0 at the time of the Windows Server 2003 release.

This KB article lists two resolutions, use the standard UNC notation to reference that drive or map a drive letter to that location. To that list, I'll a third option. Copy the file from the \\tsclient share to the remote desktop and run it from there. For one off tasks, that's usually faster than accessing a UNC named object.

Side note: While writing this post, I read on the Terminals home page on CodePlex that Microsoft will be removing the ability to connect to the console session through the RDP protocol in version 6.1. Being able to connect to the console is a little known feature of the RDP client, mstsc.exe. I use it when people leave their RDP sessions hanging on a 2003 Server box that only has the admin remote connections enabled. I can connect over the console session and blow away the left over sessions. I can query and kill the remote sessions via the command line, but sometimes you just need one session open. If you want to see this feature left in the RDP stack, place your vote here.

How to identify who has a terminal session and how to kill it

Having the ability to use a terminal service (aka Remote Desktop) session to manage a Windows Server (2000, 2003, and 2008) is very useful.  If you don't have a Terminal Services license installed, you are limited to to two active sessions (plus a bonus connection that I'll get to in a minute).  If a person disconnects from a session without logging out, it can leave that session running.  That allows you to start a long running task and come back to it later, but it does use up one of the available connections.  If both sessions are being used, you will not be able to create a new terminal service connection to the server.  At this point, you have three options:

Yell down the hallway and ask "Who has a connection to server XYZ".  This never works because either the person who left the connect forgot about it or didn't realize that he (or she) was supposed to logout.  The other problem is that you could be working from home and the only thing that the yelling accomplishes will be to attract your dog and your child, both of which will be looking for cookies.

Use the command line tools to identify the open sessions and kill one of them.  There are two tools, qwinsta and rwinsta.  If you run "qwinsta /?" from a command shell, you will get the following:

qwinsta /?
Display information about Terminal Sessions.

QUERY SESSION [sessionname | username | sessionid]
              [/SERVER:servername] [/MODE] [/FLOW] [/CONNECT] [/COUNTER]

  sessionname         Identifies the session named sessionname.
  username            Identifies the session with user username.
  sessionid           Identifies the session with ID sessionid.
  /SERVER:servername  The server to be queried (default is current).
  /MODE               Display current line settings.
  /FLOW               Display current flow control settings.
  /CONNECT            Display current connect settings.
  /COUNTER            Display current Terminal Services counters information.

                                 

If you run "rwinsta /?", you get the following:

rwinsta /?
Reset the session subsytem hardware and software to known initial values. 
RESET SESSION {sessionname | sessionid} [/SERVER:servername] [/V] 
  sessionname         Identifies the session with name sessionname.
  sessionid           Identifies the session with ID sessionid.
  /SERVER:servername  The server containing the session (default is current).
  /V                  Display additional information.

For the sample server XYZ, you would run "qwinsta /server:xyz"  That will return something like:

 SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE
 console                                     0  Conn    wdcon
 rdp-tcp                                 65536  Listen  rdpwd
                   gatesb                    1  Disc    rdpwd
 rdp-tcp#93        jobss                    3  Active  rdpwd

From that output, we can take one of the IDs that was returned for the remote sessions and use rwinsta to kill that session.  You would use something like:

rwinsta 1 /SERVER:xyz

And that will terminate that session, allowing you to open a new session.  You will need admin rights to run that command, but if you are using the admin terminal service connections to the server, then you would already have the necessary access rights to the server.

There is a third option, you can connect to the console session.  This is the bonus option that I had referred to earlier.  This is the session that you would get if you were physically in front of the server and were logging in on the server's mouse and keyboard.  You can specify the console session as a command line parameter to the remote desktop client, mstsc.exe.  The following syntax can be used to connect to the console session of a server:

mstsc /console

That feature will work with Server 2003 and later.  On some machines, qwinsta and rwinsta may have been renamed to query.exe and reset.exe, respectively.

[Updated at 2:42 pm]
Steve listed an alternative to qwinsta and rwinsta on his blog.  He uses quser.exe and logoff.exe, which provide pretty much the same functionality.  On my machine, quser.exe was buried in c:\windows\system32\dllcache, which was odd.  I wonder why it wasn't in system32?  quser has an advantage over qwinsta, it lists the logon time and idle time for each session.  That gives you a little more data when you have to kill someone session and you can't determine which one must die.