AD restore in test environment on different hardware

I think because you are trying to restore to different hardware, you are getting problems.

Try the following:

1. Install the OS on the new server.
2. Boot into DSRM mode and restore the system state.
3. Reboot into normal mode. If you get problems booting, then you will need to boot to the OS CD, and run a repair install on the system partition of the new server. This will re-assess the new hardware and configure the OS accordingly (a downside to this is that you will have to re-patch the server)
4. Reboot and you should be OK. You may still have to re-install certain PnP drivers such as video/NIC etc.

If you are looking for a built-in solution, try an ASR backup. This allows for restore to different hardware (although your disk configuration will need to be of the same capacity/config). It uses the OS CD during restore to ensure the correct hardware drivers are installed.

Check these links out:
http://technet.microsoft.com/en-us/library/cc758365.aspx (MS info on ASR)
http://www.dell.com/downloads/global/power/ps1q04-pur_oe.pdf (Dell PDF document regarding ASR)

Skip the boot.ini and windows/repair step

Yes, agree. In DR testing I have never had to do this either.

I tried that before and the boot.ini file doesn't change anyways with a System State restore.  I just thought to include that step as it was listed in the MS document.

1. Install the OS on the new server.2. Boot into DSRM mode and restore the system state.3. Reboot into normal mode. If you get problems booting, then you will need to boot to the OS CD, and run a repair install on the system partition of the new server. This will re-assess the new hardware and configure the OS accordingly (a downside to this is that you will have to re-patch the server)4. Reboot and you should be OK. You may still have to re-install certain PnP drivers such as video/NIC etc.

I'l give this a try.  Do I need to install and configure AD/DNS/DHCP after the OS install or does this automaticaly happen with the System State restore?

Additionally, if you use a third party backup application such as Symantec's Backup Exec (I'm sure others do this too), there is an option to merge registries if you're restoring to an OS on different hardware.  

Slight modification to the steps (typing too quickly last night!):

1. Install the OS on the new server.
2. Boot into DSRM mode and restore the system state *AND THE SYSTEM PARTITION* together using ntbackup.
3. Reboot into normal mode. If you get problems booting, then you will need to boot to the OS CD, and run a repair install on the system partition of the new server. This will re-assess the new hardware and configure the OS accordingly (a downside to this is that you will have to re-patch the server)
4. Reboot and you should be OK. You may still have to re-install certain PnP drivers such as video/NIC etc.

In answer to your question, no, you don't need to install any additional components beforehand. Becuase you are restoring the system partition and system state, any services will be added by this.

Third party software aside, ASR is more suited to this process. You take a single backup of the system partition, and create a boot floppy disk using ntbackup. You then use this backup file and floppy disk during the install process, so it is a lot quicker and more reliable than the above method. Although it does mean you need a floppy disk drive (which I don't think your Proliant will).

Does your network have a single domain controller holding all 5 FSMO roles, or do you have more than one DC?

So I should restore the entire C: drive = system partition?  I thought because the hardware is so different for both systems, that would be a guarantee for failure.  But it looks like the repair install you mentioned in will fix those problems.  I will give that a try.

Our regular network has 2 DCs, 1 Exchange server and 2 other servers.

Yes, in order to fully restore the system you will need to do this. A system state backup itself includes a large number of system files in it, so you may get hardware issues from just this anyway.

If you are just restoring just one of the DCs to an isolated test environment, then you will need to do the following (on the test network):

1. Perform a metadata cleanup using ntdsutil on the server's copy of AD to remove any trace of the other DC it was connected to previously. See here for details: http://www.petri.co.il/delete_failed_dcs_from_ad.htm. You will also have to check AD Site & Services and DNS are correct.

2. If the server didn't previously hold all 5 FSMOs then you will need to seize them onto it. See here: http://www.petri.co.il/seizing_fsmo_roles.htm.

I have gotten a lot further with just a few obstacles along the way.  I performed the metadata cleanup and seized all the FSMO roles to the new server.  I also cleaned up all info to the other DC (that doesn't exist on the test LAN) in DNS but it seems there are still a few strange things going on.  The fixed IP is the same on the new test server as it is for the original one.

I have another server on the test LAN but can't join it to the domain.  It shows a message showing it can't find the DC for the domain.  It identifies the right server but just can't seem to find it.  When I ping the DC, it returns its valid IP address.

When I do a dcdiag, the following error shows up (see attached).  I am still researching this but any input to point me in the right direction will be greatly appreciated.

Thanks for your assistance so far bluntTony!
GC-error.JPG

So I can assume that DNS is running, the DC is looking to itself for DNS, and you can ping it fine by DNS name from the other server?

I take it that it's also safe to assume that this test network is physically isolated from your original network (as you're using the same network ID)? Sorry if I'm asking obvious questions :)

>  "It identifies the right server but just can't seem to find it..." - Do you mean that it can resolve it's DNS name but you can't actually ping it?

Is this DC configured as a Global catalog? Make sure it is, by going to AD Site & Services, right click the NTDS settings object for the server, properties, check the 'Global Catalog' box.

Just to ensure DNS is correct, on the DC, run:
ipconfig /flushdns
ipconfig /registerdns
net stop netlogon
net start netlogon

Then can you run the following commands on the dc:

dcdiag > dcdiagresult.txt
netdiag > netdiagresult.txt

Can you attach these two txt files so I can have a look? (edit out the server names etc. if you want).

So I can assume that DNS is running, the DC is looking to itself for DNS, and you can ping it fine by DNS name from the other server? I take it that it's also safe to assume that this test network is physically isolated from your original network (as you're using the same network ID)? Sorry if I'm asking obvious questions :)

