NT migration to a new machine 1

[distancevector]

I need to migrate a NT server 4.0 to a new machine, different hardware. I am planning on installing the OS and apps from scratch and then migrating the data. I thought about using ghost but it is a totally different machine (different hardware). Does anyone have any easier ideas like pc-relocator but for NT server?

Thanks,

Jeremy

 

[ShackDaddy]

One thing you might consider is what I call a 'lobotomy'. It involves moving the HKLM\Software portion of the the registry over to the new server after the basic OS has been installed and the file structure has been copied over.

The service pack level, as well as MDAC version and other file-based environmental factors should be the same on both source and target system, and the drive letters and functional paths obviously would also need to be the same. I've done this a few times when migrating a full SQL install from a system with a dead motherboard to a new server with different hardware.

May not be the solution for you, but it's an option that's nice to have once in a while.

ShackDaddy

 

[Jackenator]

I'm currently involved in a project that requires migration of legacy NT 4.0 Server images to new hardware. So far, we are using a similar approach to the "lobotomy" method where we install and configure a fresh image of NT 4.0 Server (SP6a) on the new hardware, restore the legacy image from tape using a duplicate image of the newly installed OS that has been copied to a separate folder (WINNT.SOS in this case), then copy the following six files from SYSTEM32 of the newly installed system over to the restored legacy system:

Ntoskrnl.exe, Hal.dll, Kernel32.dll, Ntdll.dll, Winsrv.dll, Win32k.sys

Then, we copy the SYSTEM (not software) registry hive from the newly installed system over to the restored system. We are finding that this is necessary in order to avoid an inaccessible boot device BSOD during kernel mode. This method has worked successfully in regards to migration of the PDC, but has an issue with the application server we are testing. We have found that since installed application services are located in the SYSTEM hive (HKLM\SYSTEM\CurrentControlSet\Services), that the restored system is lacking application services (such as Siebel) as they are not defined in the system hive from the newly installed NT 4.0 image that we copied over to the restored image. We are attempting to export the missing keys from the production system and will import those into the restored system for testing. This will likely work, but we need to determine a more efficient method of doing this (we don't want to go searching for services on each machine targeted for migration manually).

I think the key here is to import the proper Compaq SCSI driver registry key into the system targeted for migration just BEFORE the system is backed up for migration so that when the system is restored on the new hardware, the registry already points to the correct SCSI driver. We're not sure, however, exactly what registry keys deal with the Compaq SCSI driver to that we can export them from a configured system for importation into the legacy system.

If these registry keys that pertain to the Compaq SCSI driver can be identified (we called Compaq and they weren't much help in this area) then we can "pre-seed" the legacy system with these keys before backing the legacy system up for migration to new hardware. If anyone knows exactly what keys we need to export in this case, it would be most helpful. Or, if there is another approach we should be taking, we would appreciate being enlightened. Thank you.

 

[Jpoandl]

Just a theory we have been playing with...
We are getting ready to do various Windows NT to Windows 2K migrations. We have a non-tested theory that just might work.


Hardware Migration Theory:

Based on similar hardware. For example, old hardware platform Compaq Proliant 5500. New hardware platform Compaq DL380.

Perform inplace upgrade from Windows NT 4.0 to Windows 2000.
Backup the server system to tape. Then restore the system to the new hardware. Windows 2000 should be able to autoconfigure itself to the new hardware platform. Our only concern is with the boot device.

again this hasn't been tested...and not really what you were looking for...seing how 2K is involved. But I thought I'd through this out there.

I can see what you guys are trying to accomplish. And believe the registry moves are the only way to accompish this task. I wish there was an easier, more straight forward, way of moving to a new hardware platform.

-thanks.. Joseph L. Poandl
MCSE 2000

If your company is in need of experts to examine technical problems/solutions, please check out

http://www.esavio.com

 

[Jackenator]

Thanks for the input Jpoand1. I think your approach will work due to the fact that you will be migrating a Win2K system to new hardware. Would love to do that in this case, but it appears that the customer does not have the capability to reinstall all of their apps! :O

Furthermore, not all of the apps support folks are confident that their apps are Win2K compliant. So if we want to get these old images over ot new hardware, we're going to have to devise a reliable method. Thanks again.

Jackenator

PS Would still appreciate more input on this if anyone has any suggestions.

 

[Jpoandl]

Jackentator,

Figured as much...Just thought I'd though a new idea out there..

Joseph L. Poandl
MCSE 2000

If your company is in need of experts to examine technical problems/solutions, please check out

http://www.esavio.com