Active Directory, Exchange, Microsoft, Office 365, PowerShell

How to Provision Exchange Online Mailboxes

After completing a migration to Exchange Online, it is common to have questions like:

1) What is the best practice for provisioning mailboxes?

2) How do I provision mailboxes?

3) Why should I keep this Exchange server around?

Well, these are good questions.  Let’s start with the last question.  When an organization migrates to Exchange Online, it is quite commonly thought that Exchange is no longer needed on-premise.  From a deeply technical perspective, this is true… but it is a bad idea.  As a matter of fact, it is such a bad idea that I wrote a very blunt response to another blog post suggesting that keeping hybrid in place is not really necessary.  Well, if you want to live in a world where you are maintaining your own tools, have only skilled individuals provisioning mailboxes, or you have lesser skilled folks poking around directly with Active Directory attributes, knock yourself out.  Also, this doesn’t apply to organizations that don’t synchronize their on-premise Active Directory to Azure AD.  For those that want to limit their heartburn and remain in a supported configuration, however, you must not only keep an on-premise Exchange server, but also keep it in a hybrid configuration.

Microsoft goes a long way to explain it in their article: How and when to decommission your on-premises Exchange server in a hybrid deployment.

The problem is that this article is buried deeply out there in the web and very hard to find.  Microsoft doesn’t make this very well known because this information is hard to find.  Here is the basic summary: You need to keep an Exchange server around on-premises in hybrid not because of Exchange, but because of directory synchronization.  AAD Connect (and its predecessors AAD Sync and DirSync) is built on what is now know as Microsoft Identity Manager 2016.  This is a metadirectory product that helps to synchronize and provision identities.  While there can be some bi-directional synchronization of attributes, there has to be an ultimate source of truth.  This means that when you are synchronizing to Azure AD, your on-premises Active Directory is that source of truth.  Users must be provisioned there and many attributes must also be maintained there.  Since these objects, like mailboxes, distribution groups, and mail contacts, must exist in on-premises Active Directory, it makes sense to have an administrative interface.  One could manually edit the attributes like ProxyAddresses and know that the primary SMTP address should be meet the following requirements:

1) Be prefixed with “SMTP:”

2) Be unique throughout your organization

3) Have its value saved to the Mail attribute

Other values in ProxyAddresses should be prefixed with “smtp:” or their address type prefix.  Because of these challenges, Microsoft has made it a support requirement that Exchange remain on-premises.  In fact, they have made it easier by giving all enterprise Office 365 customers a free license key for use with hybrid co-existence servers.

Aside from the support requirement, there are plenty of reasons to keep an Exchange server on-premise.  First, it makes support magnitudes more simple.  You can use the on-premises RBAC model and grant support staff the rights to provision recipients from your Exchange system without even granting rights to Office 365 or Exchange Online administratively.  Another big reason is that Exchange Online does NOT have Email Address Policies.  By maintaining a hybrid co-existence server, Email Address Policies can be established and executed there and the subsequent AD writes will be synchronized to Azure AD, this giving you Email Address Policies for Exchange Online recipients.  Finally, many time you need to relay mail from on-premises devices and applications; this is far easier if it is done centrally from a server on-premises that is granted relay rights through Exchange Online.  This simplifies firewall rules and keeps the configuration within Exchange Online to a minimum.  This relay point may as well be the hybrid co-existence server that you should already have.  Servers with hybrid co-existence perform Exchange Authentication and have a privileged existence from the standpoint of spam filtering.  Finally, if you take the server out of the topology by not keeping it in hybrid configuration, you lose access to many of the cmdlets and web interface means to properly provision recipients in Exchange Online.

Now we know why we should maintain this server, but how do we effectively utilize it?  Well, it is not a walk in the park unless you are well-acquainted with Exchange Management Shell.  Microsoft has been very inconsistent about its tools.  In the web interface, you can create a User Mailbox in Exchange Online from your on-premises server if you create a new Active Directory user account at the same time, but you cannot use an existing user account.  Also, Microsoft makes it easy to create Equipment and Room mailboxes, which are types of Shared mailboxes, but not Shared mailboxes themselves.  Microsoft recommends that you create a Shared mailbox on-premises and migrate it to Exchange Online.  This is just bad, Microsoft… you should fix this and make it work well and consistently.

Here is my cheat sheet for provisioning mailboxes and it requires Exchange Management Shell connected to the on-premises environment.  These commands count on existing AD user objects.  Let’s assume that we have the following AD user objects for which we must create Exchange Online mailboxes with their intuined types:

