Server 2008 Domain Controllers: What's Most Neat and Cool? Part #3 of 6

Schema & Functionality Changes

The following is excerpted from Chapter 7 of Windows Server 2008: What’s New / What’s Changed, available now from www.sapienpress.com.

Outside of a lab or virtual environment for testing, most initial Server 2008 Domain Controller creations will involve adding that DC to an existing Active Directory. With Server 2008, adding that Server 2008 DC will involve some changes to the Active Directory schema.

I’ve said this a few times throughout the course of this book, but schema changes are little more than updates to columns and entries inside AD’s database. As many of these changes add additional columns, anything new should not affect the current operation of your current domain. The disclaimer always exists that you should perform testing before any schema change to validate application functionality – especially so in situations where you’ve made your own custom modifications to the schema.

Let’s actually take a look at the schema changes themselves...

More after the jump.

…If you navigate to the \sources\adprep folder on your Server 2008 media, you’ll see a series of .LDF files along with an executable adprep.exe. These .LDF files are the files that include the changes to the Active Directory schema. They’re numbered in the way they are (starting with sch14) to align them with the naming of schema upgrades done as part of previous operating system upgrades.

If you open any of these files, you’ll see what columns and entries in each table that the schema upgrade will manipulate. As an example, if you open sch23.ldf you’ll see a script that looks similar to the code snippets we’ll be reviewing below. Some of the script for sch23.ldf has been removed for space reasons, but let’s take a look at three sections of this file to familiarize ourselves with what this part of the schema update is attempting to do.

In the first text block of sch23.ldf shown below, a few attributes are changed, specifically for the security settings. Here we are replacing the value attributeSecurityGuid with new settings, effectively changing the security assigned to these objects. Then we reload the schema cache for these new values to pick up their attributes.

# attributes
dn: CN=Script-Path,CN=Schema,CN=Configuration,DC=X
changetype: ntdsSchemaModify
replace: attributeSecurityGuid
attributeSecurityGuid:: ECAgX6V50BGQIADAT8LUzw==
-
dn: CN=User-Workstations,CN=Schema,CN=Configuration,DC=X
changetype: ntdsSchemaModify
replace: attributeSecurityGuid
attributeSecurityGuid:: ECAgX6V50BGQIADAT8LUzw==
-

# Reload the schema cache to pick up attributes
dn:
changetype: ntdsSchemaModify
add: schemaUpdateNow
schemaUpdateNow: 1

In the next two code blocks, instead of altering the security information we’re instead changing the value for defaultHidingValue and again reloading the schema cache. This has the effect of changing how this information is displayed.

# classes
dn: CN=Country,CN=Schema,CN=Configuration,DC=X
changetype: ntdsSchemaModify
replace:defaultHidingValue
defaultHidingValue: TRUE
-
dn: CN=Person,CN=Schema,CN=Configuration,DC=X
changetype: ntdsSchemaModify
replace:defaultHidingValue
defaultHidingValue: TRUE
-

# Reload the schema cache to pick up altered classes and attributes
dn:
changetype: ntdsSchemaModify
add: schemaUpdateNow
schemaUpdateNow: 1

Lastly, for DS-Replication-Get-Changes-All we add some new values and increase the configuration schema’s version number.

# change objects in configuration container
dn: CN=DS-Replication-Get-Changes-All,CN=Extended-Rights,CN=Configuration,DC=X
changetype: ntdsSchemaAdd
objectClass: controlAccessRight
ShowInAdvancedViewOnly: TRUE
appliesTo: 19195a5b-6da0-11d0-afd3-00c04fd930c9
appliesTo: bf967a87-0de6-11d0-a285-00aa003049e2
appliesTo: bf967a8f-0de6-11d0-a285-00aa003049e2
displayName: Replicating Directory Changes All
localizationDisplayId: 62
rightsGUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
validAccesses: 256

# Increase object version
dn: CN=Schema,CN=Configuration,DC=X
changetype: ntdsSchemaModify
replace: objectVersion
objectVersion: 23

With all of these, we’re doing the very same thing with these .LDF files as we would with .SQL files to manipulate a SQL database. We’re changing table structures and entries. To truly understand what this or any schema update will do to your Active Directory database, you’ll want to review each of the files in this folder line-by-line and evaluate if each change will negatively affect any changes you may have made to your production environment.

That being said, for most of us our AD environments are such that we’ve never needed to make custom changes. Or we don’t have tools like Single Sign On applications that directly rely on parts of the Active Directory for their functionality. In those cases, we usually can be assured that Microsoft’s changes will have little effect on our environment.

Interested in reading the whole series? Click here for a link to every post in this series.