Deploy a Test Microsoft 365 Tenancy

In recent history it was possible to set up labs to test new technologies in a lab. This was due to the ease of deploying VMs to run test work loads. But what do you do when these services become cloud services? Most companies aren’t keen on the idea of paying for a sandbox environment even when there is a quantifiable value to having it.

Microsoft have provided a solution for this if you are a developer through MSDN but now they have opened up access to their cloud services through Developer.microsoft.com.

You can join their Dev Program at Developer Program – Microsoft 365. This allows you to deploy a new tenancy and includes 25 E5 licenses (just without Windows, and PSTN services). These licenses expire every 90 days but at this stage can be renewed so is an amazing deal.

These tenancies originally expired after 90 days which was good, but the change to allow renewals is outstanding.

Just remember that since you are the admin of this environment that it still needs to be secured.

Also don’t get too attached. Microsoft could always change their mind and go back to non-renewable tenancies.

Migrating from Hybrid to Native Microsoft Cloud – Overview

While Microsoft would love businesses to consume their services as a native cloud service, most environments operate in a hybrid mode. What does this mean and when would you run in this mode?

How did we get here?

If we look back on most business systems they were all located on-premises on hardware running inside the company offices. When the Microsoft cloud was first released it was essentially Microsoft running their own server software. Few customers were able to migrate all of their services into the cloud so used Hybrid services to introduce customers to the cloud.

In this mode selected users could use Cloud Services while other users would use on-premises services.

If you needed to use any Hybrid Cloud Services they all have a prerequisite of deploying Azure AD (AAD) in hybrid mode. You did this by installing Azure AD Connect on an Active Directory (AD) joined server. This replicated your on-premises AD users into AAD.

Azure AD Connect environment
Azure AD Connect provides the glue between AD and AAD identity providers

Note that the user accounts are replicated. They are not the same account. We either use single sign on, or password replication to make it appear to the user that they are using the same account.

Over time as more users are migrated to the Microsoft Cloud there has been less reliance on the on-premises services. But what is the process to move from a Hybrid to a Native Cloud environment?

Audit your environment

First you need to look at what services you still are using on-premises. Let’s assume that you’ve migrated all of your services to the cloud AND removed the old on-premises services. (Exchange, SharePoint, Skype for Business, and Configuration Manager). You’re likely still be left with AD.

In this case you’ll likely still be creating users in Active Directory and syncing them to AAD if for no other reason than to make sure that you can add them to your AD based groups.

Is your computer still connected to the on-premises Active Directory, or were they moved to Azure Active Directory connected computers? Do you still use any services located in the old Active Directory forest on file servers for instance? Do you use Password Hash or Federated Authentication?

Once you understand what dependencies you still have on the on-premises environment you can work to remove them.

Migrate your Authentication

If you are still using Federated Authentication then this is using your internal AD to authenticate any authentication requests for you AD users. This will also stop you from having any native cloud users with the same domain name as your hybrid users.

This should be one of the first services you migrate. Once completed all Office 365 login requests will be authenticated in AAD rather than being forwarded to AD.

Migrate users to Azure AD Devices

Even when your account is AD homed you can still log on using AAD if the computer is natively joined to AAD. Once the machine is removed from AD and added to AAD users will log on using their AAD account. Remember that the accounts are seperate so if you log on to an AAD device then you are logging on using your AAD account. If you log on to an AD device then you are using your AD account.

Same user logging in to different devices
The same user uses a different identity provider by using a different machine

Unfortunately the tools to make this migration are quite limited at this time. If you need to automate this process then Binary Tree Power365 currently should help migrate machines from AD to AAD.

Migrate all non-user AD objects

Before you can move your user objects you will need to move any groups that they are a member of. If you move the account first then they would non longer be a member as the group ownership was still in AD.

In Office 365 there are different types of groups which are migrated in different ways. If a group is a distribution group then this migration will need to be performed in Exchange Online. If on the other hand it’s a security group then this is owned by Azure AD.

It might also be worth cleaning up the rest of the directory at this stage. Remember that contacts also need to be moved but you may also have other objects that need to be cleaned up. While you can the source of most objects in the Azure AD portal it is worth using the Azure AD Connect service to see exactly what is being sent to AAD.

Migrate user accounts

Once your user accounts are finally ready to move you face a problem. Microsoft currently doesn’t have a process to move a user from AD to AAD. Instead you need to stop the user from syncing which will delete the user account in AAD. Once the account is deleted you can then recover it from the AAD recycle bin complete with all data. This will then change the account to be a native cloud account.

Flip the Native Cloud Switch

Once all of your users have been migrated to be native cloud you can then disable the Sync between AD and AAD.

While this will feel like a substantial change this won’t impact your users at all as they will no longer be accessing any AD services.

Hopefully this gives you a good overview of the steps required to move from Hybrid to Native Cloud. In subsequent articles we’ll look at the details for each step and how you can minimise the user impact.