AD School of Hard Knocks

Lesson learned: Prepare for all kinds of problems, even the less common ones. This entails reviewing your AD backup plan and making sure your disaster-recovery strategy encompasses the possibility of losing all your domain controllers. We took several steps, and missteps, to recover our AD, which I explain below.

In Recovery

When you lose both directory mirrors, it's difficult to save AD. At first we tried demoting the damaged domain controller, reinstalling AD and forcing replication of its database. Trouble was, we hadn't documented which controller was providing which Windows 2000 Server operations master role. We had to seize and transfer missing roles and remove the damaged controller from the domain so replication could begin. We then experienced more problems, including excruciatingly slow replication, so we decided to scrap the recovery process and rebuild AD from scratch.

First came the task of rebuilding the domain by entering and testing the technology department's users and groups. AD users and groups have properties including names, passwords, profiles, workstations and group membership that have to be entered, copied or created, depending on the installation's requirements. At Gulf Coast Community College, we use a combination of profiles and workstations for a user to control the desktop until sign-off. In Classroom 209, for instance, Student 209 has a profile that dictates he is allowed to use workstations located only in that classroom. Some users are assigned certain applications, and there are administrative users as well. After we had to manually re-enter all the college's 200 users identified in AD, we decided to automate the user and group-building process.

We checked out several scripts on the Internet for building AD users and groups. Most didn't include all the properties we needed or didn't work as advertised. After further research, we decided to use the WSH (Windows Scripting Host), the Visual Basic Scripting engine and the ADSI (Active Directory Scripting Interface) for creating our homegrown script.Code Box 1 shows a script we developed at Gulf Coast Community College that is largely self-explanatory, with the exception of a few elements. The CSV (comma-separated value) file is called "export.txt," though it's in CSV format. The 15 or so scripting commands that set the "user-cannot-change-password property" are complicated by the involvement of an ACE (Access Control Entry) security mechanism, which requires you get permission to make any changes to an entry. So before the script can set the property, it first must deal with the ACE.

The script also lets the user belong to as many as five groups. There are separate commands to join each group instead of a single loop. And the script allows up to three logon workstations. For users who log on to a single classroom, we use many more workstations. Note that the two commands shown before the Wend command--Set Group = nothing and Set adsUser = Nothing--effectively reset the group and user before the next loop iteration.You'll need to customize some elements of the script to match your installation. Specifically, where the script shows tech.gulfcoast.edu, put the name of your domain. The script has all passwords set to "gccc," so have the user create the initial password and regularly change it.

We tested this script by building two domain controllers and a single user in a separate network that wasn't attached to the production environment. We recommend lifting the script as shown, building input for a single user and creating a test user account. That way, you'll know that all the parts--AD, the scripting engines and interfaces, and the script itself--work. You can then delete the test user and make your changes.

If your installation uses AD groups, they must be built before you add users. Code Box 2 shows how to create AD groups.

Once we had created and tested the entire script, it was time to make the input file. We wanted to develop a process that could be duplicated and run at a scheduled frequency. We first deployed the export function in the AD MMC (Microsoft Management Console) snap-in. Although we created several different files, none provided the range of data we needed, such as a list of all the workstations for a specific user. So we turned to the two command-line utilities in Windows 2000 server--LDIFDE (LDAP Data Interchange Format Data Exchange) and CSVDE (CSV Data Exchange).LDIFDE is a utility program that can be used to import and export AD objects using LDIF-formatted files. It includes several command-line switches that direct the import or export operation. Although LDIFDE is intended to assist in the migration of data, with the right combination of switches we were able to use it as our backup facility (see "The Command-Line Syntax").

By using filters to choose Users or Groups and selecting or omitting attributes as needed, you can create a nearly complete backup file. In our case, the file we created using LDFIDE still requires regular review and minor changes to support the script (see Code Box 3).

The CSVDE utility, meanwhile, imports and exports data from AD using files that store data in the CSV format. This utility operates identically to LDIFDE. Applications such as Microsoft Excel can read and save data in the CSV format, which consists of one or more lines of data with each value separated by a comma. Only the first line contains the names of each attribute in the same order as the data in any line following it. We preferred the LDIFDE format where every field is identified.

Chances Are ...

If you think instituting an AD backup plan with separate backup and recovery for users and groups requires extra effort, you're right on. Creating input files for the two scripts we developed lets the installation recover them in the event of a catastrophic failure, such as the one we experienced. Since there's no way to know for sure the chances of a major loss in your directory implementation, try measuring the risk against the cost of rebuilding your AD from scratch. Then you can decide whether opting for the backup and recovery setup is worthwhile.Dan Wohlbruck is assistant systems administrator and an adjunct instructor at Gulf Coast Community College in Panama City, Fla. Write to him at [email protected].

Post a comment or question on this story.When you add a second Microsoft Windows 2000 domain controller, Active Directorybecomes a distributed database. Installing Active Directory automaticallyupgrades a member server to become a domain controller. There is no primary ADdomain controller.

Active Directory services, along with the AD database, authenticate domainusers, administer installation policies and manage desktop practices andsoftware. The directory package also comes with management tools.Depending on the type of change you're making to Active Directory, eachmanagement role or process resides on one server in each domain. So when asystems administrator makes a change to the Active Directory schema, only onedomain controller in the enterprise can make that change to the database.Similarly, when a new domain is created, only one domain controller can add thedomain to the database. When there's just one domain controller, allmanagement roles and the Active Directory global catalog reside on that server.As you create more controllers and the database becomes distributed, the rolesand the global catalog can be dispersed among them.

Once the Active Directory database resides on more than one domain controller,it's a good idea to frequently record which server is performing whatAD-operations role. AD comes with utilities that document which domaincontroller plays what role, but it's easier to use the AD management console(MMC) snap-in because it's graphical user interface-based.

Active Directory's backup is usually performed with the backup wizard. Beware,however, that when you mark the System State checkbox, the backup utility onlyarchives the AD database, the AD checkpoint file and the AD logs for a singlecontroller. You have to back up each controller individually with the wizard.Not all controllers need their database archived, however, so take a close lookat how AD uses each domain controller.With the AD distributed database, replication is the key to ensuring thatchanges to one controller's copy of the database is sent to all domaincontrollers. A single domain controller does not notify each controller -it's a round-robin process. Replication helps the recovery of an updated database undertypical emergency conditions (unlike Gulf Coast Community College'ssituation), such as when a single domain controller is lost or when that controller's ADdatabase becomes corrupted.