Office 365 QA/Dev Tenant – Introduction

Over the past few weeks I have been working out a series of articles on a concept of how do we test things in Microsoft’s cloud environment? Depending on the environment you work in you may or may not be required to have some sort of QA or DEV environment for testing and validating changes. In the world of cloud based apps and hosted services how would one go about doing this? I believe this would depend on the cloud based service and what they offer for this particular need. For example, if your company is using SalesForce, there is an option to create a SalesForce Sandbox:
https://help.salesforce.com/articleView?id=data_sandbox_create.htm&type=5
Creating a Sandbox environment for SalesForce allows you to test certain features and configurations.

Office 365
Now what about Office 365? How can you truly perform any sort of testing, QA or DEV for Microsoft’s cloud service. There are many factors to take into consideration, the least of which is not if you are Hybrid or not. If your Office 365 cloud services are connected to your on-premises Active Directory environment, then there will be some more considerations for such a configuration. For the below example, we are going to go through the more complex option where you many have Azure AD Connect, Exchange Server on-premises, Exchange Online, etc. We will walk through each component and see how that relates to creating a test environment.
While some might say that this is against what a cloud service is supposed to provide, I have come the the conclusion that having a QA/DEV Office 365 tenant would be beneficial for several reasons:

• Change control
• All changes must be tested (company policy)
• Exploring new features without destroying production data
• Ability to make changes to existing configurations without affecting production data

Some Considerations
Creating a QA/Dev tenant for Office 365 won’t be as simple as creating a new Office 365 tenant and explore the features that it provides. It will be a project unto itself that requires planning in advance and a set of parameters as to what will be tested. Once these parameters are known, then proper planning can occur. Here are some sample items to plan for:

• Active Directory Integration – production of separate QA Active Directory?
• What services to connect to QA Active Directory?
• On-premises servers – Exchange Hybrid, Active Directory, ADFS, Azure AD Connect, etc.
• What data needs to be exported from PROD Office 365 tenant to QAS/Dev Office 365 tenant?
• What settings need to be moved over from Exchange Online, SharePoint Online, Teams, Security and Compliance Center and more?
• and so on…

A sample process would be as follows (30,000 foot view):
Step 1: Document – Exchange Online, SharePoint Online, Security and Compliance Center, Azure AD
Step 2: Apply settings to QA Tenant – could be scripted or scoped if not all options are needed.
Step 3: Create Users and groups in QA Active Directory
Step 4: Sync data to tenant
Step 5: Restore Data as needed
Sample settings that could be imported from one of the Workloads, Exchange Online, for example:

• Quotas
• Retention policies
• Distribution Groups – Dynamic and regular
• Shared mailboxes
• Resource mailboxes
• OWA settings
• Mobile device settings
• Role Groups and permissions
• DLP Policies, sensitive information types and fingerprints
• Transport Rules

In the next blog post in this series we’ll cover some requirements as well as the true value of the QA/Dev Office 365 tenant.