Here’s why I don’t like codeless sync rules (aka “Declarative Provisioning”):

• They don’t do everything you need,
• The whole Sync Rule – Workflow – MPR combination will get overly complex once you have a few different scenarios on the go,
• It’s difficult to troubleshoot,
• It adds extra objects (EREs and DREs) to slow down the sync – and the FIMMA is slow enough already,
• It requires CALs, which will put it out of the price range for a lot of people anyway.

There are already plenty of questions on the forum along the lines of ”How can I do x with codeless?” And more often than not the answer is “You can’t – but you can do it with a coded sync rule”. The fact is, to get the most out of this product you must, must, must learn about the ILM/MIIS ways of programming the Sync Service. And you may even find that it’s enough for your needs, and you can do without the CALs for now.

If you’d like to learn some more about traditional ILM methods then these posts are a good place to start: http://www.wapshere.com/missmiis/new-to-ilm-start-here

I’m pretty pleased with the results. Both of the following scripts use a CSV to bulk-create the groups:

Create Security Groups based on Filters

Create Distribution Lists for Managers which contain all the people they manage

The scripts run pretty slowly, but it’s still quicker than creating the groups by hand.

If you want to have a go at a script like this (and you can’t find an example in the ever-growing FIM Scriptbox) then I suggest you create a sample object by hand and then inspect both the object’s Advanced Properites, and the Details of the Request object which created it, for an idea of which attribute to populate.

While developing the scripts I saw the following error far more times that I would have liked:

Microsoft.ResourceManagement.WebServices.Client.PermissionDeniedException: Policy prohibits the request from completing.

After messing around with MPRs it eventually became clear that this just meant I had populated an attribute incorrently, or missed one out, and was not about permissions at all.

Handy!

I just posted this article in the Greatest Hits series of the ILM Technet forum. It describes some of the methods and considerations around disabling and deleting users accounts with ILM.

In Identity Management, deprovisioning is every bit as important as provisioning – in fact the security guys would say it is more important.

End-of-life management may have been one of the determining factors that got the IdM project started in the first place – while most
organizations have a variety of scripts and processes they use to create accounts and assign permissions, the cleanup when a person leaves is often not handled so well.

General rules for object deletion have been already well covered in Markus’ article
Understanding Deletions in ILM; however there is more that can be said on the subject of user accounts, for which an immediate delete is often not appropriate.

This article shows how you can use ILM to configure a flexible deprovisioning solution that is customized to your technical, organizational and compliance needs.

Account Deprovisioning Scenarios in this document

We are going to look at the following types of account deprovisioning:

1. Simple deletion
2. Disabling the account
3. Deleting the account on a time-delayed basis
4. Stopping ILM from managing the account without actually deleting it (disconnection)

Parts to the Account Deprovisioning Puzzle

Depending on your needs, you will most likely have to piece together a number of different elements to achieve the desired result.

Account Disabling:

Deactivating an object normally involves changing one or more of its attributes (eg.: setting userAccountControl on an AD user), and the usual way to do this is with an export attribute flow (EAF).

See code example “Disabling Flow Rules” below.

Moving deactivated accounts:

• A common practice is to put disabled accounts in a particular place, such as a “Disabled” OU.For AD this is a “Rename” activity, and is typically done in the metaverse
  extension code.
• For the “Stop management” scenario it is also possible to move the account just prior to disconnecting it in the MA Extension Deprovision method.

See code example “Metaverse Deprovisioning” below.
 

Deleting the connector space (CS) object:

• The first step to deleting an account is to delete the object that represents it in the connector space.This can happen in one of the following two ways:
  • The joined Metaverse object is deleted
  • The joined Metaverse object was disconnected, either manually or by using the
    CSEntry.Deprovision() method in the
    metaverse extension code.
• In both cases a deletion will only happen if the “Configure Deprovisioning” tab on the MA configuration has been set as follows:
  • “Stage a delete on the object for the next export run”, or
  • “Determine with a rules extension” AND the rules extension code returns
    DeprovisionAction.Delete.

 
See code example “MA Deprovision Sub” below
 
See “Metaverse Deprovisioning” for an example of the CSEntry.Deprovision() method.
 

Deleting the account in the connected data source (CDS):

• To delete the actual object in the CDS, we must first delete the connector space object using the methods above, after which we should find an export of type “delete” ready in the connector space.It is then just a matter of running an Export.
  • Note that the account used by the MA must have permission to delete objects of this type in the CDS.
  • Note also that if the MA is of type “Extensible Connectivity” you must write a Delete method in the Connected Data Source extension (see example below).

 
See code example “XMA Delete Method” below.
 

Time dependant deletion:

• Sometimes you want to delete an object on a certain date – perhaps an expiration date, or 3 months after the account was disabled.To do this you need the date available on the Metaverse object, which means you have to flow it into the Metaverse from somewhere.
  • An example for AD accounts is to use a spare attribute on the account, such as info or one of the extensionAttributes, to write the date at the same time as you disable the account.Flow this value back into the Metaverse and the information will be available.

 
See code example “Metaverse Deprovisioning” below.
 

Deprovisioning Scenarios

Simple Deprovision based on disappearance

The simplest deprovisioning scenario, and the one that can be executed without writing any code, is the “disappearance” scenario.

Here an object (or database line, or text file line) disappears from a source MA and is imported as a delete.

In the Metaverse we have configured our Object Deletion Rule as “Delete Metaverse object when connector from this management agent is disconnected” and selected our source MA.

Finally we have configured our other MAs to delete the CS objects when the Metaverse object is deleted.

In this way we could, for example, delete an AD account because the person’s record disappeared from the HR data source.

Caution: This method may lead to unexpected loss of accounts, temper and job!

As a general rule, it is a bad idea to make destructive decisions based on an absence of information. All sorts of errors, both human and machine, could happen to cause data to be unavailable at the time an Import runs. If you do use this simple approach, only use it for low-priority objects that can be deleted and recreated without much impact.

Deprovision based on attribute change

It is a much better practice to make deprovisioning decisions based on positive data.

So, with the HR data source, we continue to import resigned people, but with a status flag that indicates they are now inactive.

We then write some code in the metaverse extension which reacts to the person’s “inactive” status.

The great advantage to this method is the flexibility it gives us.

