BACKGROUND AND PURPOSE
Introducing Office 365 and Azure AD in an Enterprise environment always raises the question around how object provisioning-, de-provisioning- and organizational change-processes will be affected. These are three common concerns and questions that I get from Enterprise customers in the planning phase of an Office 365 onboarding project:
- The customer is using an identity management (IDM/IAM) solution for provisioning accounts, and want’s to better understand how Office 365 / Azure AD will affect that landscape.
- The customer have special de-provisioning routines for retaining user data (i.e. keeping the mailbox and home folder data etc.), and needs to know how these processes should be updated when Office 365 is introduced.
- The customer understands the provisioning and de-provisioning processes, but want’s to automate them as much as possible.
The purpose of this article is to provide guidelines on how to approach this topic. Please note that these guidelines are intended for large Enterprises that seeks a high level of automation in these processes. Small-/medium-sized organizations with a lower number of employee attrition and/or organizational changes per week/month does not always have to implement automation processes for provisioning/de-provisioning/org changes.
As always with the “Lost Documentation” articles, most of this information is available from Microsoft, scattered over various TechNet- and MSDN-articles – this is my attempt to assemble the information in one place, to assist fellow Solution Architects, system administrators and project managers in the journey to Office 365.
PROVISIONING A USER FOR OFFICE 365 – WHAT COULD POSSIBLY GO WRONG?
Implementing user provisioning processes in Office 365 is generally very easy and straight-forward. Many often think that if you have complex provisioning processes in place today, you will have a hard time make it work for Azure AD / Office 365. This is almost never the truth, as the provisioning processes for Azure AD / Office 365 is “put on top” of what you already have. You kan keep provisioning users based on data from your HR system, and assign them roles based on data in a payroll system, or whatever it is that you are doing – as long as the user is created in Active Directory – it will be provisioned in Azure AD / Office 365 through a separate appliance-like synchronization engine (AAD Connect) without you having to change anything in the current provisioning routines. However, some processes will require updates – i.e mailbox provisioning in Exchange – and you will also be required to assign an Office 365 license to your users before they can use any of the services. The higher ambition you have for automation around these processes, the more challenging this topic will be for you – simply because automation is handled differently by every customer so there is no general answer to how it is achieved.
Below is guidelines for approaching provisioning automation, which can help you update your own routines and processes.
GUIDELINE #1: KNOW YOUR USER PROFILES BETTER THAN EVER BEFORE
The nature of SaaS: Office 365 is a subscription-based service, sold and consumed in a SaaS-model. Each user has assigned services in Microsoft’s data-center, with associated SLAs. A fundamental aspect of this delivery model is that each user must have an assigned license to be able to consume the service. A challenge for large Enterprise customers is that they are used to the traditional ways of purchasing Microsoft licenses (not services), which required a yearly inventory (“true-up”) of how many users were having Office applications, Exchange mailboxes, Skype for Business/Lync profiles, access to SharePoint etc. – and all you had to do as a customer was to share this updated figure with Microsoft – pay accordingly – and continue to use the services.
There have never before been any “enforcement method” that makes Office, Exchange, Skype for Business or SharePoint stop working if you are using more licenses that you have accounted for in your “true-up” – everything has just worked and it has been very much up to your own customer loyalty to make sure that you actually have payed for every user that you have provided with Microsoft software – such as Exchange mailboxes, Office applications, Skype for Business/Lync profiles and access to SharePoint Sites. And of course, this would include all your employees, but also any external user, like consultants getting Exchange mailboxes so that they could send and receive e-mail with your domain.
Don’t under-estimate the task: With Office 365 in place, the reality is changed. Users that are not assigned a license does not get access to any services (can’t activate the Office applications, no mailbox access in Exchange Online, no OneDrive for Business, no access to SharePoint Sites etc.). There is no “grace period” – you will need to have the right number of licenses reserved from your Enterprise Agreement through the VLSC Portal, and these licenses need to be assigned to a user (activated on that user’s account – read more later in this article) in order for that user to be able to use the services. This fact will require you to both know exactly how many users you are providing with Office 365 services, and if you are providing more than one license plan (SKU), i.e you have purchased a mix of E1, E3, E5 and K plans – you will need to know exactly what individuals should be mapped to exactly what license plan.
The task of mapping each user to a user profile (license SKU) is often extremely under-estimated. It is important to understand the consequences of not having the user profile mapping completed before commencing the Office 365 onboarding project. The consequence includes:
- The onboarding project will be stalled, as licenses will either run out, or the technical team doing the onboarding will at a certain point in time need to know what licenses to assign for each user, as all users are onboarded.
- The business case for moving to Office 365 will be impacted. Let’s say you invested in 50 000 E3 licenses, because that was the amount of Office ProPlus licenses you bought in the traditional license model. As it then turns out, you were actually providing these services for 55 000 users, you just had not calculated for all the external people who you have provided with IT-tools. This would mean an additional cost of 10% over your initial Office 365 investment.
- Users would get insufficient or wrong services assigned. Imagine if you assign E1 licenses to a department of 5000 users where you deploy Office 365 ProPlus – no one would be able to activate their Office applications, and your support organization would have to take the hit. Another consequence of getting the wrong services assigned is that you pay an extreme over-price for a user getting more services than he or she ever would actually use.
So before you dig deeper into the technology around provisioning, it is recommended that you map each and every user account in your organization to a user profile, which also translates to a license SKU.
Clean-up: Also note that accounts (i.e. Active Directory users with or without Exchange mailboxes) that are not actively used cannot be provisioned without an active license, which means that if you have licenses for 50 000 users, but you have 60 000 mailboxes in Exchange, where 5000 are Shared Mailboxes and Equipment/Room Mailboxes (these are free in Office 365 / Exchange Online), you have an overhead of 5000 user mailboxes which will need to either be removed or to acquire a license. Cleaning up your Active Directory and Exchange Server from inactive user objects and mailboxes before Office 365 onboarding is as important as the user profiling work itself.
GUIDELINE #2: UNDERSTAND IDENTITY/USER PROVISIONING AND LICENSING
Identity Bridge: The recommended way for Enterprise customers to provision users, groups and contact objects in Azure AD / Office 365 is by extending your on-premises Active Directory to the cloud through an appliance-like synchronization tool called Azure AD Connect (AAD Connect). The tool was previously known as DirSync and AADSync, and there was also a standalone FIM / MIM Management Agent – all these three still works, but future development will only be done in AAD Connect, which makes that the best choice for every organization today, regardless of complexity and identity landscape in general. Hand-in-hand with identity synchronization for provisioning and administration, a security token service (like ADFS) is usually implemented to provide single sign-on to Office 365 – this however has actually nothing to do with provisioning, why it will not be mentioned more in the article.
Sync: With AAD Connect in place, the on-premises Active Directory will be replicated to the Azure AD / Office 365 every 30 minutes. All your users, groups and contact objects will be provisioned in Azure AD / Office 365, but no Office 365 services are assigned to any users until you assign a licenses yourself as an admin. AAD Connect makes sure that you keep administrating your identities the same way you are today, and that you won’t have to maintain multiple identities (on the ground and in the cloud). It also makes sure that what ever identity provisioning routines you have in place today will continue to work as before, as long as they provision identities in Active Directory, AAD Connect will do the rest on top of what you already have.
Beware of 3rd-party or self-made sync: It is not recommended to replace AAD Connect with a 3rd party or self-developed synchronization / provisioning script (i.e. PowerShell / REST API provisioning). The main reason is that it will not be supported for all complex scenarios (such as Exchange Hybrid Configuration, attribute write-back scenarios, etc.). There is a AAD Federation Compatibility List (previously known as the “Works With Office 365 Identity Program”) that lists 3rd party STS services compatibility towards federation with Azure AD / Office 365 – found here – however, not many are reading the top note on the page that says that the solutions listed are only tested for federation scenarios – synchronization and multi-factor authentication scenarios provided by 3rd party vendors are not supported by Microsoft.
Synced users needs licenses: When AAD Connect is in place and is replicating your Active Directory data to Azure AD / Office 365, you will need to license users in order to activate them for Office 365 service – such as being able to active Office 365 ProPlus or read content from SharePoint Online. Assigning licenses can be done manually via the Office 365 Admin Portal, but if you want to automate this for Office 365 licenses, you have to create your own solution as of now. The recommendation is to implement a PowerShell-script that assigns licenses based on Active Directory attributes or Security Group membership. This script can run as a Scheduled Task, for example on the same server that hosts AAD Connect. A good place to look if you want to automate user licensing with PowerShell is at this post by Office 365 MVP Johan Dahlbom (and in this post he explains how to do it with Azure Automation).
Two things before you sync: It is recommended that you inspect your Active Directory for directory quality errors before you automate your identity provisioning and administration with AAD Connect. Use the IdFix tool to run the inspection and then remediate all errors found. It is also recommended that you change your users UPN-names to match their primary SMTP-addresses before you sync. You don’t have to change the samAccountName, so users can keep logging in to Windows etc. the same way as before. The main reason to why you should change UPN-names to match SMTP-addresses is that users should know what username to use when accessing Office 365 in the mobile context (it has to be in the UPN-format). If you have contemplated Alternate Login ID as the solution for this, beware of the limitations (great article here by Joe Palarchio) – I generally do not recommend using it.
GUIDELINE #3: UNDERSTAND MAILBOX PROVISIONING – DURING AND AFTER COEXISTENCE
With our user profiling, AD/Exchange clean-up, identity bridge and automated licensing in place, we are ready to look at process updates required for provisioning Exchange mailboxes.
Different ways depending on if you do hybrid or not: If you have established an Exchange Hybrid Configuration, you will provision mailboxes as an administrative task much like you have done before, until the last Exchange Server and the hybrid configuration is fully decommissioned. If you are not in a hybrid configuration, you will provision mailboxes simply by assigning a license for Exchange Online to one of your users. Let’s break down the rationales and guidelines:
As long as you are in an Exchange Hybrid Configuration with at least one Exchange Server still running on-premises, you can provision new mailboxes directly in Exchange Online by creating new “Remote Mailboxes”. A Remote Mailbox is a mailbox in Exchange Online that you can see and manage from your Exchange Server administration tools. You can of course create Remote Mailboxes from your Exchange administration tools (GUI), but for automation purposes it is recommended to use PowerShell. For updating your mailbox provisioning routines to create remote mailboxes in Exchange Online while you still have Exchange Server on-premises, study and use the PowerShell cmdlets for provisioning new Remote Mailboxes. Here are some examples:
To create a new Remote Mailbox for an Active Directory Mail User that you have provisioned on-premises, synced to Azure AD and assigned an Office 365 license (the most common scenario), run the following command in the Exchange Management Shell:
Enable-RemoteMailbox -Identity <UPN-name> -RemoteRoutingAddress <USERALIAS>@<TENANTNAME>.mail.onmicrosoft.com
To create a new user in the on-premises AD and a new Remote Mailbox that will be enabled when the new user is synced by AAD Connect (a fairly common scenario), run the following command in the Exchange Management Shell, and then license the user:
New-RemoteMailbox -UserPrincipalName email@example.com -Name “Display Name” -OnPremisesOrganizationalUnit OU=Users,DC=addsdomain,DC=com -Password (ConvertTo-SecureString -AsPlainText “Pa$$word” -Force)
To create a new Shared Mailbox directly in Azure AD / Exchange Online as a Cloud ID (without any corresponding AD-user on-premises), run the following command in PowerShell, after connecting to Exchange Online:
New-Mailbox -Shared -Name <UPN-name> -PrimarySmtpAddress <User>@<DOMAIN>.com
(If you want the Shared-/Room-/Equipment Mailboxes to be represented in the on-premises AD, you will need to provision them as User Mailboxes first and convert them to shared mailboxes afterwards and remove the licenses – Shared-/Room-/Equipment mailboxes does not require a license once they are provisioned as such).
If you are not in an Exchange Hybrid Configuration, you provision mailboxes simply by assigning users with the correct attributes and an Office 365 license (that includes Exchange Online). The attributes that must be populated before you sync and license the users are: proxyAddresses (should include all necessary SMTP- and SIP-addresses), mail (should be populated with the primary SMTP-address), UPN (should preferably match the primary SMTP-address), Display Name (as you want it to appear in the Global Address List). The same process goes for Distribution Groups – you provision them in the on-premises AD with these attributes (minus UPN) populated, and then let AAD Connect synchronize them to Azure AD / Exchange Online.
About administration of Exchange Online: When AD synchronization with AAD Connect is enabled, most attributes are owned by AD on-premises, and you will therefore not be able to fully administer Exchange Online from the web-based administration portal (Exchange Control Panel). Some Exchange-attributes (such as proxyAddresses) simply must be administered in the on-premises AD and be synchronized to Azure AD / Exchange Online for the change to have effect. Because of this, it is worth noting that if you are decommission all Exchange Servers on-premises, you might need to build in more Exchange administration to your IDM / IAM provisioning and self-service tools than what you had before. End-users that administer Distribution Groups in Outlook are also affected, as this will for the same reasons stop working after the users mailbox is moved to Exchange Online – self-service tools for Distribution Group/List management will be required.
GUIDELINE #4: UNDERSTAND SKYPE FOR BUSINESS (LYNC) ONLINE PROVISIONING
Skype for Business Online (formerly known as Lync Online) provisioning works in the following way:
- If you have Lync Server or Skype for Business Server on-premises, and have users provisioned there with active SIP-profiles, and you are using AAD Connect so sync your AD on-premises to Azure AD / Office 365, no provisioning will occur in Office 365 for the SIP-enabled users, regardless if you license these users for Skype for Business Online in Office 365.
- If you license SIP-enabled users for Skype for Business Online, and then remove the SIP-profile from Lync-/Skype for Business Server on-premises, users will be provisioned for Skype for Business Online at the next AAD Connect sync cycle (often referred to as a “cut-over move”).
- If you are leveraging a Lync-/Skype for Business hybrid configuration, users must be licensed for Skype for Business Online, and you can then move users from the on-premises pool to the online pool. When all users are moved, you can for the purpose of provisioning decide to keep or remove the on-premises Lync-/Skype for Business Server environment, and select another provisioning method from this list of guidelines.
- If you are not having Lync-/Skype for Business Server on-premises, you provision users for Skype for Business Online simply by assigning them an Office 365 license (with Skype for Business Online included). It is recommended that you in this case populate the proxyAddresses attribute in the on-premises AD with a SIP:-address that matches the primary SMTP address.
GUIDELINE #5: UPDATE YOUR PROCESSES FOR DE-PROVISIONING USERS
There are many different aspects of user de-provisioning, including return of licenses, removing permissions, store/hold user data, etc. By understanding the fundamentals of how Azure AD / Office 365 de-provisioning works, you will be able to update your current processes to work with Office 365. Here are the fundamentals you should know about:
- If you are disabling a user in the on-premises AD, you are disabling the user in Azure AD / Office 365, but the license is still active.
- If you are deleting a user from the on-premises AD, you are deleting the user in Azure AD / Office 365. When this happens, all data is soft-deleted for 30 days and the license is returned to the license pool. If you restore the user within these 30 days (restore the user in the on-premises AD and sync the user again), all data will be kept. If you don’t restore the user within 30 days, and have not applied any rules for data Hold, the data is lost.
- If you remove the license from a user in Office 365 (for example if you move the user to a OU for de-provisioned users, disable the account and strip it from it’s group memberships as your de-commissioning routine in the on-premises AD), all data is soft-deleted for 30 days. If you re-assign the license to the user within the 30 days, and have not applied any rules for data Hold, all data will be kept. If you don’t re-assign the license within 30 days, the data is lost.
- If the user is licensed when it is deleted and the Manager field is populated for that user in AD, the Manager will be notified and given access to the users OneDrive for Business site for 30 days through the Access Delegation mechanism, explained here. If you remove the license before actually deleting the user, the Access Delegation process will not be triggered.
- There are different ways to keep the data for more than 30 days after you have removed the license from a user. The general recommendation is to use the Hold capabilities, administered from the Office 365 Protection Center.
GUIDELINE #6: UPDATE YOUR PROCESSES FOR ORGANIZATIONAL CHANGES
When users go through a department change, country transfer or other forms of organizational change, there are often identity-related processes that goes with it. In Azure AD / Office 365, it is much like with the provisioning; you can keep doing what you did before and let AAD Connect handle all the provisioning aspects in Azure AD / Office 365 for you. There is however one concern regarding the UPN attribute that you should be aware of. Here are the fundamental guidelines for organizational changes:
- If the organizational change is resulting in attribute updates, or even changes of Organizational Units, in the on-premises AD – let AD Connect take care of updating this in Azure AD / Office 365 for you through the regular synchronization cycle.
- Beware of delays that can occur, such as generation of the Offline Address book used in Outlook that can make updates in the Global Address List need a day to show up to all users, or back-end replication to SharePoint Online to let all organizational attributes show the correct values.
- If the organizational change requires a change of the UPN-name and the user is licensed, you will need to manually give it a push in Azure AD in order for it to change, AAD Connect can not change UPN-names in Azure AD / Office 365 for licensed users. To manually fix the UPN-name for the licensed user, follow the steps outlined in Scenario 2 in this article. A summary of the steps: change the UPN-name in the on-premises AD, let AAD Connect run a sync cycle, then connect PowerShell to your Azure AD tenant and run this command in PowerShell:
Set-MsolUserPrincipalName -UserPrincipalName [CurrentUPN] -NewUserPrincipalName [NewUPN]
SUMMARY AND DISCLAIMER
All guidelines presented here are based on my field experience and are made available for your own interpretation to assist in updating provisioning/de-provisioning routines in the move to Office 365. I hope you will benefit from these guidelines, and that you will give me suggestions for more topics that would make this article more complete. I am always listening to feedback on Twitter. Thank you for reading.