Disconnecting Objects with AADConnect

If you're familiar with MIM, you know there exists the capability to disconnect an object from the metaverse to force it to go through the join/provision process again. This is useful when the object was joined to the wrong metaverse object for some reason (like a bad join ruleset or incorrect data at the time of joining) and you want to have it be reassessed like it was a new object. In AADConnect, the disconnect function has been removed. The only supported way to cause an object to be reevaluated is to delete all objects from the connector space, and run a Full Import and Full Sync against all objects. That's a bit heavy handed when you have a large connector space and only want to reevaluate a single object.

Update 2019.11.12: If you can edit the source AD object you can leverage the default filtering rules to disconnect the object.

Fortunately, there's a round-about way, that clearly says it is for testing only, to disconnect an object in AADConnect.

Note: performing this procedure incorrectly can introduce incorrect data into AADConnect, which may require deleting all the connector space objects and running a Full Import and Full Sync to correct. Make sure you understand how this works before you make changes to a production system.

First, we need to save the connector space view of the object as we'll need it later. The syntax is csexport.exe ma_name filename.xml /f:d="DN" /o:b

As an example from my lab:

C:\Program Files\Microsoft Azure AD Sync\Bin>csexport.exe "logon.loderdom.com" c:\temp\contact001.xml /f:d="CN=Contact001,OU=userids,DC=logon,DC=loderdom,DC=com" /o:b 
Microsoft Identity Integration Server Connector Space Export Utility v1.2.65.0
c 2015 Microsoft Corporation. All rights reserved
[1/1]
Successfully exported connector space to file 'c:\temp\contact001.xml'.

Second, we delete the single object from the connector space. The syntax is csdelete.exe ConnectorName ObjectDN

As an example from my lab:

C:\Program Files\Microsoft Azure AD Sync\Bin>csdelete.exe "logon.loderdom.com" "CN=Contact001,OU=userids,DC=logon,DC=loderdom,DC=com"

Next, we need some template data for how to structure the import. You can create the template yourself by creating a new delta import Run Profile. Use the Set Log File Options to select the Create a log file setting and provide a filename. Make a small change to an in-scope AD object, and run the new delta import step. This should cause an XML file to be created in the C:\Program Files\Microsoft Azure AD Sync\MaData\MAName folder. This log file is the basis for the template to import data. It should look something like this:

<?xml version="1.0" encoding="UTF-16"?>
<mmsml xmlns="http://www.microsoft.com/mms/mmsml/v2" step-type="delta-import">
  <directory-entries>
<delta operation="replace" dn="CN=Contact001,OU=userids,DC=logon,DC=loderdom,DC=com">
 <anchor encoding="base64">NhtjCw4HbUuNLrUso4zsyw==</anchor>
 <parent-anchor encoding="base64">NH+Z2J4tEkuLRC42kBckew==</parent-anchor>
 <primary-objectclass>contact</primary-objectclass>
 <objectclass>
  <oc-value>top</oc-value>
  <oc-value>person</oc-value>
  <oc-value>organizationalPerson</oc-value>
  <oc-value>contact</oc-value>
 </objectclass>
 <attr name="cn" type="string" multivalued="false">
  <value>Contact001</value>
 </attr>
 <attr name="displayName" type="string" multivalued="false">
  <value>Contact001</value>
 </attr>
 <attr name="givenName" type="string" multivalued="false">
  <value>Contact</value>
 </attr>
 <attr name="objectGUID" type="binary" multivalued="false">
  <value encoding="base64">NhtjCw4HbUuNLrUso4zsyw==</value>
 </attr>
 <attr name="sn" type="string" multivalued="false">
  <value>001</value>
 </attr>
</delta>
  </directory-entries>
</mmsml>

I've highlighted the template portion in yellow, and the replaceable object-specific content in green.

Take the XML data from the cs-objects/cs-object/synchronized-hologram/entry section of the export file from the first step of this procedure and use it to replace the data from the import template. Take care to make sure the XML is still structured properly. The DN is part of the entry element, with the other data being children.

The structure should be identical to the import template from above, just containing data from the object you exported.

When saving the template XML file with notepad, be sure to use Unicode, not ANSI. Copy the input file to the C:\Program Files\Microsoft Azure AD Sync\MaData\MAName folder.

Finally, we can import this object into the connector space. Edit the custom delta import Run Profile (or create a new one if you just used the XML from above). Use the Set Log File Options to select the Resume run from existing log file and stage to connector space (test only) setting and provide the filename.

If you get a parsing error, validate that the XML structure matches the template example and that the file is encoded with Unicode.