Friday, August 21, 2009

An Overview on Backing up and Restoring Active Directory

To ensure availability of mission critical resources and network objects, and business continuity, you would need to perform backups of Active Directory if it is running in your environment. This is because Active Directory normally hosts mission critical data, and resources. Backups are typically preformed for a number of reasons, including the following:

  • Protect your network environment from the accidental deletion of, or modification of data, and from hardware failures: Having a readily accessible back up of Active Directory would ensure that you can recover any important Active Directory objects which were deleted in error. Backups also prove invaluable when unauthorized users intentionally delete or modify data. The backup would enable you to restore data to its previous state of integrity. Because certain hardware failures such as corrupted hard disk drives can cause considerable loss of data, backing up your data would ensure that the business can continue to perform its mission critical functions when such an event does occur.

Store mission critical data: It is recommended to regularly back up mission critical data so that any previous version of information can be accessed, if necessary, at some time in the future
because Active Directory is dependent on the Registry, you need to back up files within the system directory. These files are called system files. System state data basically contains the main configuration information in Windows 2000, and Windows Server 2003. What actual information is included in system state data is determined by operating system (OS) configuration.

System state typically includes the following important data, files and components:
  • The Windows Registry
  • The contents of the SYSVOL directory
  • Files which are protected by the Windows File Protection system
  • Boot and system files: Ntdetect.com, Ntldr and Bootsect.dat.
  • The COM+ Class Registration database
  • The Active Directory database (Ntds.dit), including all log files and checkpoint files
  • Cluster service files
  • Certificate service files
  • The Internet Information Server (IIS) metabase
You can use one of the methods listed below to back up Active Directory.
  • You can back up the system state data only
  • You can back up Active Directory as part of a full system backup
  • You can back up Active Directory as part of a partial system backup
The best option to use when specifying what data or components should be backed up in the Active Directory backup; is to specify a back up of system state data. This ensures that all core system files are backed up. When a full system backup is performed, system state data is automatically included in the back up process. When performing a partial backup, you can specify that system state data should be included. Manually specifying individual files and components for an Active Directory backup can be an extremely complicated process. Apart from having to be able to identify and specify all important system files and

components, you also need to be able to specify which other important Active Directory data and components need to be backed up, such as the replication topology, and Group Policy information. You can back up Active Directory by using the Windows Server 2003 Backup utility, or you from the command line, using the Ntdsutil command-line utility. The Windows Server 2003 Backup utility includes the feature of using volume shadow copying to back up open files. With the previous versions of Windows, a third party backup tool had to be used to back up open files. The Volume Shadow Copy service creates a read-only copy of any open files. This in turn ensures that these files can continue to be accessed. In Windows 2000 Active Directory, you could only perform one of the following restore methods:
  • Authoritative Restore
  • Non- Authoritative
When it comes to restoring Windows Server 2003 Active Directory, you can use one of the following restore methods:
  • Normal Restore: In Windows 2000, this was your Non-Authoritative restore method. A Normal restore functions pretty much the same as a Non-Authoritative restore. With a Normal restore, the Backup utility is run on the computer while in Directory Services Restore Mode. After the domain controller is rebooted, normal replication occurs with replication partners.
A normal restore is typically performed when the following conditions exist:
o A domain has multiple domain controllers, and only one domain controller is operational. You can use a Normal restore to restore all other domain controllers in the domain.
o A domain has a single domain controller, and that domain controller has to be restored. You can also choose to alternatively perform a Primary restore of Active Directory.

  • Authoritative Restore: An Authoritative restore of Active Directory has to be performed in cases where a Normal restore would not be able to return Active Directory to the correct state. For instance, if an organizational unit was deleted in error, a Normal restore would only result in the particular OU being deleted once again, after replication. This is basically due to the replication partners having a higher version number for the particular OU. An Authoritative restore has a similar process to that of a Normal restore, the difference being that after system data is restored, you define certain Active Directory objects as being authoritative. When Active Directory objects are defined as authoritative, the particular objects have the higher version numbers. This results in these objects being replicated to the other domain controller’s copies of the Active Directory database.
  • Primary Restore: The Primary restore method is used when each domain controller within a domain hosting multiple domain controllers, needs to be restored. What this means is that the entire domain has to be reconstructed from the Active Directory backup. This method can also be used to restore Active Directory for a domain that only has one domain controller. The Primary restore method is selected in Windows Server 2003 Backup utility by merely enabling the Primary restore method checkbox. This removes previous complexities associated with performing this type of restore in Windows 2000. The Primary restore process is also very similar to that performed for a Normal restore of Active Directory.

Exchange Server 2003 Data Storage and Management

Understanding Exchange Server 2003 Data Storage

Exchange Server 2003 uses the Extensible Storage Engine (ESE) database structure to store data. Data can be stored separately for messages and for transactions:
Messages are stored in.edb and .stm database files. Database files also contain a number of other components, including:

• Rules
• Folders

• Attachments

• Indexes

Transactions are stored in transaction log files.