User Mailbox (AD user object name: “User Mailbox”):

1. From Exchange Management Shell: Get-User “User Mailbox” | Enable-RemoteMailbox -RemoteRoutingDomain TenantName.mail.onmicrosoft.com

2. Wait for a sync cycle or manually synchronize from AAD Connect: Start-ADSyncSyncCycle -PolicyType Delta

Room Mailbox (AD user object name: “Room Mailbox”):

1. From Exchange Management Shell: Get-User “Room Mailbox” | Enable-RemoteMailbox -RemoteRoutingDomain TenantName.mail.onmicrosoft.com

2. From Exchange Management Shell: Get-RemoteMailbox “Room Mailbox: | Set-RemoteMailbox -Type Room

3. Wait for a sync cycle or manually synchronize from AAD Connect: Start-ADSyncSyncCycle -PolicyType Delta

Equipment Mailbox (AD user object name: “Equipment Mailbox”):

1. From Exchange Management Shell: Get-User “Equipment Mailbox” | Enable-RemoteMailbox -RemoteRoutingDomain TenantName.mail.onmicrosoft.com

2. From Exchange Management Shell: Get-RemoteMailbox “Equipment Mailbox” | Set-RemoteMailbox -Type Equipment

3. Wait for a sync cycle or manually synchronize from AAD Connect: Start-ADSyncSyncCycle -PolicyType Delta

Shared Mailbox (AD user object name: “Shared Mailbox”):

1. From Exchange Management Shell: Get-User “Shared Mailbox” | Enable-RemoteMailbox -RemoteRoutingDomain TenantName.mail.onmicrosoft.com

2. Wait for a sync cycle or manually synchronize from AAD Connect: Start-ADSyncSyncCycle -PolicyType Delta

3. From Exchange Online PowerShell: Get-Mailbox “Shared Mailbox” | Set-Mailbox -Type Shared

That’s it.  Distribution groups are created on-premises just like normal and members added from on-premises.  Mail contacts are also created just like normally on-premises.  Each of these synchronize properly to Azure AD.

Ensuring that you properly provision your mailboxes on-premises means that messages relayed from on-premises devices and applications do not get NDRs and that email addresses get assigned via policies, reducing the opportunity for human error.  One thing to keep note of is that Shared mailboxes are still inconsistent from the rest; they are created as regular mailboxes and then converted to Shared mailboxes in Exchange Online directly.  I wish Microsoft would change this as it is possible… if you manually set the msExchRecipientDisplayType and msExchRecipientTypeDetails attributed to the proper values, they will be provisioned in Exchange Online properly, but this should be a requirement.

Exchange, Microsoft, Office 365

Potential Litigation Hold Loopholes and How to Avoid Them

One long standing feature of how Microsoft Exchange works has recently changed: where “Sent Items” reside when you “Send As” another recipient.  The traditional flow is that if “User A” has privileges to “Send As” “User B”, then the message would go in the “Sent Items” folder of “User A”.  This changed with Exchange Server 2013 CU9 and Exchange Online with the following: Want more control over Sent Items when using shared mailboxes.  Fortunately, this feature is disabled by default and things work the same as the original method, and I will explain why this is a good thing below.

So here is the issue: shared mailboxes do not require a license.  The rationale from Microsoft is that you license users and a shared mailbox can only be access by a licensed user via their own user mailbox.  This is great for customers because they can create these shared mailboxes and allow groups of users to share the mailbox and respond to messages.  However, since it isn’t licensed, the mailbox lacks many features: Online Archive, Retention Policies, and In-Place/Legal Holds.

So, this causes two issues:

1) There are no backups in Exchange Online and the easy way to manage this is to use the underlying resiliency of Exchange Native Data Protection and implement Online Archive (with unlimited space in Exchange 2016, assuming you have the storage to support this, and Exchange Online), Retention Policies to move messages to the Online Archive, and In-Place/Legal Hold to make the messages immutable.  This means that if a user deletes a message, it ages out of the Deleted Items Retention, and you implement In-Place/Legal Hold for 6 months, 1 year, indefinitely, you can use eDiscovery to find the messages and recover them for the user.  This is a great value when you are already paying for Office 365 and you can eliminate a significant cost related to backups… which can be rather significant just considering email.

2) You have a regulatory or business policy that requires you to retain messages for some period time for legal purposes.  You utilize these same features to defend or litigate.

