CheckADC (English Version)
Diese Information ist auch auf Deutsch verfügbar. Siehe CheckADC.
All Scripts are provided "AS IS". No guarantee etc.
We all know, that the ADC is a very important component during a exchange 5.5 to Exchange 2000/2003 migration. The ADC ist responsible to replicate informations about users, groups, public folders and configuration between both systems. (It does not replicate the content of mailboxes nor public folders)
But because it's such an important thing, we should be able to monitor it's state and process. Unfortunaly it looks like that there is no tool to check the ADC and its progress. Of course you can activate diagnosting logging and check the eventlog. But have you ever tried that in an lager environment with many ADC connection agreements on different servers ? I had to to that many times in the past and especially if you want to remove the last exchange 5.5 server and the ADC-CAs later on, you should make sure, that everything is already in out active directory.
ADC internals
So write a monitoring script, we have to learn, how the adc works internally and what we can monitor. The adc uses connection agreements, to replicate certain sources to a default target and back. It's a link between two directory services. the initial replication hast to replicate a lot of data but subsequent replications are only replicating modified objects. So there must be a way to find not replicated objects.
The adc uses the USN number of the directory services to find newer objects and stores them in a special locations with the connections agreement. After the adc finished a replication, it stores the highest USN for future use. During the next replication, the adc simply queries for objects with a higher USN. Additional the ADC must check, that these newer objects require replication.
These USNs are stored with the connection agreement in the following fields
| field | type | meaning |
|---|---|---|
| msExchServer1ExportContainers | Multivalue | Conatins all source OU's in the AD, which must be replicated to the exchange 5.5 organization |
| msExchServer1ImportContainer | String | This is the default target for new objects during a replication from exchange 5.5 to the active directory |
| msExchServer1NetworkAddress | String | Name of the active directory domain controller |
| msExchServer1HighestUSN | last processed USN of that domain controller (keep in mind, USNs are different per DC) | |
| msExchServer2ExportContainers | Multivalue | contains all source recipient containers in exchange 5.5 for replication into the ad |
| msExchServer2ImportContainer | String | contains the default recipient container for new objects during a replication from AD to exchange 5.5 |
| msExchServer2NetworkAddress | String | Name of the exchange 5.5 server (or SRS !!) with a dir.edb or srs.edb |
| msExchServer2HighestUSN | String | last processed highest usn of the exchange 5.5 directory service |
How CheckADC works
With these informations in mind we gan explain, how CHECKADC is working. Think about the following simple logic
- direction: exchange 5.5 to AD
IF EX5:highestCommittedUSN > ADC:msExchServer2HighestUSN then Check EX->AD - direction: active directory to Exchange 5.5
IF AD:highestCommittedUSN > ADC:msExchServer1HighestUSN then Check AD->EX
CHECKADC is simply performing that tests. It loops through all connection agreements and checks the stored highestUSN against the current USNs of the targetserver. These are two tests per connection agreement (if set to bidirectional). But it does some more things. We have to connecto to all Servers, which are used in the CA, we have to check the direction and do the right tests. And we have to check, how many objects require replication. the USN difference is not the main key, because the USN are incremented, if you modify any object in the ad, even if it has nothing to do with exchange.
All results are stored in a XML-file for further processing. Here is a sample output:

The XML-files contains informations about the connection agreement and all parameters. If you have a look at the sample, you can see, that the USNDiff tells us, that there are 389 modified objects, which are not yet replicated. But if you check the "MissedObjects" you can see, that no objects are really missed. If there are objects, you can also see which objects are pending for replication.
It's very easy to create a nice looking output with a XSL stylesheet. But because it's xml you can use it as souce for further processing. Here you see a output with internet explorer.

Hey just kidding. this is my virtual machine with only on CA left. you can imagine, how it looks in a larger Installation. Every connection agreement create a line per replication direction. So if you have 20 bidirectional connection agreements, you will have 40 rows.
This picture shows a much more interesting exchange organisation.

The stylesheet is used for adding some colors. green means "good", yellow means something like "some objects pending". Red means, that there could be something wrong. there are many pending objects. That can be possible, if you are migrating hundreds of users or distribution groups and the adc hat to update many objects. but its a good indicator to analyse these connections agreements. And the Script tells you, which connection agreements are scheduled to "newer"
Using the Script
You must have sufficient permissions to use that script. Ths script itself is only "READING" data from the active directory and all servers, which are used in any connection agreement. So make sure you can read all that stuff. You can use some parameters
C:\>cscript z:\CheckADC.VBS [/debug:xx] [/Target:adc-dn] [/MaxDelta:xxxx]
Description of the parameters:
- Debug
Use that to enable a debugging. 0 = only normal output to the screen and debug file. you can use 1 up to 6. a higher number results in a more detailed debug log. Output is written to the screen and a debug file. - Target
You can specify a DN of a connection agreement to test. simply do not specify that parameter to get a full test. - MaxDelta
You can specify a maximum value for a error. If a connection agreement has more pending objects, we will create an ALERT. This is done in the screen but if you are running that script as MOM2005-Test, you will get an MOMAlert also.
You HAVE to edit the following line in the script
const XMLOUTFILE = "C:\temp\fcarius\Checkadc4.xml"
Please specify a valid path and file name for the XML-File.
MOM Integration
Do you like MOM2005 ? i do and so i have written that script for both environments. You can run taht script with CSCRIPT" or inside of MOM2005. the script automatically detects, if its running inside MOMHOST and uses the correct objects. Use the MaxDelta Parameter to specify the limit for generating an alert.
Download
Information
This script is only useful, if you are still running exchange 5.5 and
Exchange 2000/2003 together in one organzation and you are using the active
directory connector. If you are running Exchange 2000/2003 in native mode, you do
not need that script anymore.
Future
This script si currently working for me without problems. it helps me to migrate mixed environments and to demonstate some of my skills. But this script is far away from being perfect. If you compare it with other scripts in my personal Franks Tools- Section, you can see, that there is still many work to do.










