Forefront / Microsoft Identity Manager contains numerous Management Agents (MA’s) out of the box. However an MA for creating user home directories and setting the associated permissions isn’t one of them.

Over the years I’ve accomplished home directory provisioning and permissioning in Active Directory / Windows File Services and Novell eDirectory / Novell File Services using methods that aren’t strictly best practice / supported (e.g. calling native libraries from within a Management Agent Extension to create/manage/delete etc). Whilst this functionally works the ability for end customers to maintain the implementation for changes is limited.

Overview

In this blog post I’ll document how you can enable an Active Directory users with a home directory with the required permissions and update their associated AD object with the home directory path and drive letter utilising Søren Granfeldt’s extremely versatile PowerShell Management Agent. I’ll show you how to do the minimum of provisioning a home directory to a user. Understanding how this is done you can then easily then extend the functionality for lifecycle management (e.g. change location of home directory, add sub-directories, delete for de-provisioning). I didn’t start from scratch on this one as Kent Nordström had most of what I needed as detailed here. I stripped it back to do what I wanted with a few other subtle changes.

My Home Directory MA is used in conjunction with an Active Directory MA and Declarative Rules in the MIM Portal.

Getting Started with the Granfeldt PowerShell Management Agent

First up, you can get it from here. Søren’s documentation is pretty good but does assume you have a working knowledge of FIM/MIM and this blog post is no different. Configuration tasks like adding additional attributes the User Object Class in the MIM Portal, updating MPR’s, flow rules, Workflows, Sets etc are assumed knowledge and if not is easily Bing’able for you to work it out.

Three items I had to work out that I’ll save you the pain of are;

• You must have a Password.ps1 file. Even though we’re not doing password management on this MA, the PS MA requires a file for this field. The .ps1 doesn’t need to have any logic/script inside it. It just needs to be present
• The credentials you give the MA to run the scripts as, needs to be in the format of just ‘accountname’ NOT ‘domain\accountname’. I’m using the service account that I’ve used for the Active Directory MA. The target system is the same directory service and the account has the permissions required (you’ll need to add the service account to the appropriate Lync role group for user management)
  
• The path to the scripts in the PS MA Config must not contain spaces and be in old-skool 8.3 format. I’ve chosen to store my scripts in an appropriately named subdirectory under the MIM Extensions directory. Tip: from a command shell use “dir /x” to get the 8.3 directory format name. Mine looks like C:\PROGRA~1\MICROS~4\2010\SYNCHR~1\EXTENS~2\HomeDir
  

Schema Script (schema.ps1)

As I’m using the OOTB (out of the box) Active Directory MA to provision the AD account and only showing provisioning of home directories. As such the schema only consists of the attributes needed to create the home directory and update the user object in AD.

Password Script (password.ps1)

Just a placeholder file as detailed above.

Import Script (import.ps1)

Nothing to complex. Bringing back in the two attributes that we export to allow the confirming import to complete.
On the $request line you’ll see I have a filter for the User Object Class and users with an account name starting with ‘U’. For the customer I wrote this for, all users start with U. You can obviously also have Filters on the MA. I have a few there as well, but limiting the size of the returned array makes things quicker to run full imports.

Export Script (export.ps1)

The export script is doing a couple of functions. It is creating the home directory, setting the necessary permissions on the home directory for the user and then updating the AD object with the home directory path and the home directory drive letter.

Wiring it all together

In order to wire the functionality all together there are the usual number of configuration steps to be completed. Below I’ve shown a number of the key points associated with making it all work.

Basically create the PS MA, import attributes from the PS MA, add any additional attributes to the Portal Schema, update the Portal Filter to allow Administrators to use the attribute, update the Synchronisation MPR to allow the Sync Engine to flow in the new attributes, create the Set used for the transition, create your Synchronisation Rule, create your Home Director Workflow, create your Home Directory MPR, create your MA Run Profiles and let it loose.

Management Agent Configuration

As per the tips above, the format for the script paths must be without spaces etc. I’m using 8.3 format and I’m using the same service account as my AD MA.

Password script must be specified but as we’re not doing password management its empty as detailed above.

If your schema.ps1 file is formatted correctly you can select your attributes.

My join rule is simple. AccountName (which as you’ll see in the Import.ps1 is aligned with sAMAccountName) to AccountName in the MetaVerse.

My import flow is just bringing back in the DN to a custom MV attribute.

Synchronisation Rules

My Home Directory Outbound Sync rule doesn’t need to be very complex. All it is doing is sync’ing out the Home Directory Drive Letter and Home Directory Path attributes.

Set

I created a Set that I use as a transition to trigger provisioning to the Home Directory. My Set looks to see if the user account is in AD and active (I have a Boolean attribute not shown and another rule in the MIM Portal that is set based on an advanced flow rule in the Sync engine that has some logic to determine if employment date as sourced from my HR Management Agent is current and the user should be active) and that the Home Folder Path is not already set.

Workflow

An action based workflow that will use the trigger the Synchronisation rule on the Home Directory MA.

MPR

Finally my MPR for provisioning Home Directories is based on the transition set,

and my Home Directory Workflow.

Summary

Using the Granfeldt PowerShell MA it was very easy to provision home directories to new users and permission them correctly. It is also easy to extend the solution to manage moving home directories to different locations, deletion etc.

Follow Darren on Twitter @darrenjrobinson