How to Use PowerShell to Troubleshoot FIM Query Issues

Trying something new, posting to the FIM wiki:

How to Use PowerShell to Troubleshoot FIM Query Issues

There are a lot of useful scripts on the FIM wiki and I like the idea of collecting them all in one neat place.

FIM MVP’d Again!

I’ve been honoured with FIM MVP status again, so am basking in the glow of my MVP’ness.  2011 was a fun year for me working with FIM.  I was lucky enough to engage in really fun and challenging projects.  I was also lucky enough to get invited to speak at a few conferences.  Conference sessions are a forcing function for me to share something on CodePlex.  Last year I put up a few projects, and am actively using most of them in production today, as are some other people that were able to take the source and run with it. 

This year I plan to keep those same projects moving, and maybe add an additional project or two.  FIM is a sweet spot for PowerShell because it lowers the coding bar for IT Pros like me, while at the same time extending the reach and automation of FIM.  On a daily basis this means I get to do FIM deployment work while writing fun PowerShell scripts.  It’s fun work and I’m glad to be recognized as part of the community again.  Woo-hoo!

TEC 2012 Agenda is Filling Up!

Looks like some fun sessions lining up for TEC 2012.  Once again the PowerShell Deep Dive is on the agenda, so I expect to sit in there to learn as much as possible.  PowerShell 3.0 should be in beta by then so there oughta be a bunch of really cool sessions on things like WF and WS.

Oddly I’m mentioned in the press release for the PowerShell Deep Dive.  While I’m still a FIM MVP, I do tend to talk a lot about PowerShell simply because it makes for excellent integration glue.  The sessions and workshop I’ve proposed all include some angle of PowerShell so I’m hoping I get the opportunity to share as much as I anticipate learning ;-)

Wiping out the WSS Internal Database

Recently I was making some changes to a server (in my VM lab) that created an interesting problem.  FIM had been running under the security context of a local computer account, and I wanted to switch it now to a domain account.

The process of uninstalling FIM (Service and Portal) then SharePoint seemed to go fine.  Then re-installing WSS would not work.  The installation log complained of a database connection, so it did not like having the database lying around from the previous installation.

The simple fix was to follow the guidance in the article below to delete the Internal Database:

Windows Internal Database is not listed in the Add or Remove Programs tool and is not removed when you remove Windows SharePoint Services 3.0 from the computer

After following the instruction (one step!) in the KB article, I was able to install WSS, then get on with re-installing FIM.

Don’t Be a Button Monkey

It’s no secret that I’m a huge fan of PowerShell.  The simple reason is that it makes for impressively effective integration glue, AND it is actually fun to use.  FIM is also strongly rooted in integration glue, but Don Jones’ example of Button Monkeys highlights a big difference between FIM and PowerShell. 

FIM (with its Codeless Provisioning) is aimed at making life easier for both the Button Monkey, and its users.

PowerShell declares that Button Monkeys are on the verge of extinction, and challenges them to evolve by learning (and building) new tools.

I’m not saying PowerShell is going to replace FIM.  Both are integration tools and have great value.  FIM provides value that does not overlap with PowerShell, while PowerShell provides value and benefits to FIM to extend the reach of FIM, while making it easier to design/deploy/manage. 

My take is: PowerShell adds an incredible (and fun) opportunity for FIM folks to solve integration challenges faster, with higher quality.  Don’t be a Button Monkey.

BTW – when Don talks about WF in PowerShell, think about what that might mean for WF in FIM…

FIM 2010 R2 RC is Available

Fresh off the press:

Forefront Identity Manager 2010 R2 Release Candidate Now Available

FIM 2010 R2 includes the big new reporting feature based on System Center (I’m more partial to PowerShell reporting of course).  This release also includes fixes to the FIM PowerShell snap-in, such as the ability to import DateTime attributes.

Quit Blocking My Pipeline!

A really cool feature of PowerShell is the async nature of the pipeline, whereby the first command outputs to the next command as soon as it has any results (so BEFORE it is done collecting ALL of its results).

Sometimes because of filtering or selection you only want a subset of the results from the previous command.  In these cases it is nice to not have to wait for that first command to finish, but if that command blocks the pipeline you get to wait for it to complete.

This is one of the annoyances of Export-FimConfig.  Though it is a very useful cmdlet it does block the pipeline.  You can see from my script below that I am only looking for the first item from the output.  I can only get that first item AFTER all the results are returned.

If this is an annoyance for you too then feel free to vote for the feedback on Connect.

A reasonable workaround is to instead write your own cmdlet to replace Export-FimConfig (such as the FIM cmdlets on CodePlex thanks to Quest), but it sure would be nice for this to just work.

FIM Protocol Docs

I seem to mention these things a lot, but never show where to find them.

The first hint was from Joe Schulman (ex-FIM PM)

As a small part of the the announcement about Office 2010 Technical Preview, Microsoft published the Office 2010 protocol documents. A small and dedicated group of us worked hard and long for these past months to release documents related to FIM’s protocols on time. Of particular interest to this audience may be the FIM web service protocol document.

The protocol documents are part of Microsoft’s earnest commitment to interoperability. More information about this program can be found here.

There happen to be quite a few protocol documents for FIM, each document name starts with “User Profile Synchronization (UPS)”.  Why THAT name?  My guess is that these were published because SharePoint took a dependency on FIM when they delivered their component for User Profile Synchronization.  Anyhow, there is the list:

• [MS-UPSCDAP]: User Profile Synchronization (UPS): Configuration Database Data Access Protocol Specification
• [MS-UPSCDS]: User Profile Synchronization (UPS): Configuration Data Structure
• [MS-UPSCP]: User Profile Synchronization (UPS): Configuration Protocol Extensions
• [MS-UPSDBDAP]: User Profile Synchronization (UPS): Database Data Access Protocol Specification
• [MS-UPSLDAP]: User Profile Synchronization (UPS): Lightweight Directory Access Protocol Version 3 Extensions
• [MS-UPSMODS]: User Profile Synchronization (UPS): Management Objects Data Structure
• [MS-UPSSCXPP]: User Profile Synchronization (UPS): Schema Exchange Protocol Profile

The most interesting protocol document in terms of deployment automation is MS-UPSCDS (Configuration Data Structure) since it details the ma-data and mv-data XML.  Get those right and you can manage the sync engine via the FIM Service, that’s the theory anyway…