|
|
|
|
AD School of Hard Knocks
|
 |
|
September 4, 2003
By Dan Wohlbruck
|
|
The unthinkable happened. Then things got worse. When we tried to salvage data after our Windows 2000 domain controller's hard drive crashed at Gulf Coast Community College earlier this year, the mirrored side failed, too. The college's Active Directory system was lost in the disaster, as was access to several other applications at our Panama City, Fla., campus.
Without AD, users couldn't get authenticated and, therefore, couldn't sign on to the domain. Classes were in session, so the pressure was on to get the network back up and running. Because the damaged hard drive was one side of a mirror, we first performed a shutdown and inserted a replacement drive. The other side of the mirror failed when we attempted to reboot. We learned the hard way that our recovery plan--a combination of a mirrored directory and replication from the second AD domain controller--wasn't enough.
|
|
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.
|
|
|
|
|
|
|
|
RSS
