CLEARING DIRSYNC ERRORS: ORPHANED AZURE AD OBJECTS

Clearing Dirsync is very straightforward but can be a bit confusing when you are dealing with orphaned objects. There are times you see Dirsync errors pointing to attribute conflict, you check the on prem AD and you cant seem to find the duplicate object with the same attribute. The error says the object synced from AD but you simply cant find the object.

Causes of Orphaned Objects:

• Orphaned object are caused by objects that that were initially synced from a directory or forest that is no longer managed or connected to Azure Ad connect tool.
• Objects were created by another synchronization engine or a synchronization engine with a different filtering configuration. These orphaned objects are no longer managed.
• Uninstalling the ADconnect software
• Deleting a synced object on the On Prem AD. A common scenario is when an admin attempts to delete a synced user on office 365 by first deleting the user on the AD instead of moving the user to the lost and found container or an unsyncd OU.

Ways of identifying Orphaned objects:

1. SEARCH THE AZURE AD CONNECTOR SPACE

• Open the AD connect synchronization service
• click on connectors and double click on the Azure AD connector
• At the right hand side of the Sync service window, click on "search connector space"
• In the Scope box, select Pending Import, and then select the Add check box. This search gives you all synced objects in Azure AD that cannot be associated with an on-premises object.

Double click on the object and note the distinguished name. Search for the object on your AD and confirm that it does not exist.

2. ANALYZING THE DIRSYNC ERROR

• Export the DirSync errors from Azure AD portal and Msol PowerShell.
• Go to: https://portal.azure.com/#blade/Microsoft_Azure_ADHybridHealth/AadHealthMenuBlade/SyncErros

• Connect to Msolonline PowerShell and use the command below:
• C:\> Get-MsolDirSyncProvisioningError | Select-Object DisplayName, Objecttype, immutableId, ProvisioningErrors, ObjectId, @{Name='Proxyaddresses';Expression={[string]::join(";", ($_.Proxyaddresses))}} | Export-Csv -Path c:\error.csv

Note: The "Join powershell" command is used to properly export PowerShell values/attributes that exceed one line to csv. If you don't use the expression you would get "System.Collections.Generic.List" value on the csv sheet.

Copy the values of the ExistingObject.SourceAnchor and IncomingObject.sourceAnchor. This is the immutableId. Covert the immutable ID to ObjectGuid. use the Powershell command below:

[GUID][system.convert]::FromBase64String("EKST4SlEl0mDz1imODOGXg==")

Search the AD using the SamAccount or proxyaddress you would only see one object with the same ObjectGuid. The non existent object is the orphaned object

How to Clear the errors:

Identify the object type i.e. user, contact or a group.

Connect to MSol online and the delete the object.

For users:

Remove-MsolUser -UserPrincipalName "davidchew@contoso.com" -Force

for Groups:

Remove-MsolGroup -objectid 78c4ca1a-4e22-40ac-b0bd-abeca4bcafc5 -Force

For Contact

Remove-MsolContact -ObjectId 40c4ca1a-4e15-40ad-b0bd-abeca4bcafcd -Force

You can bulk delete the objects by using the objectID of the orphaned object in a script. Get the objectID of the object from the DirSync error you exported above. create a txt file with the ObjectIds of the objects you want to delete, then run the script below:

$content = get-content "C:\usersdirsync.txt"

foreach ($user in $content)

{

Remove-Msoluser -ObjectId $user -force 

}

CAUTION: before deleting Msol users, confirm the primary account of the user, check the sign in history and the likes. If the existing object of the user is the orphaned object, you have to perform Hardmatch using the immutable ID. Deleting Msoluser without confirm this can lead to data loss. e.g email, SharePoint, OneDrive and so on.

It may take awhile before you the DirSync error clears on the GUI, simply use the Get-MsolDirSyncProvisioningError Msol online command to confirm that there are no DirSync errors.

Thank you for reading.