For example, we may deal with the person’s connected objects in different ways, deleting contacts and application accounts immediately
but, just disabling the AD user account until further notice.

Deprovisioning a connector space object from metaverse extension code is trivial – all you have to do is add the line

CSEntry.Deprovision()

The bulk of the code before this will be spent in testing attribute values, and connections to different MAs, to determine when conditions are right to issue this command.

Disable then delete

It is simple enough to disable an account using an EAF (see example “Disabling Flow Rules” below).

You could also move the account to a special location (see example “Metaverse Deprovisioning” below).

However what do you do if you want to remove the account at some point in the future?

The first thing to be aware of is you must not delete the metaverse object.

To be able to delete the disabled account in the future it has to be connected to something in the
metaverse.

ILM can only manage connectors.

Next, you will need some kind of datestamp on the metaverse object so your
metaverse extension code will know when it’s OK to delete the account.

The only way to write a value to a metaverse object is with an IAF – so this implies writing the
datestamp outside ILM, on a CDS object, and then importing it back in.

The method in the code examples below works like this:

1. Based on the status attribute in the Metaverse, I export the userAccountControl to disable the AD user account,
2. Based on the same rules, I also export today’s date to the user’s info attribute,
3. II import info back to a metaverse attribute called disableDate,
4. I can then use disableDate in my metaverse extension to decide when the time is right to issue a CSEntry.Deprovision().

There are a couple of points to note about this method:

• While disables will happen on a delta sync, deletions will only happen on a
  full sync.
• The CDS attribute used to hold the date could be modified in the CDS (though you can use this to your advantage if you want to extend the disabled life of an account).

Stop Managing an Object

In some cases object deletion is handled in the CDS itself and all you need to do is to stop managing the object.

In ILM terminology the object becomes a “disconnector” and, while it may still exist in the MA’s connector space, it is no longer connected to a Metaverse object, and ILM can no longer impact it in any way.

To disconnect rather than delete you actually use exactly the same CSEntry.Deprovision() method, but with the correct option selected on your MA’s Configure Deprovisioning page.

You could choose to:

• “Make them disconnectors”. The object is disconnected but remains in the CS and CDS.It will be reassessed for possible joins at each Full Sync,
• “Make them explicit disconnectors”.Like the above, but it will not be reassessed for possible joins, or
• Decide with a Rule Extension (see example “MA Deprovision Sub” below).

The “explicit” option needs a bit more discussion.

If ever you delete and re-import the CS all “explicit” tags will be lost and the objects become regular disconnectors again, and available for joins.

This option should only be chosen in particular circumstances, such as when there is a regular and reliable deletion of redundant objects happening in the CDS.

If you are sure that you will not need to rejoin to an object once it has been disconnected then another idea is to export a blocking attribute before disconnecting.

For example you export the string “Unmanaged” to an attribute on the CDS object, and only disconnect it once the attribute value is confirmed.

You can then use this attribute in a Connection Filter to prevent future re-connections.

Some Common Problems and Questions

I staged some Deletes but I don’t want to export them now

Perhaps there was an error in your code or your import data and you have a bunch of Deletes waiting to go out – but you really don’t want to do that!

Even after correcting the code and re-syncing you may find they turn into Delete-Adds – these should also not be exported as the actual CDS objects will be deleted and recreated – not great for AD accounts!

Unfortunately, the only full-proof fix in this case is a delete and re-import of the connector space.

I have some old accounts with no HR reference – will ILM delete them?

ILM can only delete objects that it is connected to, so if it never connected to the object it can never delete it.

If you plan to tidy up unmanaged objects in your CDS then have a look at the tool csexport.exe (from the MIIS\bin folder) which can be used to export lists of disconnectors.

How can I block an Export if there are too many Disables?

The Export run profile contains an option to stop the job if there are more than a certain number of Deletes queued to go out.

Unfortunately it is not possible to do something similar for disables with native functionality.

If something like this is needed then it should be possible to increment a count in a file from the EAF which deactivates the account, and then modify the script which runs the Export profile to first check the count.

Sideways Joins

A scenario you need to watch out for is what I call a “sideways join”.

Take a situation where the “person” object type has one source MA (eg.: HR) and multiple target MAs (AD, Notes, some other applications).

The source object has been deleted, but one or more of the target objects have remained and are still joined to a
metaverse object.

The problem here is that these objects won’t show up in lists of disconnectors and so can remain, unobserved, for some time.

If deprovisioning logic is based on a value from the source MA then, in a default configuration, this value would have been recalled and is no longer present on the Metaverse object – so your code is probably just skipping it.

When writing your metaverse extension code, it is a good idea to test for unexpected situations – like an object with no connector in the primary source MA – and then throw an error or otherwise deal with the object.

I can see Deletes staged in the connector space, but the objects don’t get deleted in the external system

First, look for error messages in Identity Manager and in the Event Log that may indicate the problem.

Make sure the account used by the MA has the correct permissions in the CDS.

If it’s an “Extensible Connectivity” MA, check that a Delete method has been written in the Connected Data Source Extension.

I disabled an AD user – now how do I remove it from groups?

This is one with no short answer.

You cannot manage the memberOf attribute on AD users as it is a backlinked attribute.

So group membership can only be managed through the member attribute of groups.

This is fine if you are already managing AD groups with ILM – but not ok if they are managed manually in AD.

One of the reasons to keep an account in a disabled state for a while is to allow it to be restored quickly with all its previous rights intact – so removing it from groups may not be the best idea anyway.

If it is necessary then the choices are to fully take over group management with ILM, or to write a script that removes disabled users from groups, and is run outside of ILM.

Code Examples

MA Deprovision Sub

In this example, when the Metaverse object is deleted or disconnected, accounts in the “Student” OU are deleted while accounts in the “Staff” OU become disconnectors.

This sub is located in the Management Agent Extension code.

Public Function Deprovision(ByVal csentry As CSEntry) As DeprovisionAction Implements IMASynchronization.Deprovision
   If csentry.DN.ToString.Contains("OU=Students") Then
      Return DeprovisionAction.Delete
   ElseIf csentry.DN.ToString.Contains("OU=Staff") Then
      ' Optionally, rename the cs object or change attributes
      ' just prior to disconnecting
      Return DeprovisionAction.Disconnect
   Else
      Throw New UnexpectedDataException("DN does not contain " _
      & "'OU=Staff' or 'OU=Students' so I don't know " _
      & "which deprovision action to perform.")
   End If
End Function

Metaverse Deprovisioning

In this example we use the user’s status attribute in the Metaverse to decide if the account should be moved to a “Disabled” OU.

(The actual account disabling is done by an EAF and the disableDate and
userAccountControl are flowed back by IAFs – see below.)

We then use the disableDate attribute on the metaverse object to decide when to perform the final deletion.

This example subroutine has been called from Sub Provision which is located in the Metaverse Extension code.

Private Sub User_Provisioning(ByVal mventry As MVEntry)
   Dim ADMA As ConnectedMA = mventry.ConnectedMAs("MyDomain")
   Dim expectedDN As ReferenceValue
   Dim ShouldExist As Boolean
   Dim DoesExist As Boolean
   Const OU_USERS As String = "OU=Users,OU=MyOrg,DC=mydomain,DC=com"
   Const OU_DISABLED As String = "OU=Disabled,OU=Users,OU=MyOrg,DC=mydomain,DC=com"
   Const KEEP_DISABLED_DAYS As Integer = 90

   '' Should the account exist?
   '' Inactive accounts should exist for KEEP_DISABLED_DAYS after being disabled.
   If mventry("status").IsPresent AndAlso mventry("status").StringValue = "Active" Then
      ShouldExist = True
   Else
      ShouldExist = False

      If MVEntry("userAccountControl").IsPresent AndAlso _
         MVEntry("disableDate").IsPresent Then

         If (MVEntry("userAccountControl").IntegerValue And ADS_UF_ACCOUNTDISABLE) = _
             ADS_UF_ACCOUNTDISABLE Then

            'Account disabled – allow to exist until deletion date
            ShouldExist = True

            Dim disabledDate As DateTime
            disabledDate = Convert.ToDateTime(MVEntry("disableDate").StringValue)
            If Now.Subtract(disabledDate).Days > KEEP_DISABLED_DAYS Then
               ShouldExist = False
            End If
         Else
            'Account enabled
            ShouldExist = True
         End If
      End If
   End If
   '' Check if the AD account already exists
   Select Case ADMA.Connectors.Count
      Case 0
         DoesExist = False
      Case 1
         DoesExist = True
      Case Else
         Throw New UnexpectedDataException("Multiple connectors in MA " & ADMA.Name)
   End Select

   '' Generate the expected DN for the user - to use in renaming or moving
   Dim RDN As String = "CN=" & mventry("displayName").StringValue

   If mventry("status").StringValue = "Active" Then
      expectedDN = ADMA.EscapeDNComponent(RDN).Concat(OU_USERS)
   Else
      expectedDN = ADMA.EscapeDNComponent(RDN).Concat(OU_DISABLED)
   End If

   '' Take action based on values of ShouldExist and DoesExist

   If ShouldExist And DoesExist Then
      'Check if account should be renamed or moved
      Dim CSEntry As CSEntry = ADMA.Connectors.ByIndex(0)
      If CSEntry.DN.ToString.ToLower <> expectedDN.ToString.ToLower Then
         CSEntry.DN = expectedDN
      End If

   ElseIf ShouldExist And Not DoesExist Then
      'Provision Account
      <...>

   ElseIf Not ShouldExist And DoesExist Then
      'Deprovision Account
      CSEntry.Deprovision()

   End If
 End Sub

Disabling Flow Rules

With these flow rules I disable an AD account and also write a date onto the object (I’m using info but you can use any free attribute) to indicate when it was disabled.

I also flow userAccountControl and info back into the metaverse so I have access to the values in my
metaverse extension code (above).

Public Sub MapAttributesForExport(ByVal FlowRuleName As String, ByVal mventry As MVEntry, ByVal csentry As CSEntry) Implements IMASynchronization.MapAttributesForExport

   Const ADS_UF_NORMAL_ACCOUNT As Long = &H200
   Const ADS_UF_ACCOUNTDISABLE As Long = &H2

   Select Case FlowRuleName

      Case "export_userAccountControl"
         Dim currentValue As Long

         If csentry("userAccountControl").IsPresent Then
            currentValue = csentry("userAccountControl").IntegerValue
         Else
            currentValue = ADS_UF_NORMAL_ACCOUNT
         End If

         If mventry("status").IsPresent AndAlso mventry("status").Value = "Active" Then
            ' Enable account
            csentry("userAccountControl").IntegerValue = _
            (currentValue Or ADS_UF_NORMAL_ACCOUNT) And (Not ADS_UF_ACCOUNTDISABLE)

         Else
            ' Disable account
            csentry("userAccountControl").IntegerValue = _
            currentValue Or ADS_UF_ACCOUNTDISABLE
         End If

      Case "export_info"
         If mventry("status").IsPresent AndAlso mventry("status").Value = "Active" _
            AndAlso csentry("info").IsPresent Then
            csentry("info").Delete()
         ElseIf mventry("status").Value = "Inactive" AndAlso _
            Not csentry("info").IsPresent Then
            csentry("info").StringValue = Now.ToString
         End If

      End Select
End Sub

XMA Delete Method

For an MA of type “Extensible Connectivity” you need to write your own routines for the export types
Add, Modify and Delete.

This example shows the Delete step for an XMA which manages home folders for user accounts.

The sub is found in the Connected Data Source Extension.

This example is a very simple deletion of the folder, but you could easily add extra code to, for example, move the folder to an archive location.

(If you want to see an example of the Add method see my blog:
Creating Home Directories)

 Public Sub ExportEntry(ByVal modificationType As ModificationType, ByVal changedAttributes As String(), ByVal csentry As CSEntry) Implements IMAExtensibleCallExport.ExportEntry

If modificationType = Microsoft.MetadirectoryServices.ModificationType.Add Then
' Create the folder

ElseIf modificationType = _
Microsoft.MetadirectoryServices.ModificationType.Delete Then
System.IO.Directory.Delete(csentry("path").StringValue, True)
End If

End Sub

About the Author

Carol Wapshere has been working in IT since 1990, and has since worked in many different organizations, across four different countries. She started out in Netware then moved into Microsoft server products, picking up an assortment of skills in other non-Microsoft systems along the way. She first started working with MIIS in 2005 and loved how it could be used to tie together disparate systems, bringing in much-needed order, and making lots of tedious jobs just disappear.

