Corelan Cybersecurity Research

Updating from 2003 to 2003 R2 & implementing Exchange are 2 common administrative tasks which both require a schema update. Since I’ve mentioned "updating from 2003 to 2003 R2", I’ll take the opportunity to add some "notes from the field" to this blog post, which will increase success rate of the update and limit the risk of the schema update itself.

I’ll jump into a technique that will allow you to safely apply a schema update without messing up an entire AD forest right away, but first, I’ll explain some steps on how to apply the R2 update. I’ll assume that you have 2003 with SP1 (or higher) running on all DC’s. If your environment doesn’t meet this assumption, I recommend upgrading to 2003 SP1 first. A domain that has SP1 applied, will also have the necessary domain partitions that are required to complete the R2 schema update. This means that, if you have SP1 or higher running on your DC’s, then you don’t need to run adprep /domainprep.

Before starting any schema update, it is important to

• Ensure a good backup of at least the DC’s that have the FSMO roles. This will allow you to restore quickly in case something does go wrong
• Verify proper replication between your DC’s. Run repadmin /replsum /bysrc /bydst /sort:delta on every DC and look for failures. If you have failures, you need to fix those prior to running the update.
• Realize that there is no automatic o rollback scenario for a schema update. If it goes wrong or if you applied it by mistake, you’ll have to go back and restore your DC. All of them… (unless you use the following procedure and verify the update before replicating it down)

Applying R2 schema update to 2003 SP1 Domain Controllers

First of all, locate the Domain Controller that holds the schema owner FSMO role. You can do this by running either dcdiag /test:KnowsOfRoleHolders or netdom query fsmo at a command prompt on a DC.

Next, verify that the schema operations master has performed inbound replications of the schema directory partition since the last time the server restarted by running repadmin /showrepl. Check date and time of last successfull replication.

Before running the adprep, disable replication on the DC that holds the schema owner FSMO role. This will allow you to revert back to your backup (perform an authoritative restore) on this DC and you’ll be fine in case something goes wrong during the adprep. Suppose the DC that holds the schemo ower FSMO role is called mydc01.domain.com, then you should run the following command, at a command line on that DC, to stop AD replication : repadmin /options mydc01.domain.com +DISABLE_OUTBOUND_REPL +DISABLE_INBOUND_REPL. You will get a message showing the options that are still active on the DC. Make sure Disable_outbound and disable_inbound replication are now part of those options after running the repadmin. A good example of what you could get as a result is
Current DC Options: IS_GC
New DC Options: IS_GC DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL

Next, on the same DC, disable Sysvol replication :

SC.EXE \\mydc01.domain.com STOP NTFRS
SC.EXE \\mydc01.domain.com CONFIG NTFRS START= DISABLED
(don’t forget the SPACE between ‘start=’ and ‘disabled’!)

Now you are ready to perform the update. After applying the update, you can evaluate if your DC still looks fine before opening the gates and propagating the new schema to all other DC’s in the forest.

In order to apply the update, log on to the DC that holds the schema owner role, with schema admin rights. Load the 2003 R2 second CD-Rom. Change to the Cmpnents\R2\Adprep folder of 2003 R2 Disc 2, and type: adprep.exe /forestprep. This is what you’ll get :

ADPREP WARNING:

Before running adprep, all Windows 2000 domain controllers in the forest should
be upgraded to Windows 2000 Service Pack 1 (SP1) with QFE 265089, or to Windows
2000 SP2 (or later).
QFE 265089 (included in Windows 2000 SP2 and later) is required to prevent potential domain controller corruption.
For more information about preparing your forest and domain see KB article Q331161 at http://support.microsoft.com.

[User Action]
If ALL your existing Windows 2000 domain controllers meet this requirement, type
C and then press ENTER to continue. Otherwise, type any other key and press ENTER to quit.

>>> Type "C" and press ENTER

Opened Connection to MYDC01
SSPI Bind succeeded
Current Schema Version is 30
Upgrading schema to version 31
Connecting to "MYDC01"
Logging in as current user using SSPI
Importing directory from file "C:\WINDOWS\system32\sch31.ldf"
Loading entries…………………………………………………………………………………………………………………………..
139 entries modified successfully.

The command has completed successfully

Adprep successfully updated the forest-wide information.

When you change the schema on the schema operations master, the changes are automatically propagated to all other domain controllers in the forest. Therefore, it is not necessary to perform this operation on other domain controllers.

Before opening the gates, verify that the R2 schema update was applied successfully. Note : the following procedure contains references to values that represent the R2 schema version. If you are applying different schema updates, the values may differ. Look in schema update release notes or application manual to check the corresponding value.

Log on to an administrative workstation that has ADSI Edit installed.

