MIM Sync Engine Debugging: Should You Bother?

So far in the series, we’ve looked at why we test and how we do it. The next logical step might be a blog on how to debug your code in Sync Engine, but –
since this article on MSDN covers that well enough, and since there are plenty of other blogs out there on the subject – I’m going to look at a more original subject. In this blog, rather than talking you through how to debug code in Sync Engine, I’ll discuss this method of testing in terms of the advantages and disadvantages it offers.




The approach to testing described in the MSDN article allows you to test your code within the Sync Engine itself. This is useful as you can test with real data in the system, follow the steps through, and see the outcome.

There is still a place for testing the code in the Sync Engine, but knowing all my unit tests are passing gives me great confidence to let the schedule in the development run as it would in the production environment, making use of preview syncs if anything unexpected occurs. In a later blog, I’ll discuss end-to-end system testing in more detail.


There are a lot more cons than pros to this method of testing.

The biggest disadvantage is that it blocks anyone else from using the Sync Engine. While you are debugging your code, no one else is going to be able to run any steps, so it blocks them from testing and developing their part of the solution. Also, when you compile the code, it updates the extension folder, which – if someone else is running a Sync – will cause it to stop prematurely.

Another big hindrance is that it’s not automated. To run through your tests, you need to manually run them, which is a time-consuming process. You must get the data into the connector space, and then perform the Sync. If you want to follow it step-by-step, you need to attach the debugger, and if you make a change to the code, you need to start all over again.

You also need to manually record the results if you want to view the history of your tests. You cannot see the performance of the code, or how long a test took to carry out. Does one set of parameters cause it to take longer than another set of parameters? These bits of information can be important to determine if there is a slow piece of code, and could be the difference between a 5-minute sync or a 30-minute sync.

You need to be connected to the Sync Server to write the code, compile it, and test it. This limits the amount of connections available on the server, and limits the size of the team that can be working on it at any one time.



The method of testing and debugging mentioned in the MSDN article is nearly 7 years old now, and the disadvantages of this approach outweigh the advantages. This method of testing might seem quick and easy, but taking that approach is a shortcut to failure.

With solutions getting more complex, more consultants working on a project, and more testing and regression testing of solutions being required, a new way of testing the Sync Engine code needs to be adopted and used if projects are going to be successful.

In the next blog, we will be getting technical (very technical) with Visual Studio 2015, setting up the environment, and learning how to unit test Rule Extensions without needing to be on the Sync Server.


Want to learn more about identity management? Watch a recording of our MIM webinar for a comprehensive look at Microsoft’s latest automation product and its benefits.

If you’re worried about whether you’ve lost touch with the latest developments in cloud-first identity, take a look at our ‘Navigating the world of identity and access management’ webinar recording.