10/1/2000 -- Let’s face it, the computer industry is evolving faster than most hardware budgets. New software requires much more processing power than that of even six months ago. For that reason, coupled with budgets that don’t allow the purchase of new servers each year, many companies are adding multiprocessor support to their Windows NT servers.

This has created many a headache for those of us in the trenches. uptomp.exe, the utility provided in the Windows NT 4.0 Resource Kit, is unreliable at best. Even with it, you still must contend with locating the updated files and modifying the %systemroot%\repair\setup.log file so that the next time you update or reapply the service pack, the server doesn’t lock up at the logon screen.

There’s a better way, as I’ll show you here. Building on details from a Microsoft KnowledgeBase article, you can let the NT Service Pack install do much of the work of the upgrade. Allow me to explain.

The Nightmare
My first multiprocessor upgrade was a six-hour nightmare. I gathered and thoroughly read as much information as I could find, then went on-site prepared to use uptomp.exe as described in KB article Q124541 (“Use uptomp.exe to Upgrade Single-Processor to Multiprocessor”). I knew the procedure inside and out and had a hard copy of the article with me. I verified the backup, did a test restore, and updated the ERD (emergency repair disk). I took down the server, dropped in the new hardware, and powered back up. So far, so good.

I verified the service pack level and expanded the appropriate service pack out to a folder on the server, since uptomp would require these files to upgrade the OS. I executed uptomp.exe and pointed it to the appropriate upgrade files. After the two minutes that seemed like an eternity, the process completed without reporting any errors. Success? I watched carefully during the reboot for any signs of the impending doom. The startup screen indicated, “Multiprocessor Kernel,” a positive sign. My heart raced as the green background appeared, then finally the splash screen saying “Press Ctrl-Alt-Del to Log On”. I felt like leaping for joy—until I pressed Ctrl-Alt-Del to log on and absolutely nothing happened. I reviewed my process. All steps were completed successfully, but my server was still locked up. I rebooted the server and watched again as the same thing happened. As soon as the logon screen popped up and the second processor began receiving threads, the server locked up. I tested everything I could think of but couldn’t get this machine back to life. I finally decided to restore the original OS from tape so I could step back and regroup. The restore was successful, and I had the server back to functioning on the single processor. I returned to my shop feeling like a failure. After nearly five hours of effort, the only accomplishment was installing 128M of RAM.

More research, however, yielded KB article Q156358, “How to Manually Add Support for a Second Processor.” The article makes the process seem simple and straightforward, but it isn’t. I followed the article’s procedure exactly, only to achieve the same results as with uptomp.

Inspiration Strikes
I was starting to grasp the theories involved; a bit of thinking resulted in a new theory. Doing a parallel install after adding a second processor causes NT 4.0 to detect and install multiprocessor support into the new install. If I were to do the parallel install and bring it to the service pack level of the original install, we could simply boot to the second installation and copy the appropriate files to the %systemroot%\system32 folder of the original system. Fortunately, the third time proved to be a charm, temporarily.

A few months later, I got a phone call from the server’s owner. He had attempted to re-apply the service pack following some networking changes only to have the server lock up at the logon screen. During my testing, I found that the startup screen no longer indicated “Multiprocessor Kernel.” At least this time I immediately knew how to get the server up again. Restoring from tape would have invalidated all of the configuration changes they had just made, so I simply performed another parallel install, applied the service pack, and copied over the appropriate files again. This got the server back online, but I still had to discover why re-applying the service pack caused the lockup. KB article Q168132, “After Applying Service Pack NT Reports Single Processor,” seemed to hold the key. Using this article as a reference, I updated the %systemroot%\repair\setup.log. I then reapplied the service pack without any problems.

I did several more upgrades using this “parallel-install” method. It works very reliably. The only failure was traced back to an incorrectly modified value in the setup.log. The downside of this method is the amount of time involved, since a server must be offline for anywhere from two to five hours to complete the upgrade. But it doesn’t have to be like that.

