Monday, February 25, 2013

Update your MARunScheduler

This may just be one of the shortest blog entries that I ever did. But if you are a heavy user of my MARunScheduler, I just wanted to let you know that there is a new version out. You can get the new MARunScheduler here -

Also, if you're on Facebook, I'd be happy to get your "thumbs up" there, so go and get more informal updates and news through Facebook on

Tuesday, February 19, 2013

Hotfix for FIM 2010 R2

A short while ago, Microsoft released a small hotfix for FIM 2010 R2. You can read more on this hotfix in KB2814853.

Also, notice that this hotfix has a known issue that can "break" your ECMA / XMA Management Agents, but also has a description for fixing this if you run into that issue.

New version of the PowerShell Management Agent

It has been around since April 2011 and popularity is still growing.

The number of downloads of version 4 of my PowerShell Management Agent for FIM 2010 has just passed 300. And with that number of downloads from more than 20 different countries, this MA seems more popular than ever. It's being used extensively for all different purposes and is extremely popular for handling Office 365 users/licenses. So the need for this flexible type of MA is very clear.

Also, I get tons of support requests from all over the world asking me for help on writing PowerShell scripts for the MA or even for general help on using and configuring FIM. I usually refer most of these to the FIM 2010 forums where I'm happy to see that different people are very happy to help and give good advice and support for using the MA.

I want to keep expanding on the functionalities of this powerful Management Agent as needs arise and as FIM and the ECMA2 framework evolves. Now, I've already had a some great feature requests but I do want more.

I want your five cents

I'm currently working on the next version which will be out this spring. It will have the following enhancements -
  1. Support for password change/sets (thereby supporting password synchronization / PCNS)
  2. Support for custom error message returned to the Sync Engine
  3. Flexibility on the type of object passed to the Export script (allowing for simpler export objects in the export script)
  4. Generally, utilizing the new features of the ECMA2 framework that is introduced with Service Pack 1 for FIM 2010 R2
  5. A few other hidden gems to be revealed later...
If you are using the PowerShell Management Agent today in your or your customers FIM installation, I would very much like to get your ideas and feature requests for this next version.

I'm open to your ideas and requests, so drop me an email with your ideas or even better yet, share your ideas as comments here on this blogpost, and I'll be sure to pick them up.

Thank you very much for your support.

Tuesday, February 12, 2013

How to return custom error messages in ECMA2 SP1

While updating my Management Agents (or connectors) and building a new one for a customer, I wanted to take advantage of the new possibility in the Service Pack 1 version of the ECMA2 framework where you can return a custom errorname and error detail to the Synchronization Service Manager. It took me sometime to get my head around this, but I finally got it working.

Before Service Pack 1, you could also use the CSEntryChangeResult to return a error on your imports and export actions. In your PutExportEntries interface code, you would put something like this to return a export error -

CSEntryChangeResult cschangeresult = CSEntryChangeResult.Create(csentryChange.Identifier, null, MAExportError.ExportErrorSyntaxViolation);

This line above would show up as a export error with the error code 'syntax-violation' in the Synchronization Service Manager. You can find the additional MAExportError options here (

With Service Pack 1, however, you are now able to return a custom error name and detail, which is awesome because you can give more information to the administrator. The caveat is that you do need to set MAExportError to either ExportErrorCustomContinueRun or ExportErrorCustomStopRun for your custom error information to be returned. These two enumeration options are new for Service Pack 1 and I was struggling for a few hours before I noticed these.

So after changing my MAExportError enumeration value to ExportErrorCustomContinueRun, my custom error message was returned to the Synchronization Service Manager. My line now looks like this -

CSEntryChangeResult cschangeresult = CSEntryChangeResult.Create(csentryChange.Identifier, null, MAExportError.ExportErrorCustomContinueRun, "script-error", scriptResult);

Notice that I keep my error name to the general, well-known syntax of <warning/error>-<message> (second last parameter). I just like this as a best practise but it is not a requirement; you can write any text, you like.

Happy coding.