Monday 25 February 2008

SBS & ShadowProtect - Some Hardware Independent Restore considerations

The Hardware Independent Restore (HIR) of ShadowProtect is a pretty neat feature.

It gives us the ability to take the OS image from an existing server and restore to a completely different set of hardware.

This feature may be needed if the existing hardware is no longer good for production or it may have failed beyond recovery.

Another use we have for the HIR, is to restore a production SBS box on a dedicated Xeon 3000 box here in the shop for our Swing Migrations.

One should not expect the SBS OS to come up happy after the HIR process has finished though. Many components within the old box are no longer in existence!

There are a number of post restore steps that need to be accomplished:
  1. Remove the previous server's NICs in the Device Manager
  2. Configure the new server's NICs with the appropriate IPs and network settings
  3. Rerun the CEICW
  4. Restore the previous Drive Letter arrangement
  5. Restore the previous share setup (if needed)
  6. Reboot
One of the first things we will encounter when we go to setup the IP addresses on the new NICs is this:

Microsoft TCP/IP

The IP address 192.168.xxx.xxx you have entered for this network adapter is already assigned to another adapter "The Previous NIC". "The Previous NIC" is hidden from the Network Connections folder because it is not physically in the computer. If the same address is assigned to both adapters and they both become active, only one of them will use this address. This may result in[sic] incorrect system configuration.

Do you want to enter a different IP address for this adapter in the list of IP addresses in the Advanced dialog box?
Many thanks to Chris Knight for pointing us in the right direction by commenting in a previous post SBS and Intel SE7520JR2 Warranty Replacement Experience about how to reveal hidden items in the Device Manager.

His comment with the methodology lead us to the following KB article: KB 31539: Device Manager does not display devices that are not connected to the Windows XP-based computer

To reveal the hidden NICs we need to get rid of:
  1. Start a command prompt
  2. set devmgr_show_nonpresent_devices=1 [Enter]
  3. start devmgmt.msc [Enter]
  4. View --> click on Show hidden devices
We will see the following in the Device Manager once we click the Show hidden devices:

Device Manager - Show hidden devices

We right click on the old physical NIC which is greyed out and "Uninstall". Note that the Miniport will not uninstall due to services still being tied to it. We do this for any previous NICs in the old server.

Once we have configured the IPs, rerun the CEICW, and rebooted the server, we will be live!

Some things to keep an eye on when doing a HIR to new hardware that will go into production:
  • Many new server boards do not have a parallel port on them, so one will need to remove the physical parallel port references in the registry to clear up the service did not start error associated with the Parallel Port service.
  • Make sure to run the new motherboard's setup CD for drivers and monitoring software
  • For Intel ProSet Adapter Teaming: Make sure to install the newest version of ProSet and validate or recreate the Team
Another thing to keep in mind: The OS will want to be reactivated due to the hardware change. If this newly restored box is going into the production environment, then by all means make sure that the activation process is completed before delivery.

If, however, as it is in our case, we only need the box for our SwingIt needs, we will not be activating the server. This gives us 72 hours to complete the portions of the Swing Migration that require the original SBS box. In most cases, that is lots of time! ;)

Oh, and one more thing: Crashing a newly configured SBS box after taking a full ShadowProtect image and restoring it to the same hardware and then putting it into production is good practice for your disaster recovery planning. Taking that same image and restoring it to different hardware is good preparation for the "phone call" and will greatly reduce the amount of stress in an already very stressful situation for the client.

UPDATE 2008-03-04: As a side-note observation: After firing up the temporary SBS box after the HIR, what a huge difference in performance there is between the same OS running on the old box and now on the temp one.

The old box is a P4 HT at 3.0GHz and the temp box is a Xeon 3070 at 2.66GHz.

The performance change really demonstrates how far superior the Core 2 technologies are over the old NetBurst ones.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists

*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.

7 comments:

Anonymous said...

Thanks Philip! Great info! I think I'll link to this blog if that's okay with you.

Incidentally, information on showing the hidden devices, and removing those which are no longer present, is covered in a whitepaper in the StorageCraft community download area:

http://forum.storagecraft.com/Community/files/folders/supportwhitepapers/entry156.aspx

David Moisan said...

I have moved SBS between machines a number of times.
I've found that I need to use a command line utility, devcon, http://support.microsoft.com/kb/311272 to completely remove all the old NICs

Anonymous said...

I thought everyone knew of the DEVMGR_SHOW_... parameter?

I'm just not sure how you cleaned up a person's registry without knowing this. No offense intended.

Here's the way I use the command. (I put this on EVERYONE'S computer)

Make it a permanent part of a computer by:
Start-RClick My Computer-Properties-Advanced Tab-Environment Variables-System Variables-New.
In the first box, type:
DEVMGR_SHOW_NONPRESENT_DEVICES
In the second box, type:
1

You can also enter another system variable:
DEVMGR_SHOW_DETAILS=1
(type it same way as above)

This will ensure the variable survives reboots.

There is a way to update the variables into memory without rebooting but I've not got that data close at hand.

(This post does not demean Phillip, I think he's great, actually.)

ZC1
Beta tester of "0"s and "1"s

Anonymous said...

Potential correction:

The parameter is:
DEVMGR_SHOW_DETAILS
The value is 1.
("type it same as above" was supposed to mean, in the same manner as the other parameter)

ZC1
Beta tester of "0"s and "1"s

Philip Elder Cluster MVP said...

Nate,

Yeah, I see that now.

I honestly did not look into the White Papers too much because in my mind the term is oriented more to marketing materials than technical documents. Might want to have a cache of "Technical Documents" instead. ;)

David,

Awesome link! Thanks for that.

ZC1,
No worries. If there is one thing I have learned in this industry ... a truism of sorts ... the more I know, the less I know.

I appreciate being corrected and updated! :)

I believe that one of the KB articles, can't remember if it is the XP or W2K one, demonstrates setting things up with environment variables.

Thanks very much for the comments folks!

Philip

Anonymous said...

Philip,

Since I did at least mention the DEVMGR_SHOW.... parameter, allow me to give you a helpful tip concerning Win98 boxes, possibly WinME, this parameter and removal of dead (ghost) device manager entries.

In XP, when you use the DEVMGR_SHOW... parameter, reboot, then proceed to prune the Device Manager list of ghosted items, you can prune anyway you want paying close attention to the advice of a previous poster (ie. leave Sound,video and game controllers section alone and leave NonPlug and Play section alone (unless you recognize an leftover PNP device). (for really good reasons too).

But....
In Windows 98 editions, Possibly WinME (I suspect the same about Win95), only prune the ghosted entries per section from the BOTTOM UP.
Example: If there are multiple ghosted drive entries in Disk Drives, expand the section and remove the items starting from the bottom of the list UP.

Why is this so?
Windows 98 editions are very finicky about removal of ghosted items and the OS gets really screwed up if this procedure is not followed.

I've been using this method since Win98 and when I violate it enough times, I end up having to reinstall the entire OS. (if I dont have a registry backup).

One day on some tech support board I was giving out this parameter when the next poster said "Oh by the way, only remove the entries starting from the bottom up", evidently I wasn't the only one who learned this.

ZC1
Beta tester of "0"s and "1"s

Anonymous said...

Ended up using this one on the weekend when virtualising a physical box - couldn't find the ShadowProt doc (even though I've used it several times before) so cheers!