So we’ve had this ILM instance over in our eval/staging forest for many years. It’s a VM, and it has a bit of a sordid history having become a VM via a somewhat checkered path. This ILM instance is where I test out changes before deploying them. But for several reasons I won’t go into here, this ILM instance has never automatically run the usual cycle as the production ILM instance does.

But I’d like it to now, so I went through all the steps to do that. In a nutshell, this means having a script which will call the MicrosoftIdentityIntegrationServer WMI provider and execute the right management agent run profiles. This script is triggered by a scheduled task which is recurring. This is the standard approach everyone uses, because ILM has never had it’s own automation. You can see an example of the script code used to do this here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms697765(v=vs.85).aspx

I used the same script I was successfully executing with my admin account, but set it up to run with a service account. The service account was, of course, in all the right ILM groups.

But the scheduled task wouldn’t run properly.

So then I tried via a runas command prompt as the service account. And thus began a long saga of learning obscure things.

The first error was clearly a DCOM permission issue. And so I manually fixed the DCOM permissions, although that would have been fixed by an ILM reinstall.

Then I ran into a more obscure error:

Event Type: Error

Event Source: MIIServer

Event Category: Security

Event ID: 6600

Date: 8/30/2012

Time: 3:15:00 PM

User: N/A

Computer: KIBBLESNBITS

Description:

A user was denied access for an operation.

 Additional Details

 User: “DOGFOOD\a_ilm-acct” Operation attempted:”CServer::GetEnumInterface

With an error code from the script of: 0x80041001. That translates to one of two possible causes: REC_E_NOCALLBACK or WBEM_E_FAILED. If I had known more about WMI at this point, I might have saved myself some time.

Reinstalling ILM when you run into an odd problem such as this is a common recommendation, and that’s what I tried first, after verifying the account was in all the right groups. But reinstalling ILM didn’t help.

My next theory was that perhaps SQL permissions weren’t correct. This installation of ILM was using SQL Express, so I had to download the free sql server management studio express to check out the permissions. SQL permissions were fine.

Then I started looking more closely at exactly which line of the script was raising an exception.

This led to realizing that something about WMI wasn’t happy. I’m not really a WMI expert.

I found a thread online with other folks who had run into a similar problem: http://social.technet.microsoft.com/Forums/en-US/identitylifecyclemanager/thread/2a4c8f42-4123-4297-aa35-29a96956946e/.

So I tried the WMI repository fix (basically deleting it). That didn’t fix the problem and actually seemed to make it worse, as now the script couldn’t even find the MicrosoftIdentityIntegrationServer WMI provider/namespace.

But then I realized that I might need to re-register that provider/namespace afresh, and I tried Yorick’s fix in that thread, i.e. running “mofcomp mmswmi.mof”.

And then the script worked for my service account.

I suspect that if I had looked at the WMI permissions instead of wiping the WMI repository, I would have found that the service account didn’t have permissions, but it’s also possible that there was some kind of WMI corruption present.