A Closer Look at Preparing Active Directory for Exchange 2007 (Part 3)

If you missed the other parts in this article series please read:






Over the course of the first two parts of this article we have looked at the first step required when preparing Active Directory to receive Exchange 2007, namely the preparation of legacy Exchange permissions. For those of you that are not coexisting with either Exchange 2000 or Exchange 2003 this step will not be required. However, throughout the first two parts of this article there is extremely useful information that may prove of worth to you in the future, such as using tools such as LDP to determine if the specified permissions have been set correctly. If you have skipped the first two parts of this article because you are not coexisting with either Exchange 2000 or Exchange 2003, I still urge you to read these parts anyway.


Now it is time to move on with the rest of the Active Directory preparation steps, starting with the preparation of the Active Directory schema.


Preparing The Schema


Like legacy versions of Exchange such as Exchange 2000 and Exchange 2003, Exchange 2007 requires updates to the Active Directory schema in order to operate. Therefore, you will need to ensure that the account you use for the following process is a member of the Schema Admins group. In addition, the account also needs to be a member of the Enterprise Admins group to successfully complete the schema update process. You will likely need to plan ahead for making this change since, in secure environments, it is likely that membership of these groups is not given out at a moment’s notice. Finally, note that you must have access to the Active Directory domain controller running the schema master role to run this process since you are making changes to the schema. Specifically, run the schema preparation process from a server that is located in the same Active Directory site and domain as that of the schema master. If you don’t, the organization checks portion of the schema update process will fail with this descriptive error:


“Setup needs to contact the Active Directory schema master but this computer is not in the same Active Directory domain as the schema master (DC=domain,DC=com).


Setup encountered a problem while validating the state of Active Directory: Exchange organization-level objects have not been created, and setup cannot create them because the local computer is not in the same domain and site as the schema master. Run setup with the /prepareAD parameter on a computer in the domain {domain} and site {site name}, and wait for replication to complete.”


In parts one and two of this article we have already prepared the legacy permissions via the setup /pl command since we are coexisting with Exchange 2003. However, if for some reason you have not issued this command and you are going to coexist with legacy versions of Exchange, note that it will be performed as part of the schema update process that I am about to cover.


In this article we are coexisting with Exchange 2003 so it is worth pointing out that the Exchange 2007 schema update also includes the schema updates applicable to both Exchange 2000 and Exchange 2003.


To prepare the schema with the Exchange updates, you use the following command:


setup /PrepareSchema


As with the command used for the preparation of the legacy permissions there is a shortened version of the schema update command. It is:


setup /ps


In my example environment I am going to run setup /ps on the root domain controller called AD-ROOT. You can see the result of running this command in Figure 15 where the updates have been successful.


Figure 15: Successful Schema Update


Updating the schema can take a few minutes. If you want to check that the process is running, then during the Extending Active Directory schema portion of the process navigate to the TEMP folder of the user account that you are using to perform the schema update process. By default, the user’s TEMP location will be the %USERPROFILE%\Local Settings\Temp folder. You can see what this looked like during my schema update in Figure 16.


Figure 16: Contents of The TEMP Folder


As you can see from Figure 16 there are three temporary files in this location at the time I captured the screen shot. The file of interest is highlighted, namely ldif.log. This file, at the time of the screen capture, contained the contents of one of the specific LDIF files from the Exchange 2007 source files and was the LDIF file being imported at the time. If you monitor the contents of the TEMP folder during the schema update process, you will see the ldif.log file alternate between 0KB and around 3KB as the different LDIF files are processed. Figure 17 shows you the contents of the ldif.log file at a specific point in time during the schema update process.


Figure 17: Contents of LDIF.LOG


Active Directory Replication


It is recommended that you check Active Directory has replicated the changes throughout your environment once you have made the changes in any of the steps in this article series. To confirm whether the schema update has been applied to your domain controllers, you can check the value of rangeUpper on the ms-Exch-Schema-Version-Pt attribute using ADSIEdit when connected to a specific domain controller. This attribute is used to track the version of the schema that has been installed and since the rangeUpper value for Exchange 2007 SP1 is 11116 that is the value we need to look out for. If you are reading this article and Microsoft has released a new service pack for Exchange 2007, this value will be different so be sure to check out what the new value should be. Here’s how to confirm that a domain controller has this value set. This process assumes you’ve installed the Windows Support Tools since that’s where you obtain ADSIEdit.



  1. Run ADSIEdit.msc
  2. In the left-hand pane of the main ADSIEdit window, expand the Schema object and then select the next Schema object that appears below it.
  3. In the right-hand pane, locate the CN=ms-Exch-Schema-Version-Pt attribute, right-click it and select Properties from the context menu.
  4.  In the resulting properties window, scroll down the list of attributes until you reach the rangeUpper attribute. Check that the Value column shows 11116 as you can see in Figure 18.


Figure 18: Value of rangeUpper


Another tool supplied with the Windows Support Tools that is useful for checking Active Directory replication is the Active Directory Replication Monitor, replmon.exe. Here is what to do to use this tool:



  1. Run Replmon.exe and you will be presented with the main Replmon window as shown in Figure 19.


Figure 19: Replmon Main Window



  1. In the left-hand pane, right-click Monitored Servers and choose Add Monitored Server… from the context menu. The Add Monitored Server wizard opening window appears.
  2. In this opening window, select the relevant option to either add the domain controller by name or search a specific domain. Since I only have a few domain controllers in my lab, I’ll choose to add the server by name.
  3. In the Add Server to Monitor window, the option available is Enter the name of the server to monitor explicitly and therefore in this field I enter the Fully Qualified Domain Name (FQDN) of a domain controller to monitor as you can see in Figure 20.


Figure 20: Adding a Specific Server



  1. After you click Finish, you will be back at the main Replmon window but this time a connection has been made to the chosen domain controller. Repeat this process for other domain controllers as required and you should see a screen similar to the one shown in Figure 21.


Figure 21: Replmon With Monitored Servers



  1. It is now possible to check the replication of the various containers by expanding them and checking the information presented in the right-hand pane. For example, look at Figure 22 where you can see that replication was failing before the successful update.


Figure 22: Replication Failure and Success


You may remember that in part one of this article we briefly covered the fact that Exchange creates setup log files during the various Active Directory preparation tasks. If you have looked again in the C:\ExchangeSetupLogs folder during the steps listed in part two of this article, you may have noticed that the schema update process also creates the PowerShell script called Install-ExchangeOrganization-{DATE}-{TIME}.ps1. Examining the contents of these programmatically generated PowerShell scripts can help your understanding of the Exchange setup process, so it’s worth checking them out.




Here in part three of this article we have covered a very important part of the Active Directory preparation process, namely the preparation of the schema. It can be said that all parts of the preparation process are vital to the successful running of Exchange, but there is always that something extra about updating your schema. It is important to verify that the schema has updated correctly so use the steps in this article to do so.


If you missed the other parts in this article series please read:



About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top