How to Speed up an Exchange 2000 or 2003 / DC reboot
The official advice from Microsoft is that you should not install Exchange 2000 / 2003 on a Domain Controller. Of course, in the real world, there are many Exchange DCs out there. Let’s face it; in a small organization, a request for another server ‘just to handle email’ is not always guaranteed to be received with a sympathetic response. Those of you that do have an Exchange DC (but not some SBS2003 servers*) in your charge, however, will have noticed that they take rather a long time to reboot. In such a situation, it’s easy to believe that it’s only your server that behaves like this, and that there’s something wrong with it. Well, actually, they all do that - it’s a known problem, caused by the fact that the server shuts down its Active Directory services before it shuts down the Exchange services. Exchange, of course, is heavily reliant on Active Directory; therefore it takes it a long time to shut down cleanly while it is waiting for responses from AD. Naturally, this wouldn’t be a problem if you never needed to reboot your server, but those automatic updates that insist on a reboot do seem to be arriving more frequently these days.
* Out-of-the-box SBS2003 actually has the opposite problem. A badly configured registry entry causes the server to shut down too quickly, with occasional store corruption. See MS KB article KB839262. http://support.microsoft.com/default.aspx?scid=kb;en-us;839262
There is, in fact, a Microsoft knowledgebase article KB555025 that discusses this issue. At the time of writing, it is located here: http://support.microsoft.com/default.aspx?scid=kb;en-us;555025. The article suggests either creating a batch file, or modifying a registry entry located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WaitToKillServiceTimeout
The article suggests that a suitable value for the registry can be found by experimentation. In order to test these suggestions, I am going to install a brand new server, and see what difference they actually make to the long shutdown time.
The server I am going to use has a fresh installation of Windows Server 2003, with the latest patches applied by automatic update. In this state, a shutdown takes only 45 seconds. It is a long time since I saw a server shutdown that quickly. I then installed Exchange 2003 (plus SP1) and then timed the shutdown again. This time it takes a little over 16 minutes! Not, perhaps, an eternity, but long enough to make you think about pressing that reset button – especially if you had needed to shut down a live server in the middle of a work day.
Let’s see what difference changing the registry key makes. The default value is 600000, which I assume represents 600000 thousandths of a second, or 10 minutes. I suppose you can only guess which value to choose, but a quick check of an SBS2003 registry (SBS is known to have a smaller value) reveals a value of 120000, i.e. 2 minutes. I change the registry value to 120000, and time the shutdown once more. The shutdown is a lot quicker this time, 195 seconds, and it is easy to see a relationship between this registry value and the reboot time. Unfortunately, one of the Exchange services (the MTA) fails when the system is back up and running. It starts easily enough manually, but the experience is not encouraging. Besides, MS do say that changing that registry key is not supported. It seems to kill the services dead, which is probably not a good idea if it can be avoided.
Let’s change the registry key back to its original value, and try shutting down the services (and then the server) using a batch file. Here are the contents of my batch file, which can be downloaded here http://www.leederbyshire.com/DL/ExShutdown.zip, or you can copy/paste the text into Notepad, and save the batch file yourself.
ECHO Please select...
ECHO R - Reboot
ECHO S - Shut Down
ECHO A - Abort Shutdown
ECHO Q - Quit
CHOICE /C RSAQ
IF ERRORLEVEL 4 GOTO END
IF ERRORLEVEL 3 GOTO ABORT
IF ERRORLEVEL 2 GOTO SHUTDOWN
IF ERRORLEVEL 1 GOTO REBOOT
IF ERRORLEVEL 0 GOTO END
net stop MSExchangeES /y
net stop MSExchangeIS /y
net stop MSExchangeMTA /y
net stop MSExchangeSA /y
net stop WinHttpAutoProxySvc /y
shutdown %PARAM% /t 10 /c "TO ABORT, RE-RUN BATCH FILE AND PRESS A"
The batch file first displays a menu on the screen that looks like this (figure 1):
Fig. 1: The Shutdown Menu
The menu text is produced by the lines that begin with ECHO. The key press is handled by the CHOICE … ERRORLEVEL section. Note that the ERRORLEVELs need to be listed in reverse numerical order.
The rest of the batch file does the actual shutdown. If you pressed R, the batch file will reboot the server; S will shut it down; A will abort a previous shutdown (maybe you’d earlier pressed R or S by mistake?); and Q just quits.
First, the services are stopped using NET STOP. You can actually stop the IS and MTA by just stopping the System Attendant (SA) on its own, but I prefer to do it explicitly. The order isn’t particularly important, except that the SA needs to be stopped after any other main Exchange Services.
After shutting down the services, the batch file runs shutdown.exe with parameters /t 10 (which causes a delay of 10 seconds) and a comment that it will display while waiting to shut down (in this case, the abort instructions). Shutdown.exe displays the dialog box shown in figure 2.
Fig. 2: The Shutdown Dialog
Note: You now have ten seconds to abort this shutdown. If you do want to abort, you must quickly re-run the batch file and press A to prevent the reboot from taking place (I had to be quick to get that screen shot). You will also need to run the Services utility and re-start the Exchange Services manually if you want to keep your server up and running.
Running the batch file shuts down the server in about 160 seconds. Not as good as the original 45 seconds, of course, but not that bad considering that about a minute was required shutting down the Exchange services alone. You also have the advantage of having the services shut down cleanly and in the correct order. It’s a shame that the Exchange setup program doesn’t ensure that this happens automatically; after all, Microsoft must know that Exchange does get installed on Domain Controllers, in spite of their advice to the contrary.
Check out a more recent article of mine that describes an improved method, which offers automation of the script, rather than manual execution.