The Solution
With the help of Timothy Dubman, also an MCSE, I’ve developed a new procedure that through testing and real-world implementation has proven successful, reliable, and fast. I build on Q168132 and essentially make the Service Pack install do all the work.

The real benefit is that this procedure can be completed in less than 30 minutes (excluding hardware installation and system backup), thus reducing costs as well as headaches. The process is simple.

1. Make, verify, and test a full system backup; update the ERD.
2. Bring down the server.
3. Install the new processor as described in the hardware documentation. Verify that the hardware is recognizing and initializing the additional processor.
4. Restart the server. Remove the Read-Only attribute from %systemroot%\repair\setup.log and make a backup copy of it. As outlined in KB article Q168132, edit these six lines of the original setup.log so they read as follows.

For Windows NT 4.0:
\<%systemroot%>\system32\ntoskrnl.exe = “NTKRNLMP.EXE”,“e76ab”
\<%systemroot%>\system32\kernel32.dll = “KERNEL32.DLL”,“5b7f8”
\<%systemroot%>\system32\winsrv.dll = “WINSRV.DLL”,“37b4e”
\<%systemroot%>\system32\ntdll.dll = “NTDLL.DLL”,“59c19”
\<%systemroot%>\system32\win32k.sys = “WIN32K.SYS”,“132603”
\<%systemroot%>\system32\hal.dll = (see chart below or refer to KB article Q156358 for other processors)

For Windows NT 4.0 Terminal Server Edition:
\<%systemroot%>\system32\ntoskrnl.exe = “NTKRNLMP.EXE”,“fe754”
\<%systemroot%>\system32\kernel32.dll = “KERNEL32.DLL”,“700ee”
\<%systemroot%>\system32\winsrv.dll = “WINSRV.DLL”,“3e526”
\<%systemroot%>\system32\ntdll.dll = “NTDLL.DLL”,“62b31”
\<%systemroot%>\system32\win32k.sys = “WIN32K.SYS”,“140e95”
\<%systemroot%>\system32\hal.dll = (see chart below or refer to KB article Q156358 for other processors)

5. Save the modified setup.log in \%systemroot%\repair.
6. Apply or re-apply the current Service Pack (Service Pack 4 or greater). When you reboot following the service pack application, the OS should recognize and begin using the additional processor correctly.
7. Test. You can verify multiprocessor support by looking for “Multiprocessor Kernel” on the “Blue Screen of Life” during startup.

How It Works
The %systemroot%\repair\setup.log file is created during the initial installation of NT. It’s simply a record of the files installed with the operating system. The installation process automatically detects and installs the appropriate support for the number of functioning processors. Note that a fresh installation of NT 4.0 to a multiprocessor server will automatically install support for all the processors. When the OS is installed on a single processor server, the single processor files were copied and recorded in the setup.log. To use a second processor installed after the OS, the following six files must be updated:

• ntoskrnl.exe
• hal.dll
• kernel32.dll
• ntdll.dll
• winsrv.dll
• win32k.sys

When a service pack is applied to the server, update.exe checks the setup.log to determine which files to extract and replace. All the files required for multiprocessor support are included in Service Pack 4 and greater. By editing the setup.log file first, the update.exe of the service pack is instructed to extract and install the multiprocessor versions of the required files.

A Little Touch-up
This procedure allows your operating system to take advantage of a multiprocessor system, but some services and applications will also need to be modified to fully function with multiple processors. For example, Microsoft Proxy Server 2.0 requires that you replace the ipfltdrv.sys file before it will properly function in a multiprocessor environment. (The multiprocessor version is located in the \msproxy\i386\routing folder of the Proxy 2.0 CD.)

Although I’ve used this method successfully in production, I can’t guarantee anything. All environments are different, and you should always research and test any solution in your specific environment prior to implementation. This information applies to NT 4.0 running on an i386 platform. Although not as thoroughly tested, it should also work successfully on NT 4.0 Terminal Server Edition.

This article originally appeared in MCP Magazine, July 2000.