Wednesday, February 16, 2011

SPNs Broke My WinRM

Preparing for a demo of FIM Service to FIM CM integration, I planned on using PowerShell and WinRM as the stars of the show.  FIM CM still relies on .NET Remoting (hasn’t changed since pre-CLM days, just ask Brian…).  .NET Remoting is easy enough, but I was keen on using WinRM because:

  • we get it for free on Windows 2008
  • PowerShell is much easier to troubleshoot than compiled .NET code
  • WinRM requires no client side proxies or DLLs

This worked GREAT on a one-box environment, then I stretched it out a little.

In my demo I have FIM Service and FIM Certificate Management running on separate servers in the same forest.  Both FIM CM and WinRM use HTTP as their transport.  Both FIM CM and WinRM enjoy the use of Kerberos to protect said transport.  Only ONE of them can have an SPN identifying the computer account and the transport.

For the life of me I can’t figure out how to trick WinRM into using a different SPN.  The only way I have been able to un-break WinRM is to break FIM CM by deleting it’s SPNs.

The same issue described in this post.  It is also nicely described here.

So at the end of the day I’ve had to workaround this heart break by using .NET Remoting instead of WinRM.  At least it won’t be much work to switch back to WinRM once I figure out a workaround.  I’ve structured my PowerShell module to hide the .NET Remoting crap in a neat little function.

Wish me luck on the demo!  I’ll be posting this stuff to CodePlex this week, win or lose :-|

Friday, February 04, 2011

FIM Sync Engine–More PowerShell Added

Back in November I posted about the ILM Sync Engine PowerShell cmdlets.

Turns out they were added to FIM in a hotfix last year (I’d assumed they were in RTM).

From the KB Article

Features in Sync Engine
Feature 1
A limited set of PowerShell cmdlets are added to allow you to perform some limited editing of the Sync Service configuration.
For more information about these PowerShell cmdlets, visit the following Microsoft Website:

General information about PowerShell cmdlets that let you edit the Sync Service configuration 

So if you are running FIM Sync with a build of at least 4.0.3547.2 then all you need to do is add the snap-in and you’re off to the PowerShell races.  No need to download the MSI!

How Delta Sync and Full Sync Compare During Provisioning

A while back I posted on an obscure bug that the vast majority of customers will never see due to the scale required for it to repro: Reference Depth.

Turns out this taught me a lesson about a key difference between Full Synchronization and Delta Synchronization.

The scenario is this: you ran a sync and have objects pending export in a connector space.  Those objects are pending because you have not exported them to the target system yet, they’re just sitting there waiting to be exported.

If you were to Preview one of those objects from the source system again, using a Full Sync Preview you would see the following in the preview results:

“Auto-Deleted” followed by “Added”

So during a Full Sync of that object, the pending export is whacked, then replaced by a fresh new pending export.  This made total sense to me; something could have changed, our rules fired again, so the new object is created. 

Now if you were to Preview the same object using a Delta Sync Preview you would NOT see this behavior.  This is where I got confused, because I had a breakpoint in my rules code and watched as all the code was called, all the way down to CommitNewConnector().  But after watching that happen, there was no “Auto-Deleted” and no “Added”, there was no status reported for provisioning at all, like it never happened.

Turns out the rules extension IS called on both Delta and Full in this scenario, but on Delta the action is just thrown away silently by the server.  Well, it is only silent if you haven’t littered your code with trace logging, and if you’re not nosing around with a debugger.

The moral of the story here is that I’ve been working with this engine for a decade now and STILL learn new things about it – so one could argue the moral of the story is that I am not the sharpest tool in the shed, but most certainly a tool.

The real morals of the story are:

  • if you need a pending export deleted then added then you do not get this for free on delta synchronizations, only on full.  So code accordingly.
  • test, test, test.  If found this when I was writing test scripts against my MV code. 

Had I not been scripting this test case, I probably would have finished the engagement and nobody would have ever noticed my bug.  As much as it sucked to admit the mistake, I did learn something new about the engine, but most importantly it showed me that better test coverage increases deployment quality (duh).  In the end my tests were smarter than me, providing me with both humility and relief.