Bare Metal Restore is a restore process when the whole machine is being restored. Usually this
type of restore is performed after a complete hardware failure or hardware upgrade.
You should have a backup of the machine’s System State and Services Database. When you
restore the System State, Services Database and Operating System files, everything must be
selected and restored in one step (at the same time) because a reboot is required immediately.
Microsoft recommends using the same hardware for the destination machine.
- You can restore Windows machines to different hardware.
Switching between different computer types (ACPI to standard computer type and vice versa) is not allowed.
1. Determine your computer type:
Before starting the restore you can check your computer type. Follow these steps:
Click Start, point to Settings, click Control Panel, and then double click System.
Click the Hardware, and then click Device Manager to view what is listed under the computer
Here are the descriptions of the computer types and the associated hal.dll:
- ACPI Multiprocessor PC – halmacpi.dll
- ACPI Uniprocessor PC – halaacpi.dll
- Advanced Configuration and Power Interface (ACPI) PC – halacpi.dll
- MPS Multiprocessor PC – halmps.dll
- MPS Uniprocessor PC – halapic.dll
- Standard PC – hal.dll
- Compaq SystemPro Multiprocessor or 100% Compatible – halsp.dll
There are other types available but that would require Hardware vendor specific installation
(involving customized hal.dll).
2. Restoring from one computer type to another:
In some cases it is necessary to perform bare metal restore to a machine of different type. In this
case after successful restore, after the reboot you will not be able to start your machine.
Regardless what backup software you are using, your computer would not start at all or would not
Asigra Cloud Backup™ software has a solution for this problem:
- DS-Client will automatically save some critical files in order to preserve them. These are saved with an extra extension, in the format *.asigra-date-time. The files are – hal.dll, ntoskrnl.exe, ntkrnlpa.exe, kernel32.dll, ntdll.dll, win32k.sys, winsrv.dll, setup.log (in \WINNT\repair directory), and boot.ini.
- After the restore is finished, reboot the target computer.
- If your computer boots normally, no intervention is required. If your computer does not boot, or crashes, follow the steps outlined below:
- Reboot the computer from the Windows installation CD, and start a repair process using the recovery console.
- At the command prompt, change to the system32 directory (by typing cd system32), and type dir *.*.asigra*
- You should see the 7 saved files. Copy each one of them to their original name. For example if it is hal.dll.asigra-022403-0800, you should type copy hal.dll.asigra-022403-0800 hal.dll. Confirm the overwrite and repeat with the rest of the files.
- Type cd dllcache. Type dir *.*.asigra*. You may see 2 more files. Copy them to their original names.
- Change to the root of C:\ drive by typing cd \
- Type dir *.*.asigra*. You will see one file. Copy it to the original name (boot.ini).
- Change to C:\WINNT\repair by typing cd \winnt\repair. If the %SystemRoot% is located on a different drive or has a different name, move it to the proper location.
- Type dir *.*.asigra*. A file is displayed, copy it to the original name (setup.log). You will need this file if you need to perform repair.
- After successfully copying all the files type exit, which would reboot the machine. Boot normally, and your machine should be up and running.
There would be a rebuild of the plug and play database, and you may be prompted to provide drivers for the new hardware found. Follow the instructions on the screen. When prompted to reboot, select NO and finish installing all drivers. Set the TCP/IP details for your network adapter(s).
Now you have to fix your computer type. If you did not check the computer type of the destination machine (the one that you are restoring to), you can find out the type by checking the properties of the hal.dll. Open your Windows explorer and go to %SystemRoot%\system32 (%SystemRoot% is usually located in C:\WINNT). Locate the file hal.dll with the additional asigra extension. It could be like hal.dll.asigra-022403-0800. Right click on it and select properties. Click Version, and from Item name, select Internal name. In the Value field you would see the original file name. In step 1 above there is a description for each computer type and its corresponding hal.dll.
Now you have to change your computer type to the right one (if it is not already so). Click Start,
point to Settings, click Control Panel, and then double click System. Click Hardware, and then
click Device Manager to view what is listed under computer. Right click on the computer type,
select Properties, and select Driver. Click Update driver. Click the radio button Display a list of
the known drivers for this device so that I can choose a specific driver and click Next. Select
the right model for your computer (the one that you discovered by checking the original hal.dll
properties) and click Next. Finish and reboot the system when prompted.
3. Restoring Active Directory in a multiple server tree.
Active directory is part of the System State and can be restored only as a System State restore. System State would restore the registry as well. There are 2 types of AD restore – normal and authoritative. The AD objects restored through normal restore, would be overwritten by the AD replication. The restored objects would have their original update sequence number. These USNs are used by the replication process to detect and propagate AD changes among the servers in the tree. Because of this the restored data would look old to the AD replication and the data would never get replicated. In fact the replication process would overwrite it. When is the normal (nonauthoritative) restore useful? It is good for single server trees, or when you want to restore the registry, but not to overwrite the Active Directory.
Microsoft has a default tombstone lifetime (DTL) value in an Active Directory forest which defines the number of days that a domain controller preserves knowledge of deleted objects. This value also defines the useful life of a system state backup that is used for disaster recovery or installation from backup media.
Active Directory protects itself from restoring data that is older than the tombstone lifetime by disallowing the restore. The tombstone lifetime is stored in the tombstoneLifetime attribute of the object CN=Directory Service, CN=Windows NT, CN=Services, CN-Configuration, DC=ForestRootDomain. In a forest that is created on a domain controller that is running Windows Server 2003 without Service Pack 1 (SP1), the default tombstone lifetime is 60 days. In a forest that is created on a domain controller that is running Windows Server 2003 with SP1, Windows Server 2003 with Service Pack 2 (SP2), or Windows Server 2003 R2 or Windows 2008, the default tombstone lifetime is 180 days. Because the tombstone lifetime can be changed administratively, do not assume the default value. Be sure that you are aware of the tombstone lifetime that is in effect in your forest.
For more information on this topic, refer to the following Microsoft Knowledge Base articles:
However in case you need to restore an older version of the Active Directory, perform an authoritative restore. Following is a description of each restore type:
Authoritative restore - Select Authoritative restore in the last screen of the Restore Wizard. This will perform authoritative restore of both AD and FRS.
The following list of requirements must be met before you perform an authoritative FRS restore:
a) The FRS service must be disabled on all downstream partners (direct and transitive).
b) Events 13553 and 13516 have been logged in the FRS event log.
c) The computer that is configured for the authoritative restore is configured to be authoritative for all the data.
d) All other partners in the replica set must be reinitialized with a non-authoritative restore.
To reinitialize the partners with a non-authoritative restore, stop the FRS service, configure the BurFlags registry key, and then restart the FRS service. To do so:
- Click Start, and then click Run.
- In the Open box, type cmd and then press ENTER.
- In the Command box, type net stop ntfrs.
- Click Start, and then click Run.
- In the Open box, type regedt32 and then press ENTER.
- Locate the following subkey in the registry: HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
- In the right pane, double click BurFlags.
- In the Edit DWORD Value dialog box, type D2 and then click OK.
- Quit Registry Editor.
- Perform this for every partner.
After rebooting the machine you just restored, start the FRS service on all the partners by typing net start ntfrs in the command box. They will synchronize from the restored machine.
Normal restore - default - Authoritative restore is NOT selected. This will perform nonauthoritative restore for both Active Directory and NTFRS.
You can still perform Non-authoritative restore with DS-Client and then manually run ntdsutil. However this would not work if you are performing bare metal restore where the destination for restore doesn't have AD. If this is the case, let DS-Client perform authoritative restore. DS-Client is running several activities that you can not perform when you manually run ntdsutil.
Note: After successful restore you should reboot the machine. Once the machine is restarted the plug and play database is reinitialized and you may be prompted for a reboot. Please do not reboot immediately, wait and make sure the Active directory and FRS are synchronized. Replication may take some time before the restored data would be propagated. If you are testing authoritative restore – objects added to the AD after the backup, would not be removed from AD after the authoritative restore.
4. Restoring Active Directory on a server that is not the PDC when the PDC is missing.
There are some scenarios when you have to restore AD on a domain controller when the PDC is missing. In this case there are several steps that should be performed in order to get the AD in 100% running condition.
If the destination machine is a domain controller already, you have to boot into Directory Services Restore Mode. If the destination machine is a stand-alone Windows computer you can start the restore immediately.
Select Authoritative restore in the last screen of the Restore Wizard. This will perform authoritative restore of both AD and FRS.
After successful restore of the System State, reboot the computer when prompted. Please note that you may have to perform the steps outlined above in case you are restoring to different computer type.
These articles from Microsoft describe the whole process:
• 216498 - HOW TO: Remove Data in Active Directory After an Unsuccessful Domain Controller Demotion
• 248410 - Error Message: The Account-Identifier Allocator Failed to Initialize Properly
• 234790 - HOW TO: Find Servers That Hold Flexible Single Master Operations Roles
• 223787 - Flexible Single Master Operation Transfer and Seizure Process
Outlined below is the whole process:
4.1.Login to the restored machine (after the normal reboot) and start command prompt.
- Type domain management
- Type connections.
- Type connect to server ServerName (where ServerName is your current computer name).
- Type quit.
- Type select operation target.
- Type list roles for connected server.
The system will display a list of roles associated with the server.
- Type list sites and note the number for the site you are dealing with.
- Type select site # (where # is your site number. e.g. 0, 1, ...).
- Type list domains in site and note the domain number.
- Type select domain # (where # is your domain number. e.g. 0, 1, ...).
- Type list servers in site and note the number for the missing PDC.
- Type select server # (where # is your server number. e.g. 0, 1, ...).
- Type list naming contexts and note the number for the CN=Configuration.
- Type select naming context # (where # is your naming context number. e.g. 0, 1, ...).
- Type quit.
- Type quit.
- Type roles to take you to the fsmo maintenance: prompt.
Now seize all 5 rows. ntdsutil will attempt to safe transfer the roles, but the transfer will fail since the PDC is missing. Just ignore the errors, because seizure will succeed:
- Type seize domain naming master.
- Click Yes at the pop up message.
- Type seize infrastructure master.
- Click Yes at the pop up message.
- Type seize PDC.
- Click Yes at the pop up message.
- Type seize RID master.
- Click Yes at the message prompting you to synchronize and Yes to confirm the operation
- Type seize schema master.
- Type quit.
- Type quit to exit ntdsutil.
4.2.Use ADSI edit to delete all references to the missing server.
This utility is free and is located on the Windows Server installation CD. It is in \support\tools. Just install the tools.
Start ADSI Edit. If you launch ADSI edit immediately after login, an error may occur saying that the domain does not exist. Wait a minute or so and try again.
- In the Domain NC... folder, browse until you reach OU=Domain Controllers. Locate the missing server and delete it. Redo the delete if you get an error or partial delete.
- In Configuration Container..., browse until you reach CN=Sites, CN=SiteName - CN=Servers. Locate the missing server and delete it.
The last step is to set the Global catalog. In Active Directory Sites and Services browse the site until you reach NTDS settings for the server that you restored. Right click NTDS Settings, select Properties, select Global Catalog, click Apply, and close this dialog box.
4.3.Reboot the server.
4.4.Examine the logs for any errors.
If there are errors, you may have incompatible hardware or device drivers. Usually the error would give you an indication what the problem is and you must be able to solve them.
4.5.Your server is now ready.
Note: If there are no other domain controllers to synchronize with, you will have problems. For an explanation of how to fix this, refer to the next section 5 (Restoring Active Directory from a multi server to a single server environment, or when the rest of the domain controllers are missing).
5. Restoring Active Directory from a multi server to a single server
environment, or when the rest of the domain controllers are missing:
You will have SAM errors if other domain controllers are missing. If you do not plan to ever start the other controllers, then you should remove them from Active Directory. Use ADSI Edit as explained in step 4 above.
From Active Directory Sites and Services delete Connection from NTDS Settings. After Service Pack 3, the FSMO role holder would not assume its FSMO role unless it had successfully completed at least one sync. Microsoft changed this in order to avoid multiple FSMO owners in a domain, and to prevent the Domain Controller from issuing duplicate RIDs.
As described in the previous steps if you seize the RID Master role it will not become authoritative until it synchronizes with another DC.
During disaster recovery where you restore only one domain controller from backup, or when you remove domain controllers from AD, you may get The account-identifier allocator failed to initialize properly... errors in the System log. The error would be from source SAM and Event ID 16650. Dcdiag may report problems with RID Manager or corrupted data.
There are 2 solutions:
a) You can restore another domain controller, or
b) You can delete the replication links
In case you want to keep only one domain controller, you have to delete the replication links, otherwise the domain controller is not fully operational.
Following are the instructions for deleting the replication links:
1. You need to use the repadmin tool. It is part of the Windows Support tools. The installation of the tools is located in \SUPPORT\TOOLS on the Windows CD.
2. Open the command prompt and type repadmin /showreps /v.
3. Find the guid-based-dns-name of replica partner, which is displayed after Address: of the deleted partner.
4. Following is an extract from repadmin:
C:\>repadmin /showreps /v
DSA Options : IS_GC
objectGuid : a089478f-cffb-409f-b74b-addb83a6e93e
==== INBOUND NEIGHBORS ======================================
DEL:b91cd853-6af0-4c3a-9586-b5dcc8f489f7 (deleted DSA) via RPC
ntdsDsa invocationId: 8994f8c1-f71e-454c-ad3a-17b119621381
WRITEABLE SYNC_ON_STARTUP DO_SCHEDULED_SYNCS
USNs: 3518/OU, 3518/PU
5. In the above example, the FQDN is spdnt4.local and the "guid-based-dns-name of replica partner" is "a48650dc-8ed0-4363-8c25-b41553f9248d._msdcs.spdnt4.local"
6. The restored server is called SPEEDYNT4 and the deleted partner - TR1.
7. Now you can delete the replicas. The syntax is:
repadmin /delete <naming context> <restored server name> <guid-based-dnsname of replica partner> /localonly
8. <naming context> would be for the Schema, Configuration and Domain.
9. In our example to delete the links for the schema we would type:
repadmin /delete CN=Schema,CN=Configuration,DC=spdnt4,DC=local speedynt4.spdnt4.local a48650dc 8ed0-4363-8c25- b41553f9248d._msdcs.spdnt4.local /localonly
10. To delete the links for Configuration we would type:
repadmin /delete CN=Configuration,DC=spdnt4,DC=local speedynt4.spdnt4.local a48650dc-8ed0-4363 8c25- b41553f9248d._msdcs.spdnt4.local /localonly
11. To delete the links for Domain we would type:
repadmin /delete DC=spdnt4,DC=local speedynt4.spdnt4.local a48650dc-8ed0- 4363-8c25 b41553f9248d._msdcs.spdnt4.local /localonly
12. Reboot the server after deleting all the replication links.
13. Check the System Log after the reboot to make sure there are no errors from source SAM.
6. Common mistakes:
- Slow clients logins
- Mis-configured DNS, DHCP
- If the missing server is your PDC, and also your main DNS and DHCP server,
your client computers may experience slow logins or errors when trying to login to the domain. If you are using fixed IP addresses, make sure the clients DNS settings are correct. Check your DHCP server for proper settings.
After performing BMR of a Windows machine, the computer fails to start and displays the following
"Windows could not start because of a computer disk hardware configuration problem. Could not read from the selected boot disk. Check boot path and disk hardware."
- The computer fails to boot because of a different system disk configuration between the original backed up computer and the target restore machine.
1. Perform an alternate restore of only the boot.ini from the Windows BMR backup set. Compare this file with the boot.ini of a freshly prepared target restore machine. If they are different, save a copy of the target restore machine’s boot.ini (e.g. boot.ini.original), perform the BMR, then before restarting replace the restored boot.ini with the (i.e. boot.ini.original).
2. Restart the computer. If it still fails to start, perform the file renaming steps of the 7 automatically saved files described in this Knowledge Base Article’s section 2