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 :-|

1 comment:

Anonymous said...

here is the workaround:
1) Add the SPN for WinRM service
2) use ConnectionUri parameter with WinRM port in remoting cmdlets
-ConnectionUri http://:5985