A healthy Exchange Hybrid environment is vital for any organization looking for a stable and rapid migration and essential for those organizations expecting to stay in Hybrid mode for more than a very short period.
Microsoft’s FastTrack Onboarding center is excellent at providing enough guidance to get a customer’s Exchange organization ready to move a mailbox, but there’s a reason why it’s advisable to do more than just the bare minimum. Being able to safely move a mailbox doesn’t necessarily mean the Hybrid environment will meet your internal business requirements during coexistence or plan for anything non-standard.
In this article, I’ll walk through reasons why it’s important to have a healthy Hybrid environment, some of the basic tasks you can perform to understand the environment, simple tests you should run and what areas you should collect data from. I’ll then show you how to use that data at a high level to pick out the most valuable and critical tasks to get your Hybrid healthy.
An ad-hoc implementation approach versus a formal design
If you are running Exchange Server 2010 or above in your environment, you already have the basic components necessary for Exchange Hybrid installed but not configured in your environment. This means you can add Hybrid into the existing environment fairly easily with the right advice.
Performing just the minimum steps to enable Hybrid is a good approach for smaller organizations because if you only have a couple Exchange servers, there’s likely only one good way to implement Hybrid. In such circumstances, an ad-hoc approach of performing some remediation steps, running the Hybrid Configuration Wizard and then performing troubleshooting until it (just about) works might be OK. Self-supporting customers using the Onboarding Center report this kind of experience, but if you’re working with a slightly larger user base, this might not fit.
When planning to eventually move all mailboxes to Office 365, it can seem counter-intuitive to write out a design for Exchange Hybrid. After all, Microsoft has designed and built Exchange Online already. As most email admins will agree, mail is one of the most critical communications channels within an org (whatever Yammer fanboys say!) therefore it’s not something to just guess at. I often liken the Exchange Hybrid design to building a bridge. It is connecting two existing environments together and needs to be able to handle the traffic we put across it.
If you have started off with an ad-hoc approach but have some nagging worries keeping you up at night before your migration starts – or already see issues you didn’t expect – giving your Hybrid environment a bit of a health check might be a wise idea.
Understanding your Hybrid environment
Getting to know your Hybrid environment starts with understanding the surrounding Exchange environment, Active Directory and respective Office 365 tenant. To help get you started, I’ll cover a couple tools to help collect data.
If you aren’t using a tool to monitor your environment at present, you can use my Exchange Environment Report to gain a little insight into your installed Exchange servers. You can download it from the TechNet Scripting Gallery:
The report will give you a better understanding of the scale of the existing environment and will be crucial when understanding how much data you need to plan to move.
Next you need to understand if the Hybrid Configuration matches the actual environment. Use the Get-HybridConfiguration cmdlet to obtain the current configuration. In particular, you want to understand which servers are being used for Hybrid Mail flow and which domains have been configured for Hybrid:
Compare and record this information against both the organization’s on-premises accepted domains and the Office 365 tenant’s accepted domains. Check that connectors both inbound and outbound match the configuration and the organization’s requirements.
Often the configuration will not match what has been actually applied. Sometimes this is because changes have been made after implementation, but other times, this can be because the wizard failed but certain things worked – so people moved on.
Have a read through the log files – typically in the following location – and see if errors are shown:
C:\Program Files\Microsoft\Exchange Server\V15\Logging\Update-HybridConfiguration
If you see a number of errors in the latest log files, you can be sure there are some issues that have not been cleaned up. Use the following Microsoft tool to analyze the logs:
You’ll also want to perform some testing to understand what does and doesn’t work. These tests should include the following for the most basic tests:
- Verify directory synchronization is populating the full global address list.
- Verify all in-scope users to migrate have the tenant routing address added (e.g. email@example.com)
- Test creation of on-premises and Office 365 users via on-premises Exchange and ensure they are visible in both GALs.
- Verify the same policies have been created that already exist on-premises, for example, in-place hold, mobile device and unified messaging.
- Test basic mail flow and verify that mail is TLS-secured.
- Test internal and external out of office auto replies work as expected between on-premises and Office 365.
- Test the route for inbound and outbound mail both for on-premises and Office 365 mailboxes works as expected.
- Test availability in both directions between on-premises and Office 365 mailboxes.
- Test federated calendar sharing works as expected for all users.
- Test public folder access functions as expected, if configured.
- Test Outlook and other rich client setup experiences work as expected for new mailboxes.
- Test integration of third-party tools, such as Outlook add-ins or Skype for Business.
- Test mailbox moves for functionality and throughput.
- Test post-migration experience for mailboxes from an end-user perspective – both to the cloud and when testing off-boarding.
Collate the data you have amassed from the environment so it is easy to align to both the business requirements (e.g. high availability, service-level agreements or expectations for the migration speed). A typical first step when I perform a health check is to get this raw data together in what is likely a long document.
The full scale of this information can include not only the above but also:
- Business requirements such as SLAs
- Datacenter and Office location information
- Network diagrams and usage information
- Active Directory domain and forest information
- Active Directory site and subnet information
- Active Directory server and role information
- Active Directory DNS information
- Active Directory UPN information
- Results from IDFix tools
- Configuration information for Azure AD Connect, Azure AD Sync, DirSync and/or Active Directory Federation Services
- Multi-factor authentication system information
- Networking and Forward Proxy information
- Reverse proxy and load balancer information
- Exchange environment report information
- Exchange Internet facing sites
- Exchange internal and external URL information
- Exchange receive and send connectors
- Exchange-accepted domains
- Mailbox size distribution
- Shared mailbox and delegate information
- Public Folder infrastructure
- Mail spam filter solutions and gateways
- Archiving software
- Third-party add-ins, like signature software
- Unified messaging configuration
- Office 365 licensing information
- Office 365-accepted domains
- Office 365 Hybrid configuration
- Office 365 Migration Endpoints
- Assessment of migration speeds
- Client information including OS, Office version and third-party clients
- Mobile device information and MDM solution configuration
Forming a remediation plan
The information collected isn’t that useful as-is. It needs to be reviewed to look for inconsistencies or areas where it doesn’t meet the business requirements. A great approach for marking off critical areas is to use a Red/Amber/Green (RAG) report format with references to the raw data.
You’ll see in the report below that I reference the section, issue, impact, severity and RAG and a recommended action:
Choosing top priority tasks
Not all issues will need to be corrected. It may be that some issues – for example, low priority issues – may be left as-is. Other issues with the existing environment might be the reason for the migration to Office 365 and cannot be fixed easily.
Therefore, it’s important to prioritize. Choose the remediation tasks that are critical to support the Hybrid migration before focusing on the trivial tasks. View the big picture and deal with the big areas of risk first. Often the default position of a Project Manager might be to add everything identified in the report onto the project’s issues list. It might be that some issues will not need to be fixed and can be safely ignored.
A healthy Exchange Hybrid environment is a necessity for all but the simplest migrations to Office 365. Collect data about your environment to give you the wider picture and then pick out the issues to tackle that will help best accelerate your migration or are essential to the project’s success.