How to perform a Bare Metal Restore of Windows (ALL VERSIONS)

Modified on Sat, 23 Sep, 2023 at 4:25 PM

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. For more information you can check Microsoft’s knowledge base article number 237556.

Determining 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 branch.

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).

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 of what backup software you are using, your computer would not start at all or would not start properly.

DS-Client will automatically save some critical files 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 DVD, 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.
a) Change to the root of C:\ drive by typing cd \
b) Type dir *.*.asigra*. You will see one file. Copy it to the original name (boot.ini).
c) Change to 'C:\Windows\repair' or '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.
d) 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).
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.
a) Open your Windows explorer and go to %SystemRoot%\system32 (%SystemRoot% is usually located in C:\WINNT).
b) Locate the file hal.dll with the additional asigra extension. It could be like hal.dll.asigra-022403-0800.
c) Right-click the file and select properties.
d) Click Version, and from Item name, select Internal name. In the Value field you would see the original file name. There is a description for each computer type and its corresponding hal.dll.
Change your computer type to the right one (if it is not already so).
a) Click Start, point to Settings, click Control Panel, and then double click System.
b) Click Hardware, and then click Device Manager to view what is listed under computer.
c) Right-click the computer type, select Properties, and select Driver.
d) Click Update driver.
e) 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.
f) Select the right model for your computer (the one that you discovered by checking the original hal.dll properties) and click Next.
g) Finish and reboot the system when prompted.

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:

The FRS service must be disabled on all downstream partners (direct and transitive).
Events 13553 and 13516 have been logged in the FRS event log.
The computer that is configured for the authoritative restore is configured to be authoritative for all the data.
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. The following are the detailed steps, which you need to perform for every partner:

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:
HKEY_LOCAL_MACHINE\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.

• 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 non-authoritative 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.

Please note that replication may take some time before the restored data would be propagated. If you are testing authoritative restore – please note that objects added to the AD after the backup would not be removed from AD after the authoritative restore. For more information see Microsoft’s knowledge base article 216243.

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 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.

NOTE: 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.

1. Log on to the restored machine (after the normal reboot) and start command prompt.

2. Start ntdsutil.

3. Type domain management.

4. Type connections.

5. Type connect to server ServerName (where ServerName is your current computer name).

6. Type quit.

7. Type select operation target.

8. 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.

9. Type select site # (where # is your site number. e.g. 0, 1, ...).

• Type list domains in site and note the domain number.

10. 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.

11. Type select server # (where # is your server number. e.g. 0, 1, ...).

• Type list naming contexts and note the number for the CN=Configuration.

12. Type select naming context # (where # is your naming context number. e.g. 0, 1, ...).

13. Type quit.

14. Type quit.

15. Type roles to take you to the fsmo maintenance: prompt.

16. Seize all 5 rows. ntdsutil will attempt to safe transfer the roles, but the transfer will fail since the PDC is missing. Ignore the errors because seizure will succeed.

a) Type seize domain naming master.

b) Click Yes at the pop up message.

c) Type seize infrastructure master.

d) Click Yes at the pop up message.

e) Type seize PDC.

f) Click Yes at the pop up message.

g) Type seize RID master.

h) Click Yes at the message prompting you to synchronize and Yes to confirm the operation

i) Type seize schema master.

j) Type quit.

k) Type quit to exit ntdsutil.

17. Use ADSI edit to delete all references to the missing server.

18. Install the tools.

19. 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.

20. In the Domain NC... folder, browse until you reach OU=Domain Controllers.

21. Locate the missing server and delete it. Redo the delete if you get an error or partial delete.

22. In Configuration Container..., browse until you reach CN=Sites, CN=SiteName - CN=Servers. Locate the missing server and delete it.

23. Set the Global catalog:

a) In Active Directory Sites and Services browse the site until you reach NTDS settings for the server that you restored.

b) Right click NTDS Settings, select Properties, select Global Catalog, click Apply, and close this dialog box.

c) Reboot the server.

d) 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.

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 paragraph 5 (Restoring Active Directory from a multi server to a single server environment, or when the rest of the domain controllers are missing).

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 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:

Restore another domain controller
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.

The instructions for deleting the replication links using the repadmin tool are as follows:

You must use the repadmin tool.

Open the command prompt and type repadmin /showreps /v.
Find the guid-based-dns-name of replica partner, which is displayed after Address: of the deleted partner.

Following is an extract from repadmin:

------------------------------------
C:\>repadmin /showreps /v
Default-First-Site-Name\SPEEDYNT4
DSA Options : IS_GC
objectGuid : a089478f-cffb-409f-b74b-addb83a6e93e
invocationID: a089478f-cffb-409f-b74b-addb83a6e93e


==== INBOUND NEIGHBORS ======================================
CN=Schema,CN=Configuration,DC=spdnt4,DC=local
Default-First-Site-Name\TR1
DEL:b91cd853-6af0-4c3a-9586-b5dcc8f489f7 (deleted DSA) via RPC
objectGuid: a48650dc-8ed0-4363-8c25-b41553f9248d


Address:
a48650dc-8ed0-4363-8c25-b41553f9248d._msdcs.spdnt4.local
ntdsDsa invocationId:
8994f8c1-f71e-454c-ad3a-17b119621381
WRITEABLE SYNC_ON_STARTUP DO_SCHEDULED_SYNCS
USNs: 3518/OU, 3518/PU
------------------------------------

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"

The restored server is called SPEEDYNT4 and the deleted partner - TR1.

3. Delete the replicas. The syntax is:

repadmin /delete <naming context> <restored server name>

<guid-based-dns-name of replica partner> /localonly

<naming context> would be for the Schema, Configuration and Domain.

a) In our example to delete the links for the schema we would type:

repadmin /delete

CN=Schema,CN=Configuration,DC=spdnt4,DC=localspeedynt4.spdnt4.local

a48650dc-8ed0-4363-8c25-b41553f9248d._msdcs.spdnt4.local / localonly

b) 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

c) 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

4. Reboot the server after deleting all the replication links.

5. Check the System Log after the reboot to make sure there are no errors from source SAM.

Common mistakes

Slow client 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.

Troubleshooting

Problem

After performing BMR of a Windows machine, the computer fails to start and displays the following message:

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.

Reason

The computer fails to boot because of a different system disk configuration between the original backed up computer and the target restore machine.

Solutions

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).
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