This project is read-only.


Starting with Exchange 2010 SP2 RU6, OAB generation will skip any problem objects and report them in an event 9414 in the application log. Thus, in SP2 RU6 and later, it usually is not necessary to use OABValidate. Simply examine the application log for 9414's, and fix the indicated objects. If you can't determine what the problem is with those objects, you might consider using OABValidate to look for problems on those particular objects. But the all-encompassing search for problems should no longer be necessary.

What is it?

This is a tool for use with Exchange Server. It was originally written back in 2004 for Exchange 2003 to help troubleshoot oabgen problems, but this updated version is much better, faster, and easier to use. When you get events like this:

Event ID : 9126
Category : OAL Generator
Source : MSExchangeSA
Type : Error
Message : OALGen encountered error [0x8004010e] while calculating this OAL. This OAL will not be available for client download. (\Global Address List)

Event ID 9330
Source: MSExchangeSA
Type: Error
Category: OAL Generator
Message: OALGen encountered error 8004010e (internal ID 5000f5f) accessing Active Directory MYDC1 for "\Global Address List'.
- Default OAB

Event ID: 9339
Source: MSExchangeSA
Active Directory MYDC1 returned error 8004010e while generating the offline address list for '\Global Address List'. The last recipient returned by the Active Directory was 'Whoever' This offline address list will not be generated.
- Default OAB

You can use OABValidate to identify problem users that are preventing generation of the OAB.

Note: It is recommended you first use OABInteg and resolve any outstanding issues flagged there. After that, if the 9339 events remain, use OABValidate to scour the directory for problems. OABValidate cannot help if you are not seeing a 9339.

Note that OABValidate may report unresolvable DNs for other reasons. For instance, if you run OABValidate as a user who can not see all the mailbox stores, then when OABValidate looks at a user homed on one of those stores it may report that the homeMDB value for that user is unresolvable. It is up to you to determine whether the unresolvable DN is because of a permissions issue, or some other problem, or if that value on the user is really pointing to an object that doesn't exist.

How do I use it?

  • Put OABValidate.exe on a computer with .NET Framework 2.0 or higher installed.
  • Launch it.
  • Enter the name of the GC and hit Get OABs.
  • Choose the OABs to validate.
  • Hit Go.

What will it do?

OABValidate will look at the filters of any address lists on the selected OABs and will query for all users matching those address lists. Then, for each user returned, it will attempt to bind to any DNs contained in DN-valued attributes. As it runs it will report progress in the GUI. It finds 1000 objects at a time, and then processes those objects before proceeding to the next group of 1000 objects.

The tool creates an OABValidate folder in the Documents folder of the user running it. When OABValidate is run, it will create a new subfolder named with the current date and time in numeric form and the name of the GC it was pointing to. This folder will contain the following files:
  • log.txt - this is the log, which is the same as the output you see in the GUI
  • Fix-DC=contoso,DC=com.ldf - this is an ldifde import file. One import file will be generated for each domain in which we found objects with problems. Importing this file will delete all the bad DN values we found, except for lingering links/objects. Lingering links and lingering objects will be called out in the log with a warning stating that we didn't add them to the import file, and they will be easy to find in the tab-delimited file (see below).
  • ProblemAttributes.txt - this tab-delimited file will list every bad attribute we found in the form: object<tab>attribute name<tab>link type<tab>attribute value. You can open this in Excel to take a closer look at what exactly the tool found, allowing you to easily sort by attribute or value. Link type can be one of the following values:
    • NullValue - the link is an empty string. This can be fixed by the import.
    • UnresolvableDN - the link is not resolvable, probably because it's pointing to a tombstone. This can be fixed by the import.
    • ObjectGuidMismatch - the link contains a DN that appears to be resolvable, but it actually points to a DN that has a different objectGUID than the one stored in the link. This is usually a lingering link and cannot be fixed by the import.
    • LingeringLink - this bad link is only present on the GC (read-only), and not the DC, thus it cannot be fixed by the import.
    • LingeringObject - the whole object which contains this link is only present on the GC, thus it cannot be fixed by the import. Note: Other kinds of problems might cause an object to be flagged as a lingering object. Since any lingering objects have to be manually investigated anyway, the user will likely find the real problem when he or she attempts to investigate the lingering object.
    • LdapException - we hit an LDAP exception, and as a result, we couldn't tell whether the link was valid. This is usually because a DC is offline or something similar.
  • Statistics.txt - this small file just lists each attribute and how many times we found bad values in that attribute.

When the tool completes, you can review these files to see which attributes had problems. The most useful is probably the tab-delimited file, where you can quickly see every problem that was found.

After reviewing the problem attributes, you can use the ldifde import files to delete the bad values of type "NullValue" and "UnresolvableDN". The syntax for that is:

ldifde -s DCForThatDomain -i -f importfilename.txt

However, if you have other types of bad links, the ldifde files alone may not fix the oabgen problem. Often the ldifde files will fix a lot of bad values in attributes like homeMTA that more recent versions of Exchange don't actually care about. Of course, getting rid of these bad values won't hurt, but it may not help.

In that case you will have to manually fix the problems flagged as "LingeringLink", "LingeringObject", and "ObjectGuidMismatch".

Advanced Options

Command line options

You can run the tool from a command line. It has three parameters, all of which are positional and optional:

OABValidate <FQDN of GC> <LDAP Filter> <Property List>

For instance, to run it against a particular GC and use the default filters and properties, you would just specify the first parameter:


But if you want to specify a property list, you must also specify a filter, because the parameters are entirely positional at this time:

OABValidate "(mailnickname=*)" member,showInAddressBook

There is also an optional -dclist parameter. It should be a comma-separated list of dcs by short name or FQDN, such as:

oabvalidate -dclist dc1.bilong.test

OABValidate takes that list, connects to each DC specified, looks at that DC's defaultNamingContext, and then adds that DC to its connection cache as the DC to use for that naming context. If you specify more than one DC with the same defaultNamingContext, only the last one specified will be used, overwriting the earlier ones.

Debug Logging

It can be useful to enable debug logging to understand why OABValidate is generating certain results. To do so, create an OABValidate.exe.config file in the same folder with OABValidate, and set its content as follows:

<?xml version="1.0"?>
<add key="DebugLogging" value="true" />

When you launch OABValidate with DebugLogging set to true, it will generate an OABValidateDebug.log file in the logs folder (%PROFILE%\Documents\OABValidate by default).

Last edited Oct 14, 2014 at 8:48 PM by bilong, version 22