Appendix E: Troubleshooting ECMA2

The following appendix is to provide guidance on troubleshooting.

Troubleshooting the ECMA 2

There are two main areas where troubleshooting and more importantly, having the ability to walk-through the code become very helpful. These are during the creation of the MA and when running profiles on the MA.

First, when creating the MA, if there is any problem with your code then an exception will be thrown and the MA will not be created. This exception typically doesn’t reveal why this is occurring. An example of this is during the GetSchema method. If your schema discovery is not valid or has some syntax errors then an exception will be thrown while you are going through the create MA wizard. However, the exception doesn’t tell you why the exception occurred. To break into the code you can use System.Diagnostics.Debbugger.Launch() at the beginning of a method to invoke the debugger and use Visual Studio to walk the code. In our example above, we would put this line at the beginning of the GetSchema method. See the screenshot below for an example.


Now we can use F11 and step through the code until we hit the exception.

Second, when running imports and exports you can debug the code by attaching to the miiserver.exe process and putting in breakpoints on your IMAExtensible2CallImport methods or your IMAExtensible2CallExport methods. This will let you step through the code to ensure that you are connecting to the connected data source, are importing and exporting data, and that the data is being set correctly. This will also help troubleshoot errors with the MA. For example, when developing this doc the following error was seen. The Synchronization Service threw a ma-extension error.


When clicking on the error the only additional information was an unexpected-error. There was nothing in the event log.


Now after attaching the Visual Studio project to miiserver.exe and setting a break poing on the PutExportEntries method, walking through the code was possible. Going through the code revealed an UnauthorizedAccessExeption


Looking at the details from this error showed an Access Denied.


So from this, it was determined that the CORP\FIMSyncService account did not have sufficient permissions in AD to modify an attribute. This is a little more revealing than the cryptic ma-extension error.