A message that is created is first written to log files before it is written to the database files. From the log files, the transactions are sequentially written to a numbered file. Data in the log file is written to the database at a later stage. Transaction log files are written to in a sequential order. Database files are written to in a random manner. They are also read in a random manner. Exchange Server 2003 automatically creates a new transaction log file when the current log file reaches 5 megabytes (MB) in size. The transaction log files and database files should be located on disk systems that have the following characteristics:
The disk systems are optimized for the type of functions to be performed.
The disk systems do not compete.

The disk setup that you use for transaction log files and database files should provide the following:
• Best cost.

• Best data protection.

• Best performance.




Understanding How Transaction Logs Protect Data
When you store transaction log files separately to database files, the following benefits are achieved:
• Disk performance is improved.

• Protection from data loss.


Each storage groups has its own transaction log file. The Information Store is arranged into storage groups. A storage group is a group of separate databases which have a common set of transaction log files. It is these storage groups that contain the mailbox stores, public stores, or both of these stores
From the transaction log file, the information is saved to the database file of the storage group. A checkpoint file indicates which transaction log entries have since been written to the database file. The information is not deleted from the transaction log file at this stage. It is only deleted when a full online backup of all the databases in the storage group is performed.
The concept of a soft recovery and hard recovery is illustrated below:

Soft recovery: When the hard disk containing the storage group databases is lost, the damaged disk can be replaced. You can use the latest database backup for the restore. When the checkpoint file is deleted, an automatic log file replay of all transactions that took place since the backup, transfers the transactions from the log files to the databases. A soft recovery is also referred to a roll-forward recovery.



Hard recovery: A hard recovery can be performed when you have backed up transaction log files since the last full backup. With a hard recovery, transaction log files from the backup medium are replayed after the database is restored from an online backup. If Exchange 2003 detects that additional log files are available on the server, soft recovery is initiated to restore these log files to the database.




If the disk you are using for the transaction log files fails and the disk storing the databases are still online, no storage group data needs to be restored. You cannot though replay any transactions that are recorded to log files and not to the database files on disk.


Storage Technologies used with Exchange Server 2003
The different storage technologies that can be used with Exchange Server 2003 are listed below. The storage technology that you choose will be determined by the size of your Exchange Server 2003 organization

External storage array (ESA): The characteristics and features of an external storage array are listed here:
An external Small Computer System Interface (SCSI) drive cabinet hosts multiple SCSI disk drives that are typically set up as RAID sets.
SCSI cables connect the disk drives to an Exchange Server 2003 server.
External storage has to be managed on a per Exchange Server 2003 server basis.
External storage provides good performance.
Limited scalability is provided.
Recommended for small Exchange organizations.

Network Attached Storage (NAS): The characteristics and features of network attached storage are listed here:
SCSI or fiber channel connections can be used to connect the storage device to the Ethernet network.
Network attached storage has its own IP address and is not directly attached to the Exchange Serve 2003 server.
File requests are mapped by the Exchange Server 2003 server to the network attached storage server.
This is not the recommended storage technology for Exchange Server 2003, simply because Exchange Server 2003 has local data access and bandwidth requirements that are not compatible with network attached storage products.

Storage area network (SAN): The characteristics and features of a storage area network are listed here:

• For medium to large Exchange organizations, using a SAN as a storage technology is the recommended solution.


• A SAN uses fiber channel switching to provide fast and reliable connections between storage and applications.


• SANs optimize the performance and reliability of a server.



• SAN packages are supplied by hardware vendors such as IBM and Intel. The SAN package includes all hardware, software and support functions.

• The main components that make up a SAN are listed here:


• Fiber channel switching


• Storage arrays that store and protect data.


• Storage software and SAN management software


• The advantages of using a SAN technology in an Exchange Server 2003 organization are listed here:


• You can connect multiple Exchange Server 2003 servers to multiple storage arrays and share storage between the servers.


• The high I/O bandwidth needed by Exchange Server 2003 is supported by SAN solutions.


• The Exchange organization can be easy expanded by adding servers.


• SANs are highly scalable and disks can easily be added.


Managing Storage and Storage Groups
• A few best practices for configuring storage groups and databases are summarized here:

• You should never use circular logging.


• Use only four databases for each storage group.


• When creating additional storage groups, create the databases that are needed before you create the additional storage groups. This prevents overhead on the server for log file management.


• To ensure short maintenance and restore times, you should strive to keep the size of the databases small.


• When you configure your storage group limits, it is recommended that you do not enable the prohibit-send option.


• You should not change the online system maintenance default setting of enabled.


• It is recommended that you perform a full backup each day, if feasible.


• Verify that backups have occurred successfully.


• You should retain deleted mailboxes for a minimum of thirty days.


• You should retain deleted items for a minimum of seven days.


• Ensure that the logs are purged.


Additional Storage groups would need to be created under the following conditions:

• There is a need to utilize separate physical transaction log drives so that performance can be improved.


• There is a requirement that multiple databases need to be backed up simultaneously. If you use multiple storage groups, then each storage group can
be backed up at the same time.


• The existing storage group is already using the maximum number of databases supported, and you need another