Monday, September 29, 2014

DSC Resource Property Name Cannot Be 'scope'

Been doing a lot of custom DSC resource work lately, and now have some seriously good coverage of FIM configuration object types in the FIM Service.  Best part is, I got through most of them without hitting any major snags in PowerShell Desired State Configuration (solid work by the PowerShell team!).

On my last custom DSC resource, I tried to add a property name of ‘Scope’, since I was working with the Group object type which has an attribute named ‘Scope’.  I created the DSC resource provider just fine but when I went to write the tests for it I got a generic DSC error:

PSDesiredStateConfiguration\Node : The term 'cFimGroup' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included,

verify that the path is correct and try again.

PowerShell does a great job with error messages usually, but this one wasn’t specific enough to make debugging easy (at least for me).  It took me a while to track down but I figured out that you can’t use the word ‘Scope’ as the name of a DSC resource property.

Anyhow, I have a workaround but managed to file a bug for PowerShell (vote for it if you hit this too, but I suspect nobody will have this specific problem): DSC Resource Property Name Cannot Be 'scope'.  Kinda neat to finally find a bug in PowerShell, but even so it doesn’t matter so much because the workaround is pretty simple.

Monday, September 08, 2014

Get-ADGroupMember Forgot My Contacts

Working on a script to copy groups and members from one forest to another, and was so happy with the Get-ADGroupMember cmdlet but ran into an issue that means I can’t use it.

The challenge was that the cmdlet wasn’t returning the correct group membership.  I could count the group members using this:

 

Get-ADGroup hoofhearted -Properties member |

Select-Object -ExpandProperty member

 

However, this command would return no objects:

 

Get-ADGroup hoofhearted |

Get-ADGroupMember

 

Thought it just a permissions issue, that I had access to the group but not the member objects, but that turned out to be false.

The answer is right in the TechNet documentation for the Get-ADGroupMember cmdlet:

The Get-ADGroupMember cmdlet gets the members of an Active Directory group. Members can be users, groups, and computers.

Note that members can be users, groups and computers (NOT contacts).  Bummer, I guess they designed the cmdlet with security principals in mind so didn’t include contacts.

The workaround isn’t very difficult:

 

Get-ADGroup hoofhearted -Properties member |

Select-Object -ExpandProperty member |

Get-ADObject

 

This is one of the things I love about PowerShell, and one of the reasons they don’t take many bugs, because there is almost always an easy workaround. 

Thursday, September 04, 2014

What Requests Touched my FIM Object

Changes to objects in FIM usually happen when a Request is processed.  Here is a quick query to find recent Request objects that touched a given FIM object:

 

###

### Find Requests that touched a certain object with a specific time

###

Export-FimConfig -Only -Custom "Request[Target = /ManagementPolicyRule[DisplayName='HoofHearted'] and CreatedTime >= '$([DateTime]::UtcNow.AddMinutes(-5).ToString("s"))']" |

Convert-FimExportToPSObject |

Select-Object -Last 1 |

Get-FimRequestParameter |

Format-Table Mode, PropertyName, Value -AutoSize

 

There are only a few tricks in this snippet:

  • Using the “s” format string to get a DateTime string compatible with the XPath query for FIM
  • Using [DateTime]::UtcNow to get a DateTime in the same ‘kind’ as FIM
  • Using Get-FimRequestParameter to parse the FIM Request details into sometime easier to work with

I have been using this lately to validate that the code I’m working on is producing the expected changes in the FIM Requests it is making.

It’d be so nice if FIM would tell you the ObjectID of the Request it creates after you submit the operation to the FIM web services.