Monday, July 23, 2012

Chasing References in FIM

Polyarchy has been one of my favourite tools that never shipped from MMS 3.0.  I was happy to see it mentioned by Kim Cameron in a really neat post lately:

Yes to SCIM.  Yes to Graph

Kim talks of the value of references in the data, mainly to show us the importance of the new Graph API but it also pertains to FIM 2010.  Today in FIM 2010 we can query the web service using XPath as the filter dialect.  It turns out to be pretty powerful in its ability to traverse references.  When the schema is designed correctly, the references in the objects can make easy work of rather sophisticated queries.  Unfortunately some of that sophistication is tamed for performance reasons in FIM Set definitions – but otherwise you can still issue some pretty useful queries.

For example, suppose a Request was submitted to create a Group object.  FIM gets busy creating objects to track the workflow and approvals.  On completion, we can use the relationships to easily get detail about the actors, such as this query to get the approver of the request:

$XPathFilter = @"









Export-FIMConfig -only -CustomConfig $XPathFilter | Convert-FimExportToPSObject

The output of the above command is the Person object that approved the Request.

ObjectID    : urn:uuid:d51a311e-ehaa-eheh-98c3-c788b4b55154

AccountName : hoofHearted

CreatedTime : 7/23/2012 6:09:24 PM

Creator     : urn:uuid:306f4a58-ec2c-4a6b-aa9a-6b34ee7588d3

DisplayName : Hoof Hearted?

Domain      : IceMelted

Email       :


ObjectType  : Person

As much as I’ve enjoyed learning about XPath, I can’t believe it has an enduring future in the product.  If FIM follows AD then I believe the time spent with WS.* will be short lived as the Graph API is all about OData/REST.  It seems the journey has been LDAP –> XPath/WS.* –> OData/REST.

Monday, July 16, 2012

APIs are the new integration platform

There is huge momentum behind ‘APIs’ which seems obvious from a software point of view, but APIs are kinda like the new ODBC in that you can easily connect to any number of things with common protocols and encoding. 

From a metadirectory standpoint this is really neat because the integration/reach story has always been the management agent for me.  Today the API plays a key role in the integration/reach story (how many things can you connect to?, Do you have an MA for X?).  This should shift the value of the metadirectory to the integration features it provides, instead of just the number of things it can connect to.

Anyhow, here’s a neat sample of using an API to connect to Bing to provide search results.  There are a huge number of public/free APIs to choose from, including some that come from Microsoft server products like Windows and Active Directory.

Using PowerShell to Query the Bing API

Monday, July 02, 2012

Dell to Acquire Quest Software

I' am a HUGE fan of the TEC conference put on by NetPro, then Quest and hopefully in the future, Dell:

Dell to Acquire Quest Software

Quest is a special company because of their cool products and their contributions to the PowerShell community.  Looking forward to seeing Dell make this even better in the future.

Microsoft Announces Winners and Finalists of the 2012 Partner of the Year Awards

Microsoft partners work hard to get nominated, so congrats to all.  I’ve been watching these for a few years now and this year the results seem different (except for Oxford of course).  As a metadirectory historian I find this year’s results interesting for a few reasons:

  1. There are a lot of systems integrators (sometimes unsung/unknown) doing FIM work (yay!)
  2. There is a trend for LARs to do SI work (who knew CDW would deploy FIM for you?)
  3. FIM is leaving it’s incubation/niche nest

From the press release:

Identity and Security Partner of the Year

· Winner: Itergy

· Finalist: CDW Corp.

· Finalist: Oxford Computer Group Ltd.

The Identity and Security Partner of the Year Award recognizes the partner that has delivered end-to-end security, identity and access solutions enabling customers to achieve their business goals while managing risk and helping to ensure that the right people always have secure access to the information they need to get their jobs done. The winning solution used Microsoft’s security, identity and access products, technologies and solution accelerators, including, but not limited to the following:

· Microsoft Forefront Endpoint Protection

· Microsoft Forefront Protection for Exchange Server

· Microsoft Forefront Online Protection for Exchange

· Microsoft Forefront Protection for SharePoint

· Microsoft Forefront Security for Office Communications Server

· Microsoft Forefront Threat Management Gateway

· Microsoft Forefront Unified Access Gateway

· Microsoft Forefront Identity Manager

The winner has dramatically transformed the security of a customer’s IT infrastructure resulting in higher levels of protection and compliance, reduced IT labor or hardware costs, or streamlined overall operational efficiency.

Neat Article on Hierarchy in SQL Server

Here is a neat article on Hierarchy in SQL Server:

Hierarchies: Convert Adjacency List to Nested Sets

It is relevant to FIM because both the FIM Service and FIM Synchronization Engine deal with sets and hierarchy, and sometimes we do this hierarchy processing outside of FIM (pre-processing) because we need to handle hierarchy differently than the engines do today.

A really great FIM blog post would be to share how FIM processes hierarchy internally, but I’m just not that deep in SQL to go digging for the answer.

This also makes me wonder what the relationship is to .NET 4.0 and the DLR (Dynamic Language Runtime).  We see some great uses of this in PowerShell 3.0 in the form of Intellisense (freakishly awesome!).  While I don’t have a lot of hierarchy challenges in front of me today, I would be really curious to solve them with the ‘blinding speed’ of SQL and the awesomeness of PowerShell.