Exchange Schema Version
Following the schema extension, setup assigns a unique value called "Exchange Schema Version". This value is queried by the ScGetSchemaVersion function to retrieve the current Exchange schema version. In this manner setup determines whether a schema update is necessary on rerunning the installation.
This article explains the schema version of Exchange 2007 RTM. For Exchange 2007 SP1 and newly added attributes please check the following:
Active Directory Schema Changes (SP1)
You can check whether setup extended the Active Directory Schema for Exchange or not using the following methods:
LDP.exe
ADSIEdit.msc
ExchangeSetup.log
Exchange Server Progress Log.log
These are the values for the Exchange Schema Versions:
Exchange 2000 Server - 4397
Exchange Server 2003 - 6903
Exchange Server 2007 RTM - 10628
Exchange 2003 will show the following entry at the Exchange Server Setup Progress.log file.
FIGURE B.5 - Exchange Schema Version shown for Exchange Server 2003
Exchange 2007 doesn't show the same message as in Exchange 2003. Instead it identifies the schema version by executing the ScGetSchemaVersion function as discussed in the first section of this article series. The Exchange Server Setup Progress.log shows the following:
FIGURE B.6 - Exchange Schema Version in Exchange 2007 Setup
For Exchange 2007, the attribute ms-EXCH-Schema-Version-Pt at /dc=com/dc=Test/cn=Configuration/cn=Schema contains the schema version. You need to check the rangerUpper value. Exchange 2007 setup log just displays the schema version but the entry doesn't clearly tell whether it requires updating the schema or not. Instead, this is logged in the ExchangeSetup.log file as shown below:
FIGURE B.7 - Displaying Exchange Schema Status in the ExchangeSetup.log file
The "True", as shown in above figure, indicates that the Schema needs to be extended.
Using LDP.exe you need to bind and connect to the domain and then search ms-EXCH-Schema-Version-Pt to get the value of rangerUpper.
Using ADSIEdit.msc to check rangerUpper, select ms-Exch-Schema-Version-Pt as shown below:
FIGURE B.8 - Checking Exchange Schema Version using ADSIEdit.msc
If anything goes wrong on extending the schema, the Exchange Setup doesn't start at all. You need to clean the Exchange-Specific classes from the schema container. This task isn't easy to perform as you have to make a lot of changes to the LDF files. We have two options. If you know which schema extensions completed successfully you can simply edit the Exchange-specific classes using ADSIEdit.msc snap-in and then delete them completely from Active Directory. Note: Schema deletion is not possible using standard tools. This requires a couple of steps to be performed if you want to delete using ADSIEdit.msc snap-in. This is out of scope for this article. If you are not sure which classes have been added by the setup then you have to completely depend on the LDIFIDE mechanism.
You can use existing LDF files to delete Exchange classes/attributes from the forest. In order to do that, you need to edit all the LDF files one by one and then change the CN and ChangeType to Delete. As an example, the SCHEMA0.LDF file contains the following entry in it as shown below:
FIGURE B.9 - Contents of SCHEMA0.LDF file
The first entry is the DN that contains the full AD path where the Setup will import the contents of this file. Look at the path, the entry is not complete. We have the <SchemaContainerDN> tag that needs replacement. Apart for that we also need to tweak the changetype value.
dn: CN=ms-Exch-Access-Control-Map,<SchemaContainerDN>
changetype: add
The DN should reflect the complete LDAP path and the changetype should be set to "delete".
After changing all the LDF files, these will look as shown below:
FIGURE B.10 - Contents of LDF after modifying the DN and ChangeType
We can now import these using LDIFDE. For details on LDIFDE commands please check out the following Microsoft Knowledge base articles:
LDIFDE - Export / Import data from Active Directory - LDIFDE Commands
http://support.microsoft.com/kb/555636
http://support.microsoft.com/kb/555637
Troubleshooting Tips
If setup is not able to extend the schema then you need to make sure that:
- The schema master is contactable. Look in Exchange Server Setup Progress.Log for the following entry:
FIGURE B.11 - Exchange Server Setup Progress.log showing Schema Master Name
Make sure you have the permissions on the following NCs as described earlier in his article series:
/dc=com/dc=domainname/cn=Configuration/cn=Services
Read, Write, SetPermissions
/dc=com/dc=domainname/cn=Configuration/cn=Schema
Update Schema (Read, Write)
/dc=com/dc=domainname
Read, Write.
Make sure all the Domain Controllers are running - Check this using the NetDiag and DcDiag tools. No error should be reported. Exchange Setup will also fail if any of the Domain Controllers is not contactable.
Setup uses LDAP protocol over port 389 to contact the Schema Master. Make sure the port is open.
Make sure you see the following entry in ExchangeSetup.Log. This tells you whether the setup is ready to extend the schema or not. If you don't see this then go back to the other steps.
FIGURE B.12 - Exchange Setup ready to extend the Schema
***
Internally setup uses the LDAP protocol to import LDF files into Active Directory. It uses Port 389 as a source port and the destination port would be any dynamic port above 1024. Setup only uses LDIFDE to import the LDF files but LDIFDE internally uses the LDAP protocol to contact the domain controllers. Note further that setup already knows the schema master name returned by CDirectoryManager procedure as discussed earlier in this article series.
How does Exchange Setup detect that it is going to operate in a cluster environment?
The Exchange Setup checks to see if it is going to install in a cluster environment by looking for the ClusSVC.exe process. Setup doesn't really look for the cluster modules or DLL files. Instead it checks the Cluster Service status. If the Cluster Service is running it will proceed to install the Exchange Server in the cluster. If the Cluster Service is not running or is stopped for whatever reason, then it will give an error message that the cluster service is not running. Setup always uses the Service Control Manager to interact with the Cluster Service.
The Exchange 2007 cluster setup changed from previous Exchange versions. The setup will proceed with no initial notification and installs the binary files on the cluster node. There will be no user intervention at all after you supply the common setup information.
The Setup Wizard doesn't check the Cluster Service registry at HKLM\System\CurrentControlSet\Services\ClusSvc. As shown in figure B (see article Part 3), it checks the ClusSvc.exe system instance which can be seen running through the Task Manager and executes a series of API calls via the Service Control Manager (SCM) to check the status of the Cluster service. If setup detects that there is a live instance of the ClusSvc.exe running then it will install the cluster version of the Exchange Server. You can also perform a couple of tests on the ClusSvc.exe using SC.exe to make sure it is operating normally and also accepting commands from the Exchange Setup.
Troubleshooting Tips
If you're troubleshooting an Exchange Installation in cluster, your first task is to make sure that the cluster is up and running (e.g. Cluster Service is running). If setup has detected that the cluster is operating normally then it will log a message in the ExchangeSetup.Log file as shown in the figure below:
FIGURE B.13 - ExchangeSetup.Log file showing Cluster Message in Exchange Server 2007
FIGURE B.14 - Exchange Server Setup Progress.log file showing Cluster Message in Exchange Server 2003
Conclusion
In this part we started our discussion with the Exchange Schema version detection and saw the different version numbers in use by Exchange. We also highlighted the logging information that is reported in case a schema update is required and discussed what to do if the setup stops responding in the middle of a schema update.
Finally, we saw how setup detects that it is going to operate in a cluster environment and the corresponding entry in the Exchange Setup log files. In the next part we will look at the Exchange Cluster Installation process and the files used to make an Exchange Server cluster-aware.