Tuesday, August 25, 2009

Best Practices for Active Directory Schema changes

Part of my job is to extend AD Schemas to support new versions for products like Exchange and OCS, and this is part of what I do prior to Schema changes for customers as well as internally.

First off, a quick review of AD schema, and what it is and the function it performs. The Schema is essentially the "database" that AD resides in, so when we say things like "extending the schema" we mean the same thing any SQL DBA would mean - we are adding additional objects attributes to AD. These new additions allow for features in products that were not previously there to store their settings in Active Directory.

Some of the recent Schema extensions you will see:

  • Exchange 2007 SP2 requires schema extension.
  • Exchange 2010 requires schema extension.
  • OCS 2007 R1 or R2 require schema extension.

Additionally, while not an extension, these best practices also apply before raising your forest or domain functional levels.

Step One - Determine your Schema Master FSMO role holder

  1. On any domain controller, click Start, click Run, type Ntdsutil in the Open box, and then click OK.
  2. Type roles, and then press ENTER.
  3. Type connections, and then press ENTER.
  4. Type connect to server <servername>, where <servername> is the name of the server you want to use, and then press ENTER.
  5. Type q to return to the fsmo maintenance prompt.
  6. At the FSMO maintenance: prompt, type Select operation target, and then press ENTER again.
  7. At the select operation target: prompt, type List roles for connected server, and then press ENTER again.
  8. This will display all 5 FSMO roles. The one that has Schema is the one we need to back up.
  9. Type q 3 times to exit the Ntdsutil prompt.

Step Two - Ensure you have your DSRM password

  1. Most of the time, even if this is known, it has not been changed in a long time and is likely due.
  2. Follow instructions to reset DSRM password from KB322672
  3. This allows your backup to be authoritatively restored in the case you need to. Without this password being correct, your backup may not be usable.

Step Three - Take a system state backup (or two)

  1. I recommend taking an ntbackup.exe (Windows 2003) or Windows Server Backup (Windows 2008) if you are more comfortable with Microsoft restore procedures.
  2. I recommend taking another backup using whatever third party vendor product you typically use, if you are more comfortable with their restore procedures.
  3. I usually recommend taking BOTH of the above for the Schema Master FSMO role holder.

While I have YET to run into any issues or problems with Schema extensions, if I ever did, I know I want a really good backup or two!

Backing up Exchange 2010 and Exchange 2007 SP2 using Windows Server Backup

2/17/2010 Update

Hi there - this was written in August 2009, 3 months before Exchange 2010 released, and these screen shots are Windows 2008, not Windows 2008 R2. We are now almost 3 mos PAST RTM of Exchange 2010 and there are starting to be other options for backup solutions. I am trying to keep a running list of these here:


Now, on to the main article:

In both Exchange 2007 SP2 on Windows 2008 and Exchange 2010, Microsoft has enabled Windows Server Backup to allow VSS backups of the Exchange database. I hope to shed some light on how to configure these backups, for both one off backups as well as scheduled daily backups.

First off - how to take a ONE off backup.

Launch Windows Server Backup on your mailbox role, and click the "Backup Once…" action.

Not having a schedule at this point, only "Different Options" is a choice

Only full server or custom is a choice. I am OK with Full server, but I will go with Custom for this.

Now, we can see that there is not much granularity to selections. Since this is VSS based, it has to be by disk. You can also see there is no "Information Store" to choose. Select ALL volumes that host Exchange (this is why I am OK with Full Server above)

For location - if I choose local drive, I will have only the DVD as an option. You cannot back up a drive to a drive that it is backing up. (this is the one down side of VSS in my opinion. It was nice to exclude e:\backups and save them there)

Specify location:

If you specify a location already used, you will receive this message.

This is nice because unlike old scheduled ntbackup.exe BKF files, we won't have an ever-growing backup set that is not being watched.

Something to note here - when you do this as a scheduled job, it needs to be a local disk. A network share will not suffice. I have used an iSCSI SAN device

This is an IMPORTANT step. If you choose copy, your tlogs won't be flushed, and your databases will not register as backed up.

Confirm the settings (not pictured screen) and then click BACKUP and you can watch progress of the VSS backup. Here the shadow copy is produced.

Exchange 2010 consistency check being run:

This backup process flushed transaction logs in Exchange 2010, marked the databases housed on Exchange 2010 as backed up. The backup set is larger than my actual Exchange data would be since I am backing up all the binaries on C every time.

This is a GREAT tool and I am very glad Microsoft listened to the need for an included backup utility.