Recipient Validation

Recipient objects in Exchange 2007 fall under a more strict "validation" scheme than they did in previous versions of Exchange. This means that if some property is incorrect or missing on the recipient object, there is higher-level logical enforcement that this property must be corrected before the object will successfully validate as being in a good state. This is done to help ensure that these recipient objects are not corrupted in some way which would cause them not to function properly. 

If a recipient object does not successfully validate when it is read from the AD, a warning will be reported to detail the cause of the failure(s). It may also prevent the action you were attempting, such as: moving the mailbox, saving other properties to the recipient object, etc until the object passes validation.

Here is a list of some of the known validation failures and effective ways to resolve the corruption:

1) Display name has leading or trailing whitespace

WARNING: Object Domain.com/Users/TestUser has been corrupted and it is in an inconsistent state. The following validation errors have been encountered:
WARNING: The DisplayName property contains leading or trailing whitespace, which must be removed.

This can be fixed by "trimming" the invalid whitespace from the displayname with a cmdlet one-liner like:

Get-Mailbox | Foreach { Set-Mailbox –Identity $_.Id –DisplayName $_.DisplayName.Trim() }

2) Alias (mailnickname) has spaces.

Identify all recipients with this issue with a simple LDAP query - (&(objectclass=*)(mailnickname=* *))

3) Extension Attributes: PSH and AD Schema Conflict

WARNING: Object fwf.net/Operations/User Test01. User has been corrupted and it is in an inconsistent state. The following validation errors have been encountered:
WARNING: CustomAttribute15 is too long: maximum length is 2048, actual length is 2500.

Extension Attributes are renamed back to Custom Attributes in PSH.  PSH does not reference the AD schema for attribute properties, it uses its own lookup table. Therefore, even if the AD schema has been manually modified to allow greater than 2048 length for a "Custom Attribute" value, PSH will mark the recipient using this larger size as invalid.  This maximum length was changed in Beta builds from 1024 to 2048, but does not reference the AD schema size definition if has been customized.