Thanks to Markus Vilcinskas and Peter Geelen for their help with this document.

Warning: I will have to revisit this post – as I haven’t yet installed Exchange 2010 in a production environment the Exchange comments are based on reading rather than hands-on experience, and in particular I’m unsure about the management of email-enabled Security groups.

• The ECP, or Exchange Control Panel, is a web interface where users can perform certain administrative functions such as modifying their own profile and managing Distribution lists they own.
• Users can request to join groups which may include an owner-approval workflow.
• And finally Role Based Access Control simplifies assigning the right level of permissions – so intead of making someone an organization-wide Exchange administrator, you can grant more finely-grained permissions, and it’s based on roles so it should be simpler to apply.

So, in one swoop, a number of the key features of FIM look less relevant: the FIM user portal for self-management, the distribution list management and workflows, and the MPRs which give access to other user’s attributes. Hmmm.

Of course we get a lot more with FIM, and it’s a generalised platform, as opposed to being targeted specifically at Exchange-enabled objects. Also one can make the argument that it’s more secure to make modfications outside of AD and then sync them across in a controlled way, rather than giving people access directly into AD. And finally FIM gives us password reset…

But considering the expected cost of FIM CALs, how many IT decision makers will look at FIM and decide it doesn’t give them enough over what they’re going to be getting anyway with Exchange 2010?

They give permissions, to a Set or referentially

The first thing I understood about MPRs is that they give permissions within the FIM Portal environment. There are various MPRs that come pre-configured to give permissions to the Administrator, the Built-In Sync Account, and Portal users – and a number of them have to be enabled before you can get going.

Permissions may be granted to Sets, where a Set is a group that exists solely within the Portal. You can’t specify a single user here, but I think most people would agree it’s better to grant permissions to groups instead of individial users - even if this means creating a set with a single member.

Permissions may also be granted referentially, where you choose an attribute of the person currently making the request through the Portal, and apply permissions to that. The attribute selected would have to be the Reference data type, such as:

• ResourceID – permission granted to the person to act upon their own profile,
• Manager – permission granted to the person’s manager,
• Assistant – permission granted to the person’s assistant.

The rights change straight away

I really like the way permission changes are applied immediately, and without any need for an iisreset.

And I particulary like the way the View and Edit forms change accordingly – attribute names are removed from the view of users with no rights to them. Unfortunately this is not the case for the Create forms, where the only way you can completely remove a field is by editing the underlying XML. (I asked about this on connect and was told the Create forms will self-modify in a future release.)

Rights are cumulative and there’s no “Deny”

Still on the permissions side of MPRs – you can only give rights, you can’t block them. All permissions are assumed to be not allowed unless explicitly granted.

The lack of Deny is probably a very good thing as we could easily end up with multiple MPRs applying to a user. At least this way we only have to worry about the permissions that have been granted, without the possible complication of over-riding denials.

They also trigger Workflows

As well as applying permissions, MPRs trigger Workflows. Some MPRs just grant permissions, some just trigger workflows, and some do both.

At first I found this hard to understand, because permissions and workflows are completely different things. But after creating a few it’s starting to make more sense. It means that you tailor your MPRs to specific events you expect to happen, such as:

• When the Built-In Sync Account imports a new person object from the Sync Service (with permission to do this) a workflow should run to generate some extra attributes (tack on an Action workflow).
• When a user requests an account for a contractor (with permission) seek approval from their manager, and then generate some extra attributes (tack on an AuthZ and an Action workflow).

MPRs can also trigger workflows because a value changed. In some MPRs this can be any change; in others the change causes the object to move from one Set to another. So perhaps the Department changed, causing the person to move from the “All People in HR” set to the “All People NOT in HR” set. (When you create a Set for MPRs, you usually have to create the opposite Set as well.)

I worry about keeping track of them

You can call an MPR whatever you like, which of course means you are free to be as tidy or as messy as you like. As I’m yet to play with FIM in anything other that a test environment I have no idea what it will look like with a couple of hundred MPRs defined. Clear naming for searchability and ongoing management will be important.

What I would really like is a utility that shows you all the MPRs that apply to an object – something like this will be invaluable in troubleshooting, especially if it wasn’t you that built the system. Perhaps someone far cleverer than me will write something along these lines.

… UPDATE: and it looks like someone has already done exactly that and I hadn’t noticed! One of Jorge’s very informative posts today has pointed out the new Explore option which should help with this. I’ll have to have a play next time my lab is fired up.

So while I’m doing and thinking all things FIM I’ve decided to start a little “Five things about” blog series on different aspects of the new platform. To start – some generalities about the FIM Portal (aka All The New Sharepointy Stuff).

1. It’s a framework

I have always told people that ILM is a framework, instead of a complete OOB solution. And then, before their eyes completely glazed over, I have attempted to impress on them that this is a Good Thing! IdM is an inherently complex problem, with every organisation having their own perculiarities, and I firmly believe that workable IdM must be grown into the environment, preferably in a standards-based, manageable way.

ILM always ticked these boxes for me and now, with FIM, Microsoft have extended the notion to the Portal. Essentially we have a new framework for defining the schema, workflows, permissions and data-entry points. RC1 comes with a schema and a starter collection of policies, sets and workflows – but you are free to view these as suggestions which you may change or build upon.

2. Sequential processing

Those of us who work with ILM have come to think in its “steady-state” way, where all we care about is the state of the data right now. The Portal operates in a sequential way, and I had to get used to it.

I was following Jorge’s method to get around the lack of an “IsPresent” qualifier when I realised I didn’t actually need it. We had made a very simple form to request a user account through the web services and I wanted to use a workflow to generate system-type attributes such as Account Name, Display Name and Employee ID. My immediate thought was to make a set of “Account Name not present” but that’s an ILM way of thinking – ie just look at the data now.

The FIM Portal way is to think about where the data came from. In this case it was the account I’d created for the web service. I modified the MPR that gave rights to the service account, and now it also runs the Workflow that generates the attributes. Obvious in retrospect, but it did make me realise I had to adopt a more sequential way of thinking for the Portal.

3. The WS-* thing really is a big deal

I’ve heard a lot about the web services interface to the Portal but, not being a developer, I’d filed it under “find out more later”. But now I’ve had the chance to work with a developer colleague for a couple of days and have seen how excited he is about the possibilities.

With RC1 he did have some tedious mucking about with library versions first (something about an x64/x32 conflict – don’t ask me more), but once that was sorted he showed me how simple the code is.

I started to think about how important it is that we’re not being tied to the Portal interface to use it. Many organisations will already have existing portals where people are accustomed to find data and make requests – this way those interfaces can be modified to access the Portal at the back-end, and users don’t need to worry about learning something different.

4. It is distinct from the sync service, and that is fine

I have been told that I should consider the metaverse and the data in the Portal as the same thing – but they’re not, and actually I don’t see that as a problem. The Sync Service is a distinct unit and, for it, the FIM Portal is just another connected data source. I am very comfortable with the idea of preparing my data in the Portal and then, when it is ready, sync’ing it through the Sync Service.

This has also led me to the decision that I won’t be using the Portal-based Sync Rules, at least for the first release. I do have concerns about performance and troubleshooting which have not been allayed but what I see in RC1 but, more fundamentally than that, I want to keep the configuration of the Sync Service within the Sync Service.

Partly it is to do with seperating the part of the product that is mature and stable, from the part of the product that is completely new. Many people I talk to are interested, but concerned about adopting a “version one” product. I am hoping that the product being only ”half new” will seem like an acceptable risk. I need to be able to guarantee that the half which isn’t new will perform without problems.

5. All Resources are treated in similar ways

Resources are just objects that exist within the Portal. These are users and groups, but also the things that make up the functionality of the Portal – like Workflow Activities, and Requests, and MPRs.

Because they’re all just Resources, the methods for interacting with them are repeatable. So when I wanted to give the Administrator account access to add a new workflow activity, I followed exactly the same process as giving a user the permission to create a group. If I want to change a form, or add a new attribute, it will be the same process for any resource type. This reapplication of methods should certainly make the Portal easier to learn!

http://social.technet.microsoft.com/Forums/en-US/identitylifecyclemanager/thread/f8ad045d-7252-4cd1-a189-d704a8f99129

The article covers various management tasks you can acheive with the standard AD MA, including provisioning and updating of users, mailboxes, contacts and distribution groups. There are quite a few code samples as well.

Managing Exchange 2000/2003/2007 with ILM 2007

This article covers the management of Exchange-enabled objects using the native Active Directory Management Agent that is included with ILM 2007 FP1.

The managed object types discussed are Users, Contacts, Groups and Dynamic Distribution Lists. The article also covers the special cases of adding mailboxes to existing accounts, and supporting a Resource Forest. Where extra steps are required for Exchange 2007 this has been highlighted.

It is assumed that the reader is comfortable with the concepts of Provisioning code and Advanced attribute flow rules.

Permissions

The service account used in the connection properties of the Management Agent must have sufficient rights to execute the required changes in AD.

Typically a Domain Admin account will be used, but if this is not permitted in your environment you will need to do some testing. The minimum permissions required are:

• Replicate Directory Changes
• Rights to create/delete/modify objects in the specific OUs
• Exchange Administrator (2003) or Exchange Recipient Administrator (2007)

Users

Provisioning Mail Users

Exchange 2000/2003

Provisioning a mail user is most simply done using the CreateMailbox method of the ExchangeUtils class. This method will create a new user account, and populate the necessary mail attributes for you.

See the code sample Create a User with a Mailbox at the end of this document for an example of the provisioning code.

Mixed Exchange 2003 and 2007

In a mixed environment the RUS still runs so Exchange 2003 methods may be used. Make sure that you do not tick the “Enable Exchange 2007 provisioning” box in the Management Agent configuration.

Exchange 2007

The same code will work when provisioning to Exchange 2007, however there are some extra requirements for the ILM server:

• ILM 2007 FP1 or later
• Powershell
• Exchange 2007 Management Tools
• Latest rollup packs on Exchange and ILM servers

In addition you must tick Enable Exchange 2007 provisioning on the Extensions tab of the Management Agent.

Adding a Mailbox to an existing User

Sometimes you may need to create a mailbox for an existing account. As the account already exists this is not actually a provisioning task, and is therefore handled with export flow rules.

All you need to do is to populate the following attributes, in addition to the basic user attributes:

• displayName – if not already set
• mailNickname – with the local part of the email address (the bit before the “@”)
• homeMDB – with the DN of the mail store
• mDBUseDefaults – set to “True” to use the default quota settings

Special Mailbox Types

Exchange 2007 includes some extra mailbox types:

• Room Mailbox,
• Equipment Mailbox,
• Linked Mailbox.

The Linked Mailbox is covered in the Resource Forest section below.

The Room and Equipment mailboxes are currently not supported by ILM 2007 provisioning. The only reliable method is to create a User Mailbox using ILM 2007, and then use the set-mailbox cmdlet to change the mailbox type.

Troubleshooting

Export Errors

The most common problems with provisioning Exchange users will relate to permissions. Make sure that the account used by the MA to connect to AD has permission to create Exchange users. Also make sure you have the latest service packs and rollups on the Exchange and ILM servers – at least SP1 RU9.

Where’s the Mailbox?

Exchange does not create the actual mailbox until it is opened or something is sent to it, therefore it is completely normal for no new mailboxes to be listed directly after the ILM export.

To confirm if the user is really mail-enabled:

• In Exchange 2003, check that the user’s Exchange tabs have appeared in the Exchange-enhanced version of AD Users & Computers.
• In Exchange 2007, use the get-user cmdlet to confirm the user’s object type is “UserMailbox”, or check that they appear as a Recipient in the Management Console.

Exchange 2007 and Global Catalog targeting

There is a known problem with Exchange 2007 provisioning and AD replication delays. On the MA’s Configure Directory Partitions tab you can hard-code the name of a preferred domain controller. Enter the name of the nearest Global Catalog to ensure that both the user creation and the mailbox creation are performed in the same place.

Note
Use the Resource Kit utility nltest to find Global Catalog servers: nltest /DSGETDC:mydomain.com /GC

Modifying Mail Users

You can change a user’s Exchange related attributes using export flow rules.

The following table is not exhaustive. If you wish to automate an Exchange modification the best thing to do is make the change manually and then inspect the attribute changes using ADSIEdit.
In this way you can discover which attributes you need to create flow rules for, and the types of value you should flow.

Resource Forest

In a Resource Forest scenario the following accounts are needed:

1. An enabled user account in the Account Forest.
2. A disabled account in the Resource Forest with an attached mailbox.

The account creation in the two forests and the mailbox linking are simple enough to achieve with ILM. A provisioning code sample has been included at the end of this document under Create Account Forest and Resource Forest Accounts.

The difficulty comes with the permissions assignment piece of the puzzle – it is necessary for the user’s account to have the Full Access and Send As rights to the mailbox. This is not something that is possible with the native Active Directory MA.

While there are several ways to solve the permissions-assignment problem, the typical way is to run a script after the export step. The script might simply trawl AD looking for accounts to update or it could read details from the ILM export log and target the new accounts.

While outside the scope of this document, the following resources have been included for reference:

1. A Microsoft technote showing how to Script Exchange 2000/2003 mailbox permissions,
2. A PowerShell script for Exchange 2007 has been included in the Code section at the end of this article.

Contacts

Contacts are used for two primary functions in Exchange, both of which can be automated with ILM:

1. Adding organization-wide contacts to the Global Address List.
   ILM could be used to import information from a CRM system and automatically create the contact object.
2. As a way to forward mail from a mailbox within the organization.
   Some organizations (such as universities) allow users to forward their mail to another address. As long as ILM has the information about the forwarding request (perhaps entered by the user in a self-service portal) it can be configured to create the contact and set up the forwarding.

Provisioning

Contacts may be provisioned very simply using the CreateMailEnabledContact method from the ExchangeUtils class.
See the code sample Create a Contact at the end of this document for an example of the provisioning code.

Modifying

Distribution List

There are three types of Distribution list in Exchange:

1. Groups of type Distribution
2. Groups of type Security that have an email address
3. Dynamic distribution lists.

All three types can be created and managed with ILM, but the processes will differ.

Distribution Groups

To provision a standard Distribution Group use the CreateDistributionList method of the ExchangeUtils class. See Create a Distribution List at the end of this document for a code sample.

The main modification you will do with groups is to update the membership list. Group population is outside the scope of this document, though it is worth looking into Group Populator and Multi-Value tables.

Security Groups with Email Address

It is possible to mail-enable a Security group, allowing it to then also act as a distribution list.

Provisioning such a group is a simple matter of creating a security group and adding the mail address. See Create a Mail-Enabled Security Group under Code Samples at the end of this document.

Dynamic Distribution Lists

You may also use ILM to provision Dynamic Distribution Lists. All you need to do is to create an object of type msExchDynamicDistributionList and add values to the following attributes:

• displayName
• mailNickname
• msExchDynamicDLFilter
• msExchDynamicDLBaseDN

See Create a Dynamic Distribution List under Code Samples at the end of this document.

Code Samples

Create a User with a Mailbox

This MVExtension code is in addition to export flow rules to the user object type on the following attributes:

• displayName
• givenName
• sAMAccountName
• sn
• userPrincipalName

Public Sub Provision(ByVal mventry As MVEntry) Implements IMVSynchronization.Provision

  Const ADS_UF_NORMAL_ACCOUNT As Integer = &H200

  Dim csentry As CSEntry

  Dim MA As ConnectedMA

  Dim dn As ReferenceValue

  Dim rdn As String

  Dim homeMDB As String

  Dim mailNickname As String

  Dim mail As String

  Select Case mventry.ObjectType

  Case "person"

    MA = mventry.ConnectedMAs("MYDOMAIN")

    If <test that account should exist> AndAlso MA.Connectors.Count = 0 Then

      rdn = "CN=" & mventry("sn").Value & ", " & mventry("givenName").Value

      dn = MA.EscapeDNComponent(rdn).Concat("OU=Users,OU=MyOrg, " _

                                            & "dc=mydomain,dc=local")

      mailNickname = mventry("mailNickname").Value

      ' The following line assumes MDB, SG and MailServer have been

      ' populated for the user in the Metaverse.

      homeMDB = "CN=& mventry("MDB").StringValue _

         & ",CN=" & mventry("SG").StringValue _

         & ",CN=InformationStore,CN=" & mventry("MailServer").StringValue _

         & ",CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT)" _

         & ",CN=Administrative Groups,CN=First Organization" _

         & ",CN=Microsoft Exchange,CN=Services,CN=Configuration" _

         & ",DC=mydomain,DC=local"  

      csentry = ExchangeUtils.CreateMailbox(MA, dn, mailNickname, homeMDB)

      csentry.DN = dn

      csentry("unicodePwd").Values.Add("FirstP@ssw0rd")

      csentry("userAccountControl").IntegerValue = ADS_UF_NORMAL_ACCOUNT

      csentry.CommitNewConnector()

    End If

  End Select

End Sub

Create Account Forest Accounts and Resource Forest Accounts

Public Sub Provision(ByVal mventry As MVEntry) Implements IMVSynchronization.Provision

  Const ADS_UF_NORMAL_ACCOUNT As Integer = &H200

  Dim csentry As CSEntry

  Dim MA As ConnectedMA

  Dim dn As ReferenceValue

  Dim rdn As String

  Dim homeMDB As String

  Dim mailNickname As String

  Dim mail As String

  Select Case mventry.ObjectType

  Case "person"

    'Create Account Forest account - no mailbox

    MA = mventry.ConnectedMAs("AccountForest")

    If MA.Connectors.Count = 0 Then

      rdn = "CN=" & mventry("sn").StringValue _

                  & ", " & mventry("givenName").StringValue

      dn = MA.EscapeDNComponent(rdn).Concat("OU=Users,OU=MyOrg, " _

                                            & "dc=accountdomain,dc=local")

      csentry = MA.Connectors.StartNewConnector("user")

      csentry.DN = dn

      csentry("unicodePwd").Values.Add("FirstP@ssw0rd")

      csentry("userAccountControl").IntegerValue = ADS_UF_NORMAL_ACCOUNT

      csentry.CommitNewConnector()

    End If

    'Create disabled account and mailbox in Resource forest. 

    '  This can only be done once the objectSID from the account domain 

    '  is available. Create a metaverse Binary attribute called SID

    '  and flow objectSid -> SID.

    '  The account is disabled because no password is set. Alternatively set

    '  a random password and disable using userAccountControl.

    MA = mventry.ConnectedMAs("ResourceForest")

    If MA.Connectors.Count = 0 AndAlso mventry("SID").IsPresent Then

      rdn = "CN=" & mventry("displayName").StringValue

      dn = MA.EscapeDNComponent(rdn).Concat("OU=LinkedMailboxes,OU=MyOrg, " _

                                            & "dc=resourcedomain,dc=local")

      mailNickname = mventry("mailNickname").StringValue

      homeMDB = "CN=" & mventry("MDB").StringValue _

         & ",CN=" & mventry("SG").StringValue _

         & ",CN=InformationStore,CN=" & mventry("MailServer").StringValue _

         & ",CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT)" _

         & ",CN=Administrative Groups,CN=First Organization" _

         & ",CN=Microsoft Exchange,CN=Services,CN=Configuration" _

         & ",DC=mydomain,DC=local"  

      csentry = ExchangeUtils.CreateMailbox(MA, dn, mailNickname, homeMDB)

      csentry.DN = dn

      csentry("msExchMasterAccountSid").BinaryValue = mventry("SID").BinaryValue

      'The following setting is optional but can help with tracking the mailbox user.

       csentry("extensionAttribute1").Value = "accountdomain\" _

                                              & mventry("uid").StringValue

       csentry.CommitNewConnector()

     End If

  End Select

