jump to navigation

How to Backup/Restore a Windows 2003 Domain Controller November 13, 2009

Posted by General Zod in Microsoft, Tech.
trackback

A couple years back, I was working for a rather large company with hundreds of sites in about 50 different countries that were all linked by a single global network… except for 4 or 5 data center sites that were called “solution centers”.  I worked at one of these special sites.  The purpose of the solution centers was to house whatever services a customer company required us to while keeping it separate for our company’s global network.  As we were not part of the global network, we were considered the black sheep of the company… and I was the lone systems engineer responsible for keeping the servers at my site running.  No bother… I do my best work when I’m left to my own devices.

However, this did present many additional complications that others in my company did not have to contend with.  The largest challenge to overcome was our site’s disaster recovery plan.  We could not just assume to relocate to a new site because we would need to recover our own environment, which included our own domain.

Yes, I know… I could have just housed one of our domain controllers at another location and established a special VPN just for the communications between the DC’s.  That would be a valid solution, but just not good enough.  During a DR event, that would place me very dependent upon the IT staff at that other location… and call me crazy, but I want to be able to ensure that I would be able to perform the recovery 100% without the assistance of anyone else.

I spent a lot of time reading over Microsoft white papers and procedures written by various individuals, throwing ideas around with colleagues, and plucking away at ideas in an attempt to develop a procedure that would fulfill our needs.  Eventually, I developed the procedure that you’ll read below… and tested it successfully on several occasions.  Knowing that someone else out there is probably looking for the same thing, I figured it would be grand to share it with you.

How to Backup the Domain Controller(s)

Obviously, before you can restore your domain, you have to back it up first. 🙂
Mainly what we’re interested in backing up is the System State of a Domain Controller.  So what is the System State?

The System State of your server includes the Registry, the Boot files, some System files, the Active Directory service, and other components.  (Read more about it here.)  You can not pick and choose between which components are backed up during a System State backup.  It’s an all or nothing situation.

Since this includes the whole of your Registry, you have to understand that this includes the information about the original System’s installed hardware.  This may complicate the restore process somewhat.  If you backed the System State from DC on an HP Proliant DL380 G5 series server… and attempt to restore it on a Dell PowerEdge T100… you will most likely have issues with booting up the OS afterwards because the hardware set is significantly different.

As part of your DR plan, I recommend making a point of documenting the hostname, IP address, Operating System, Service Pack level, and the hardware make/model of each of your domain controllers.  You may find this information useful when the time comes.

These instructions are going to use the hostname "DC123" as name of the domain controller, and assume that you want to run your System State backup every day at 3:00am.

Login to your domain controller, and perform the following steps:

  1. Create a C:\Backup\ folder.
  2. Click Start — All Programs — Accessories — System Tools — Backup.
  3. Click [Next] — Select Backup Files and Settings — [Next].
  4. Select Let me choose what to back up — [Next].
  5. Expand My Computer — Check System State — [Next].
  6. Set the location of the backup file to C:\Backup\ folder.
    Set the Name of the Backup to “DC123 System State”.
  7. Click [Next] — [Advanced] — Select Normal — [Next].
  8. Check the Verify Data after Backup box — [Next].
  9. Select Replace the existing backups — [Next].
  10. Select Later — Set the Job Name to “DC123 System State”.
  11. Click [Set Schedule] — Schedule the job to run Daily at 3:00am.
  12. Click [OK] — Enter a set of user credentials — [OK].
  13. Click [Next] — Enter a set of the user credentials — [OK] — [OK] — [Finish].

The actual backup job itself will probably take somewhere between 15 – 30 minutes to run.  Then, you can backup the C:\Backup\ folder to tape.  Personally, I had preferred to schedule another task that would launch at 4:00am to “robocopy” (which can be found as part of the Windows Server 2003 Resource Kit Tools download) each of the backup files to another server where they were all dumped to tape a few hours later.

You only really need to backup 1 domain controller for this to work, but then your pretty much locked into a single hardware set when it comes time to do the restore.  Since I was never sure what kind of hardware I would have available to me when it came time to do the restores, I tried to make a practice of housing each domain controller on a different model of server… and backing each of them up individually.  Each backup ran me somewhere between 600 – 800 MB of disk space (which is rather a small pittance by today’s standards).

