In the previous articles in this series I covered the concept of creating a QA/Dev Office 365 tenant for testing. Some may ask what the value is in doing this. Cloud environments are supposed to save costs and we are supposed to rely on the provider for testing and ensuring quality. Is it truly worth the cost to add this to your existing IT infrastructure? Let’s take this question and see if we can provide a suitable answer.
Production tenants can leverage quite a few features in Office 365 that can be tested without technically affecting users in the cloud. Some examples of this are:Quotas – can be applied per mailbox
DLP – can be applied per mailbox or just use mail tips (no production data affected).
Retention Policies – per mailbox application
Transport rules – can be per mailbox
Labels – in the Security and Compliance Center
However, a lot of settings are configured on a per mailbox basis. What if a DLP [policy needs to be applied tenant wide, irrespective of user or app in Office 365? What if a DLP policy needs to be applied to all content – OneDrive, SharePoint Online, Exchange Online, etc. While again, these can be scoped, a rule with a larger data set (tenant wide) is a hard item to test.
Other items to expand on:
- Azure AD Connect Upgrade testing
- Exchange On-premises CU upgrades
- Different feature rings for Office and Office 365
- Mail flow changes – ATP, ATP and more
- Fully testing a change or policy that deletes or modifies production data – retention policy, dlp policy, etc. Better to test the deletion process in a controlled manner.
Office 365 QA/DEV Tenant
For all of the configuration options discussed above, the one item that is shared between all is the creation of an Office 365 Tenant. This tenant will be sync with the QA/DEV Active Directory or OU’s via a separate on-premises installation of Azure AD Connect. Syncing these users are allowed as long as the users are only synced by one Azure AD Connect server and not multiple servers. The exact size of your test Office 365 tenant depends on your budget and what features you decide to license for testing purposes. For a test Office 365 tenant, you may not necessarily need a full set of licenses. For example, a production Office 365 tenant could consist over a thousand mailboxes in Exchange Online with either an E1, E3 or E5 assigned to them. For testing, you may not need all one thousand, but perhaps a sampling of 10 or 20.
Factors When Choosing What to Duplicate
- Budget: How much to spend per month for licensing and support.
- Responsibilities: C-Level, IT, front line, HR, R&D, Legal, etc.
- Features Applied – Quotas, Legal Holds, Labels, message encryption, etc.
Possible Scripting Needs
- Script to document settings in Exchange Online
- Script to document settings in Security and Compliance Center
- Script to export data
- Script to import data
- Etc.
In the next part of this series, a series of practical PowerShell scripts will be used to perform the above tasks to help prep a QA Active Directory/Office 365 tenant.
Configuration 1
One option for configuring a QA/DEV Office 365 tenant is to set up a completely segregate network that does not communicate with the production environment. Using a Router to handle traffic routing to prevent the two networks from communicating with each other. Access rule and other methods can be used to keep these items separate.
In order to make this work, one could utilize network separation as noted in this Cisco guide – https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Network_Virtualization/PathIsol.pdf
Pros
• Restore entire network to a test domain
• Exact replica of Exchange configuration
• Complete restore of mailbox data as well
Cons
• Requires careful configuration and setup to keep AD separate
• Might require additional cost for equipment
Caveats
• Would need to add a QA domain to AD
• Change all user UPNs to QA domain
• Then sync to QA tenant to keep things separate
Configuration Option 2
For this option we would need to configure a physically separate environment. This means servers, routers, switches, ISP connections. Basically everything. The purpose of a configuration like this is true separation.
Pros
• Restore entire network to a test domain
• Exact replica of Exchange configuration
• Complete restore of mailbox data as well
Cons
• Cost of additional equipment
Caveats
• Would need to add a QA domain to AD
• Change all user UPNs to QA domain
• Then sync to QA tenant to keep things separate
Configuration Option 3
For the last option, we don’t have physical separation at all. The QA/DEV AD is on the same network as the production network. This allows for an easier initial setup of the environment as there will be no need to create an additional Active Directory infrastructure, use additional network equipment or worry about physical separation.
Pros
• Cheaper – no additional network equipment
• Easier – no separation or special network routing needed.
Cons
• No separation
• Some care needed in setup of users and Azure AD Connect set up for the different environments.
• Restoring data a bit more difficult and may require more manual work.
Caveats
• Two Azure AD Connect servers will be needed. One to sync the QA users to the QA Office 365 tenant and one to sync production users to the production Office 365 tenant.
• Additional domain will be added to the Production domain.
Configuration Option 4
Option 4 would only require a separate AD Forest to handle the separation of data and AD issues that could occur in other scenarios. Configuration Option 4 is perhaps the best way to perform testing as we can still duplicate data, mailboxes, users and more without causing issues in the production AD/Exchange.
For All Scenarios
Manual work examples:
(1) Active Directory
PowerShell can be used to export a list of users and all of their respective properties to a CSV file. This same file can then be used to duplicate this user base in the same AD Forest or anew forest depending on the Option chosen above.
(2) Exchange
Exchange mailboxes can be exported and restored via PowerShell. Keep in mind that if restoring users to the same AD, that even if there is a separate server hosting these users, they will be in the same Exchange. This could lead to other issues with QA users showing up in the GAL. So testing this will be planned out carefully to consider the effect or resting mailboxes, for QA purposes, into a production environment.