End Sub

Assign Resource Mailbox Permissions – Exchange 2007, powershell

The following script assigns the FullAccess and SendAs permissions to a resource forest mailbox.
The resource forest account needs to have the domain\username of the user’s actual account written to extensionAttribute1, as per the provisioning code above.

$Filter = "(&(ObjectCategory=user)(extensionAttribute1=*))"

$Searcher = New-Object System.DirectoryServices.DirectorySearcher($Filter)

$Searcher.Findall() | Foreach-Object -Process {

$alias = [string]$_.properties.item("mailNickname")

$user = [string]$_.properties.item("extensionAttribute1")

Add-MailboxPermission -Identity $alias -AccessRights FullAccess, SendAs -User $user

}

Create a Contact

Public Sub Provision(ByVal mventry As MVEntry) Implements IMVSynchronization.Provision

  Dim csentry As CSEntry

  Dim MA As ConnectedMA

  Dim dn As ReferenceValue

  Dim rdn As String

  Dim mailNickname As String

  Dim mail As String

  Select Case mventry.ObjectType

  Case "person"

     MA = mventry.ConnectedMAs("MYDOMAIN")

     If MA.Connectors.Count = 0 Then

       rdn = "CN=" & mventry("displayName").StringValue

       dn = MA.EscapeDNComponent(rdn).Concat("OU=Contacts,OU=MyOrg, " _

                                            & "dc=mydomain,dc=local")

       mail = mventry("mail").StringValue

       'The mailNickname is only for internal Exchange purposes.

       'You could just as easily use an id number from the source data.

       mailNickname = mventry("mail").Value.Split("@")(0)

       csentry = ExchangeUtils.CreateMailEnabledContact(MA, dn, mailNickname, mail)

       csentry.DN = dn

       csentry.CommitNewConnector()

    End If

  End Select

End Sub

Create a Distribution List

Public Sub Provision(ByVal mventry As MVEntry) Implements IMVSynchronization.Provision

  Dim csentry As CSEntry

  Dim MA As ConnectedMA

  Dim dn As ReferenceValue

  Dim rdn As String

  Dim mailNickname As String

  Dim mail As String

  Select Case mventry.ObjectType

  Case "group"

    MA = mventry.ConnectedMAs("MYDOMAIN")

    If MA.Connectors.Count = 0 Then

      rdn = "CN=" & mventry("cn").StringValue

      dn = MA.EscapeDNComponent(rdn).Concat("OU=Groups,OU=MyOrg, " _

                                            &"dc=mydomain,dc=local")

      mailNickname = mventry("mailNickname").StringValue

      csentry = ExchangeUtils.CreateDistributionlist(MA, dn, mailNickname)

      csentry.DN = dn

      csentry.CommitNewConnector()

    End If

  End Select

End Sub

Create a Mail-Enabled Security Group

Public Sub Provision(ByVal mventry As MVEntry) Implements IMVSynchronization.Provision

  Dim csentry As CSEntry

  Dim MA As ConnectedMA

  Dim dn As ReferenceValue

  Dim rdn As String

  Dim mailNickname As String

  Dim mail As String

  Select Case mventry.ObjectType

  Case "group"

    MA = mventry.ConnectedMAs("MYDOMAIN")

    If MA.Connectors.Count = 0 Then

      rdn = "CN=" & mventry("cn").StringValue

      dn = MA.EscapeDNComponent(rdn).Concat("OU=Groups,OU=MyOrg, " _

                                            & "dc=mydomain,dc=local")

      mailNickname = mventry("mailNickname").StringValue

      csentry = MA.Connectors.StartNewConnector("group")

      csentry("groupType").Value = -2147483640  'Universal Security

      csentry("displayName").Value = mventry("cn").StringValue

      csentry("mailNickname").Value = mailNickname

      csentry.DN = dn

      csentry.CommitNewConnector()

    End If

  End Select

End Sub

Create a Dynamic Distribution List

This MVExtension code snippet creates Department DDLs.
The department names have been imported into department objects in the Metaverse.
The users’ department attribute matches exactly the department names.

Public Sub Provision(ByVal mventry As MVEntry) Implements IMVSynchronization.Provision

  Dim csentry As CSEntry

  Dim MA As ConnectedMA

  Dim dn As ReferenceValue

  Dim rdn As String

  Dim mailNickname As String

  Dim mail As String

  Select Case mventry.ObjectType

  Case "department"

    MA = mventry.ConnectedMAs("MYDOMAIN")

    If MA.Connectors.Count = 0 Then

      rdn = "CN=" & mventry("cn").StringValue

      dn = MA.EscapeDNComponent(rdn).Concat("OU=DDLs,OU=MyOrg, " _

                                            & "dc=mydomain,dc=local")

      mailNickname = mventry("mailNickname").StringValue

      csentry = MA.Connectors.StartNewConnector("msExchDynamicDistributionList")

      csentry.DN = dn

      csentry("displayName").Value = mventry("cn").StringValue

      csentry("mailNickname").Value = mailNickname

      'The following filter selects users whose department equals the DDL cn

      csentry("msExchDynamicDLFilter").Value = "(&(!cn=SystemMailbox{*})" _

         & "(&(&(&(& (mailnickname=*)" _ 

         & "(| (&(objectCategory=person)(objectClass=user)" _

         & "(|(homeMDB=*)(msExchHomeServerName=*))) )))" _

         & "(objectCategory=user)(department=" _

         & mventry("cn").StringValue & "))))"

      csentry("msExchDynamicDLBaseDN").Value = "OU=Groups,OU=MyOrg, " _

                                            & "dc=mydomain,dc=local"

      csentry.CommitNewConnector()

    End If

  End Select