Yes, this was probably a significant amount of overkill on my part.  However, I find that the more paranoid you are, the better prepared you tend to find yourself.  And I tend to be rather paranoid about things like DR.

 

How to Restore the Domain Controller(s)

Now let’s pretend that a disaster has struck!

You’ve retrieved your tapes from off-site storage and acquired your target hardware, so let’s get to work!  (Remember that matching the hardware to the DC restore would be best, but you can make substitutions.  It’s not an exact science, so some experimentation may be required.)

Note:  These instructions are written with a few assumptions in mind.

  1. We assume that your entire domain has been leveled by some catastrophic event.
  2. We assume that your domain controllers are running a Windows 2003 operating system.
  3. We assume that whomever is doing the work knows the login credentials (from the original domain) to the domain’s Administrator account or a user account that is a member of both the domain’s "Domain Admins" and "Schema Admins" groups.
  1. Build a stand-alone Windows 2003 server, and bring it up to the same Service Pack level as the original DC.
  2. Name the server with the same hostname as your original DC.
  3. Restore your System State backup files from tape, and copy them to the new server’s local hard disk.
  4. Reboot the server.
  5. After POST, hit [F8] and select to boot into “Directory Services Restore Mode (Windows domain controllers only)”.
  6. Click Start — All Programs — Accessories — System Tools — Backup.
  7. Click [Next] — Select Restore files and settings — [Next] — Browse to the location of the backup file — [Next].
  8. Expand File – System State Backup — Check the System State box — [Next].
  9. Click [Advanced] — Select Original Location — [Next] — [OK] — Select Leave existing files (Recommended) — [Next].
  10. Check the boxes for:

    *  Restore Security Settings
    *  Restore junction points, but not the folder and file data
    *  Preserve existing volume mount points
    *  When restoring replicated data sets, mark the restored data as the primary data for all replicas

  11. Click [Next] — [Finish].
  12. After the restore is completed, click [Close] — [Yes] to reboot the system.

If your server hardware is significantly different from the original DC, then you may experience difficulty with the boot to the GUI.  If this is the case, then you might be able to still recover the OS by booting into Safe Mode or by booting to an original Windows 2003 OS CD to perform a Repair.

Once you get into the GUI, you will need to login using the local Administrator password from the original DC.

Now you will be able to seize the FSMO roles.  (Note:  After each "seize" command, click [Yes] and allow 3-5 minutes for the task to complete.)

  1. Click Start — Run — NTDSUTIL — [OK].
  2. Type the following commands into NTDSUTIL.

    roles
    connections
    connect to server DC123
    q
    seize domain naming master
    seize infrastructure master
    seize PDC
    seize RID master
    seize schema master
    q
    q

Next, confirm that your DC is a Global Catalog server.

  1. Launch AD Sites and Services
    (C:\Windows\System32\dssite.msc)
  2. Expand Sites – Default-First-Site-Name – Servers – DC123.
  3. Right-click and select NTDS Settings — On the General tab, verify that the Global Catalog box is checked.
  4. Perform a clean reboot of the system.

Now we’ll clean the old domain controllers out of the AD database.

  1. Click Start — Run — NTDSUTIL — [OK].
  2. Type the following commands into NTDSUTIL.

    metadata
    cleanup connections
    connect to server DC123
    quit
    select operation target
    list domains
    select domain <#>
    list sites
    select site <#>
    list servers in site
    select server <# of bad DC>
    quit
    remove selected server
    quit

  3. Launch Active Directory Sites and Services(C:\Windows\System32\dssite.msc).
  4. Expand Sites – Default-First-Site-Name – Servers.
  5. Right-click on <bad DC hostname> — Select Delete.
  6. Launch Active Directory Users and Computers (C:\Windows\System32\dsa.msc).
  7. Expand the domain — Open the Domain Controllers container.
  8. Right-click on <bad DC hostname> — Select Delete.
  9. Select The domain controller is permanently offline and can no longer be demoted using Active Directory Installation Wizard (DCPROMO).
  10. Click [Delete] — [Yes] to confirm.

 

Your domain should now be successfully restored, but don’t consider yourself finished at this point.  This restored server should be considered hinky at best, and should not be kept as a long-term solution.

