I just ran into a “bug” related to SP1 in MIM 2016. The problem is related to schema changes made in the FIMService in SP1.
My situation where the problem showed itself might not be the most common one, but as I will explain later in this post it also have implications in other scenarios.
My situation was at a customer where we started buildning a new MIM 2016 solution about a year ago. We installed MIM 2016 RTM (4.3.1935.0) in the Dev/Test environment.
The development of the solution took some time and we updated the Dev/Test environment to SP1 (4.4.1302.0) when it came around.
It was now time to go to production with the solution and the production environment was installed using SP1 (4.4.1302.0). By the looks of it, we had the same version.
Now the problem showed itself when we started migration the configuration from Dev/Test to Production. We used the “standard” method described by Microsoft
At the import changes we got a big fat error when importing the schema changes. Drilling down into the error I found that the basic schema was different depending on how I got to 4.4.1302.0.
If you look in the schema on your MIM 2016 SP1 (4.4.1302.0) or later and search for attributes named domain you should find three different attributes as in the picture below.
If you cannot see the last one called “Domain FQDN” with the system name msidmDomain you are affected.
When the configuration import found this missing attribute and two bindings related to it, it could NOT import the changes, FIMService gave the following error in the eventlog.
Microsoft.ResourceManagement.Service: Microsoft.ResourceManagement.WebServices.Exceptions.PermissionDeniedException: SystemConstraint ---> System.InvalidOperationException: The system name provided includes a reserved prefix.
The msidm prefix seems to be reserved and you are not allowed to add attributes starting with that prefix.
Even if we never use this attribute or need it. It will make our future configuration migration fail unless we remove this error from the process.
Conclusion
The MIM 2016 SP1 setup version have some issues with the schema. Product team have told me that these issues are fixed in 4.4.1459.0 version, so by making sure both source and target systems run 4.4.1459.0 version of the schema I should be save from this issue.
Implications
Not many people will have my situation where production is installed using a newer version than dev/test. But this problem will also show itself for anyone doing a disaster recovery with configuration restore without data restore.
Typically you make a reinstall reusing the FIMService database, but there are occasions when you would like to make a fresh install, import the configuration and then reload all data into FIMService again. If this is a scenario and your current configuration is based on RTM and reinstall is made using SP1, you might be affected by this problem.