I usually ask the obvious questions first as well. :) All of it is correct.

I checked the NTDS settings and the Global Catalog box was checked and I ran the DNS commands.  Attached are the files as requested.  The server name is IMISQL2K and IP address is 192.1.1.3.  (I didn't set this up so it may sound a bit odd.)



dcdiagresult.txt
netdiagresult.txt

I should have followed all the steps in the MS document because this procedure fixed my problem.  dcdiag doesn't show any error anymore and I can add the other server to the domain.  It looks good so far.  My next step is going to restore my Exchange Server to this test network.


In the restored domain controller, change the BurFlags value to d4. To do so, follow these steps:

   1. Click Start, and then click Run.
   2. In the Open box, type regedit, and then click OK.
   3. In the left pane, expand My Computer.
   4. Expand HKEY_LOCAL_MACHINE, and then expand SYSTEM.
   5. Expand CurrentControlSet, and then expand Services.
   6. Expand NtFrs, and then expand Parameters.
   7. Expand Backup/Restore, and then click Process at Startup.
   8. In the right pane, right-click BurFlags, and then click Modify.
   9. In the Value data box, type d4, and then click OK.

      Note If the restored domain controllers BurFlags value is not changed to d4, sysvol does not share out.

Actualy, those were not the instructions I followed.  I meant to refer to this document and these instructions:

http://support.microsoft.com/kb/249694/en-us

9. If the destination computer will be the first or only domain controller for the domain, follow these steps to authoritatively restore the File Replication service (FRS). This step must also be completed before the first restart after the restore operation is finished.

Warning Do not follow these steps if there are existing domain controllers in the domain.

   1. Click Start, and then click Run, type regedit, and then press ENTER.
   2. Locate the following registry subkey:
      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets
   3. Expand Replica Sets, identify the subkey that refers to the replica set DOMAIN SYSTEM VOLUME (SYSVOL SHARE).
   4. Then find the subkey of the Cumulative Replica Sets subkey that matches the name of the subkey from the previous step.
   5. Expand Cumulative Replica Sets, click the subkey that represents the Sysvol replica set, double-click BurFlags.
   6. In the Edit DWORD Value dialog box, type D4, and then click OK.
   7. Restart the computer.

Glad you got it sorted...

Not everything is quite running yet.  I am also restoring an Exchnage 2007 server but can't mount a database.  One of Microsoft's suggestions is to check the Domain Controller Security Policy but I am getting the following error:

Failed to open the Group Policy Object.  You may not have appropriate rights.
Details: The system cannot find the path specified.

Browse to your SYSVOL share (\\domain.local\SYSVOL) - in the 'Policies' folder you should have a number of folders with the GUIDs representing your group policies. If these aren't here, then that's your problem.
Using the D4 flag to reinitialise FRS will bring it back online, but if there was nothing in there it won't solve your problems. If this is the case, you can redirect a restore of the system state - this includes the SYSVOL share. You can then copy the group policy folders from the restored folder to the SYSVOL share on your test DC.
Let us know how you get on...

There is nothing in the sysvol folder, except a few subfolders.  So when I did the first restore of the System State and the C: drive, it didn't do it correctly.  I'll try another System State Restore as suggested.
imi.jpg

Right, you should have 'Policies' and 'scripts' folders under the magnetics.com folder.
When you do a system state restore - DONT restore it in place - do a redirected restore to an alternate location (from the same system state backup you rebuilt the server from).
This will place the folder in a seperate location, you can then drop the folders into the magnetics.com folder above.

When I boot into Directory Services Restore mode, I can't log on anymore because it doesn't take the account and password I use for the domain.  I tried a few other regular passwords we use but no luck.  Would it be asking for the password that was used when the server (the original server, not this test server) was first installed before it was a DC?

You need to directory services restore mode password to get into DSRM. This is specified when you promote the server in the first place. No biggie - If you boot back into normal mode, you can use ntdsutil to change this password (you don't need to know the old one to change it):
http://support.microsoft.com/kb/322672
While it's wise to do this, so you know your DSRM password, you don't actually need to go into DSRM to do the type of restore you want. You need to restore the system state to an alternate location. Are you using windows backup? At the bottom of the 'Restore and manage media' tab, there is a drop down saying 'Restore files to' - change this to 'Alternate Location' and select a target for the restore. You can then go to this folder with Explorer and copy the folders over into the SYSVOL share.

I'm leaving for the day so I'll check to see how you got on tomorrow. Good luck...

Brilliant, that worked great. :)  It didn't fix my Echange problem but that's a different subject.

Yes, dcdiag and netdiag come out clean.  To recap, these are all the steps for future reference..  Many. many thanks for your expert assistance!

1.      Install Windows 2003 Server 2003 R2 Standard x32 on the new server.
Volume License Install CDs
 CD Key: xxxxxxxxx
2.      Boot into DSRM mode (hold F8 on OS bootup) and restore the system state and C: drive together using ntbackup.
3.      Reboot into normal mode. If you get problems booting, then you will need to boot to the OS CD, and run a repair install on the system partition of the new server. This will re-assess the new hardware and configure the OS accordingly (a downside to this is that you will have to re-patch the server).
4.      Reboot and you should be OK. You may still have to re-install certain PnP drivers such as video/NIC etc.
5.      Perform a metadata cleanup using ntdsutil on the server's copy of AD to remove any trace of the other DC it was connected to previously. See here for details: http://www.petri.co.il/delete_failed_dcs_from_ad.htm
6.      Remove any entries from DNS pointing to the other DC on the live network
7.      You will also have to check AD Site & Services and DNS are correct.
8.       If the server didn't previously hold all 5 FSMOs then you will need to seize them onto it. See here: http://www.petri.co.il/seizing_fsmo_roles.htm
9.      If the destination computer will be the first or only domain controller for the domain, follow these steps to authoritatively restore the File Replication service (FRS). This step must also be completed before the first restart after the restore operation is finished.
Warning: Do not follow these steps if there are existing domain controllers in the domain.
   1. Click Start, and then click Run, type regedit, and then press ENTER.
   2. Locate the following registry subkey:
      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets
   3. Expand Replica Sets, identify the subkey that refers to the replica set DOMAIN SYSTEM VOLUME (SYSVOL SHARE).
   4. Then find the subkey of the Cumulative Replica Sets subkey that matches the name of the subkey from the previous step.
   5. Expand Cumulative Replica Sets, click the subkey that represents the Sysvol replica set, double-click BurFlags.
   6. In the Edit DWORD Value dialog box, type D4, and then click OK.
   7. Restart the computer.
10.      Check the Sysvol share (\\imi\sysvol) to make sure the Policies and Scripts subdirectories are there.  If they are missing, do another System Restore and restore files to a different location, not to their original location.  After the restore, copy the files to the \\imi\sysvol\magnetics.com directory.
11.      Run dcdiag and netdiag from the Support Tools to make sure no other errors show up.

Perfect solution for my issues.

Glad you got it nailed! Thanks for posting your complete solution. It'll be a help in future....