GalSync issue: The property you specified, “-1073741562”, isn’t defined in the Enum type “Nullable`1”.

This week I’m working on a couple of MIM-related cases, and the first one’s been related to MIM GalSync solution.

The background: every sync cycle run we see many contact provisioning for security groups failed with a generic “ma-extension-error”. Actually, that’s even worse. MIM/FIM is not aware about the contact objects being created as a (not mail-enabled) objects in AD, which are considered as filtered disconnectors during the next synchronization. In other words, MIM continues pushing additional object (duplicates) in every synchronization cycle. In my case I’ve found an Active Directory with almost 100000 contacts duplicates created for less than 100 universal security groups.

Looking into Application event log we could see some details:

There is an error in Exch2010Extension AfterExportEntryToCd() 
function when exporting an object with DN CN=groupcn,OU=GALContacts,DC=contoso,DC=com.
Type: Microsoft.MetadirectoryServices.ExtensionException
Message: 
**** ERROR ****
The property value you specified, "-1073741562", isn't defined in the Enum type "Nullable`1".
**** END ERROR ****

After digging a bit within GalSync source code I discovered, that the procedure EAFmsExchRecipientDisplayTypeForwards (you could refer to GALMA.vb file for details) contains some issues preventing it from creation a valid msExchRecipientDisplayType attribute value for universal security groups contacts.

What’s wrong there? First, let’s convert the value from the event log to hexademical representation, that gives us &HC0000106. This seems to represent a number calculated as addition of several well-known values for Exchange “base” recipient display types:

REMOTE_USER (&H80000000) + REMOTE_MAIL_USER (6) + SECURITY_PRINCIPAL(&H40000000) + DISTRIBUTION_GROUP(&H100)

For me, there’s something wrong about combining some of base recipient display types in the section above (DG is NOT a security principle, at least). Exchange also doesn’t like the resulting recipient display type value, and generates errors while ADGAL MA’s running Update-Recipients cmdlet.

How to fix it? Of course, I’d like to see EAFmsExchRecipientDisplayTypeForwards validated and rewritten. So far I came up with a workaround targeted on the specific issue with contacts creation for universal security groups.

Let’s change GALMA.vb, EAFmsExchRecipientDisplayTypeForwards procedure, to add an explicit processing of a value that we consider as wrong. See the changes (additions) below:

            ' Modifications start here
            Dim wrongUniversalSecurityGroupRecDispType As Integer = &HC0000106
            Dim correctUniversalSecurityGroupRecDispType As Integer = &H80000906

            If (csentry(RECIP_DISPLAY_TYPE).Value = wrongUniversalSecurityGroupRecDispType) Then
                csentry(RECIP_DISPLAY_TYPE).Value = correctUniversalSecurityGroupRecDispType
            End If

            ' Modifications end here
        End Sub '<------ insert right before this
    End Class
End Namespace '<----- here's the end of GALMA.vb file

Build the solution using Visual Studio (you will probably need to add references to Microsoft.MetadirectoryServices.Ex.dll and Logging.dll, and change the target .Net Framework version to 3.5.), get a new custom version of GalSync.dll, put it into your environment and check if the issue’s gone.

Let me know if you’ve found this post useful.
Cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *