Can’t Use XPath Contains Function to Query Sets in FIM

This kinda surprised me.  I tried to do this and it failed:

001 002 003 004

### ### Find all Sets where the Filter uses 'myAttribute' ### Export-FIMConfig -CustomConfig "/Set[contains(Filter, 'myAttributeName')]"

Thinking I had a problem with my syntax (the usual suspect) I changed the attribute from Filter to DisplayName and the query succeeded.  It wasn’t the query that I wanted, but it demonstrated that my syntax was correct.  I guess this means you can’t make this query in FIM.  This was a bit annoying, but there is a simple workaround.

The workaround is to just export ALL the Set objects, then use the PowerShell Where-Object cmdlet to do the filter.  Way more expensive, but who cares?  I’m not doing this all that often and I take slight pleasure in punishing the service for not accepting my leaner query to start with.

Here is the workaround script:

001 002 003 004 005 006

### ### Find all Sets where the Filter uses 'myAttribute' ### Export-FIMConfig -CustomConfig "/Set" |     Convert-FimExportToPSObject |     Where-Object {$_.Filter -ilike "*myAttribute*"}

NOTE: find the Convert-FimExportToPSObject here.

Debugging FIM Workflows

Most blog posts enjoy the theme of sharing something that was hard to learn.  This blog post shares nothing but failure, except for the small glimmer of hope that somebody will point out that I am just missing something obvious.

Windows Workflow Foundation does a nice job of providing a canvas for drawing code.  It is a visual representation of what we would otherwise have done in code.  This visual representation is very convenient when debugging (or just learning) workflows.  The ability to set a breakpoint on an item on the workflow canvas is a very intuitive experience.

This is the thing I have not been able to figure out.

The FIM Debugging Guidance on MSDN only shows how to debug managed code in a FIM WF.  What I’m really after is what Bahram asked for back in the RDP: debugging the WF code type.

What I really want to do is watch the debugger through the WF designer, as opposed to setting a breakpoint in the code then trying to correlate.

If anybody has been able to figure this out, I’d love to know the secret!

BTW – it is not a case of missing symbols or selecting the wrong code type.  I can demonstrate breakpoints working in the same class inside code activities, but failing for the actual WF breakpoint. Arg!

Using RegEx to Validate FIM Service GUIDs

Sometimes it is useful to validate a GUID before using it to script against FIM.  I’ve been using the regex pattern below in PowerShell scripts, and parameter validation scripts.

001 002 003 004 005 006 007 008 009 010

### ### Regex pattern to test a UUID from FIM ### $regExPatternForFimUuid = "^(urn:uuid:){0,1}[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}" ### Test 1 - should return TRUE when GUID is prepended with 'urn:uuid:' 'urn:uuid:fea6a1cc-0ee3-4aa6-aba7-ad339d6cab5f' -match $regExPatternForFimUuid ### Test 2 - should return TRUE when GUID is not prepended with 'urn:uuid:' 'fea6a1cc-0ee3-4aa6-aba7-ad339d6cab5f' -match $regExPatternForFimUuid

debug.MakeCurrentUserAdministrator

<WARNING>

!!! DO NOT DO THIS ON A PRODUCTION FIM SERVER !!!

</WARNING>

If you have accidently whacked your FIM administrator object in the FIM Service, there is a rescue utility in the FIM Service database in the form of a stored procedure named ‘debug.MakeCurrentUserAdministrator’.

From what I can see, this procedure will add the current user to the Administrator Set in the FIM Service database.  It does not require any parameters, so is quite easy to execute. 

Caveats:

1. The current user must exist in the FIM Service database already

2. The operation is not logged in the FIM Service request history

This is a good rescue utility for a lab environment, but I would not use it on a production server because I’m pretty sure Microsoft doesn’t support it.

PowerShell at the Core of Microsoft Server 8

‘Windows’ was intentionally dropped from the title here.  This article is a good read, and a demonstration of how serious Microsoft is about PowerShell.  If you were waiting to learn PowerShell, the time to stop waiting is NOW.

Windows Server 8: The Microsoft Server Fork

Some interesting points from the article:

Microsoft’s lead server architect is also the “inventor” of the PowerShell scripting methodology, whose command list will exceed 2300 native commandlets in Windows 8

Each Windows 8 version can be strongly PowerShell-controlled, and optionally with traditional GUI

Windows Server administration was encouraged to be PowerShell-driven, rather than through the maze of administrative GUIs that have been the mainstay of Windows Server versions for nearly two decades

Microsoft Adds BHOLD Technology Assets

Pretty neat announcement, and I’m excited to see what happens.  If the BHOLD stuff gets lopped into a FIM box with a new splash screen then I think that would be a fail.  In fact, since GRC is already growing in System Center you could argue FIM + BHOLD is  the wrong pairing.
When Zoomit was acquired back in 1999 we had the initial release of Via that amounted to some rebranding but mostly the same code until 2003 when the next major release represented true integration into the Microsoft platform.
When Alacris was acquired and added to the ILM box we had the same initial release (mostly branding changes) but the next major release did not enjoy major changes or integration (Just ask Brian Komar to spot the differences…).  Instead FIM today is composed of three products (Sync, Service and Certificate Management) each with their own set of APIs, databases, user interfaces, policy engines, etc.  While the amount of features is compelling, the cohesion could be better (FWIW – I am NOT saying that competitor products are any better, just that I have a higher expectation of software from Bill’s software hut).
My expectation in the short term is that BHOLD will simply be rebranded.  Longer term I hope the technology is truly integrated into FIM or System Center, or into some fascinating Azure concoction. 
For good TV, think about what happens to the other ISV partners that provide the same technology to Microsoft customers.  What happens when the 800 pound gorilla makes THIS step?
The TEC conference in Germany next month just got a little more interesting…
Update: Kinda neat, this blog gets mention in BHOLD's press release.

PowerShell 3.0 Workflows

An early version of PowerShell 3.0 is available for download:

The next version of PowerShell is exciting enough, but THIS is just too much:

Windows PowerShell 3.0
Some of the new features in Windows PowerShell 3.0 include:

• Workflows
  Workflows that run long-running activities (in sequence or in parallel) to perform complex, larger management tasks, such as multi-machine application provisioning. Using the Windows Workflow Foundation at the command line, Windows PowerShell workflows are repeatable, parallelizable, interruptible, and recoverable.

I like really really love PowerShell because it is a strong automation and integration platform, which is basically what we use FIM for.  Oh, and it is actually FUN to use.  Sometimes I joke that FIM is just a few good PowerShell cmdlets away from being replaced entirely by PowerShell.  That sounded funny to me when I first said it a couple years ago, but it seems a little more real now that PowerShell supports workflows.

Hopefully I’ll be able to demonstrate this at TEC in Frankfurt next month during my AD PowerShell session, which is basically about using PowerShell for AD automation and integration when you can’t use FIM.  Today that might be the poor man’s replacement for FIM.  Tomorrow that might just be the replacement for FIM, who knows…

Find Permission Granting MPRs

When troubleshooting sometimes I need to find the MPR that grants permission to an attribute.  The script below just issues a query to FIM to find the MPRs that grant access to the attribute.

‘ActionParameter’ is an interesting case because on the surface it looks like it should be a reference, because the UI provides a dialog that resembles the identity picker.  The attribute is not a reference though, as you can see in the output below it comes out as a string.  Compare this to the other attributes in the MPR that are indeed references, such as Creator and PrincipalSet.

In the sample below I use an extra variable to stretch out the XPath filter.  I find this much easier to read, instead of cramming the filter into a one-liner.

001 002 003 004 005 006 007 008 009 010

$filter = @" /ManagementPolicyRule [   ActionParameter = 'HasAccessToStuff'   and   GrantRight = 'True' ] "@ Export-FIMConfig -Only -CustomConfig $filter |     Convert-FimExportToPSObject

ObjectID                 : urn:uuid:7a797e38-ad64-4001-8c24-9a872826c2d4 ActionParameter          : {AccountName, HasAccessToStuff, HoofHearted} ActionType               : {Modify} CreatedTime              : 9/8/2011 4:35:26 PM Creator                  : urn:uuid:7fb2b853-24f0-4498-9534-4e10589723c4 Description              : This MPRS grants permission to IceMelted DisplayName              : HoofHearted can Modify Access to stuff and things GrantRight               : True ObjectType               : ManagementPolicyRule PrincipalSet             : urn:uuid:25a42597-1b6b-4221-b7d4-63a0a8b6a2b0 ResourceCurrentSet       : urn:uuid:8887df8e-6e84-49f2-a794-f9e9802077e0 ResourceFinalSet         : urn:uuid:8887df8e-6e84-49f2-a794-f9e9802077e0 ManagementPolicyRuleType : Request

PowerShell Deep Dive Content from TEC 2011 in Vegas

The most exciting part about TEC this year is the new PowerShell Deep Dive track.  The cult-like following once enjoyed by the metadirectory seems to be alive and well in the PowerShell community, and was finely gathered at TEC in Vegas.  For those going to TEC in Frankfurt, you’re in luck as there will again be a PowerShell Deep Dive track.

Anyhow, Dmitry has been kind enough to post the PowerShell Deep Dive Content for those that missed it.

Oh, also posted are the abstracts for the PowerShell Deep Dive track in Frankfurt.