The Architecture

The controller

The component in the sync engine responsible for talking with the connectors, both the built-in connectors and ECMA1/ECMA2, is called the controller. It is responsible for reading and writing the connector space and present the data in the format the connector wants. For example, one connector might want all attributes for an object when only one has changed and another connector only wants the changed attribute. The controller is responsible for delivering the data in the format needed by each connector. The format is defined by capabilities in the connector code.

The data stored in the connector space is different depending on the defined capabilities. That is the reason why many capabilities can only be set during the creating of a connector. As soon as the first full import has completed, the connector space layout would be different if a capability has changed.

Drop files

You can get data directly from the controller by using drop files. A drop file is defined on the run profile and has these options:

Options for creating a drop file

Options for creating a drop file

A drop file gets its data directly from the controller so it is an excellent way to look at how the data would be presented from the controller to the connector (on export) and from the connector to the controller (on import).

A drop file is not going to be an exact representation and interaction with the connector when you do not stage to the connector space. There are some scenarios, for example when an object is moved from an out-of-scope OU to an in-scope OU, where data from an earlier imported page affects what will happen later. When data is not staged to the connector space, the controller doesn't know that the data it needs is not complete. But for most scenarios, it is a good representation and used to understand how the sync engine works under the cover.


All interfaces, methods, and properties for ECMA2 can be found in Microsoft.MetaDirectoryServicesEx.dll. It can be found in the ..\bin\assemblies folder. In the same folder, you also find a file named Microsoft.MetaDirectoryServices.dll. This latter file is only shipped for backward compatibility with MIIS2003. MIIS2003 did not ship with signed DLLs. If you compiled code using the unsigned DLL with MIIS2003, you cannot use a signed version without recompiling the code. The Ex version of the DLL should always be used for all new installations and in Azure AD Connect, the unsigned DLL is no longer available.