FinOps Azure Cloud Cost Management
Finances, cost, spend... It's the second most important topic when it comes to the public cloud, right after security....
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.
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!
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”.
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 was already 11.50, I assumed it must be connected to the installation failure.
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.
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.
As it turned out, verifying if SharePoint Admin Service is online is one of the first steps performed by 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.
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 complete the installation:
And hooray! It worked. MIM Service and Portal 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. 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.
Read similar articles