How I became a plumber: Resolving a rare problem with MIM update Microsoft Identity Manager

Recently, I’ve conducted an update of Microsoft Identity Manager. In the process, I came across an unusual problem (“MicrosoftILMPortalCommonDlls.wsp already exists error”) and couldn’t find a working solution.

It took a few attempts, but I managed to find a fix. I’ll share it with you in this article, so if you come across it, it might help you too.

Updating SharePoint Server

Let’s start with what happened. It was a standard security & maintenance update of SharePoint Server and MIM.

In theory, the process is hardly complicated, though it requires a bit of preparation afore. In practice, it likes to go astray as it’s extremely sensitive to any hidden flaws in configuration. 

First, I updated the SharePoint Server. No unusual events here.

Then came the time for MIM Synchronization Service. The process went quite smoothly, and it seemed I managed to even out the environment sufficiently to avoid any glitches on the way. Kudos to me!

Deploying MIM Service and Portal

Well, not so fast. Once I got to MIM Service and Portal installation, my luck ran out. The installation failed, for no apparent reason.

A quick log check was enough for the diagnosis: “MicrosoftILMPortalCommonDlls.wsp already exists error”.

The culprit is found!

Trying to resolve the error during deployment

My first stop was our internal knowledge base. It already features lots of scenarios and topics related to MIM. But, alas, I found no answers, just an ambiguous note about SharePoint misconfiguration.

And so, the investigation continued.

I checked every setting that I know has an impact on installation: the SharePoint farm admin, alternative access mappings, site collection admin, sysadmin on SQL Server… Everything was in perfect order, nevertheless, the installation still failed. 

Digging a bit further, I checked the solution status (SharePoint Central Administration -> System Settings -> Farm Management -> Manage Farm Solutions). As it displayed “Retracting / Deploying (Scheduled at 11.45)” despite it being already 11.50, I assumed it must be connected to the installation failure.

 (image source)

I turned to online search and got a new idea. The plan was to bring the Timer Service online (Thanks a lot, Matt!) and manually remove the MIM .wsp files from SharePoint (All hail Stack Overflow!). 

The command for manual retraction or deployment is: stsadm -o execadmsvcjobs 

However, prior to running it, you need to disable SharePoint Admin Service. 

Now we’re getting somewhere… or so it seems

I attempted the installation again. The result? “Not great, not terrible.”

The process ran a bit farther to the “Deploying MIM Solution Packs” stage, and then I saw the beloved “Rolling back the changes” message.

MIM did not want to cooperate

As it turned out, verifying if SharePoint Admin Service is online is one of the first steps performed by the MIM installer and this condition is regularly checked throughout the entire installation.

Thus the error changed from “MicrosoftILMPortalCommonDlls.wsp already exists” to SharePoint Admin Service is not running. It makes perfect sense when performing a MIM update by the book. SharePoint Admin Service is necessary as it governs the deployment and retraction of SharePoint solutions.

Unfortunately, in my case, it kept getting stuck on those operations, thus I needed it to be turned off for stsadm command to work. 

Step-by-step solution

It seemed like a vicious circle, but I managed to come up with a solution. I decided to become, as it were, a plumber for the system, and push the solutions down the drain.

Here’s the step-by-step guide to completing the installation: 

1. Go to Job Definitions (SharePoint Central Administration -> Monitoring -> Timer Jobs -> Review Job Definitions) and remove “Microsoft SharePoint Foundation Solution Retraction for microsoftidentitymanagement.wsp” job by clicking on it and pressing the “Delete” button.
   

2. Ensure that Timer Service is online – otherwise, neither SharePoint Admin Service nor stsadm command would do a thing.
   
3. The moment the installation reaches the point of “Retracting solution pack” quickly stop the SharePoint Admin Service and then run the stsadm -o execadmsvcjobs command to retract the old solution.
4. Once the solution is retracted, immediately relaunch the service – otherwise, the SharePoint Admin Service check is going to kill the installation.
   
   

   Relaunching the Admin Service

5. Having successfully gone through the retraction of old solutions, it gets tricky as there are two ways the process can go:
   
   a) First, let the SharePoint Admin Service do the job – for some machines MIM requires help only with the retraction of the old solutions.
   
   b) If the installation fails also on deploying new solutions – repeat steps 3 and 4 to help MIM installation deploy new solutions. After .wsp re–deployment, the only task remaining is to mash the Refresh button on the services console and manually restart the SharePoint Admin immediately as it goes down. 

SharePoint services panel

And hooray! It worked. MIM Service and Portal were installed successfully. Using the steps above, I was able to conclude the SharePoint Server and MIM update.

Well, I hope you’ll find this guide helpful. If you have any questions about this process or would like to share your experience, get in touch.

And one more thing. Microsoft announced they would no longer actively develop MIM, and the maintenance support will only be available till January 2029. If you have it at your company, you might like to learn about its alternatives. These include Omada Identity and Azure AD (Microsoft Entra) among other things. At Predica, we know how to use both of them, so feel free to reach out to us if you need support.