In-Depth
From the Trenches: Move Seamlessly from One Processor to Many
How do you get NT 4.0 to recognize your second processor if it won't even boot up?
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.
- Make, verify, and test a full system backup; update
the ERD.
- Bring down the server.
- Install the new processor as described in the hardware
documentation. Verify that the hardware is recognizing
and initializing the additional processor.
- 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)
Processor |
Entry |
MPS (Multiprocessor
Specification) Multiprocessor PC* |
"HALMPS.DLL",
"1a01c" |
Compaq SystemPro
(or compatible) Multiprocessor |
"HALSP.DLL",
"0f337" |
* Replaces HALAPIC.DLL |
|
|
|
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)
Processor |
Entry |
MPS (Multiprocessor
Specification) Multiprocessor PC* |
"HALMPS.DLL",
"1a062" |
Compaq SystemPro
(or compatible) Multiprocessor |
"HALSP.DLL",
"15a34" |
* Replaces HALAPIC.DLL |
|
|
|
- Save the modified setup.log in \%systemroot%\repair.
- 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.
- 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.