Before doing anything else, I recommend that you build a 2nd “clean” domain controller alongside this restored 1st DC.  Then, transfer the FSMO roles to the 2nd DC.  Finally, demote the 1st DC to a member server and retire it from the domain.  That will hopefully ensure that your domain is running on a clean and stable DC that you can rely upon.  Then, build a new 2nd DC to ensure some redundancy.

Congratulations!  Your domain is restored.  Now get to work on restoring everything else. 🙂

Comments»

1. GC - June 3, 2010

Its Very Usefull Infromation,
thnkas and pls keep sharing like this information.

2. Maki - May 11, 2011

Nice blog! This is the steps that I really need. I won’t be needing to spend much time reading technet because of this. Thanks!

3. Genlor - November 8, 2011

Hi Thank you for sharing this step by step information. Very detailed one.

More power to you!!!!

4. Michael Dunn - February 13, 2012

Very helpful and detailed information! I wish more IT professionals would post in this format. Thanks!!

5. D.R. GURU - March 8, 2012

Excellent instructions. It may be worth mentioning a gotcha with two MS patches that inhibit communications between DC’s and client systems in a DR situation. KB95178 and KB951746 need to be removed from any DC’s and member servers after recovery or else there is port blocking that prevents the servers re-registering themselves.

6. alco - May 3, 2012

Can I use this way, if I have windows 2003 different platform?
In this case I want to change windows server 2003 standard edition that I got from x86 to x64.

7. General Zod - May 4, 2012

Alco,

If you want to change from 32-bit to 64-bit DCs… then just spin up a couple 64-bit DCs, move your FSMO roles to them, and demote your 32-bit DCs. The 2 types should co-exist rather nicely until your done your migration.

Of course, you might want to consider moving your DCs directly to Win2K8R2 systems. You shouldn’t have a problem with them intermingling for now. Then, you can just retire all the Win2k3 DCs just before you’re ready to upgrade the functional level of the domain itself.

I’m sure you’ll find your own set of challenges along the way, so come on back and tell us about your hurdles. We’d like to learn from them in return.

Thanks.

8. Jim - June 23, 2013

I just need to replace the drive in my 2003 server – I gather I can use this methodology to do so given I am restoring to virtually the same hardware (other than the new drive).

9. Manan - July 18, 2013

I want to format my ibm x3200 server having 2003 standard edition can i backup and restore AD in 2003 enterprise edition in other pc say p4 2gb ram and 80 gb hdd

10. General Zod - July 19, 2013

I suppose you could. However, if your AD is currently online, but only on a single server (assumed your x3200)… then why don’t you build a 2nd Domain Controller on another box and move the FSMO roles to it. Then, you can demote the x3200 server to a Member Server and take it down, format it, etc. I’d think that that would be the safest way to do it. Of course, if you’re only running your AD on a single box, then a PC wouldn’t be my first choice… but you do what you have to do.

Carl - July 19, 2013

General,

Do I need to add the AD role first before I do the restore of the system state or do I just press F8 at boot up and restore the system state backup?

Thanks

11. General Zod - July 19, 2013

Carl,

Keep in mind that this article is written specifically for Windows 2003… which did not have “roles” per se. If you leverage it to restore a Win2K8 (or higher) AD environment, then use at your own risk. (And let me know how it goes… because I’d be interested.)

However, if you can successfully leverage this process for a Windows 2008 AD, then I’d ASSUME that you would NOT need to pre-install the AD role… since you’re basically restoring on top of a generic OS.

One day, I might update this article for Win2008 and Win2012… but since my professional responsibilities no longer involve domain administration, updating the article hasn’t been a priority. (These days, I work primarily as a specialized Virtualization Engineer.)

12. Jason - May 23, 2014

This is still a very useful article! We had one of our two Server 2003 domain controllers die last week and did not have very good backup/recovery processes in place. I am using this article as reference to build a new DR plan for our two domain controllers.

13. RyanH - October 1, 2014

Thanks for this! It’s still useful and relevant today🙂.

14. Oscar G - July 29, 2015

Extremely well explained. Thank you for taking the time to document this process so well. We appreciate that very much.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: