In August 2016 I wrote this post on how to use PowerShell to leverage the Microsoft GraphAPI and use Differential Queries. The premise behind that post was I required a Microsoft Identity Manager Management Agent to synchronize identity information from AzureAD into Microsoft Identity Manager. However the environment it was intended for has a large AzureAD implementation and performing a Full Sync every-time is just to time consuming. Even more so with this limitation that still exists today in MIM 2016 with SP1.
In this blog post I’ll detail how to implement a PowerShell Management Agent for FIM/MIM to use the MS GraphAPI to synchronize objects into FIM/MIM, supporting Delta and Full Synchronization run profiles. I’m also using my favourite PowerShell Management Agent, the Granfeldt PowerShell Management Agent.
I’m using the ADAL helper library from the AzureADPreview PowerShell Module. Install that module on you MIM Sync Server via PowerShell (WMF5 or later) using the PowerShell command;
Install-Module AzureADPreview
If you don’t already have it, what are you waiting for. Go 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.
Three items I had to work out that I’ll save you the pain of are;
My Schema is based around enumerating and managing users from AzureAD. You’ll need to create a number of corresponding attributes in the Metaverse Schema on the Person ObjectType to flow the attributes into. Use the Schema info below for a base set of attributes that will get you started. You can add more as required. I’ve prefixed most of them with AAD for my implementation.
If you want to manage Groups or Contacts or a combination of object types, you will need to update the Schema.ps1 script accordingly.
The logic that the Import.ps1 implements is the same as detailed here in my post using Differential Queries. Essentially, perform a full import and create a file with the cookie/watermark. Allow Delta Sync run profiles to be performed by requesting the GraphAPI to return only changes since the cookie/watermark.
You’ll need to update the script for your AzureAD Tenant name on Line 28. Also the path to where the cookie file will go and the debug file if your path is different to mine. Lines 11, 46 and 47.
Importing of the attributes is based around the names in the Schema.ps1 scripts. Any changes you made there will need to be reflected in the import.ps1.
Empty as not implemented
Empty as not implemented in this example. If you are going to write information back to AzureAD you’ll need to put the appropriate logic into this script.
With the Granfeldt PowerShell Management Agent installed on your FIM/MIM Synchronisation Server, in the Synchronisation Server Manager select Create Management Agent and choose “PowerShell” from the list of Management Agents to create.
As this example is for Users, I’ve named my MA accordingly.
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 an Office 365 account to connect to AzureAD/Office365 and import the user data.
Paths to the Import, Export and Password scripts. Note: the Export and Password PS1 scripts files exist but are empty.
Object Type as configured in the Schema.ps1 file.
Attributes as configured in the Schema.ps1 file.
Anchor as per the Schema.ps1 file.
The rest of the MA configuration is up to your implementation. What you are going to join on and what attributes flow into the MV will vary based on your needs and solution. At a minimum you’d probably be looking to do a join on immutableID (after some manipulation) or UPN and flow in attributes such as AADAccountEnabled etc.
To finalise the MA you’ll need to do the usual tasks of creating run profiles, staging the connector space from AzureAD/Office365 and syncing into the Metaverse. Once you’ve done your initial Stage/Full Sync you can perform Delta Sync’s.
A “Full Import” on a small AzureAD (~8500 Users) took 2 minutes.
A subsequent “Delta Import” with no changes took 6 seconds.
A similar implementation of the logic, but for Groups gives similar results/performance.
A “Full Import” on a small AzureAD (~9800 Groups) took 5 minutes.
A subsequent “Delta Import” with 7 Adds (new Groups) and 157 Updates took 1 minute.
Follow Darren on Twitter @darrenjrobinson
A few weeks back the Microsoft AI Tour was in Sydney Australia. There was a…
If you're anything like me you always have PowerShell open, and often both PowerShell and…
Decentralised Identity is a technology I'm passionate about and have written many posts and tools…
Over two years ago I authored a PowerShell Module that enabled the automation of 1Password.…
Buried in my PowerShell Snippets Vol 4 post from 2021 is the PowerShell script and…
Short post on how to recovery from "The Windows Subsystem for Linux instance has terminated"…
This website uses cookies.
View Comments
Thanks you so much for your great article, I've used the same idea you followed here in this article but I used MSol module instead to Sync B2B user data and profiles from Azure AD into on-premises SharePoint 2016 User Profiles
Nice one. Be aware though that the MSOL module is being superseded and the endpoint it talks to will be turned off at some point.
https://uploads.disquscdn.com/images/e672e15aabf610f82eadbbf1f2ec2b478fb3d50bd016ab6ab502371e66b75707.png
https://uploads.disquscdn.com/images/99edb6339818833d04065fb98bb5ffe38b88a7f7e714a3557ccfa01af7ec8135.png
https://uploads.disquscdn.com/images/2fe1871ae21aaced5f11e016223a7678af7578dd8ca4651a4ed427167115613c.png
https://uploads.disquscdn.com/images/cce3267424d51b0893ab5cf5a9ef4f7cf681958dd50c589afe1dbeb85efad718.png
https://uploads.disquscdn.com/images/e08b3c5ee62cf66474b06e7e1b2e6215a6df936a196d65a538a3ffb4e1e9bedc.png