Sunday, September 30, 2012

Keep Calm and Learn PowerShell

This week I installed Windows 8 on my main work desktop.  I was mostly enticed by Hyper-V on the client.  VirtualBox has served me surprisingly well for the past few years, but the Oracle splash screen was getting too hard to swallow.

Holy Kittens!  Windows 8 was not an easy UI to love at first.  The learning curve shocked me, and the amount of disorientation was a bit embarrassing.  When I first started using Windows 8 I couldn’t even shutdown the machine, I had to open PowerShell to do so.

BTW – if you don’t already know PowerShell, yesterday was the time.  If you manage Windows computers, you MUST learn this.  Here’s a fun Lock Screen image to share this opinion (  Anyhow, on with the Win8 rant…

The move from iPhone to Windows Phone 7.5 took about a day to get over.  The move from Windows 7 to Windows 8 has taken me a few days, but I can forgive that learning curve because I do like the new OS, and enjoy the features it brings.  The shocking part for me is that I consider myself an experienced Windows user, and worry that the learning curve for the average Windows 8 user on computer with a keyboard and mouse will be, well, um, higher.  My hope is that people are delighted by the stability, features and improvements enough to forgive the learning curve this OS requires.  I know I am already happy, but even more excited to see what Surface feels like next month!

Wednesday, September 19, 2012

Group Expansion in the FIM Service

The FIM product is full of little features than can be fun to discover.  Just when you thought you knew it all…  Somebody asked me about using FIM Groups as owners of Groups, and I didn’t have the answer so I tried it.
#FAIL.  Turns out you cannot use the FIM Portal to add a Group as an owner of a Group. 
Then I dug a little deeper and tried it directly against the FIM Service (bypassing the FIM Portal, which is really just a client to the FIM Service).  The FIM Service happily accepted the request.  The script and resulting request are shown below.
### Add a Group as the Owner of another Group
New-FimImportObject -State Put -ObjectType Group -AnchorPairs @{DisplayName='testGroup828'} -Changes @(
    New-FimImportChange -Operation Add -AttributeName Owner -AttributeValue ('Group','DisplayName','GroupOwnersGroup')   
) -ApplyNow

The interesting thing about the request above is that it shows the type of object in the reference, indicating that we have added a Group to the Owner attribute.
The next thing I wondered is, what happens when the FIM Approval Activity processes a request where approval is required?  We know the Approval Activity refers to the Group owner attribute with XPath syntax, so what is it expecting when it finds a Group there instead of a Person?  Will it freak out and end this experiment?

### Add a user to the Group
New-FimImportObject -State Put -ObjectType Group -AnchorPairs @{DisplayName='testGroup828'} -Changes @(
    New-FimImportChange -Operation Add -AttributeName ExplicitMember -AttributeValue ('Person','DisplayName','newGroupMember1')   
) -ApplyNow
The result of this script is actually quite interesting.  The script just adds a member to a Group that requires owner-approval for new members.  This triggers an MPR that fires a Workflow with the Approval Activity.  The Group in question has two owners listed:
1. groupOwner1 (a person object)
2. GroupOwnersGroup (a group object)

The Approval object created by the Approval Activity shows that FIM is expanding the members of GroupOwnersGroup and placing them into the Approval as Approvers.  Pretty cool.  So the FIM Service expands groups for approval activities similar to how Exchange expands groups for mail delivery.

The moral of the story here is that the FIM Portal is really just a client to the FIM Service, and that scenarios may be closer to working than the portal will have you believe.  In this case, I bet the Group RCDC can be modified to allow you to select Groups as owners, and the whole thing will probably work.  Probably.  The pessimist might wonder why it isn’t this way already in the product?  Is there a bug lurking in there that my little experiment dodged somehow?  Time will tell.  I know I’ll be looking into this a little deeper and writing a few test cases for it.

Does it work with Nesting?

Somebody responded and asked if this still works with group nesting, so I tried that too.  I added another group with two members, then added the new group to the scenario above and the Approval Activity still expanded all the way to the nested group’s members.

Wednesday, September 12, 2012

FIM Ducks the Axe

Phew!  That was a close one!  Seems Microsoft pruned heavily in the Forefront bushes today:

Microsoft axes many of its Forefront enterprise security products

The FIM suite survived, which is good given the momentum added to it with the R2 release and BHOLD.  Also good because I enjoy being a FIM MVP and image they wouldn’t need many of those if FIM got the axe.

Tuesday, September 04, 2012

Does Code Coverage Really Matter for FIM Deployments?

There is tremendous value in treating a FIM deployment like software development project but there is a balance to strike between dev and ops (devops anyone?).  Keep in mind, I qualify myself as more ops than dev!

Code coverage is good at measuring how much of a project’s code is covered by tests.  FIM as a product aims to be highly declarative, in theory making the product easier to deploy without writing much code.   A FIM deployment (even one with lots of code) consists mostly of configuration.  Unfortunately there is no ‘configuration coverage’ tool for FIM, which makes it difficult to measure how much of a deployment’s configuration is covered by tests.

Code Coverage Doesn’t Provide Enough Value for the Typical FIM Deployment

My opinion is that code coverage by itself doesn’t provide enough value or raise quality enough for the average FIM deployment because most of the functionality is accomplished through configuration supported by some code.

Test Plans Become More Important

With or without code coverage, we’re supposed to have a nice little document that describes all of the tests we will perform on our deployment, and how we are going to do them.  The test plan needs to have tests for all of the functionality that is supposed to be in the solution.  The lack of code coverage puts more pressure on this document (and the resulting tests) to be more complete.  My suspicion here is that very few deployments see quality measured this way, but I bet most get a rubber stamp on testing!

Code Coverage for Finding Dead Code

A FIM deployment with lots of code has probably been produced and maintained by several developers (and even non-developers) over time.  Code coverage can be used in this scenario to simply show how much code is executed.  For example you can instrument your DLLs, deploy them to your server and let it run for a day or two then produce the code coverage report.  It will show code that is most likely no used, and can likely be removed.  Some of it will be obvious (properties and methods that are never called) but some of it could be code for use cases that rarely happen in production.

Can a Configuration Coverage Tool Be Built?

I thought about doing this for the Sync Engine, and for the FIM Service a while ago but decided against actually building it because there are probably very few people that would actually use it.  Maybe as FIM integrators move more towards devops it will be interesting.  Hopefully it will since configuration coverage would be a really fun tool to build.