Share iT…

Just configured a Azure AD Connect (AADConnect / AADSync) synchronisation between an on premise domain and Office 365. All users are synchronized without any problems except one user. Nothing special for this user, same OU, member of the same groups, no special rigths or anything visible different. Also no errors in AADConnect logs, event logs or whatever.

Also followed this helpful Microsoft document One or more objects don’t sync when the Azure Active Directory Sync tool is used, but none of the options described solved the problem. sAMAccountName, proxyAddresses, etc are all correctly filled.
Other strange thing is when you run IdFix as described in the same document, the result also does not show this specific “problem” user.

Solution:
Accidently I did an export of all mailboxes and properties and for this perticular user I saw that LinkedMasterAccount was filled with an SID and the IsLinked value was set to true.
To see if these values are set for this account run the following powershell command: get-mailbox username | select-object *link*

If the IsLinked is set to true the mailbox is a linked Mailbox and linked mailboxes are not synced to Azure AD, as described in this article: Understanding Users and Contacts in Azure Active Directory Sync

A disabled account will contribute userPrincipalName and sourceAnchor, unless it is a linked mailbox.

Disabled accounts are synchronized as well to Azure AD. Disabled accounts are common to represent resources in Exchange, for example conference rooms. The exception is users with a linked mailbox; as previously mentioned, these will never provision an account to Azure AD.

In this case the linked mailbox was probably a leftover from the past so we could convert the mailbox back to a normal user with this powershell command: Set-User -Identity kweku@fabrikam.com -LinkedMasterAccount $null and after that the account was directly synced to Azure AD at the next syncronization schedule.

When you go through the Exchange 2010 manage hybrid configuration wizard, at the Mail Flow Security option the certificate list is empty. When you click on view certificate you get the error “No valid certificate exist for the Hub Transport server(s)”.

When you take a look in the Exchange Management Console at server configuration your certificate is visible and also valid. When you run the following command in the Exchange Management Shell: Get-ExchangeCertificate | FL you will see the result RootCAType : Registry as result.

The problem in this case was that the Root CA certificate (in this case the GoDaddy Root CA certificate) was only available in the Thrusted Root Certificate Authorities store and NOT in the Third-Party Root Certificate Authorities store.

Solution:

Open a mmc windows and add the Local Computer Certificates snap-in, browse to the Thrusted Root Certificate Authorities / Certificates store and export the Root CA certficate (when not avaiable at all, get the certificate from your provider).

Then browse to the Third-Party Root Certificate Authorities / Certificates store and right choose all tasks and choose Import. Follow the wizard and import the exported certificate in the selected store.

You should now see the Root CA Certificate in the Third-Party Root Certificate Authorities / Certificates store.

When you run the following command in the Exchange Management Shell: Get-ExchangeCertificate | FL you will now see the result RootCAType : ThirdParty as result.

When you now go through the Exchange manage hybrid configuration wizard you should be able to select the certificate and complete the wizard.