Click Start, click Run, type adsiedit.msc, and then click OK.
Double-click Configuration Container, and then double-click CN=Configuration,DC=forest_root_domain
(where forest_root_domain is the fully qualified domain name (FQDN) of your forest root domain.)
Double-click CN=ForestUpdates.
Right-click CN=Windows2003Update, and then click Properties.
Verify that the Revision attribute value is 9.
Double-click Schema.
Right-click CN=Schema,CN=Configuration,DC=forest_root_domain
(where forest_root_domain is the FQDN of your forest root domain.)
Click Properties.
On the Attributes tab, Select a property to view, select objectVersion.
Verify that Value(s) equals 31.

Feel free to reboot the DC and see if it still works fine.

If you are confident that the update was successful, you can enable replication again :

Enable AD replication :

repadmin /options mydc01.domain.com -DISABLE_OUTBOUND_REPL -DISABLE_INBOUND_REPL
Current DC Options: IS_GC DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL
New DC Options: IS_GC

Enable sysvol replication :

SC.EXE \\mydc01.domain.com CONFIG NTFRS START= AUTOMATIC
SC.EXE \\mydc01.domain.com START NTFRS

(don’t forget the SPACE between ‘start=’ and ‘AUTOMATIC’!)

Now wait for the replication to kick in. You can use the repadmin /replsum /bysrc /bydst /sort:delta command again to verify replication, you can also you dcdiag to test replication, and you can go to each DC, open adsiedit.msc and verify the Revision and objectVersion attribute values as shown in the procedure above.

If the change is applied to all DC’s, then your domain is R2 aware. You are now ready to use R2 specific features on your member servers (such as FRS etc); or even upgrade your domain controllers to R2. In that scenario, I would recommend to start with the FSMO role holders first. (First PDC’s, Rid, etc…; then upgrade other servers)

Exchange 2003 Schema change

Most (small scale) Exchange installations are launched on a member server (or domain controller), with an admin account that has schema editor rights. But in larger implementations, where privileges are limited and schema updates are assigned to a happy few only, you’ll have to do it differently. Basically, you’ll need to use the same procedure as explained above, but instead of running the adprep from R2, you’ll have to run the setup /forestprep from the Exchange CD-Rom, in the domain that hosts the DC which has the schema owner FMSO role. Preferably, run the setup /forestprep on the DC itself. Of course, you need to be logged on with schema update rights . The Exchange schema update requires a schema update to be performed on a forest level, and maybe on a (child) domain level. You’ll have to log on with schema update rights every time. Don’t forget to backup, stop replication, and verify the update before doing anything else. If you have applied the forest update first, then wait until it has replication to all DC’s before doing a domain update.

Exchange 2007 Schema change

In Exchange 2007, the process is different again. As you know, Exchange 2007 only runs on 64bit machines. However, in most cases, the DC’s still run on 32bit architecture. So before you can run the schema update separated from the installation of Exchange itself, you’ll need 32-bit binaries. Start with downloading the Exchange 2007 32-bit evaluation DVD from http://www.microsoft.com/technet/prodtechnol/eval/exchange/default.mspx.
Next, install PowerShell on the 32bit DC that will be used to perform the schema update (http://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx)
You will also need the .Net Framework 2.0 (http://www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-aab15c5e04f5&displaylang=en) and a required update (http://www.microsoft.com/technet/prodtechnol/exchange/Analyzer/729d1648-ff17-43f9-a1cf-4285a82d4917.mspx?mfr=true). Also, make sure you are running MMC 3.0. If you are not running on Windows 2003 R2, then you’ll need to download and install this package : http://www.microsoft.com/downloads/details.aspx?familyid=4C84F80B-908D-4B5D-8AA8-27B962566D9F&displaylang=en
Now, you are ready to perform the update.

First of all, check the steps in the first part of this blog. Make sure replication works, make sure you have a backup, and then stop replication.
When all prerequisites have been met, Login to the schema master with an account that is a member of both the Schema Administrators and Enterprise Admins. Load the Exchange 2007 32bit evaluation DVD in the drive.
From a command prompt, go to the DVD drive
If you have 2000 or 2003 Exchange servers in your environment, check http://technet.microsoft.com/en-us/library/bb125224.aspx (setup.com /PrepareLegacyExchangePermissions)

Run setup.com /PrepareSchema
Run setup /PrepareAD
Run setup /PrepareDomain

Note : You will need to run the /PrepareDomain in each domain that will host Exchange 2007 servers.

If the update goes wrong…

…then hopefully you did not enable replication again yet. Just go into Directory Services Restore mode and perform an authoritative restore of AD.

If you did enable replication and you have a corrupted schema, or wrong schema, you’ll have to rebuild the entire AD starting from the top.
Turn off every DC, and start restoring AD from the top down. Start with the FSMO role holders. When they are up and running, remove the non-FSMO holders from AD using a metadata cleanup, and then set up new boxes and dcpromo them into AD.
If you don’t have the proper backups to restore the FSMO role holders, you’ll have to rebuild AD from scratch. Ouch. Don’t go around and say that I didn’t warn you !!! ?