Forefront / Microsoft Identity Manager contains numerous Management Agents (MA’s) out of the box. However, a MA for Lync / Skype for Business isn’t one of them.
Over the years I’ve accomplished lifecycle management for users in Lync via FIM using methods that aren’t strictly best practice / supported (e.g. calling PowerShell from within a Management Agent Extension to enable/disable/manage policies). Whilst this functionally works the ability for end customers to maintain the implementation for changes is limited.
In this blog post I’ll document how you can enable an Active Directory User for Lync / Skype for Business utilising Søren Granfeldt’s extremely versatile PowerShell Management Agent. I’ll show you how to do the minimum of enabling a user. Understanding how this is done you can then easily then extend the functionality for lifecycle management (e.g. change mobility, federation, voice policies for users based on managed attributes, and de-provisioning).
My Lync / Skype for Business PS 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\Lync
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, the schema only consists of the attributes needed to know the state of the user with respect to enablement and the attributes needed to enable an account.
Password Script (password.ps1)
Just a placeholder file as detailed above.
Import Script (import.ps1)
I’m using msDS-cloudExtensionAttribute20 as a breadcrumb attribute. I’m not exporting anything else on the Lync MA but we need to export something to trigger the Export script. It exists in the Import script as well for the confirming import.
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)
In the working example below I’ve hard-coded the RegistrarPool into the Export Script. If your environment contains more than one RP then you could have the desired pool as a flow rule on your AD MA that creates AD users on so you can make it an initial flow attribue.
A key item is I’m also using Remote PowerShell for Lync. That way I don’t need to have the PS Module for Lync on the MIM server itself.
Wiring it all together
In order to wire the functionality 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 attribute, create the Set used for the transition, create your Synchronisation Rule, create your Lync Workflow, create your Lync 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 flows are a combination of logic used for other parts of my solution, and a Boolean flag to determine if the user in enabled for Lync or not (used for my Transition Set and my Export script).
My Lync Outbound Sync rule doesn’t need to be very complex. All it is doing is sync’ing out my breadcrumb attribute. I’m flowing out the objectGUID out to ms-dsCloudExtensionAttribute20.
I created a Set that I use as a transition to trigger provisioning to Lync. My Set looks to see if the user account is active and in AD (I have a Boolean attribute 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),
An action based workflow that will use the trigger the Synchronisation rule on the Lync MA.
The Transition Set MPR.
And the Policy Workflow created above.
Using the Granfeldt Powershell MA it is easy to enable users for Lync.
Follow Darren on Twitter @darrenjrobinson