As we know the PDN issues cause massive problems and contribute full OAB downloads. Recently I just worked an issue for two large global customers that were receiving Event ID 27’s for Mod diff failures, however the Event ID 27’s were not indicating signature mismatches. A signature mismatch will cause Outlook clients to fail when applying the OAB differential files because there are problems with the offsets in the OAB files.
This case was fixed in Exchange 2003 and will not be fixed in Exchange 2000, however I added a new check to OABInteg that will allow administrators who are running Exchange 2000 server to search all of the objects in the /Global Address List and look for the ‘@’ character in the legacyExchangeDN. If the legacyExchangeDN has the @ character in it, it will need to be removed. If they are all removed before the next OAB generation the problem will not occur.
Now when OABGen.dll is reading in all GAL objects during the OAB generation it will detect this character in the legacyExchangeDN, and interrupt this as a new proxy address when in fact it’s part of the RDN (Relative Distinguished Name). This will alter the state of the legacyExchangeDN which is used for indexing on the Outlook client side. When the Outlook client downloads the OAB files and tries to apply the OAB differential files, it will detect this change and cause the differential OAB file apply to fail. As a result of the failure the Outlook client will need to perform a full OAB download. The reason both customers were running in to this problem is that they are both generating the OAB on an Exchange 2000 server and they were hitting this case.
Here is the scenario for the problem:
- Monday morning – OAB Generates the OAB successfully.
- Monday afternoon – Clients download the OAB differentials just fine
- Tuesday morning – OAB Generation reads in a GAL object that contains the ‘@’ character in the legacyExchangeDN.
- Tuesday afternoon – Clients download the OAB differential files and fail to apply them. With Outlook advanced logging turned up the Event ID 27 was displayed, however there was no evidence of a signature mismatch. Outlook client will perform a full OAB download.
There is a simple fix for this problem if you are on Exchange Server 2000. You need to scan all of the legacyExchangeDN’s, and find the objects that have the ‘@’ character in the legacyExchangeDN and remove it. The ‘@’ character DOES not belong in the legacyExchangeDN.
NOTE: If these objects are found on Exchange 2003 they will NOT be a problem, however it will allow you to fix them. If you are running on Exchange 2000 this will cause full OAB downloads.
So to find the objects you can run: OABInteg.exe /s:srvname /t:proxytest /v:2 /l (this will create a c:\OABInteg.txt file). You can then search the text file and look for the following text: **PDN WARNING – LegacyExchangeDN has the @ character present. This can cause full downloads on Exchange 2000.
I have also added a new counter that will display the total objects found that meet this criteria. The counter looks like this: Total objects with the ‘@’ character in the legacyExchangeDN: 10.
The new version has been posted to: http://gotdotnet.com/Community/UserSamples/Download.aspx?SampleGuid=A2338E73-F521-4071-9B1D-AAF49C346ACD.