Using Ryan Newington’s PowerShell Module to create a Mail Notification process

, , 0 Comments

One of the things that I had to bear in mind for my FIM implementation was that the current legacy code provides email notifications of changes made. Due to the nature/ structure of the organisation, the different groups only want to know about changes to their own users.

So, when initially thinking about what people are currently informed about, and then the number of MPR’s, Workflows, Sets and Mail templates required to duplicate that functionality – I thought “no way!” It would be unmanageable. In the end and after discussion with the recipients of those mails, I got to a manageable number of things that those people really wanted to know about. These are:

  • A new user starting (a real new person), or a person who has moved horizontally within the organisation – they have moved INTO that department.
  • A user in their department becoming disabled
  • A user in their department becoming deleted
  • A user moving OUT of their department

So, I’m down to 4 things, but I have 9 different groups to inform.- So I have 36 Templates, 36 Workflows, 27 Sets and 36 MPR’s to define…..Even if I had a minion, I wouldn’t make them do that manually….

So, during Ryan’s presentation to the FIM User Group, I noted that he had introduced the ability to import these object by providing an XML file that defined them.

Using the examples from here https://lithnetrma.codeplex.com/wikipage?title=configuration%20management&referringTitle=Home and a bit of syntax pain, I ended up with the XML file below – note that this only does the “stuff” for one one those groups – my production XML file has all of this 8 more times – with pointers to alternate XOML and html files.

Load the Module, then check the validity of the XML file by running:

Import-RMConfig -File .\YourXmlFile.xml -Preview -Verbose

If all looks OK, run the command again without the Preview & Verbose switches.

My initial runs ran into errors due to the way that the employeeEndDate plus 180 days filter was being passed to the FIM service. Ryan has rapidly fixed and produced new versions to resolve these problems.

The great thing about this method, is that by using xmlref pointers, everything just joins up, resulting in a consistent set of objects that reference each other.

Note that the line:

Is used to provide a reference to the mail recipient, more recipients could be added, using the same structure, but a different id. Other pre-existing object references could also be added as appropriate.

So to summarise what is defined in the XML file:

  • 4 Email templates – Add, Disable, Delete & Move – each with a corresponding and each slightly different html file
  • 4 Workflows – Add, Disable, Delete & Move – each with a corresponding and each slightly different XOML file
  • 3 Sets – User in OU=Blah, User in OU=Blah AND whose Status=Disabled, User in OU=Blah whose end date has passed, plus 180 days
  • 4 MPR’s – Add, Disable, Delete & Move – all are transition in, except for the Move MPR, which is a transition out.

An example of the XOML and html: