Figure 7.1 Exchange Online hybrid high-level infrastructure overview
Chapter 7
Exchange 2013 Hybrid Coexistence with Office 365
Exchange hybrid is the term used when an Exchange organization running in a customer or partner datacenter is connected to Microsoft Office 365. This configuration provides an extremely rich coexistence feature set that allows mailboxes to be hosted on-premises or in Office 365 while the end-user experience remains virtually the same.
This chapter discusses why you may want to evaluate Exchange hybrid, design considerations of this configuration, and tips from real-world deployments to help ensure that your Exchange hybrid project is a success.
Before we discuss Exchange hybrid, we should briefly touch on Office 365. Office 365 provides cloud-based versions of some of Microsoft's major products, including Microsoft Office, SharePoint, Exchange, and Lync. In this context, the term cloud essentially indicates services that are hosted by someone else (Microsoft in this case) and that you can access over the Internet.
The services hosted by Office 365 are fundamentally the same as those that you can run in your own datacenter, with some slight differences. Microsoft adds the word Online to the names of these services so that Exchange becomes Exchange Online and SharePoint becomes SharePoint Online. These services are also generally abbreviated. Exchange Online is abbreviated as EXO, SharePoint Online is abbreviated as SPO, and so forth.
One of the main benefits of an online service is that you can take advantage of its continuous improvements as the feature set is enhanced. To simplify matters, each service has a fairly well-defined description.
Service descriptions for each service can be found at the following URL:
http://technet.microsoft.com/en-us/library/jj819284.aspx
Figure 7.1 shows a typical Exchange hybrid infrastructure. The services required for Exchange hybrid will be discussed in more detail later in this chapter.
Figure 7.1 Exchange Online hybrid high-level infrastructure overview
Exchange Online is a multi-tenant messaging system. This means that customers have their own area within the Exchange Online service. Nonetheless, the servers that provide the services are shared with other customers. This is part of the reason why Microsoft can offer the service at such a low cost. From a customer and end-user perspective, however, the tenant that you are provided looks and feels like a totally isolated Exchange organization. That is, although the platform is shared, each tenant is a discrete and isolated instance of Exchange Server. Before you can begin to work with Exchange hybrid, you must have an Exchange Online tenant.
Directory Sync (DirSync) is the process responsible for reading the local Active Directory and creating matching accounts in your Office 365 tenant. DirSync also copies attributes required to maintain a common global address list, across the entire organization. This process is discussed in Chapter 14, “Migrating to Exchange 2013.” DirSync is also responsible for ensuring that the accounts created in your Office 365 tenant will be able to authenticate via your on-premises Active Directory Federation Services server.
AD FS provides single sign-on (SSO) to Office 365. This means that a user needs to remember only a single account name and password that is stored in the local Active Directory; this is known as identity federation. When a user tries to log on to a mailbox hosted in their Exchange Online organization, they must first authenticate to the on-premises AD FS infrastructure. From an end-user perspective, the same account name and password are used to access local resources and resources hosted in Office 365.
A hybrid server is a standard, on-premises Exchange server that is being used to pass coexistence data between the on-premises Exchange servers and the Exchange Online service. This data might include email messages or availability data, such as when someone is free or when they are in a meeting. The hybrid server is also used to migrate mailboxes from on-premises to Exchange Online and vice versa in a hybrid configuration. The best way to think about the hybrid server is as the glue between your on-premises infrastructure and your Exchange Online infrastructure.
The External Publishing Infrastructure icon in Figure 7.1 refers to any infrastructure used to publish your internal servers to the Internet or provide Internet access for your end users. For Exchange hybrid to work, Exchange Web Services (EWS) and Autodiscover should be published to the Internet via some form of publishing infrastructure, such as a reverse proxy server, or directly via a load balancer. Additionally, client machines that are using Exchange Online will need to be able to connect to the service via the Internet quickly. For enterprise and small customers, this area often requires significant change to accommodate Exchange hybrid. We will discuss some of the design and deployment challenges later in this chapter.
One of the problems with Exchange hybrid is the hype that surrounds any cloud-based product or service. If you believe the hype, Exchange Online will cost virtually nothing, never fail, protect your data in the event of a disaster, dazzle your end users with added functionality and ease of use, upgrade itself automatically, and generally provide your organization with email nirvana. You can hear such sales claims at many Office 365 marketing events extolling the virtues of Exchange Online.
The reality, of course, is that, like most technologies, there are benefits to using Exchange Online as well as trade-offs; that is, you may gain some benefits by moving to Exchange Online, but you may also lose some flexibility and/or features. If you can handle such trade-offs, then you may stand to be in a better situation. However, as is true with all design decisions, in order to choose wisely you must know your requirements and define how you are going to meet them. In this instance, the most common approach is to work through your requirements and then search through the Office 365 service description documents to find evidence that they will be met effectively.
Exchange Online provides many benefits. Some of the main ones are stability, cost effectiveness, evergreen service contracts, and near-universal connectivity.
One benefit of Exchange Online is that the service is designed and operated by the Microsoft Exchange Product Group. This is the same team that writes the code for Exchange and operates and runs the Exchange Online service. Because of this, the developers who are responsible for specific features get to deal with problems in their own code firsthand, and they can then fix issues with better context in future product updates.
Because of the scale of Exchange Online and shrewd operations processes, it is relatively inexpensive to run Exchange Online. This reduction in cost is passed on to customers. For example, the E1 plan, which provides SharePoint 2013 Online, Lync 2013 Online, and Exchange 2013 Online, includes a 25 GB Exchange mailbox that costs $8 per user per month. For a 500-user organization, this works out to $48,000 annually. This cost is predictable, and it includes continuous upgrades.
Another common benefit occurs when an organization needs to expand for a specific time period, such as for a big event. An on-premises customer would need to grow their infrastructure, which is very costly. An Exchange Online customer would just need to add more mailboxes, pay the per-month price per mailbox, and then close the accounts when the event is over, paying only for the resources they require.
With an evergreen service contract, Microsoft automatically upgrades your Exchange service, free of charge, as soon as updates or new versions are available. For example, Microsoft upgrades Office 365 and all of the services it provides on a quarterly basis. An evergreen contract also includes major software version upgrades such as Exchange Server 2013. Customers are notified of the upgrade and any potential changes that they must make to prepare for the move. During the upgrade, the customer's data is moved over to the newer service platform. This is very appealing when compared to an on-premises migration.
Exchange Online is Internet based, and it supports all major client protocols. This means that you can connect to the service from virtually any operating system and use virtually any mail client. The provision of an always-on, always-accessible collaboration platform is great news for many customers who face the demands of a diverse and dispersed workforce, all wanting to use their own devices to access their data.
Adopting Exchange Online also has its downsides. We will now address the drawbacks of the same issues we just discussed.
Office 365 has had its fair share of service outages since its initial launch, though not all of these outages have impacted Exchange Online. These outages tend to be relatively short, that is, hours and not days. They usually impact only a subset of tenants. Nevertheless, if you are affected, you may be frustrated by the fact that there is nothing you can do about it because you are held accountable for a service outage over which you have no control. Microsoft is generally transparent about issues within Exchange Online and how to remediate them. They will also waive service charges when the service fails to meet its agreed-upon service levels. For most businesses, however, this is of little consolation because they would prefer to have a working service.
The trade-off in this area is not necessarily about total service availability—it's about control or the illusion of control. Many IT teams sense a need to retain control over the level of service that they provide. The reality is that few organizations can match or beat the service availability provided by Exchange Online. For many customers, however, the act of handing over control to a vendor is a tough pill to swallow. For others, the difficulty comes from a lack of direct involvement with the resolution process. For example, senior management may feel the need to help IT teams directly resolve problems.
Such positions are often unsubstantiated and based mainly on emotion. If a customer is presenting you with these types of objections to Exchange Online without quantitative evidence of service availability, then they just may not be ready for a cloud-based service. In our experience, these customers may benefit from a proof of concept or small production pilot to become accustomed to the differences via a hands-on process. Often, the initial pushback on cloud-based services is simply a fear of the unknown.
Cost is without doubt the most common benefit that is touted for Exchange Online and Office 365 as a suite. However, it is not a given that it will always be cheaper. Large organizations often get discounts on hardware, and if their Exchange solution is based on cheap storage and commodity servers, then it is possible to provide a cost-effective Exchange solution on-premises. The real differentiator centers on operations costs and dependencies. Taking advantage of this cost saving, however, often requires a reduction in head count. Although possible, this is rarely achieved in practice. The most common scenario is that staff who previously were engaged in supporting the Exchange infrastructure are instead moved to support the Exchange Online dependency infrastructure, such as AD FS, DirSync, and Information Rights Management (IRM) solutions.
The upshot of this is that it is sometimes difficult to make a compelling business case for Exchange Online based purely on cost, especially if the business case does not include Lync Online and SharePoint Online, since the cost benefit of Office 365 is much harder to obtain without using the entire suite of products you are paying for.
An evergreen service contract sounds like a great thing. Microsoft will automatically upgrade your Exchange service at no cost as soon as updates or new versions are available. There is a catch here, however—client supportability. As Exchange is upgraded, the supported client versions are often changed. Sometimes this may require a service pack upgrade, as it does for Outlook 2007 support with the version of Exchange Online released in 2013. Client support, however, is sometimes dropped, as it was in 2010 for Outlook 2003 in the upgrade from the Business Productivity Online Suite to Office 365.
An updated list of software requirements for Office 365 can be found at the following URL:
The impact of using an evergreen service will vary from customer to customer. However, as a general rule, it means that all clients that use Exchange Online must have automatic updates enabled, and, more importantly, the organization must have a desktop upgrade program in place that is in lock step with Office 365.
Desktop upgrades can be disruptive and time consuming. Therefore, moving to Exchange Online requires strategic planning of the desktop. This topic is often not discussed during deployments, and it can come as a shock to customers when they receive their tenant upgrade notification and discover that they need to upgrade their operating systems and Office software within 12 months, which was neither planned nor budgeted.
Google is often criticized for making sweeping changes across their free and paid-for services, because such changes result in widespread user confusion. Microsoft takes a more enterprise-friendly approach to service upgrades. They usually introduce subtle feature changes and stability improvements on a quarterly basis and reserve more significant changes for major service upgrades, typically annually.
Exchange Online offers broad connectivity; that is, you can connect to it from anywhere in the world where you have an Internet connection. This has to be a good thing, right? Again, this depends on requirements. Some organizations encourage sharing of their data and let their employees connect their preferred devices to perform tasks, while others are much more restrictive about sharing their data and how it is accessed. For example, financial, insurance, security, government, and pharmaceutical companies are often conflicted about whether to allow their employees to use their own devices globally. Moreover, they are extremely concerned that someone outside of the organization might improperly gain access to their data.
The result of this conflict of requirements is that projects try to provide open access to services but also to restrict access to data. Historically, customers achieved this by deploying multifactor authentication systems and generally making remote access of their services exceptionally difficult. Moreover, once the Exchange service is moved out to Exchange Online, it becomes even more difficult to control access.
The following URL lists some steps that can provide some level of control:
http://technet.microsoft.com/en-us/library/hh526961(v=ws.10).aspx
The reality is that controlling data leakage by restricting access is complicated, expensive, and simply does not align well with an Internet service such as Exchange Online. Instead, use an Information Rights Management product, such as Active Directory Rights Management Service (AD RMS), to provide a more scalable and dependable solution. If neither of these solutions is appropriate, then perhaps Exchange Online is just not the right solution for this customer.
In the early days of Office 365, the perception was that there was no need to design for it; that is, as the customer, you just need to click a few buttons, enter your credit card details, and you're all set.
Obviously, this is not correct, and even though Microsoft has provided a large portion of the Exchange service design, you still need to think about some of these design considerations when Exchange Online is part of the solution.
Many consulting firms will perform a solution alignment workshop for Office 365 deliveries. This process compares identified customer requirements to the corresponding Office 365 service descriptions in order to check that all requirements can be met. Additionally, the Office 365 dependencies, such as minimum client software versions, Active Directory, and network connectivity requirements, are discussed. Only when all of these discussions have taken place will the actual design and delivery work begin.
As we discussed in Chapter 1, “Business, Functional, and Technical Requirements,” requirements form the fundamental building block of all design projects. If you do not know what the solution is required to do, then how do you know if the result is a success or failure? Moreover, how do you ensure that a design is fit for a given purpose if that purpose is not defined?
Requirements elicitation is no less important just because Exchange Online is part of your design. In fact, having precise requirements becomes even more important. Exchange Online has a service description that defines what it will and will not provide. If you discover a requirement in the middle of a project that Exchange Online cannot provide, then you have some difficult decisions to make. For example, do you abort the project and revert to an on-premises solution or simply fail to meet that requirement? This issue is at the heart of most customer dissatisfaction complaints with Exchange Online. Customers simply assumed that it would do what they needed it to do, and they only found out too late—after they had migrated—that it didn't meet their objectives.
Thus, whenever Exchange Online or any other aspect of Office 365 is in your solution design, be precise with your requirements definition. The requirements that you identify can then be compared against the Office 365 service descriptions, and any gaps are thus highlighted early on in the design process. Gaps can then be discussed and evaluated against the priority of the underlying requirement. For instance, is the requirement mandatory, or do you have any flexibility to change or drop it?
Be prepared to think creatively at this stage because many organizations have a predetermined operational and design philosophy that will need to be overcome before they are able to consume Exchange Online.
Once you have a clearly defined and agreed-upon set of requirements, you can begin the solution design process. Contrary to popular belief, this can often be more complex for an Exchange Online hybrid solution than for an Exchange on-premises solution. This is due to the huge wealth of experience that exists for designing and deploying Exchange on-premises solutions compared with the relative inexperience, even among the best consulting firms, with large-scale Exchange Online designs. There are also areas within an Exchange hybrid design that will be unfamiliar to many Exchange design teams, such as dealing with a large-scale Internet proxy bypass or the intricacies of network link topology and the variation of connectivity costs around the world.
The design also needs to focus on calculating service levels of combined services. For example, if Exchange Online provides 99.9 percent availability, your Internet service provider provides 99.9 percent link availability, and your firewalls are also 99.9 percent available, what is the maximum service level that you can provide to your end users? See Table 7.1 for a quick overview of how to approach this question. The percentages of availability of dependent services are multiplied together to show the combined service availability; that is, 99.9 × 99.9 × 99.9 = 99.7. In this case, combining three services that are each a fundamental part of providing service to the end users results in an overall maximum service availability level of 99.7 percent.
Table 7.1 Combining service availability
| Service | Availability | Downtime (Hours per Year) |
| Exchange Online | 99.9% | 8.76 |
| Internet service provider | 99.9% | 8.76 |
| Firewall service | 99.9% | 8.76 |
| Total | 99.7% | 26.28 |
The bottom line is that the solution design process for Exchange hybrid is exactly the same as for an Exchange on-premises solution. The design team must ensure that the solution can meet all of the requirements and that it will be operable and deployable within the customer's infrastructure and timescales. In reality, the focus of design attention switches from Exchange high-availability, storage, and performance to network link performance, latency, security, firewalls, and service availability. There is no less design work to be done. Rather, it involves different areas of technology than for an on-premises design. The most important thing to remember is that the design process remains the same—the solution design is created to meet the requirements.
A proof of concept (POC) is often used to showcase a potential design to the customer so that they can see exactly what will be delivered. One important thing to keep in mind when planning a POC is to know what you are trying to achieve. Many POC demonstrations deliver a perfect example of something that the customer is simply unable to achieve. For example, the POC is based on Windows 8 and Office 2013, whereas the customer is tied to Windows Vista and Office 2007 for another few years.
Try to define the success criteria for the POC after consultation with the customer. Find out what they want from the environment, and agree how best to present it effectively. Also remember that reality is often different than what the documentation suggests. Physically building and deploying a POC environment is a great way to expose problems and construct solutions early on in the design process.
For an Exchange Online hybrid POC, concentrate on the things that are special about a hybrid solution. The POC does not have to be feature complete—it could be used solely to demonstrate certain key features of the solution. Often, this might include the on-premises users sharing calendar availability data with users in Exchange Online or demonstrating data leakage prevention in action.
Do not confuse a POC with a pilot. A pilot is usually a feature-complete deployment, normally in or connected to the customer's production infrastructure. Real business users are moved over to the pilot with the goal of getting feedback on the use of the solution to share with the rest of the organization. Frequently, Office 365 documentation will refer to a production POC, which is actually better described as a pilot rather than a POC.
As with any solution deployment, planning and preparation are required to ensure a smooth deployment. By far the most detailed walkthrough of configuring an Exchange Online hybrid deployment is from Henrik Walther. It is available at this address:
Additionally, Microsoft provides OnRamp for Office 365, which is an automated assistance tool that helps you gather configuration requirements and perform deployment readiness checks on your on-premises environment; see the following address:
http://technet.microsoft.com/en-us/library/jj993929.aspx
The following sections discuss high-level tasks that you should consider for your deployment of Exchange hybrid.
You should perform a client inventory as part of your Exchange deployment planning. This is equally as important for Exchange Online as it is for Exchange on-premises. You need to understand what clients are in use and then evaluate their suitability for Exchange Online. Clients may potentially need remediation or to be upgraded to ensure success.
Exchange Online Directory Sync (DirSync) synchronizes Active Directory objects with the cloud. However, there are differences between allowable field values in your Active Directory and the directory service used within Office 365. Because of this, you should identify any Active Directory objects that have invalid entries and remediate them prior to beginning DirSync. Otherwise, you will need to remediate these errors post-DirSync installation, which is both time-consuming and tedious. Thankfully, Microsoft provides a tool called IdFix that identifies and remediates objects in the directory before installing DirSync.
IdFix is available for download at this address:
http://www.microsoft.com/en-us/download/details.aspx?id=36832
Microsoft provides Office 365 tenants free of charge for POC and pilot use. Anyone can request a free 30-day trial tenant. Microsoft will also extend these tenants in the event that the POC or pilot duration goes beyond 30 days. The tenant can then be converted to a fully paid service if the customer chooses to purchase Office 365.
The address for the free Office 365 Enterprise E3 trial is as follows:
http://office.microsoft.com/en-us/business/office-365-enterprise-plan-e1-FX103887102.aspx
To use your new Office 365 tenant effectively, you will need to register your DNS domains. The process is relatively straightforward, and it requires that you perform some action within the DNS zone to identify yourself as the owner of that domain. This can take a few days to get right, however, especially if you have to pass the DNS change request on to a third party.
As a general rule, do not use your production domains in your trial tenants since it can be difficult to remove them later, and this can lead to delays when deploying into production. Instead, it is preferable to use a totally separate domain for POC testing against a trial tenant and then switch over to the production domains on the paid tenant once it is available.
Once the tenant is ready and DNS domains are registered, you should enable Active Directory synchronization. Do this as soon as possible, since it can take a day or so to switch on after enabling it in your tenant.
Internet access can be one of the biggest changes between an Exchange on-premises design and a hybrid or full Exchange Online design. Once the mailbox has been moved to Exchange Online, the clients no longer access the Exchange server via the local network infrastructure alone and instead must traverse the Internet. In the early days of Exchange Online, proper attention was not paid to the design that was required, and this led to Outlook client traffic being processed by the same Internet proxy servers that handled all other Internet traffic, such as Facebook and Google.
Network latency is a critical part of the end-user experience. High network latency can cause significant delays in client responsiveness. The Internet proxy server is now adding to the network response time between Outlook and Exchange Online. To make this even more complex, the usage pattern for Internet proxy infrastructure generally has several spikes throughout the workday; that is, it rises dramatically first thing in the morning, during breaks, and at lunch time.
We strongly recommend spending some time to design a proxy bypass solution that directs traffic to Exchange Online as directly as possible via the best possible route, bypassing the Internet proxy server infrastructure. This both improves Outlook client responsiveness and reduces unnecessary load on the Internet proxy servers.
A current list of URLs and IP addresses in use for Office 365 is found here:
http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh373144.aspx
In addition to client Internet access, a hybrid design also requires that Exchange Web Services and Active Directory Federation Services are correctly published and that the Directory Synchronization server has Internet access. There are many ways to publish web-based applications to the Internet securely, such as via Microsoft's Unified Access Gateway (UAG) or F5's BIG-IP appliance.
For UAG publishing information, refer to the following article:
http://blogs.technet.com/b/exchange/archive/2010/07/16/3410408.aspx
For F5 BIG-IP publishing guidance, refer to the following article:
http://www.f5.com/pdf/deployment-guides/f5-exchange-2010-dg.pdf
Deploying Office 365 Directory Sync is a fairly straightforward process for most organizations. Microsoft has automated the installation and simplified the configuration process for Forefront Identity Manager (FIM) to work with a single Active Directory forest and Office 365 tenant. The process is typically as simple as installing DirSync and then providing it with the credentials to access the local Active Directory and your Office 365 tenant. DirSync will then begin the synchronization process.
A few common problem areas with DirSync are presented in Table 7.2.
Table 7.2 DirSync deployment common problems
| Issue | Notes |
| Access requirements | To install DirSync, you must provide the installation process with an enterprise admin account. This is a highly privileged account in the local Active Directory, and many customers are a little uneasy about doing this.
It often helps to explain to customers that this account is not stored in the DirSync server, and it is only used during setup to create the MSOL_AD_Sync account in the forest root. Further information can be found at the following address: http://community.office365.com/en-us/wikis/sso/565.aspx |
| Tenant account expiry | During setup, the installation process will ask for an administrator account in your Office 365 tenant. This is used to create account objects. However, the default password expiration timeframe in Office 365 is 90 days. This of course means that DirSync will stop working every 90 days, and it will require that you reset the password.
There are two ways to deal with this: either remember to change your password and reconfigure the DirSync account every 90 days, or use a specific account for DirSync that is set never to expire. The instructions for setting up a DirSync service account that never expires can be found here: http://blogs.technet.com/b/neiljohn/archive/2011/09/05/office-365-service-accounts-how-do-i-stop-dirsync-from-breaking-every-90-days.aspx |
| Proxy server configuration | DirSync requires an Internet connection so that it can communicate with your Office 365 tenant. However, many organizations still enforce authenticated proxy servers. The following article discusses some ways to check the proxy configuration:
http://support.microsoft.com/kb/2517393 |
| DirSync object limit | By default, all Active Directory objects are considered for synchronization to Office 365. For larger customers, this may not be desirable. To understand how to filter objects in DirSync, see the following article:
http://technet.microsoft.com/en-us/library/jj710171.aspx If you need to synchronize more than 50,000 user objects, you will need to contact Office 365 support and request an increased DirSync limit. Also, you will need to use a full version of SQL Server 2008 rather than SQL Express for your DirSync database. |
| Domain controller unavailable | During the setup of DirSync, it will try to communicate with all domain controllers in all domains within the Active Directory forest. Make sure that the server on which you are installing DirSync has connectivity throughout the organization and that all domain controllers are online. |
As we have discussed, single sign-on requires that both DirSync and AD FS be installed in order to work. AD FS is usually split into two server roles: the AD FS server and the AD FS proxy server. The AD FS server is installed into Active Directory and configured as a farm. This allows multiple AD FS servers to be configured to provide fault tolerance. The AD FS proxy server is installed into the perimeter network and handles the secure publishing of the AD FS server farm to external clients or resources.
The most common problem during AD FS server installation and configuration is not having the correct certificates installed during the process. Make sure that you have requested your AD FS server certificates, that they have the correct names on them, and that they are correctly installed. Fixing problems caused by incorrect certificates and names is tricky, so spend a little extra time to get it right the first time.
The best source of information for AD FS deployment can be found at the following URL:
http://technet.microsoft.com/en-us/library/jj151794.aspx#bk_deployfsfarm
Back when Exchange hybrid was first launched with Exchange Server 2010, there was a checklist of more than 80 configuration steps that were required to get Exchange hybrid to work. Fortunately, Microsoft recognized that this was too complicated a process so they committed to the creation of a Hybrid Configuration Wizard. This wizard was first introduced in Exchange Server 2010 SP2. It is for this reason that we strongly recommend using a minimum of Exchange Server 2010 SP2 for your hybrid server.
If you are using a new Office 365 tenant that includes Exchange Server 2013, then you must use Exchange Server 2010 SP3 or Exchange Server 2013 CU1 as your hybrid server.
The Exchange Server 2013 CU1 version of the Hybrid Configuration Wizard has the following improvements over the Exchange 2010 version:
More information about these upgrades can be found at the following URL:
http://technet.microsoft.com/en-us/library/jj200790(v=exchg.150).aspx
Although the Hybrid Configuration Wizard simplifies the configuration process, it performs many actions “under the covers.” Our advice is to read and reread the wizard prerequisites and make absolutely sure that you have met all of its dependencies before running it for the first time.
The TechNet guidance for the Hybrid Configuration Wizard can be found here:
http://technet.microsoft.com/en-us/library/hh529921.aspx
The following summarizes the prerequisites that must be completed before running the Hybrid Configuration Wizard:
There are some common customer requirements that can mean that moving to Exchange Online is not viable. We will now discuss some of the more common problem areas and some potential solutions:
The standard version of Office 365 DirSync will only work with a single Active Directory forest. This can be a problem for many organizations, and it is something that many enterprise customers will need to solve before they can deploy Exchange hybrid. The primary method for solving this problem is simply to merge all of your Active Directory forests. Obviously, this is a non-trivial task and it is typically a project in its own right.
Nevertheless, there is a supported solution for Office 365 and multiple Active Directory forests with DirSync. The solution is to engage with Microsoft Consulting Services (MCS), which can help you deploy a custom version of Forefront Identity Manager (FIM) with the Microsoft Online management agent. Although this is a paid engagement, you do get a custom deployment of FIM, which might come in handy.
If your solution requires single sign-on, then you will need to deploy Active Directory Federation Services and DirSync. DirSync is required to synchronize your Active Directory objects to the Office 365 service, and AD FS is required to authenticate users and provide access to the Office 365 resources, as covered previously in this chapter.
One thing not addressed previously is that when you log onto Office 365, you need to use the User Principal Name (UPN) for your account. Typically, this is made up of your Active Directory forest name and your logon name. For example, my logon name might be neilj and my forest might be company.local, so my UPN would be neilj@company.local. The problem here is that Office 365 requires that you register your domain in public DNS so that you can verify ownership. Obviously, you cannot verify company.local since .local is not a valid public DNS domain. To make life slightly more difficult, Microsoft has recommended using .local or .ad for a little over 10 years, so the likelihood of coming across this situation is quite high.
The solution here is to rename the UPN to something that is a valid DNS domain (that you own). Therefore, my neilj@company.local account might become neilj@exchanged3.com instead. Changing UPNs in bulk can be done easily via ADModify, which is available at the following URL:
It is not always quite as simple as just changing the UPN, however. The UPN is often used to match certificates to user accounts via an Active Directory Certificate Authority. If end-user certificates are being issued via User Principal Name mapping, then when the UPN is changed, the certificates must be reissued at the same time. This will require some additional planning, and additional time should be included in your deployment if you need to change UPNs and reissue user certificates.
Data sovereignty is the concept that data stored in a specific location is governed by the laws and taxation of the country in which it resides. Fundamentally, this idea is used to protect data and reduce tax bills. This concept is most commonly applied in finance, insurance, and pharmaceutical organizations that will typically have datacenters in countries such as Luxembourg, Switzerland, Bahamas, Cayman Islands, and Monaco where either the tax rates are lower or the law provides a level of banking privacy that makes storing money or data in that location beneficial.
There have been many discussions about the actual benefits of data sovereignty. The reality is that, given a serious enough offense, even a Swiss bank will hand over financial data if a “lifting order” is granted by a judge. Likewise, many governments have the right to seize data from companies that operate within their jurisdiction, which is often cited as a reason to store data offshore to prevent information from being seized. However, the reality is that most countries have rights to seize data from wherever it may be if there is supporting evidence to suggest that it is in the interest of national security (or is being located there to evade payment of taxes).
Despite this, almost every financial, insurance, or pharmaceutical company still insists on this method of data security. These types of organizations are extremely protective of their data, and getting their IT risk departments to approve a change of sensitive data location is an uphill struggle.
This is a problem for Office 365 since each tenant can only exist physically in one geographic region, that is, North America or Europe or Asia. You cannot have a tenant that spans these regions—you have to pick one at the time of tenant creation. (Office 365 actually uses the address that you type in to determine the best location for the tenant.)
Luckily, this is where Exchange hybrid comes in. Typically, only a fraction of the users in any organization that requires data sovereignty will in reality be affected by that requirement. This means that if, for example, 20 percent of the users have to keep their data in a specific location, then 80 percent of the users could be moved to Office 365. This model allows for a reduction in on-premises infrastructure while still meeting the organizational data sovereignty rules.
Data leakage refers to the unapproved distribution of data. This may occur within the organization or externally. The news is often littered with companies that have lost sensitive data. Such examples include the British Ministry of Defense, which reported that 340 laptops had been lost or stolen between June 2008 and June 2010, and the loss of details about 1.2 million federal employee bank accounts by Bank of America in 2005.
Microsoft Office 365 is compliant with world-class industry standards, including ISO-27001, EU Model clauses, HIPAA-BAA, and FISMA, and it is verified by third-party auditors. However, when customers are presented with the paradigm shift of storing their data somewhere other than in their own datacenters, they are often a little uneasy about this prospect and want to understand how they can better protect their data. Often, the discussion of controlling data leakage is something that should probably have occurred many years earlier, and Office 365 is simply the catalyst that encourages a decision to be made.
The solution to data leakage is complex since it involves many factors. Imagine the differences between a lost laptop and an employee maliciously sending company confidential information to a competitor or to the press. Both constitute data leakage; however, one is accidental while the other is malicious.
The most common way to prevent data leakage with Office 365 is to integrate your tenant with an on-premises implementation of Active Directory Rights Management Services (AD RMS). This both encrypts sensitive data and controls who may access it, both inside and outside the organization. Bear in mind, however, that if someone really wants to share information with a competitor or the press, it is next to impossible to prevent it. Nevertheless, the likelihood of information getting into the wrong hands when storing your data in Office 365 is no worse than it is for an on-premises solution. If anything, you could argue that the Microsoft Office 365 datacenters are equally or maybe even more secure than most customer datacenters.
More information on using AD RMS for IRM with Exchange Server 2013 in hybrid deployments can be found here:
http://technet.microsoft.com/en-us/library/jj659052(v=exchg.150).aspx
As discussed previously in this chapter, Office 365 has a defined list of clients that are supported, especially versions of Microsoft Office. You should perform a client inventory to determine which clients you need to support. This also applies to Internet browsers if web-based services are being used, such as the Outlook Web App (OWA).
It can be quite difficult to deliver this news to customers who want to move to Exchange Online quickly, since it almost certainly means a fairly lengthy delay to their Exchange deployment project. However, it is also another area where Exchange hybrid can help. Hybrid allows some users to be moved to Exchange Online while others remain on the on-premises version. It also means that users can be migrated to Exchange Online as their client software is upgraded.
Of course, there is still the downside that the client or browser software needs to be upgraded at all. The reality is that customers eventually need to move forward to ensure security and a good user experience. Exchange Online is often just the catalyst that brings updates of client software versions into the discussion. Of course, some customers simply do not, or cannot, perform these types of desktop upgrades, and so this model may mean that they have to be very cautious about moving to Office 365.
Table 7.3 shows supported browsers and operating systems in Office 365. This table calls out that both Windows Vista and Windows XP will not be supported in Office 365 starting January 1, 2014.
Table 7.3 Client and software support in Office 365
| Operating Systems | Web Browsers |
| Windows 8 | Internet Explorer 10
Latest version of Firefox Latest version of Chrome |
| Windows 7 | Windows Internet Explorer 10 recommended
Windows Internet Explorer 9 Internet Explorer 8 Latest version of Firefox Latest version of Chrome |
| Windows Vista with Service Pack 2
(Support ends January 1, 2014) |
Internet Explorer 9 recommended
Internet Explorer 8 Latest version of Firefox Latest version of Chrome |
| Windows XP with Service Pack 2 or 3
(Support ends January 1, 2014) |
Internet Explorer 8
Latest version of Firefox Latest version of Chrome |
| Mac OS X 10.5, Mac OS X 10.6, or Mac OS X 10.7 | Latest version of Firefox
Safari 5 and later |
Table 7.4 shows which Office versions are supported by Office 365 and what updates each requires.
Table 7.4 Office version support in Office 365
| Version | Notes |
| Microsoft Office 2010 with Service Pack 1 | Customers who sign up for Office 365 after February 27, 2013 must apply all automatic public updates that were released before December 2012.
Customers who signed up for Office 365 before February 27, 2013 must complete the following: By July 1, 2013, apply KB2553248. By April 8, 2014, apply all automatic public updates for Office 2010 that were released before December 2012. |
| Microsoft Office 2007 with Service Pack 3 | Customers who sign up for Office 365 after February 27, 2013 must apply all automatic public updates that were released before December 2012.
Customers who signed up for Office 365 before February 27, 2013 must complete the following: By October 1, 2013, apply KB2583910. By April 8, 2014, apply all automatic public updates for Office 2010 that were released prior to December 2012. |
| Microsoft Office 2003
All versions |
POP3 and IMAP4 only.
For more information, see the following URL: http://go.microsoft.com/fwlink/p/?LinkID=254207 |
| Microsoft Office for Mac 2011 with Service Pack 3 | Mac OS X 10.6 operating system or later required. |
| Microsoft Office 2008 for Mac version 12.2.9 | Support ends April 9, 2013. |
This is one of the most misunderstood aspects of Exchange Online. For most people, the term single sign-on means not having to enter multiple passwords at logon. However, this is not strictly how it is applied in Exchange Online. Single sign-on in Exchange Online means that you have a single account and password, but it does not mean that you will not have to enter your password when you try to connect to Exchange Online. This is complicated further when we look at the authentication behavior for different client types. Typically, users accessing their mailbox via a web browser will experience true single sign-on in that they will not need to enter their password. Outlook, however, will prompt the user for a password. The user can chose to save their password, which will get rid of the password prompt until the user next changes their password.
This behavior is actually not a problem for most organizations, and although they would prefer that users not be prompted for passwords, the reality is that as long as the Exchange Online login name is sensible (their SMTP address, for example), they can usually manage to enter their password and click the Save Password check box without any concern. The problem arises when customer expectations are not set correctly at the outset and because the term “single sign-on” was taken literally and that customer expectation was never corrected.
Our advice here is to make sure that customers are aware of the potential change in user experience early on in the design process to give them time to get used to it. A POC can also help here. Demonstrating the actual logon experience to Exchange Online often alleviates any concerns. The bottom line, however, is that if a customer requires a seamless Outlook logon experience with no password prompts, then Exchange Online may not be the right solution for them.
Desktop virtualization has experienced a recent rise in popularity. At its most basic, Virtual Desktop Infrastructure (VDI) is the replacement of powerful desktop computers with lower-power consoles that provide a virtual desktop running on large-scale virtual server farms. This works nicely for most applications, and it allows an end user to move freely from place to place. Moreover, when the end user connects to their virtual desktop, it is exactly as they left it, which is a nice user experience.
There are some problems, however, with Outlook on VDI. When Outlook is connected to Exchange Online, it is strongly recommended that you use cached mode. Cached mode helps Outlook perform well even if the network link is slow or of poor quality. When connecting Outlook to Exchange Online, the traffic must pass through several layers of network infrastructure and the Internet. Thus, it is likely that periods of poor performance will be experienced. This recommendation for using Outlook in cached mode when connected to Exchange Online is in direct conflict with Outlook on VDI. With Outlook on VDI, it is strongly recommended that you use online mode to avoid the need to store all of that Outlook cached data on the VDI infrastructure, which would be extremely costly.
The options here are limited. VDI and Exchange Online are simply not a great mix of technology. The best solution is our old friend the Outlook Web App. This works nicely since OWA is relatively tolerant to network performance and does not have the same storage capacity requirements as Outlook in cached mode. However, this does assume that OWA will meet end-user requirements, which is often not the case. Alternatively, you could configure Outlook to use online mode. Our experience here, however, is that Outlook in online mode is very sensitive to network performance, and the client may appear to hang for several seconds during periods of poor network performance.
Exchange Online in a hybrid configuration offers many customer benefits, but it is a standardized service offering with fixed support and feature boundaries. The trick to ensuring a successful Exchange Online deployment is to define the requirements more precisely than usual and to make sure that the customer is aware of any changes in the user experience that will result.
Be realistic when considering design service levels. Try to calculate the maximum service levels that you can meet by considering all of the links in the chain. In most cases, the Exchange Online SLA of 99.9 percent availability is not achievable in reality when you include the service levels of your firewalls, network, and Internet connections.
Try to avoid being caught up in the excitement and marketing hyperboles for cloud-based services. They are not the answer to every problem in the IT world. The old adage “If it sounds too good to be true, it probably is” should be considered at every stage. There are many benefits to Exchange Online; however, there are many dependencies and constraints to address before you can use the service. Understanding what you are getting for your money, and what it is going to cost you in terms of dependency remediation, is vital to making the right choices for Exchange Online.
Once the design process has begun, it is important to remember that, although Microsoft has designed and deployed Exchange in Office 365, you still need to design and deploy the hybrid infrastructure and connectivity. Plan for your network bandwidth requirements, upgrade links, and firewalls as appropriate. Remember that you are materially changing the quantity and direction of network data traffic for your messaging service.
Perform a proof of concept and production pilot in complex environments to catch environmental issues with customer infrastructure and to demonstrate the actual end-user experience. This can help to alleviate the fear of change.
Before deployment, remember to run through the validation tools mentioned in the chapter to check that the environment is ready for Exchange Online hybrid:
http://www.microsoft.com/en-us/download/details.aspx?id=36832
Also, remember to use the Exchange Server Deployment Assistant, which will create a customized deployment and preparation plan for you.
http://technet.microsoft.com/en-gb/exdeploy2010/default(EXCHG.150).aspx#Index