Share via

Office 365 Directory Synchronization Tidbits, Part 2: More about Filtering

  • Article

In this post I will comment a little bit more on object filtering. As you probably know, Microsoft does not support any modifications in the out of the box configuration of Office 365 Synchronization Tool. There is a good reason for that, including that incorrect changes may trash your online services, including data loss. And nevertheless, the only pain for unwanted synched users is that they appear in the administration tools, but they are not showed in the GAL, so there is no big impact on service to end users anyway.

In this post you will find that “Customers that have previously configured custom filters in the directory synchronization tool, either via the filter file or directly via the Identity Lifecycle Manager (ILM) UI, should find alternate means for preventing Active Directory objects from synchronizing to Microsoft Office 365. ”

There is really not much margin for “alternate means”, as customers will be limited as of today to update their users, groups and contacts to match the built-in filters, such as sAMAccountName to contain “}”, mailNickName start with “CAS_”, etc., not really convenient…. Sad smile. On the other hand, the “filter file” mentioned refers to DirSyncFilters.xml file placed in Sync tool installation path (as referred in “HKLM\Software\Microsoft\MSOLCoexistence\InstallPath” registry value), and described quite well here is not supported anymore as it used to be in BPOS.

However, while *UNSUPPORTED*, this both techniques are still functional, so you may use them at least in your proof of concept and non-productive environments to get your hands on Sync Tool and find gotchas for your specific environment before going live.

Enjoy!

 

Update:

Ivan pointed in his comment (thanks Ivan!) that the DirSyncFilters.xml is not functional. It is partially true (does not work as in BPOS), and partially false (you can make it work Smile). Nevertheless, if you decide to use filtering in test environment, is more practical to filter objects directly in the Management Agent that through the DirSyncFilters.xml file anyways.

 
Here are some evidences of DirSyncFilters.xml usage, again, *UNSUPPORTED*:

  • With Process Monitor you can see miiserver.exe accesing the file …

image

  • If you intentionally malform the XML file content, you will get errors in the event viewer (in the example, closed <ExcludeDN> with <ExcludedDNs>) …

image

  • If you duplicate an entry, it will also give you event log errors …

image

 

  • If an object is filtered, no event is logged. You will have to enable .NET tracing to get such information. You can do that by adding the following to %ProgramFiles%\Microsoft Online Directory Sync\SYNCBUS\Bin\miiserver.exe.config file:

</configuration>
<system.diagnostics>
<trace autoflush="true" indentsize="4">
<listeners>
<add name="TextListener"
type="System.Diagnostics.TextWriterTraceListener" initializeData="trace.log" />
<remove name="Default" />
</listeners>
</trace>
</system.diagnostics>
</configuration>

Doing so will generate %ProgramFiles%\Microsoft Online Directory Sync\SYNCBUS\Bin\trace.log file with content similar to:

miiserver.exe Information: 0 : Initializing the object DN filter list.
miiserver.exe Information: 0 : The DN filter list loaded 1 filters.
miiserver.exe Information: 0 : \nIgnoring filtered object CN={795662656868316173557571543434337275635038513D3D}\n

If you enable tracing but DirSyncFilters.xml is not present, it will also trace so:

miiserver.exe Information: 0 : Could not find file 'C:\Program Files\Microsoft Online Directory Sync\DirSyncFilters.xml'.

 

 

What it is true is that the BPOS technique does not work in the same way now. Instead of specifying the objectGUID in this form:

<?xml version=”1.0” encoding=”utf-8”?>
< DirectorySyncFilters>
< ExcludedDN>CN={xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}</ExcludedDN>
< /DirectorySyncFilters>

You have now to use the object DN that sync engine assigns to the object when it is not filtered out:

<?xml version=”1.0” encoding=”utf-8”?>
< DirectorySyncFilters>
< ExcludedDN>CN={795662656868316173557571543434337275635038513D3D}</ExcludedDN>
< /DirectorySyncFilters>

 

Note that the DirSyncFilters.xml file is processed during object provisioning. So if you modify it you also need to make sync engine discard last file and reload it. The simplest way is copy and delete a file into the \Extensions folder.

 

Enjoy!

Comments

  • Anonymous
    January 01, 2003
    This comment "However, while UNSUPPORTED, this both techniques are still functional" is very misleading as the second technique (DirSyncFIlters.xml) applies to BPOS only and the entire blog post is titled Office 365 Dir Sync Tidbits.

  • Anonymous
    January 01, 2003
    Can this be used with Office 365? How do you locate the object DN that sync engine assigns to the object when it is not filtered out?  Is there a log that you can turn on?  

  • Anonymous
    June 26, 2012
    How do you identify the the object DN that sync engine assigns to the object?  Is their a debug you can turn on?