…………………… …………..……………………………………………………………………...... ……………………………………… …………………… …………..……………………………………………………………………...... ……………………………………… Network Frontiers Whitepaper Protecting Active Directory Active Directory has become a very critical piece of every Windows organization. So critical in fact, that tolerance to downtime for an Active Directory server is almost nil. And yet, most tape-based backup and restoration systems can take from half a day to over a day for restoration of an Active Directory server. By understanding your Active Directory environment, and employing the Symantec Recovery Environment, you can easily set up recovery point objectives of less than an hour or so.
Active Directory has become a very critical piece of every Windows organization. So critical in fact, that tolerance to downtime for an Active Directory server is almost nil.
And yet, most tape-based backup and restoration systems can take from half a day to over a day for restoration of an Active Directory server.
By understanding your Active Directory environment, and employing the Symantec Recovery Environment, you can easily set up recovery point objectives of less than an hour or so.
THE CRUCIAL ROLE OF ACTIVE DIRECTORY.................................................................... 3
UNDERSTANDING THE LAYERS WITHIN AN AD SYSTEM.............................................................. 4 BACKING UP YOUR DOMAIN CONTROLLER .................................................................................. 9 RESTORING A DOMAIN CONTROLLER.......................................................................................... 15 RESTORING THE DATA OF A DOMAIN CONTROLLER.................................................................. 21 RESTORING THE DATABASE OF A DOMAIN CONTROLLER......................................................... 31
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under § 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the copyright holder. Contact information is [email protected].
Limit of Liability/Disclaimer of Warranty: While the copyright holder, publisher, and author have used their best efforts in preparing this work, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be useable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
All trademarks are the property of their respective owners.
Regulatory requirements – whether Sarbanes-Oxley, California SB1386 or the Health Insurance Portability and Accountability Act (HIPAA) – require that your organization protect sensitive information at all times, regardless of where it is stored. The key to compliance is the ability to monitor and enforce security policies at all times – a task which poses challenges for many organizations. As a critical component of most network infrastructures, Active Directory is positioned to help meet many of these requirements with greater ease and fewer headaches. Active Directory provides a central service for administrators to organize network resources, manage users, computers, and applications. Many different objects can be stored in the Active Directory, including:
• Users • Groups • Security credentials such as certificates • System resources such as computers (or servers) and printers • Replication components, settings are themselves objects in the Active Directory • COM component configuration, which was stored in the registry in Windows
NT, is now stored in the class store in the Active Directory • Rules and policies to control the working environment
You can think about AD in one of two ways — as a key part of your network wherein you spend a lot of time designing and tweaking it’s architecture, or simply as another database that exists on a server in your organization (in larger organizations AD would be a distributed database system). As a database that exists on a server in your network, you should be following your best practices guidelines for backing it up and protecting it. As a key component of your network’s infrastructure, you should be planning on where it fits in the restoration chain in case you lose your network or building.
Each AD server, called a Domain Controller (DC) uses a three-layer model when creating and accessing Active Directory databases and records.
Directory System Agent
Database layer
Extensible Storage Engine
Active Directory model
Directory Systems Agent (DSA)
Let’s say that you want to access a server’s directory over your network. When you double-click one of the server’s within your Network Neighborhood, Active Directory is being accessed for verification of privileges, and therefore, the DSA is the first step in the access process. The DSA sits at the top of the three-layer AD model and creates an instance of the directory service, making it available for use. DSA also has the job of then communicating with the underlying layers as well as facilitating AD replication between servers.
The Database layer
The database layer of AD manages and interprets the database tables, and all of the parent-child relationships within the AD database structure. We’ll discuss the actual files that the database maintains below. For now, know that there are really only two tables within the database—the object table holds the database and the link table holds the relationship information.
The Extensible Storage Engine (ESE)
The ESE is the underlying engine that stores and reads AD data tables. Active Directory is a transacted database system that uses log files to support rollback semantics to ensure that transactions are committed to the database. Even though this is not a “high change rate” database, it is a database nonetheless. The files associated with Active Directory are:
• Ntds.dit, which is the actual AD database (DIT stands for Directory Information Table), grows as the database fills up. It contains both the object tables and the
link tables. Any change made to the database is also appended to the current log file, and its disk image is always kept up to date.
• Edbxxxxx.log is the current log file. When a change is made to the database, it is written to the Edb.log file first. When the Edb.log file is full of transactions (10 MB), it is renamed to Edbxxxxx.log (it starts at 00001 and continues to increment using hexadecimal notation). Since Active Directory uses circular logging, old log files are constantly deleted, once their transactions have been written to the database. At any point in time, you will find the edb.log file, and maybe one or more Edbxxxxx.log files.
• Res1.log & Res2.log are “placeholders” — designed to reserve (in this case) the last 20 MB of disk space on this drive. This is designed to give the log files sufficient room for a graceful shutdown if all other disk space is consumed.
• Edb.chk stores the database checkpoint, which identifies the point where the database engine needs to replay the logs, generally at the time of recovery or initialization. By examining this checkpoint file, AD can write any uncommitted transactions to the database during system startup after a crash.
Tertiary files and components
The Domain Controller is just that, a controller of many network objects within your Windows environment. Therefore, any discussion about the layers and structures of your DC will also have to include some of the key tertiary files and services that also have to be taken into account.
• System State data on your computer holds vital information for the launching and operation of the computer. You have to plan for the protection, and restoration, of the system state data if you are to be able to restore an Active Directory server.
• The system Registry is also vital to the restoration of a Domain Controller. A corrupt or missing Registry is fatal to a Windows system.
• The other components and services that interact with the Active Directory are DNS, Certificate Server, and all File Replication Service settings.
How data is written to the database
When data is being changed (added, deleted, modified) on a domain controller, there is a very definite process that takes place.
1. Once the DSA knows that is going to happen (let’s say a new record is going to be added) a transaction is created by the DSA.
2. The transaction is then written to the transaction log (Edbxxx.log) before being committed to the AD database.
3. Once the transaction has been written to the transaction log, it is then written to page memory within the DC’s RAM and then onto disk in the form of a table entry in the Ntds.dit database.
This process isn’t as immediate as it might have seemed when reading it above. The changes aren’t committed to disk until the DC has a period of idle time. Therefore, if the computer crashes after a transaction has been process and written to the log file, but before the changes have been committed to disk, the DC will use the log file to update the AD database. If the DC crashes after a transaction has taken place, but before the transaction can be fully written to the log file, the DC will then roll back the transaction as if it never occurred.
Setting up the AD server
For performance reasons, the log files and checkpoint file should be located on a different disk than the database to reduce disk contention. For disaster recovery reasons, having the log and checkpoint files on a different disk ensures that if the primary disk fails, the data can be rebuilt from the logs and checkpoint files. If these log files aren’t reconfigured for a different storage location during setup, they will reside in the Ntds directory within C:\WINNT.
During the setup of your system, the AD wizard will default install all of the above listed files within the NTDS directory within the WINNT directory. If you have a single hard drive with a single volume, then so be it.
Default setup for a single volume AD server (left) and better setup for an AD server (right)
However, if you do have multiple hard drives within the AD server, then the better setup is shown below. By separating your drives into three distinct volumes and having your operating system and the AD database log files on one drive with the actual AD Ntds directory information tables on a second drive and it’s own volume.
In order to backup and restore your Domain Controllers properly, you must understand their role as a service provider in your organization, and in relation to each other. Your DC is a server that hosts a domain database and performs authentication services. In Windows 2000/2003 Server, the domain database is a part of the Active Directory database. In Windows 2000/2003, object changes can be made on any DC within the environment instead of just a primary domain controller (PDC), as in Windows NT Server 4.0. DCs must initiate and perform replication operations to ensure that all DCs in the environment host a current and accurate version of the directory. In case of failure, it is important to know if the particular DC was a GC or operations master role holder so that appropriate action can be taken.
The global catalog
The global catalog's primary function is to provide fast and efficient searches that extend across the entire Active Directory forest. A GC holds a read/write full replica of all objects within the domain for which it is a member and a read-only partial replica (all objects but only a partial attribute set) of every other domain within the forest. The global catalog, therefore, makes directory structures within a forest transparent to end users, creating a search mechanism that makes finding objects in the directory uncomplicated and efficient. In addition, the global catalog is also required for the enumeration of universal group memberships and user principal names (UPNs) in a native Windows 2000/2003 domain. As a result, if a DC cannot contact a GC at the point of client logon, cached local logon credentials are all the client will receive, and access to remote resources will be denied.
If you don’t know, and want to find out if the server is the global catalog, launch the Active Directory Sites and Services application within your Administrative Tools directory, navigate to your Domain Controller and right-click on it to bring up it’s properties. The check mark will either be on (meaning that it is), or off (meaning that it isn’t). Hint here, if you are a small organization with only one DC, then it is the global catalog.
As Windows 2000/2003 DCs hold a replica of all objects belonging to their domain and have full read/write access to these objects, administration (and recovery of the data) of the domain can be done via any DC participating within that domain. These operations affect the state of an object and must therefore be replicated to the other DCs.
However, the replication of changed objects does not occur immediately. Replication is triggered after a period of time, gathering all changes and providing them to other DCs in collections. As a result, in normal operation the Active Directory on any DC can be regarded as always being in a state of loose consistency. That is, the information on all DCs within a Windows 2000/2003 environment is likely to be different as replication changes may be on the way from other DCs or waiting to be triggered.
Let’s say that you have to DCs in your organization—one for production and one for sales. An administrator adds a new server (keyserve1) to the production domain and a different administrator adds a new ordering server (orders) to the sales domain.
prod.yourco.com sales.yourco.com
Global
keyserve1.production.yourco.com
orders.sales.yourco.com
Loose consistency
Eventually the changes arrive at each other and the DCs then synchronize with each other. Replication and loose consistency are important concepts when considering the recovery techniques of Active Directory.
There are three things you need to understand in order to back up your domain controller; what you are going to back up, how often you need to perform your backups, and the access rights you’ll need.
Backing up the System State
Active Directory must be backed up as a part of the computer's System State. Depending upon how you set up your files and where you chose to store files, this collection might either be in the WINNT directory of the boot drive, or some of the files might be on other volumes and drives.
• System Start-up Files (boot files) are the files required for Windows 2000/2003 to boot. They are automatically backed up as part of the System State.
• System registry contents are automatically backed up when you back up System State data. In addition, a copy of your registry files are saved in the folder %SystemRoot%\Repair\Regback allowing you to restore the registry without doing a complete restore of the System State.
• Class registration database of COM+, the Component Object Model (COM), is a binary standard for writing component software in a distributed systems environment. The Component Services Class Registration Database is backed up and restored with the System State data.
• SYSVOL, or the system volume, provides a default Active Directory location for files that must be shared for common access throughout a domain.
• Active Directory, including the Ntds.dit, Edb.chk, Edbxxx.log, Res1.log and Res2.log files.
Before you get started, there are a few things you should know:
• The procedure adds a command line instruction to a scheduled LiveState Recovery backup job.
• This procedure is to be executed when creating a LiveState Recovery backup job for a domain controller.
• When restoring a system state, the DC will be down. If it is the only DC in your network, end users will not be able to access domain resources until the procedure is completed.
• You do not want to find that your system state backup is older than the Active Directory tombstone age (by default, 60 days).
• Successful execution is indicated by the proper operation of the restored Active Directory.
To create the system state backup, use the Live State Recovery Server Edition custom command feature. Commands must be in the form of .exe, .cmd, or .bat files placed in the Live State Recovery CommandFiles folder. This example shows creating a .bat file to run the Windows native ntbackup program.
On the server, run Notepad (Start > Programs > Accessories > Notepad) and type this line in:
ntbackup backup systemstate /f C:\systemstate.bkf
The ntbackup command line
From the File menu, select Save as, and browse to the CommandFiles folder. On the example server, it is in the default location of C:\Program Files\Symantec\Live State Recovery\Advanced Server 3.0\Agent\CommandFiles. Make sure the filename has a .bat suffix and that the Save as type field is set to All Files. Click Save.
Save the command file
Start LiveState Recovery (Start > Programs > Symantec >Live State Recovery) and click the Tools menu. Choose Create Backup Job.
Select the type of backup job you want to create. The example shows weekly Full Backups. You may also want to schedule daily incrementals if your backup policy calls for it. Click Next.
Backup type selection
Select the drive or drives necessary for the backup. The example server needs only its C:\ drive. Click Next.
Specify the location you want to write the backup image to. Enter a filename for the image. The example writes the image to a network share, \\backupserver\LiveStateRecovery_images.
Backup location selection
Next, schedule the job. The server’s performance will be impacted for a short time while the backup job runs, so schedule it at an appropriate time when usage is low.
Backup Job Wizard Schedule screen
Choose the compression level. The default is a good compromise between file size and backup speed. If you have limited backup storage space you can also specify Medium or High compression. Limiting the number of backups saved will also help manage storage space.
You will now have a system state backup file included in the server’s regular backup image.
Ensuring that your backup isn’t on a tombstone
If the backup is older than the tombstone age set in Active Directory, then it is not considered to be a good backup.
When an object is deleted in Windows 2000/2003, the DC from which the object was deleted informs the other DCs in the environment about the deletion by replicating what is known as a tombstone.
A tombstone is a representation of an object that has been deleted but not fully removed from the directory. The tombstone will eventually be removed based on the tombstone lifetime setting, which by default is set to 60 days. If a DC is restored to a state prior to the deletion of an object, and the tombstone for that object is not replicated to the restored DC before the tombstone expires, the object remains present only on the restored DC, resulting in an inconsistency. Thus it is important that the DC be restored prior to expiration of the tombstone, and that inbound replication from a DC containing the tombstone to the restored DC is completed prior to expiration of the tombstone.
Active Directory protects itself from restoring data older than the tombstone lifetime by disallowing the restore. As a result, the useful life of a backup is equivalent to the "tombstone lifetime" setting for the enterprise.
Required rights for backup purposes
To back up Active Directory, you must be a member of either the Backup Operators Group or the Administrators Group.
Restoring a Domain Controller (DC) isn’t as straightforward as restoring a normal computer or even a standard database server. Because of it’s role as a centralized security clearing house, and its replicated peer-to-peer relationship with other Domain Controllers in your organization, you have to take a few more steps to restore a Domain Controller than other devices. For this reason, we will split the restoration procedure directions into two sets—restoring the data of a Domain Controller and restoring the entire database of a Domain Controller.
There are several items to note when thinking about the restoration of a Domain Controller:
• To restore the System State data, the person performing the procedure must be a Local Administrator.
• You will also need to ensure that the backup you are restoring was taken within the tombstone lifecycle, by default this is set to 60 days.
If you are going to restore the Domain Controller to a completely different computer, you need to think about these things:
• By default, the Hal.dll is not backed up as part of System State, however the Kernel32.dll is. Therefore if you are trying to restore a backup onto a machine that requires a different HAL—to support a multiprocessor environment, for example—you will run into compatibility issues with the new HAL and the original Kernel32.dll. The only workaround for this situation is to explicitly copy the Hal.dll from the original machine and install it on the new machine. The limitation is that the new machine will now be bound to using only a single processor.
• If you backup and restore the boot.ini file, you may have some incompatibility with your new hardware configuration, resulting in a failure to boot. Before restore, ensure that the boot.ini file is correct for your new hardware environment.
• If your new hardware has a different video adapter or multiple network adapters, uninstall your video adapters and NICs before you restore data. When you restart the computer; the normal Plug and Play functionality will make the necessary changes.
• It is direly important that the partitions on the new machine match those on the original machine. Specifically, all the drive mappings must be the same and the partition size must be at least the same as on the original machine.
The types of Active Directory restorations
If you do have to restore Active Directory from a backup, there are two types of restoration— the authoritative and the non-authoritative restore. These two methods allow you to manipulate two important components of the System State during the restore process, the Active Directory and SYSVOL.
Elements of a primary SYSVOL restore for a single Domain Controller
If there is no other functioning DC in the domain, a PRIMARY restore of the SYSVOL should be done. A primary restore builds a new ntfrs (Windows NT File Replication Service) database by loading the data present under SYSVOL on the local DC. This method is the same as non-authoritative except that the SYSVOL should be marked PRIMARY.
Elements of a non-authoritative restore
Using this method, settings and entries that existed in the domain, schema, configuration, and optionally the global catalog naming contexts maintain the version number they had at the time of backup. As such, a non-authoritative restore is the default method for restoring Active Directory.
A non-authoritative restore is performed by restoring the SYSVOL of the Domain Controller in a non-authoritative manner. This is the default SYSVOL restoration method, and during this process the local copy that is held on the restored DC will be compared with that of its replication partners (using MD5 Checksums). Once a non-authoritative restore has been completed, the DC will examine the version number of an object’s attribute in its tables. If the version in the newly restored tables is older than versions on other DCs within the domain, the object will then be updated on the newly restored DC, ensuring that the database is up-to-date and synchronized with the rest of its peers.
Elements of an authoritative restore
An authoritative restore should be used when human error is involved such as when an administrator has accidentally deleted a number of objects; that change has replicated to all the DCs, existence of those objects is removed from the domain; and the administrator is unable to easily recreate these objects.
An authoritative restore requires all the steps of a non-authoritative restore before it can be initiated. The primary difference between the two is that an authoritative restore has the ability to increment the version number of the attributes of all objects in an entire directory, all objects in a subtree, or an individual object (provided that it is a leaf object) to make it authoritative in the directory.
Completely opposite of the non-authoritative restore, because the version number of the object attributes you wish to be authoritative will be higher than the existing instances of the attribute held on replication partners, the objects on the restored DC will appear to be more recent and therefore be replicated out to the rest of the DCs within the environment.
Unlike a non-authoritative restore, an authoritative restore requires the use of a separate tool (ntdsutil.exe) to make it work. No backup utilities—including the native Windows 2000/2003 utility—can perform an authoritative restore.
You should also note that an authoritative restore will not overwrite new objects that have been created after the backup was taken.
Similarly to the Active Directory authoritative restore, this method will typically be used when human error is involved and the error has propagated out to other domain controllers. The authoritative restore of SYSVOL does not occur automatically after an authoritative restore of Active Directory, additional steps are required. By restoring the SYSVOL authoritatively, you are specifying that the copy of SYSVOL that was restored from backup is authoritative for the domain. Once the necessary configurations have been made, the local SYSVOL will be marked as authoritative and be replicated out to the other DCs within the domain.
Performing a non-authoritative restore of a DC (new OS)
To restore that system state, including the Active Directory, proceed as follows. Install Windows 2000/2003 Server on the computer, following the guidelines in our general caveats discussed earlier. The LiveState Recovery Advanced Server Edition must be installed. Don’t worry about what you are going to name your machine, or whether or not you are going to join a domain at this point. This will all be replaced later.
Do not promote the machine to a Domain Controller.
Reboot the system into Directory Services Restore Mode by pressing the F8 key upon system startup and selecting Directory Services Restore Mode.
Log in as Administrator (local system account, no domain selection is available).
Start the LiveState Recovery Backup Image Browser (Start > Programs > Symantec LiveState Recovery > Backup Image Browser) and select the backup image containing the system state backup. Click Open.
Restoring the data of a DC is much easier than restoring the entire computer’s Active Directory database structure. Basically, restoration of the DC’s data comes down to whether you can manually reconfigure the DC so that the data is correct, or whether the problem is so drastic that the entire directory needs to be restored from a backup.
Process steps for restoring the data of a Domain Controller
Simply put, if the error can be resolved manually, do so. You’ll save yourself a lot of time and trouble. However, if the error can’t be resolved manually, then you’ll have to ask yourself whether or not the entire directory has to be restored. If you only have a single Domain Controller, then you shouldn’t perform a subtree restore. Instead, you’ll need to perform a Global Catalog restore.
Restoring a subtree of the Active Directory
Restoring a subtree is probably the most common restore method as it corrects an error that concerns only a partial data loss, which is the most common one. Before you get started, there’s a few things you should understand:
• The procedure restores the entire Active Directory from backup, and then specifies what part of that restore is to be kept (authoritative) when the DC comes back online and synchronizes with other domain controllers.
• The procedure is to be executed in situations where correcting an error manually is not possible. For example, if an Organizational Unit (OU) were deleted by mistake, it may not be possible to recreate it from memory.
• The procedure requires downtime for the domain controller. If the domain controller is the only one in your network, the entire network will be affected, so the procedure should be carried out after business hours and a warning sent to all users.
• You must be aware of the Active Directory tombstone lifecycle, by default 60 days. Active Directory will not allow data older than the tombstone lifetime to be restored, and you don’t want to discover that the backup data is too old while performing this procedure.
• Successful execution is indicated by the desired Active Directory data being restored to the DC and replicated out to any other DCs.
To perform an authoritative restore of a subtree follow these steps:
Reboot the DC into Directory Services Restore Mode by pressing the F8 key upon system startup and selecting Directory Services Restore Mode.
Log in as Administrator with the domain Administrator password.
Start the LiveState Recovery Backup Image Browser (Start > Programs > Symantec LiveState Recovery > Backup Image Browser) and select the backup image you want to restore from. Click Open.
Select backup image in Backup Image Browser
Select the folder containing the Active Directory files. The default location is C:\Winnt\Ntds.
Select the Active Directory folder for the restore
From the File menu, select Restore. Point the Ntds folder to its original location, C:\Winnt. Click Restore.
The Restore Items dialogue
When the restore process has finished, close the Backup Image Browser.
Open a command prompt and type ntdsutil, press Enter.
At the next prompt, type authoritative restore and press Enter.
At the next prompt, type restore subtree <path>. Following is an example for a path: OU=Engineering, OU=Cupertino, DC=Whitepaper, DC=com.
At the Authoritative Restore Confirmation dialog box, click OK.
Type Quit, and repeat until you exit out of the application.
Restart the server. Confirm that the restored Active Directory contains the correct backup information. If this DC is the only one in your network, you’re done. If it’s not the only one, you may have to force replication of the backed up subtree to the other DCs, as outlined in Microsoft Knowledge Base article #316829, Possible Active Directory Inconsistency After You Restore a Domain Controller.
Performing a Global Catalog Restore
Basically a Global Catalog Restore is a complete restore of the system volume. In order to be able to perform a global catalog restore you need to have a good backup.
A good backup needs to contain at least the system state, the contents of the system disk and the SYSVOL folder. If you have spread out the log and database files on separate disks, those files must be part of the backup. Also, the backup must be newer than the tombstone age set in Active Directory. Here are a few things you should be aware of:
• The procedure restores the Global Catalog by recovering the entire system volume of an Active Directory server.
• The procedure is supported by the Symantec Recovery Environment Boot CD. • The procedure is to be executed if the Global Catalog server has failed due to a
hardware problem or if the Active Directory itself has become corrupted. • The procedure entails downtime for the Active Directory service, so end users
will be unable to log on to workstations or access network resources for the duration.
• Due to the importance of the Active Directory service, any trouble with the procedure is potentially serious.
• Successful execution of the procedure is indicated by the proper operation of the Active Directory services after recovery.
To restore an Active Directory server’s system volume using the boot CD, put the CD in and restart the computer. If your computer doesn’t start from the CD, check that your system is set to boot from CD-ROM. Here’s what you’ll see at the bottom of the screen as the recovery CD boots:
Recovery Environment boot screen
When the system starts, the Recovery Environment is automatically launched. The System Restore feature is used to restore partitions or entire drives. The Backup Image Browser is for restoring individual files and directories, and the Utilities offer a collection of network and disk tools.
Symantec Recovery Environment console
One utility that you might need to use right away is Configure IP Address. This will be necessary to set up networking if you don’t have a DHCP server on your network, or if you want to move the computer to another subnet. Click Utilities and then select Configure IP Address.
Enter IP address and other information with the Modify button.
Network Configuration
Once you’re done, head back to the Utilities and test connectivity with your backup server with ping.exe. Enter the name of the machine (in our case, “backupserver”) and click OK.
Ping Address, from Utilities
A successful ping will be a series of replies from the backup server. If the ping doesn’t work, try pinging the backup server’s IP address instead of its hostname. If that works, you might not have connectivity with a DNS server. You can fix that or decide to skip it. All restore operations can be performed by using the IP address directly.
Use an account that is local to the backup server and has read permission on your domain controller’s backup folder.
The drive map authentication dialogue
Next, start the System Restore wizard from the Recovery Environment console.
System Restore for recovering an entire drive
System Restore presents you with two choices, Restore drives or Restore files and folders. The Restore files and folders option simply starts the Backup Image Browser. So check Restore drives.
System Restore Wizard
The wizard then asks you to specify the backup image to restore. Click Browse and open the drive mapped to the backup server.
From that drive, select the appropriate image to restore to your system and click Open.
Restoring C: drive from 10/17/03
Information about the selected image including creation date, image description, and file system size appears in the System Restore Wizard. If all looks correct click Next.
Backup image filename and details
Now we’re at a potentially confusing point in the process, choosing the destination for the backup image. The wizard doesn’t muddy the issue with drive letters, instead
showing volume labels, sizes, and file system types. In this example, I am restoring the C: drive, which is unlabeled on the disk. It’s not too hard to figure out which volume it occupies as I previously labeled the other partitions. However, if you have more than one unlabeled volumes of the same size, you’ll be guessing. If you’re that unlucky, you could boot back into Windows and label the drive with the Disk Management utility.
Note the volume management options you have at this point. By deleting volumes, you could free up space and restore a larger backup image to the disk. Click Next.
Select the correct volume for the restore
The System Restore Wizard then prompts for error checking (ensures accuracy but takes longer) and advanced restore options including disk signature and master boot record. If you’re recovering the domain controller because of a failed hard drive, then restoring the disk signature is appropriate as it contains information such as drive letter assignments. The master boot record (MBR) can be restored as well. The MBR occupies the first sector of the hard drive and contains information about disk partitions and OS boot location. Click Next.
System Restore options
The wizard then gives a summary of your restore operation and the chance to go back and fix it if something’s not quite right. You can also have the computer reboot after the restore finishes. If all’s well, click Next and the job starts.
In case of a complete failure of a Domain Controller or an Organisations Master it can be unavoidable to restore the whole database of the server. The reason for this is that secure channel issues come into play when a DC remains disconnected from other DCs for a period greater than that specified in the maximumpasswordage registry entry. This issue can be corrected using the following decision tree:
Process Steps for restoring the Database of a Domain Controller
If the Domain Controller that you have to restore was the only Domain Controller on your network you need to perform a Global Catalog Restore. If the Domain Controller was an operations master you can seize the roles that have disappeared with the server, otherwise perform a Non-Authoritative Restore.
Seizing the Schema Master Role
Before you seize the schema master make sure that the current operations master has been removed from the network. Also verify that the copy of the schema on the new operations master is up to date with the rest of the domain controllers in the forest. Next perform the following steps to seize the schema master:
1. Click Start, click Run, type cmd and hit the Enter key
2. At the command prompt type ntdsutil and hit the Enter key
3. At the ntdsutil prompt type roles and hit the Enter key
4, At the fsmo maintenance prompt type connections and hit the Enter key
5. At the server connections prompt type connect to server followed by the fully qualified domain name and hit the Enter key
6. At the server connections prompt type quit and hit the Enter key
7. At the fsmo maintenance prompt type seize schema master and hit the Enter key
8. At the fsmo maintenance prompt type quit and hit the Enter key
9. At the ntdsutil prompt type quit and hit the Enter key
After you have seized the schema master make sure that the previous schema master never gets connected to your network again.
Seizing the Domain Naming Master Role
Before you seize the domain naming master make sure that the current operations master has been removed from the network. Also verify that the new operations master is up to date with the rest of the domain controllers in the forest. Next perform the following steps to seize the domain naming master:
1. Click Start, click Run, type cmd and hit the Enter key
2. At the command prompt type ntdsutil and hit the Enter key
3. At the ntdsutil prompt type roles and hit the Enter key
4. At the fsmo maintenance prompt type connections and hit the Enter key
5. At the server connections prompt type connect to server followed by the fully qualified domain name and hit the Enter key
6. At the server connections prompt type quit and hit the Enter key
7. At the fsmo maintenance prompt type seize domain naming master and hit the Enter key
8. At the fsmo maintenance prompt type quit and hit the Enter key
9. At the ntdsutil prompt type quit and hit the Enter key
After you have seized the schema master make sure that the previous schema master never gets connected to your network again.
Seizing the Relative ID Master Role
Before you seize the relative ID master use Repadmin from the Active Directory support tools to verify whether the new operations master has received any updates performed by the previous operations master. Next perform the following steps to seize the relative ID master:
1. Click Start, click Run, type cmd and hit the Enter key
2. At the command prompt type ntdsutil and hit the Enter key
3. At the ntdsutil prompt type roles and hit the Enter key
4. At the fsmo maintenance prompt type connections and hit the Enter key
5. At the server connections prompt type connect to server followed by the fully qualified domain name and hit the Enter key
6. At the server connections prompt type quit and hit the Enter key
7. At the fsmo maintenance prompt type seize RID master and hit the Enter key
8. At the fsmo maintenance prompt type quit and hit the Enter key
9. At the ntdsutil prompt type quit and hit the Enter key
Seizing the PDC Emulator Role
Before you seize the PDC emulator master make sure the current operation master has been removed from the network and verify that the new operations master is up to date. Next perform the following steps to seize the PDC emulator:
1. Click Start, click Run, type cmd and hit the Enter key
2. At the command prompt type ntdsutil and hit the Enter key
3. At the ntdsutil prompt type roles and hit the Enter key
4. At the fsmo maintenance prompt type connections and hit the Enter key
5. At the server connections prompt type connect to server followed by the fully qualified domain name and hit the Enter key
6. At the server connections prompt type quit and hit the Enter key
7. At the fsmo maintenance prompt type seize PDC and hit the Enter key
8. At the fsmo maintenance prompt type quit and hit the Enter key
9. At the ntdsutil prompt type quit and hit the Enter key
You can return the original PDC emulator to service later and return the role to it.
Seizing the Infrastructure Master Role
Before you seize the infrastructure master make sure that the current operations master has been removed from the network and verify that the new operations master is up to date. Next perform the following steps to seize the infrastructure master:
