MIM 2016 SP2: Network Connection Flow Between The Service/Portal and Sync Services And Their Databases

celsoglima 371 Reputation points

I was wondering if some of you guys might be able to help me understand the network traffic between the MIM service/portal and sync services and their databases.

We have an environment where we are very restrictive with our firewalls, and I have a set of MIM test servers consisting of one server running MIM service/portal and sync services and one server hosting the databases. The servers are in two different subnets. The servers are pretty well configured in terms of disk space, memory and processor.

What I have noticed is that when I do an export on the MIM MA it takes a considerably longer amount of time compared to a delta import for example. If I am not mistake exports are delta type of operations, right?

How are the MIM service and sync services communicating with their databases in terms of network traffic during synchronization?

Microsoft Identity Manager
Microsoft Identity Manager
A family of Microsoft products that manage a user's digital identity using identity synchronization, certificate management, and user provisioning.
624 questions
0 comments No comments
{count} votes

Accepted answer
  1. Leo Erlandsson 1,656 Reputation points


    Well, a trace level on the MIM Service of Verbose would definitely slow things down considerably.
    Then it also depends on which rulesets (MPRs) are triggered during the Export.

    Both the Service and the database are involved in the export (and a lot of Stored Procedures, Brokers, and so on).

    I think you should start by changing the log level, and then looking at what rulesets are triggered.

    Of course network/data could be a culprit, but that's not the place I'd start looking.
    There are parameters to fine tune in the MIM Service, but you should probably rule out other things before starting to change them.

    You should also check that you don't have many errors on the export. That could make the MIMMA start doing single exports instead of composite exports (which could slow down the export with a factor of say 8-25 times). Check that in the Request log in the MIM Portal.


    0 comments No comments

3 additional answers

Sort by: Most helpful
  1. Leo Erlandsson 1,656 Reputation points


    Exports are usually delta operations yes, only changed objects are added / updated.

    Could you please provide some more information on the number of objects exported, if any?

    An empty export to MIM MA should be almost instantaneous.


    0 comments No comments

  2. celsoglima 371 Reputation points

    Hey Leo

    This export generated 40,121 updates and 5,498 adds, and it took a little over 7 hours and 40 minutes to complete. The subsequent delta sync on the MIMMA generated another 15,627 export attribute flows on the MIMMA itself which took about 10 minutes.

    I don't run the run profiles on a regular basis in this particular environment as it is a test environment. Thus I am wondering if that has to do with what I am experiencing. However, I have had data updates in production with a lot more data that did not take that long. One hour or just over one hour at the most.

    My question about the connections to the database is to try to understand the network/data flow. I am assuming the synchronization engine transfers the data from the sync database to the service database, right? That has made me wonder if my database server is not optimized for large data sets. Or if I have to fine tune the parameters in the resource management service section in the service config files. I also just realized I had left the trace level on the MIM service at verbose, and that could be a problem as well, right?

    0 comments No comments

  3. celsoglima 371 Reputation points

    Hey Leo,

    One thing I didn't mention earlier as I didn't think it was relevant is that I did have 24 errors in that synchronization run. I was not aware of the impact of errors in the synchronization. Based on what you are saying that might be the reason why it took so long for the export to complete compared to the other export operations with no error which were considerably faster. I will keep that in mind the next time and address the errors, so they don't linger around and impact future operations.

    As far as the rest of the information provided, I will work on that, and in particular the trace level which I need to remind myself to reset it once I am done with it. That has been my approach in production, but I need to extend it to test as well as I tend to forget about it.

    My conclusion here is that the errors and the trace verbosity level may have had a compounding effect on the synchronization.

    0 comments No comments