CertCities.com -- The Ultimate Site for Certified IT Professionals
Free CertCities.com Newsletter via E-mail Share share | bookmark | e-mail
  Microsoft®
  Cisco®
  Security
  Oracle®
  A+/Network+"
  Linux/Unix
  More Certs
  Newsletters
  Salary Surveys
  Forums
  News
  Exam Reviews
  Tips
  Columns
  Features
  PopQuiz
  RSS Feeds
  Press Releases
  Contributors
  About Us
  Search
 

Advanced Search
  Free Newsletter
  Sign-up for the #1 Weekly IT
Certification News
and Advice.
Subscribe to CertCities.com Free Weekly E-mail Newsletter
CertCities.com

See What's New on
Redmondmag.com!

Cover Story: IE8: Behind the 8 Ball

Tech-Ed: Let's (Third) Party!

A Secure Leap into the Cloud

Windows Mobile's New Moves

SQL Speed Secrets


CertCities.com
Let us know what you
think! E-mail us at:



 
 
...Home ... Editorial ... Tips ..Tips Article Friday: April 4, 2014


Move Seamlessly from One Processor to Many
How do you get Windows NT 4.0 to recognize your second processor if it won't even boot up?

by Douglas Dickerson - courtesy of Microsoft Certified Professional Magazine

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)

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
  1. Save the modified setup.log in \%systemroot%\repair.
  2. 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.
  3. 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.


Douglas Dickerson, MCSE+Internet, MCT, CNA, A+, Network+, is a Technical Education Instructor with Levi, Ray, & Shoup Inc. in Springfield, Ill. He has been working in IT since 1991 and has supported everything from stand-alone PCs to high-end networks running multiple platforms. You can reach him at .

There are 94 CertCities.com user Comments for “Move Seamlessly from One Processor to Many”
Page 1 of 10
10/11/00: Francois says: This is the type of articles and sites that adds value to the industry. Thank You. Francois CNE, MCSE
10/12/00: Mark says: Great and accurate information. I have been through this myself. You will love the changes made in Windows 2000. I recently added a second Pentium Pro 200 to an old Proliant 2500 that is currently running Windows 2000 Advanced Server. The upgrade was simply and painlessly accomplished through Device Manager by updating the driver on the computer itself. Reboot and all is well.
10/18/00: Sal says: Thank you for the information above. You've just help me cut another corner for Multi-processor upgrade. At least another 15 minutes. We had purchased Dual Processor boards with out the second processor for high end AutoCad Engineers. We later started installing the second processor where the uptomp.exe didn't work at all. Of course I had a learning curve and the manual upgrade article helped alot. I have had great success by slaving the hard drive to another NT system and copying over the files neccessary and modifying the setuplog.txt file. I actually created a batch file to do all my file transfer (copy) and then attrib the setuplog.txt and re-attrib when done. I had three different folders for Service Pack 4, 5 and 6, depending on which version on the machine. Now I will not even take out the hard drive with your method. Thanks again
5/31/02: Florian Cambot from Cholet - France says: A very professionnal & efficient article, just the kind µSoft should write....
1/15/03: Alex from Derby, England says: Brilliant article. Very clear, I followed it exactly as recommended and the upgrade went perfectly. What could have turned out to be a complete nightmare turned out to be quite a simple job thanks to your article.
1/17/03: Anonymous says: Good article. Thanks
6/26/03: Luca from Brescia (Italy) says: I've tested it on WinNT Terminal Server 4.0... Good article. Thanks
7/3/03: Jeff from SC says: I have also used this procedure to upgrade a Proliant 800 running WinNT TSE 4.0. It works great. Thanks for the helpful article.
8/2/05: Anonymous says: gr8
10/9/12: wholesale soccer jerseys from [email protected] says: http://elitebaltimoreravens.blogspot.com/ Ray Rice Jerseys
First Page   Next Page   Last Page
Your comment about: “Move Seamlessly from One Processor to Many”
Name: (optional)
Location: (optional)
E-mail Address: (optional)
Comment:
   

-- advertisement (story continued below) --

top