Now, let’s say you enable the new Sent Items behavior and you fall under one of these scenarios.  And because Shared mailboxes don’t require licenses and customers don’t tend to want to pay for an “unnecessary” license, these messages will not be retained; they are in the “Sent Items” of the Shared mailbox without the capability to have a hold.

This is something that I routinely advocate.  Buy an Exchange Online Plan 2 license for your Shared mailboxes.  It is $8/mailbox/month, significantly cheaper than than buying an Office 365 E3 license listed at $22/user/month.  The Office 365 E3 license includes Exchange Online Plan 2, so it is the same feature set from an Exchange perspective and a Shared mailbox doesn’t need SharePoint, Skype for Business, or Office 365 ProPlus.  This is my minimum recommendation for ALL licensing with Exchange Online if you have any of the above requirements, because Office 365 E1 or less (like kiosk licensing) do not cover you.

Perhaps Microsoft will respond to this gap by allowing for In-Place/Legal Hold for Shared mailboxes based on the number of licenses you hold.  We can hope.

Active Directory, Exchange, Microsoft, Office 365

Learning Microsoft Identity Manager

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.

Exchange, Office 365, PowerShell

Identifying Mailboxes without a Cloud Alias

In a hybrid Exchange scenario, mailboxes should be stamped with aliases that are mapped to the tenant unique namespaces (e.g. *.onmicrosoft.com).  If a mailbox does not contain these aliases, it will fail to migrate.  These aliases are normally applied via Email Address Policies, but if the AD object is set to block Email Address Policies from applying, this won’t work.  A quick trick to identify these aliases is as follows (from the Exchange Management Shell, on-premise):
$Mailboxes = Get-Mailbox -ResultSize Unlimited -Filter {EmailAddressPolicyEnabled -eq $False -and EmailAddresses -NotLike "*.onmicrosoft.com"}
Let me know if this works for you in the comments.  Thanks!

Exchange, Microsoft

Desired State Configuration, the Next Thing

PowerShell has been the topic for Windows systems administrators and engineers to learn ever since the release of Exchange Server 2007, the first major product to utilize PowerShell.  Many IT professionals are still behind the curve on adopting PowerShell and I highly recommend getting on the ball and becoming not just familiar, but intimate, with PowerShell.  Desired State Configuration (DSC) is the next thing to learn.

DSC is a highly flexible and capable platform that utilizes WMI and OMI (Open Management Interface) to implement and maintain configurations.  It functions by delivering MOF files to a set of systems that are used to distribute the desire state of configuration.  These files can be built using any ASCII text editor and distributed to systems via a push or pull mechanism (pull being the preferable situation but requires a modest infrastructure to support it, either an SMB file share or a webserver with JSON/REST capabilities).  As of PowerShell v4, but more capable as of PowerShell v5, DSC is built into PowerShell, making it very easy to implement the infrastructure and build the configurations.  Modules are available for many platforms, including Exchange 2013 (the xExchange module), SQL Server, various components of Windows Server, and even modules for Linux and more.  One of the great new features afforded to DSC with PowerShell v5 is PowerShell OneGet which is very similar to features within Unix-type package managers, like apt-get, that allow modules to be downloaded and installed.

More can be learned about DSC from the Microsoft Virtual Academy.

DSC is a great tool for IT professionals to learn, as a whole, but I am particularly interested in it relative to Exchange Server.  When  heavily into Exchange Server 2010 implementations, I made fairly significant headway into scripting and simplifying its installation and configuration.  This assists greatly in many aspects, including documentation, consistency, and reduction in human error.  However, I always thought that it was just short of something more it could become.  The xExchange module for DSC is that next step.  In addition, DSC has modules for web server configuration which are also very handy for Exchange.  One particular gripe that I have had on behalf of customers has been that various customized aspects of an implementation get overwritten when applying updates.  Of particular note, for OWA integration with presence in Lync/S4B, the web.config must be edited to provide details necessary to make this happen.  These details can now be configured through DSC and with its ability to manage and correct configuration drift, it automatically changes the desired settings back to what you wish them to be after applying updates.

More can be learned about the xExchange module for DSC from Microsoft Ignite.

There is a word of caution, however.  Implementing DSC with a refresh cycle to manage configuration drift will cause frustration for those that don’t realize what is happening.  When a newcomer to the environment makes an intended change to the infrastructure, it will be reverted if managed by DSC.  So, as always with change control and service minded organizations, document and share knowledge relative to these circumstances.