Using the FIM WMI Provider While Syncs Are Running

It’s always been a worst-practice to make external calls from rules extensions in the sync engine, but a bad idea of mine illustrated the reason why today.

In my scenario, I really want my MV code to fire on objects ONLY when they have already been exported and confirmed by the outbound MA.  The right way to do this is to use a constant Import Attribute Flow (IAF) rule on that MA, in which case the scenario looks like this:

1. MV code creates a new CSEntry in the outbound MA
2. Outbound MA runs Export
3. Outbound MA runs Import
4. Outbound MA runs Sync – this is where our IAF rule flows a value to the MVEntry

If the attribute on the MVEntry has a value, then we know the outbound MA has completed the Export and Import successfully.

The rub in my scenario is that I cannot modify the MV schema, so I can’t use this approach.  Grasping at straws I thought I could just look at the CSEntry using the MIIS_CSObject class in WMI.  This is where the wheels came off.

When I put the code in place and ran Preview, the sync service hung.  In my sync cycle, WMI was being called from my MV code which seems harmless enough since WMI is only reading objects, but I knew I was being less than smart, this was just prototyping, really, I’m normally a lot smarter, at least the second or third time.

Anyhow, this exact scenario created what is most likely a deadlock in SQL but the usual MIIS deadlock error didn’t happen.  Unfortunately the service just hung and had to be killed (killed several times in fact, as I was troubleshooting the issue).  Hard to call this a fault of the product since I should know better, but I would have liked the sync cycle to fail with a deadlock error, or the WMI call to fail with something similar.

The moral of the story is simple; follow the best practices as much as possible; don’t make external calls from rules extension code, and don’t query the sync database (even with WMI I guess) while the sync engine is running.