Microsoft Identity Manager (MIM) is a product with a long history from Microsoft. While its storied timeline begins many years earlier as a product that Microsoft acquired called ZoomIt Via, Microsoft eventually rewrote the product from the ground up and released it as Microsoft Identity Integration Server 2003. Since that time, the core component has not significantly changed but the product has picked up new features like a net roaming through the seas. It is a very important product that has seen popular usage in many applications including GALSync for synchronizing directory objections in multi-forest Exchange environments and ADAMSync for synchronizing directory information from Active Directory Domain Services (AD DS) to Active Directory Lightweight Directory Services (AD LDS), formerly known as Active Directory Application Mode (ADAM). There are two very timely uses of this product today, Microsoft Exchange EdgeSync Service, used to synchronize valid recipients from AD DS to the AD LDS created for the Edge server role, and Azure Active Directory Connection (AAD Connect), formerly Directory Synchronization (DirSync) and Azure Active Directory Sync (AADSync). Most recently, the product has been known as Microsoft Forefront Identity Manager (FIM) and finally as Microsoft Identity Manager (MIM) as the current release.
With Microsoft cloud adoption so high, it is rather prudent for IT professionals to become familiar with the inner workings of the product that keeps everything held together. Unfortunately, there is only one real book out there dedicated to the product, “Microsoft Identity Manager 2016 Handbook” by David Steadman and Jeff Ingalls, released by Packt Publishing. Now, I am somewhat perplexed by this book because it is quite literally a rebranding of “Microsoft Forefront Identity Manger 2010 R2 Handbook” by Kent Nordström, released by Packt Publishing. I am really unsure of what has happened behind the scenes, but the publisher has new authors listed for a book and they have written forwards suggesting that they have authored this new book… but it is the same book with some minor updates for the latest release and some additional chapters. Also, while the narrative approach of this book may appeal to some, it doesn’t appeal to me. Essentially, a ficticious company has been invented of an indeterminate size with minimal requirements defined… the purpose being that it doesn’t paint itself into a corner with the audience so that readers can perceive that this could be their company.
Now, I am glad that the resource exists, don’t misunderstand me on that account. However, I have thought that there is a distinct void in regards to this product. Since the product has had more rebranding than Lync/Skype for Business (which really is a feat), it suddenly hit me that one could search for the previous names of the product for older resources, especially since the core sync service really has changed very little.
This has brought me to chapter 21 of “Active Directory Cookbook”, both the 3rd and 4th editions, by Robbie Allen, et al. This solitary chapter in each book, discussing Identity Lifecycle Manager 2007 (another previous name of the product) and Forefront Identity Manager 2010, respectively, goes a long way towards explaining the purpose of the product, its unique jargon, and how the process generally works when it comes to integrating identities from various sources.
AAD Connect, and its predecessors, has gone a long way to simplying the process of installing the sync engine and configuring the prerequisites, connectors, and flows of data. While having this level of simplicity of installation is a great boost for us all, it does mean that few find it necessary to dive deeper into the underying technology that supports it. Approaching more complex scenarios, like cross-forest migrations, multi-forest relationships with Office 365, and more make this knowledge all the more necessary and beneficial. Additionally, new features that have inserted themselves through out the years provide additional value that can be leveraged, like self-service password resets and certificate management, and provide a line of vision related to the development of features available in Azure Active Directory today and into the future.
So, what are useful concepts to understand about the product? Understanding the Connector Space and Metaverse model of synchronization are key. Also, now that having at least one sync engine in service (AAD Connect) is rather mainstream, knowing that any particular SQL instance can only have a single sync service attached is fairly important; if you utilize a non-local SQL instance for AAD Connect and you require an instance of MIM for some other functionality, they cannot use the same SQL instance. In terms of licensing, the MIM server license is now included with Windows Server and many operations, namely those that only make use of the sync engine, do not require a client access license; for those tasks that do require a CAL, one is included with each license of the Enterprise Mobility + Security license that encompasses Azure AD Premium, InTune, and Azure Information Protection, among many others.
What are some valuable uses of MIM in an Azure AD and/or Office 365 deployment? One of the long-lacking features of Azure AD was license provisioning; this has been addressed with the “in preview” feature known as AD Group-based License Management. However, if your requirements are a bit more complex or it doesn’t seem to fit your needs, you could use MIM to key off of attribute values or group membership to determine the licenses that should be applied and then using the PowerShell Management Agent, it could connect to Azure AD and provision licenses to users. In addition, there are many “policy” decision-points that could have a true policy model to drive them. For instance, creating policies for mailbox size (mostly on-premise, but if you want to restrict the very generous offerings in Exchange Online it would also apply) and having MIM do the heavy lifting. Some other tasks that have some pain points include provisioning mailboxes in Exchange Online in a hybrid configuration. The tools exist within PowerShell, but they aren’t entirely consistent themselves. The Exchange Admin Center is far from consistent. For instance, you can use an existing AD user object to deploy an on-premise mailbox via the EAC, but you cannot do so when deploying an Office 365 mailbox (Remote Mailbox), but this is easy via Exchange Management Shell (e.g. Get-User <Identity> | Enable-RemoteMailbox). The various shared mailbox types are also an enigma; you can use the same commands to create a Room or Equipment mailbox by following the previous command with an operation to set the type (e.g. Get-RemoteMailbox <Identity> | Set-RemoteMailbox -Type Room), but if you just want a generic shared mailbox, Microsoft recommends to create the mailbox as a shared mailbox on-premise and migrate it to Exchange Online; however, one could connect to Exchange Online PowerShell and set the type to Shared or use the Exchange Online EAC to do the same (e.g. Get-Mailbox <Identity> | Set-Mailbox -Type Shared). These tasks could be made consistent via MIM by using an Active Directory object to classify the mailbox type and have it provisioned based on those attribute settings. Other tasks could include creating a standard to change the default calendar permissions for shared mailboxes (or user mailboxes, for that matter) so that they expose additional details. Your creativity is the limit.
Dustin Dortch 