End Sub

ILM Forum Threads

• Provisioning Exchange 2007 with ILM 2007
• ILM With FP1 and Exchange 2007
• Exchange 2007 ‘Shared’ Mailbox Provisioning with ExchangeUtils
• Attribute List for Exchnage 2003

About the Author

Carol Wapshere has been working in IT since 1990, and has since worked in many different organizations, across four different countries. She started out in Netware then moved into Microsoft server products, picking up an assortment of skills in other non-Microsoft systems along the way. She first started working with MIIS in 2005 and loved how it could be used to tie together disparate systems, bringing in much-needed order, and making lots of tedious jobs just disappear.

Thanks to Markus Vilcinskas and Peter Geelan for their help with this document.

http://www.wapshere.com/missmiis

I’ve had some problems with setting up SCR on earlier rollup packs (ru5 and earlier). On one server I could only do manual reseeds, and I had some problems with ipv6, OA and SCR. But that was then – this week, using SP1RU9 and SP2, SCR has manifestly done what it’s supposed to.

The setup was as follows:

• Two identically spec’d servers with Mailbox, Hub and CAS roles
• Eight storage groups of between 500MB and 25GB in size.

Configuring SCR

I configured SCR following the technet docs.  But in brief I:

1. Created Data and Log folders on the target server that matched the source server.
2. Used the Enable-StorageGroupCopy cmdlet to get things started:
   • Enable-StorageGroupCopy -identity StorageGroup -ReplayLagTime 0 -StandbyMachine TargetServer
3. Ran the Update-StorargeGroupCopy cmdlet on the target server to seed the replication:
   • Update-StorageGroupCopy -Identity SourceServer\StorageGroup -StandbyMachine TargetServer
4. Created standby storage groups and mail databases on the target server, according to the advice in the technet articles. These have different Data and Log folder to the copy locations, but are waiting and ready to have their paths changed at the moment of urgency. It really does make the failover procedure much quicker!
5. Monitored the status of SCR with the Get-StorageGroupCopyStatus cmdlet:
   • Get-StorageGroupCopyStatus -StandbyMachine TargetServer

Failing Over

I failed over the databases using the process I outlined in this post. This is where SCR really came into its own. The failover process took about 10 minutes per database (and you can do several in parallel). The longest part was actually the final step which reassigns users to their new MDB.

The best thing of all was we had NO DATA LOSS! I admit to some confusion over the whole “inbuilt 50 log limit” thing – but now I see that this is only a roll-in limit – the logs are replicated immediately, and the eseutil command, which you run as part of the failover process, rolls them in. The only way you can lose data with SCR is if the source server crashes before, or during, replicating the absolutely most recent logs. Data loss, if any, will therefore be very small.

Syncing Back

We plan to fail back but we haven’t done it yet. Everything is running on the DRP server and we’re going to let the dust settle a bit before we move back to the (now rebuilt) original server. In my earlier SCR post I outlined a manual database copy back to the source server, which involved downtime.  But actually I’m trying something different now it’s really happening.

Basically I have set the original server as my new SCR target. To do this I did not recreate the Storage Groups and Mail Databases on the original server – I just made sure the same Data and Logs folders were available.

When the time comes to do the full failover I will essentially execute the failover procedure in the opposite direction. I will post again with the exact steps when its done.

Other things to think of

If you want your DRP server to also take over Hub, CAS and Public Folder roles, then there is more than just SCR to think about.

CAS Role

It is good planning to assign a CName to your OWA and ActiveSync URL. Just make sure that all your possible CAS servers include this CName in their certificate: http://technet.microsoft.com/en-us/library/aa995942.aspx

Also be aware of something I had forgotten – Outlook can only redirect a user to their new server if the old server is responding. This is a total sh*t if your old server is dead and gone. I read somewhere that it may work to assign the old server name to the new server as a CName, but you may not be able to do that if you are still trying to resurrect the old one. We got by with OWA and the hard-pressed Helpdesk having to talk a lot of people through changing their Outlook profile. If you really want to be prepared then write a script now that can change the server in outlook profile (googling shows various options – none of which I’ve tried as yet – though one of my collegues says MAINTWIZ can help).

Hub Role

Make sure all Send and Receive connectors are replicated somewhere. Use costs on Send connectors to favour your usual production route.

Also, if you have scripts or applications sending email via the Exchange server, make sure a CName is used which you can rapidly change in DNS.

Public Folders

Make sure all your Public Folders, FREE BUSY and OAB folders have more than one replica server.

I had some weird experiences with trying to add the DRP server as an extra replica to top-level folders. Then I found this post and after that I gave up. It did mean that, after the failover, I had to manually add the DRP server as a replica to the top-level folders.

 I also had other bizarre public folder errors which involved:

• Manually changing the Default public folder database on the Mail Databases on the DRP server (see the Client Settings tab on the properties of the Mail Database in Exchange Management Console),
• Manually changing the siteFolderServer property on the Administrative Group objects in AD,
• Manually changing the siteFolderServer and offLineABServer on the Default Offline Address Book object in AD.

In summary…

The SCR part of the failover was the easiest part of the whole week – we had more trouble with incorrect public folder settings, missing Send connectors, and a fussy backup client that didn’t want to install on the DRP server.

The biggest problem with SCR is that there is no straight-forward “fail back” procedure. As I’ve said before, SCR is not a cluster, but rather a one-way replication to a standby server. However I think it is proving itself to be a great technology, and it’s no wonder that Exchange 2010 is building on the SCR model with Database Availability Groups. I’m looking forward to them! (Despite the dodgy anagram, which you have to be Australian to appreciate. You dag.)