Directory Synchronization

Ensure that directory synchronization to Azure Active Directory has been deployed and configured. The previous sentence greatly simplifies the work that is required to successfully deploy directory synchronization. There are many aspects , which include the following:

• Customer security team review and approval to deploy Azure AD Connect

• Azure AD Connect sizing

• Azure AD Connect filtering

• Azure AD Connect monitoring

• Azure AD Connect recovery

• Azure AD Connect Documentation

• Update to latest build of Azure AD Connect

Microsoft documents the sizing aspects for the solution, so be sure to review the limits, especially when running at scale. Note that the documentation discusses the number of objects in the source directory, not the number of carbon-based life units. Depending on the organization, this may be a significant difference.

Ensure that you consider the impact of filtering in Azure AD Connect for the Exchange hybrid deployment. Do not just assume that whoever set up Azure AD Connect has done all the work or deployed a configuration that will allow you to successfully deploy Exchange hybrid. There have been numerous projects burnt by this assumption. Exchange hybrid requires Azure AD Connect to function. One core aspect is the unified Global Address List (GAL) . Azure AD Connect is the mechanism that makes this happen. For a mailbox or mail-enabled user from on-premises Exchange to be visible to Office 365–based mailboxes, Azure AD Connect must be synchronizing those on-premises objects. This will happen by default; however, it is common for enterprises to filter the OUs, or objects that are being synchronized, to Azure AD. If an on-premises mailbox object is not within the scope of Azure AD Connect, then it will not be synchronized.

This is a common issue when starting up a proof of concept in which only a test OU in on-premises AD is set to synchronize. Another issue is that all the relevant mail objects must be synchronized. Some customers have designed their AD so that mail-enabled distribution groups are stored in OUs separate from the user objects. For these distribution groups to be visible to Office 365–based mailboxes, they must be within the scope of synchronization. If not, the Office 365 mailboxes will not see those resources in their GAL. This will generate negative feedback.

The Azure AD Connect deployment and its recovery must be fully documented, so that the entire team understands the solution. In many cases, this is simply not done. One of the great things with Azure AD Connect is that it offers a very simple express deployment. One of the bad things with Azure AD Connect is that it offers a very simple express deployment. Because of the next, next, next clicking, many deployments are never documented. This is true for the initial installation and any subsequent modifications of customizations. Ensure that all aspects of the deployment are fully understood by the relevant teams. If you have deployed Azure AD Connect as a VM, this then needs to extend to the hypervisor administrators. One customer requested that I come on-site to help them, as their Office 365 tenant had become corrupt. Why did they think it was corrupt? Well, because when they modified user objects in on-premises AD, the changes never showed up in Exchange or SharePoint Online. Thus, their entire tenant must have been corrupted, right? Well, not so much. Turns out the hypervisor admin was doing some housekeeping and decided that the Azure AD Connect VM was no longer needed, so it was compressed to zero bytes by deleting it.

This leads to the point of ensuring that enterprises deploy at least their standard OS monitoring on the Azure AD Connect server. This ensures that notifications are sent if the machine goes offline or services that should be running are not. All too often, this is overlooked.

Why is monitoring skipped? Reasons given include the statement that Azure AD Connect is an appliance, and that it does not contain any state. If there is an issue, and we need to recover, will we just create a new VM and run the install again? That may fly for small organizations, but if you have tens of thousands, or even hundreds of thousands, of objects in the directory, that will take hours—in some cases, days. Will business stakeholders really be happy with such latency? If a change or new user must be created, are they willing to wait days? Thus, it is prudent to review the recovery options and define a written SLA. That way, the correct expectations are set on all sides.

Additionally, we must ensure that Azure AD Connect was deployed with the option to synchronize the required attributes for Exchange. In the days of ye olde DirSync, it was an all or nothing affair. All attributes that were required for all the Office 365 components were synchronized to Azure AD. Today, the installation of Azure AD Connect can be customized to only synchronize the attributes for the workloads that are to be used in Office 365. For example, if only Office 365 Profession Plus is to be used, then only the attributes that are required may be synchronized by checking the appropriate products. It is possible that the option to synchronize the Exchange attributes may not have been selected. Check the installation documentation. This is another reason why we require documentation.

Another issue that may arise is with the Exchange Hybrid writeback option in Azure AD Connect. As I will discuss later, the attribute flow is mainly from on-premises AD to Azure AD. Only a very small subset of attributes flows from Azure AD back to on-premises AD. To enable the writeback, the option to enable Exchange Hybrid must be selected (Figure 3-1).

Figure 3-1. Configuring Azure Active Directory for Exchange Hybrid

Note that two areas are highlighted by red boxes in the preceding image. This is to indicate the option for Exchange Hybrid attribute writeback and to disable the synchronization process. If the synchronization process was disabled, please review “How To Enable AAD Connect Sync Cycle,” accessible from https://blogs.technet.microsoft.com/rmilne/2017/04/06/how-to-enable-aad-connect-sync-cycle/ .

As you embrace the cloud, it quickly becomes apparent that the rate of change is far greater than in many on-premises deployments. Office 365 is considered evergreen and is constantly changing and deploying new functionality. In order to keep up, the on-premises components must also be kept up to date. With regard to Azure AD Connect, this happens by installing a new release of Azure AD Connect. Depending on how you deployed Azure AD Connect and the version, you may already have the auto update feature that allows Azure AD Connect to automatically update itself. Should you have disabled this feature or deployed a custom install, you must manually update Azure AD Connect. At the time of writing in early 2017, customers must be on a 1.1 or newer build of Azure AD Connect. This brings many benefits. Multiple issues having been resolved, it is currently the latest supported version, and the synchronization cycle is now much quicker. In older builds, the synchronization used to occur every three hours. In the current builds, this now occurs every 30 minutes. This is a great improvement. If necessary, Azure AD Connect administrators may still initiate a manual sync, and this process is documented here: https://blogs.technet.microsoft.com/rmilne/2014/10/01/how-to-run-manual-dirsync-azure-active-directory-sync-updates/ .

Verify Domain Ownership

When creating your Office 365 tenant, you will have been informed that you can now send and receive e-mail to the domain called <tenantname>.onmicrosoft.com. While that may be acceptable for certain organizations, enterprises must also be able to send and receive e-mail using their own DNS names.

In order to use a custom domain, it must be added and verified in your Office 365 tenant. This is not normally an issue when discussing the domains that are commonly used. But what about the domain marketing used five years ago for a campaign that is still stamped onto some mailboxes? Those mailboxes cannot be migrated to Office 365 unless all the domains on the mailbox’s e-mail addresses have been added and verified.

It just may be that this is a good time for some spring cleaning. Review all the domains that have been used in the on-premises Exchange organization and remove those that are no longer required. Removing accepted domains is easy. Removing entries from Email Address Policies (EAPs) is also easy, but this will not delete e-mail addresses from the mailbox objects. The simplest method is to write a quick PowerShell script to run in the Exchange Management Shell, which will remove the unwanted addresses. If you do not want to write the script yourself, there are many examples on the Internet.

This issue is common when a separate team has performed the initial Office 365 deployment. They may only have added the domains that are used for User Principle Names (UPN) and not reviewed additional domains that are present in Exchange. It is recommended to align UPN, SMTP, and SIP addresses, to provide the smoothest user experience. This is to be done before the object is replicated to Azure AD by Azure AD Connect.

Take time to review your configuration and do not make assumptions. A good starting point is to review the EAP and Accepted Domains in your on-premises Exchange deployment. These findings should key you in to the SMTP domains that are being used. Also, be sure to review the Receive and Send Connectors. Sometimes, you may find that some interesting domains have been used. In recent engagements, domains such as [email protected] were noted. This was a construct the customer created more than 15 years ago. This is not valid for Internet usage and must be removed. Such tasks must be a discrete item on the Office 365 project plan and will require executive sponsorship, because business processes must be refined and adapted.

Determine Migration Method

The introduction to this chapter noted that there are multiple methods to migrate mailboxes from on-premises mail servers to Office 365. Figure 3-2 outlines the different options.

Figure 3-2. Migration options for Exchange

Multi-forest Exchange hybrid is supported today for

• Exchange 2010

• Exchange 2013

• Exchange 2016

What Servers Will Provide Hybrid Services

One item to address immediately is that there is no such thing as a “hybrid Exchange server.” There is no hybrid server. There is no special hybrid media. There is no /Hybrid install switch. There is no Hybrid server.

What we do have is an Exchange server that will provide Hybrid services. This means that the Exchange server(s) that will provide the link between on-premises and Office 365 must be deployed as if there were a regular Exchanger server. This means that CAS namespace planning, certificate planning, and dealing with self-signed certificates is no different than deploying a regular Exchange server. Exchange will consider all valid Exchange servers in an Active Directory site as valid servers to include in an Autodiscover response. This means that if you deploy additional Exchange servers, you must ensure that they are properly configured, as per the CAS namespace design. This leads us to the question: Are additional Exchange servers required? This is the consultant’s answer: It depends!

If the current environment is already properly published to the Internet and has sufficient capacity to perform mailbox moves and respond to free/busy requests, it may be possible to leverage the current infrastructure. In other cases, this may not be possible. As noted previously, in order get the best experience with Office 365, the latest version of the Office suite must be used. The same is true with Exchange hybrid. There are features that are not present if Exchange 2010 is used as the hybrid solution. In such cases, it may be desired to deploy a newer version of Exchange. However, there is no specific sizing guidance for a server that is used for hybrid purposes, and it must be sized as a regular Exchange server in the environment. Additionally, owing to the migration methodology of moving from Exchange 2010, the new environment must be fully sized and deployed at the time of cutover. This is because all the HTTP namespaces will be moved from Exchange 2010 to Exchange 2013/2016 in a single operation. The new Exchange 2013/2016 servers must be able to handle the workload of these connections. For details on Exchange 2010 migration, please review the Exchange Deployment Assistant.

If the current environment is able to provide the required features and can meet the load requirements, it generally makes sense to leverage the investment made in the current deployment. Some customers have deployed Hybrid with the existing infrastructure and moved a large percentage of mailboxes to Office 365. Once they have migrated mailboxes and thinned out the on-premises environment, they then deployed a new version of Exchange.

CAS Namespace Planning

As in previous on-premises-only Exchange deployments, CAS namespace planning is a critical phase of the project that is often overlooked. A sage Microsoft program manager once said that CAS is 95% planning and 5% implementation. This is so very true. This was also the program manager who provided the elephant’s bottom analogy for Outlook Anywhere…

As mentioned in the preceding section with regard to additional Exchange servers, the same may also be true for CAS Namespaces. If your current Exchange servers are correctly published to the Internet, you may be able to leverage the existing infrastructure and move forward. If this is the case, it typically makes sense to do so. Generally, you will be moving mailboxes from on-premises servers to Office 365 and, as a result, thin out or remove some of the on-premises infrastructure.

Some drivers to deploy additional Exchange servers may be to address issues with an existing on-premises Exchange deployment. For example, some customers may have published Exchange to the Internet with certain pre-authentication solutions. This worked well when only Outlook clients were connecting to the published infrastructure. However, now that Office 365 also must connect to the on-premises Exchange servers in a hybrid deployment, this is an issue. For example, Autodiscover must be published without pre-authentication. Pre-authentication is not supported for the Autodiscover end points that Office 365 will use. This is covered in more detail in the next section.

Autodiscover must point on on-premises Exchange servers in a hybrid deployment. Do not let the Office 365 portal goad or cajole you into prematurely moving Autodiscover to Office 365. See Office 365 Exchange Hybrid Deployments Busting the Autodiscover Myth, for more details on this issue.

In some cases, it may be desirable to create additional CAS namespaces for Office 365 mailbox migration. This may be to account for regional, publishing, or performance issues. Assume that you have a multinational on-premises Exchange deployment that spans North America, EMEA, and APAC. If you only create a mailbox migration end point in one location, that means that you will be pulling data over a WAN link from the other locations. If the migration end point was created in London, consider how Office 365 will obtain access to mailbox content. If the mailbox to be migrated resides in London, the content is locally available, and no WAN traffic is created. However, if the mailbox is in APAC, the content must be retrieved over the customer’s internal WAN from APAC. To avoid this situation, additional migration end points can be created. It is the Exchange Mailbox Replication Service (MRS), specifically the MRS proxy, that is the component used with Office 365. If we take the previous example, additional MRS end points can be created in North America and APAC. We will require an additional name on a certificate, public DNS records, and for Exchange servers to be published correctly to the Internet.

For example, we could create multiple MRS end points (Table 3-1). The following example illustrates the creation of an MRS end point per region, so that content is pulled from the region over the Internet, rather than having to backhaul over the customer’s internal WAN circuits.

Typically, each of these DNS entries will resolve to a load-balanced VIP that contains multiple Exchange servers.

In some cases, issues have arisen when trying to migrate mailboxes to Office 365. This is often owing to misconfigured on-premises network equipment. Common examples are low-level packet inspection devices, misconfigured load balancers, or problems with other on-premises network equipment. To move the migration forward, a separate migration end point can be created that is separate from the existing publishing mechanism. One customer example stands out: they spent four months trying to migrate mailboxes to Office 365 and could not even migrate a 200KB test mailbox with nothing in it. Because the customer was trying to get the mailbox content to Office 365, then surely was that not where the issue was? After spending four fruitless months, they contacted Premier support. The issue was immediately noted and a solution provided. We could immediately migrate mailboxes by creating a new MRS namespace. The new MRS namespace was not published via the security team’s standard practices; they were bypassed. A new external IP address was added and mapped to Exchange. The external firewall ACLs only allowed Office 365 to connect, so this did not present any security issues. This does require additional work to deploy, as a new external IP, public DNS record, and name on a certificate are required. But those things do not take four months.

Network Prerequisites

This is what North Americans will call the elephant in the room, in other words, a large issue that some people may wish to gloss over but must be addressed head-on. Because Office 365 resides in a Microsoft-operated data center, we require connectivity to this data center. This connectivity will take many forms as we deploy, migrate, and use the hybrid solution. Initially, we will create the hybrid relationship with the on-premises Exchange servers to Office 365. The next step is typically moving some test mailboxes over, to validate the solution from a functional perspective. When in run-state, connectivity is required between Exchange servers on-premises to Office 365, to look up the availability web service that will provide free/busy information. Note that this will work both ways. An on-premises mailbox will look up a cloud mailbox’s free/busy and vice versa.

In addition to the server-to-server free/busy lookups, we must also factor in SMTP mail flow. For a given user, their mailbox will not exist simultaneously in Office 365 and on-premises. For users to send and receive e-mail, it must flow between on-premises and Office 365. This will consume bandwidth. If the MX continues to point to an on-premises appliance/device/Exchange server, the incoming e-mail will consume bandwidth as it is handed off to the on-premises device. Should a recipient of this e-mail be located in Office 365, the message will have to be delivered to Office 365. Typically, this will mean that Internet bandwidth is used a second time for the same e-mail.

Client connectivity will also consume bandwidth. This has typically not been a major concern for most on-premises Exchange customers, if their users and mailboxes resided in the same location. The local LAN would be used for connectivity. Should the on-premises Exchange organization span multiple locations or even continents, then on-premises Outlook connectivity would have been carefully planned. The same is true for Office 365. Clients will now connect via proxy servers and firewalls to access their Office 365 mailbox that is on the Internet.

This paradigm shift in connectivity from on-premises to Office 365 created many issues for proxy server administrators. Often, the proxy administrator was not involved in the planning or was not allocated additional funding to scale the proxy infrastructure to deal with the increase in Office 365 traffic. Consider the extra volume of connections, SMTP e-mail, Outlook data, and OneDrive for Business data. Other unfortunate side effects can also be caused if the proxy servers require authentication. In many cases, NTLM authentication is used to authenticate the end users who are trying to browse the Internet. This is not the most scalable protocol and will cause NTLM bottlenecks. The issue is made worse if only a single Active Directory domain controller has been specified to authenticate the proxy requests. For this reason, Office 365 URLs should not be authenticated, as we do not want to add additional latency or potential issues.

There are multiple tools to help determine what the uptick in bandwidth consumption will be. They can be obtained from http://aka.ms/tune , along with another detailed network guidance.

In addition to the client connectivity requirements, also ensure that the necessary server connectivity requirements have been met. For details, please see the Office 365 IP and URL documentation. There are specific requirements for publishing Exchange with Office 365 that are covered in the publishing requirements for Exchange 2010 hybrid. The documentation provides details on why pre-authentication is not possible for certain Exchange on-premises URLs when Office 365 hybrid is deployed.

We are almost ready to discuss running the Exchange hybrid wizard. To recap some of the items we have discussed,

• IDFix has been executed and issues remediated.

• All Accepted domains have been reviewed and legacy/unwanted domains removed.

• All Email Address Polices have been reviewed and legacy/unwanted policies or addresses removed.

• Mailboxes have been updated to remove unwanted e-mail addresses, such as contoso.local.

• All domains have been added and verified in Office 365.

• Unwanted and legacy mailbox permissions have been documented and removed.

• Permission assignments have been reviewed to determine how users will be grouped into migration batches, to accommodate the current cross-premises permission support.

• Office clients are running a version of Office that is in mainstream support, and it is fully updated.

• The latest version of browser(s) is deployed onto all machines. This is IE11 for Windows clients. Note that Windows XP and Windows Vista are no longer supported.

• Exchange servers have been fully patched to install all Windows updates.

• Exchange servers have been updated to the latest Exchange update. This may be a Rollup Update (RU) or Cumulative Update (CU), depending if you have Exchange 2010 or 2013/32016, respectively.

Identity and authentication requirements have been discussed and documented. This may mean that AD FS is deployed. If this is the case, it is expected that a high-availability deployment of both AD FS and WAP is present. This will require load balancers in both the corporate network and the DMZ (Figure 3-3).

Figure 3-3. Network diagram showing network load balancers

A new authentication option is currently in preview. This is the Azure AD Connect Pass Through feature. AD FS–like authentication experience can be provided for domain-joined machines when they are on the corporate network and able to contact a DC.

The password hash synchronization option will also be a valid authentication mechanism for some customers. It provides the capability to use the same username and password on-premises and with Office 365.

Now that the on-premises infrastructure has been updated and legacy items removed, we can move forward with the actual Exchange hybrid deployment.

Exchange Hybrid Deployment

At the time of writing, Exchange 2003 and 2007 have already exited out of extended support. They will not be mentioned here, as customers should have already migrated off these platforms.

Regardless of the Exchange version in which the hybrid wizard is to be executed, the downloadable wizard must be used. Exchange 2010 and early Exchange 2013 builds included the hybrid wizard in the product. This was not ideal, owing to the different cadence of Exchange on-premises and Office 365 updates. By decoupling the hybrid wizard from Exchange RU and CU updates, it allows for it to be rapidly updated. Telemetry data is also provided so that if there is an issue, it is detected and can be proactively corrected. There is the opportunity to provide feedback at each stage with the new wizard. Do not use the built-in hybrid wizard on Exchange 2010, it is no longer supported. All new iterations must use the new wizard. The new Exchange hybrid wizard can be obtained from http://aka.ms/HybridWizard .

The new wizard is downloaded and installed onto the machine. Note that Internet access is required to download the wizard. This is documented in the Office 365 IP and URL article, specifically in the Exchange Online section.

Note that you will require credentials for both the on-premises and Office 365 environment. The hybrid wizard does not do anything secret. It automates the cmdlets that are already available to you on-premises and in Office 365. It is required to run the hybrid wizard to create a supported deployment. Manually creating the components is very error-prone and is no longer supported. The wizard will make the required changes to the on-premises and Office 365 environment. Some of the changes include the following:

• Disabling tiny tenant mode

• Creating coexistence mail domain—tenant.mail.onmicrosoft.com

• Creating additional send connector

• Creating additional receive connector

• Updating default Email Address Policy

• Creating trust relationship with Azure trust system—previously known as MFG (Microsoft Federation Gateway)

• Creating organization relationship between on-premises Exchange and Exchange Online

The wizard will prompt you with a series of questions, so that it can understand the environment and make the necessary configuration changes.

If the hybrid wizard encounters an issue, do not worry, as it is not the end of the world! Review the hybrid wizard log file on the servers where it was executed. Every iteration of the hybrid wizard will create a new log file. The logs are detailed and should normally allow you to isolate the issue. Once you have identified and corrected the issue, just rerun the wizard. It will verify that each configuration item was done and pick up at the point where the previous iteration failed. It is possible that there might be two separate issues. This is fine. Identify and correct the issue and then retry the wizard.

Note that blindly rerunning the wizard without making any configuration corrections will not provide a solution. In fact, if you run the wizard too many times in a given period, you will be blocked from running it until the period has elapsed.

Once the wizard has completed successfully, you should now be the owner of a shiny new Exchange hybrid deployment! Congratulations! The next step will be to run a series of functionality checks and verifications. Typically, at this point, I would suggest the following, as a minimum:

• Migrate a test mailbox to Office 365.

• Migrate a batch of test mailboxes to Office 365 that contain a reasonable amount of data.

• Review the mailbox migration statistics for these mailboxes, so that you have an initial baseline for mailbox migration performance.

• Migrate one test mailbox back to on-premises.

• Verify that AutoDiscover correctly updates the Outlook profile of a mailbox moved to Exchange Online. There should be no need of manual intervention.

• If Modern Authentication was enabled for Exchange Online, and Office 365 Professional Plus 2016 is used, the authentication experience should be smooth for AD FS and Azure AD Connect Pass through Authentication deployments.

• Verify that free/busy and calendar data is visible between on-premises and Exchange Online mailbox.

• Assuming you previously remediated AD objects and replicated them to Office 365, verify that the Global Address List is correct. There may be a little delay for it to be updated after a mailbox move.

• Test that the external mailtip is not displayed for the cross-premises mailbox.

• Send test e-mail between the on-premises and Exchange Online test mailbox.

• Review the X-Headers, to ensure that the message was treated as from a trusted source.

• Verify that OOF messages are visible cross-premises.

Once the base functionality checks have completed, you can now start to migrate some of the pilot users to Exchange Online. The pilot users must be a representative mix of your organization’s user base. These people should be willing to work with IT through any possible issues that may arise. While it is perfectly fine to include the IT team as part of the pilot group, additional business staff must also be added. If there is an issue or behavior change, the typical IT person will take it in stride and just address or fix the issue, with minimal impact. If the same challenge were presented to a standard user, they might be sidelined by this change. By adding such people to the pilot group, feedback and learning can take place, so that issues can be corrected for the mass migrations that will follow.

Note that permissions to shared resources must be considered when selecting the pilot group. Do not move people who have a dependency on resources that are still on premises where they require send-as and receive-as permissions on those resources. The considerations for a hybrid deployment are outlined here, as is the current stance on cross-premises permissions.

Exchange Server Hybrid Deployments

As the pilot users are migrated to Office 365, it is critical that you continue to monitor performance on the on-premises Exchange infrastructure. The act of moving a mailbox will require the mailbox content to be read, serialized, and then transferred to Office 365. Additionally, there will be cross-premises Exchange Web Services (EWS) calls between Exchange Online and Exchange on-premises. A prime example is for calendar and free/busy data. Users will have to continue to book meetings and review calendar data, and EWS requests are used in modern versions on Exchange.

It is also required that you plan and manage the subsequent mailbox migrations to Office 365. As noted earlier, ensure that you consider the permission implications and map out how people interact with others within the business. While the UI is great for moving some test mailboxes and a limited number of pilot users, we really need to script and automate the mass migrations. PowerShell can be used to do all of this, and TechNet documents the cmdlets, for example, New-MigrationBatch .

It is also critical that you have an initial network performance baseline, taken before migrating users to Office 365. As the migrations continue, the statics from your network devices must be collected and reviewed. The CPU load and connection count on firewalls is one of the items your network team must review. There have been issues in larger deployments wherein there were issues with NAT scalability. Troubleshooting such connections from the client side is ineffective, as the symptoms are sporadic. It is much more efficient to track from the network infrastructure. The network team should already have the tooling and process to report and analyze their devices.

In addition to the performance of specific network devices, the available network bandwidth must also be monitored. Planning for an increase in connections, firewall resources, and bandwidth is a core task of successfully deploying any cloud service. Microsoft provides tools to help with this process. Please review the available documentation and tools at http://aka.ms/tune .

As part of the bandwidth planning, there are two distinct elements to this. Bandwidth consumed while migration is in progress and bandwidth consumed once the new steady state is obtained. For example, the bandwidth to move 10TB of mailbox content is not the same as the bandwidth required once all content has been migrated. At this point, the bandwidth will be consumed by SMTP, client connectivity, and cross-premises web services requests. Probably, it will be less than what was used to migrate the content.

The network team must be engaged right at the start of any Office 365 project. Most likely, an increase in bandwidth is required. This could take months to procure, and the lead time factored into the project. Service providers may have to lay new fiber, and this could take even longer. In extreme cases, when the additional load of the Office 365 connections was factored in, the network team reported back that they needed brand-new egress firewalls. The cost for this was projected at $1.5 million. This was a larger enterprise customer, and the firewalls were already due for replacement. They wanted to get the Office 365 project to pay for their new gear. The lead Office 365 project manager said absolutely not! The meeting in which that was discussed was “interesting,” to say the least…

As you continue to move mailboxes, there may come a point where you are able to consolidate and shrink the on-premises messaging footprint. The degree to which you will be able to do this will vary by organization. Some will move 99% of mailboxes to Office 365, others will move less. If you can move 100% of mailboxes, currently it is still expected that you maintain at least one Exchange server on-premises. This is to provide the following two capabilities:

• Ability to manage Exchange attributes in a supported manner

• Mail flow from printers/scanners/LOB applications

Once the on-premises footprint and the number of mailboxes located there have been reduced, some customers then chose to update Exchange to the next version, if this has not already been done. If you recall, some customers may use Exchange 2010 as the hybrid solution, if it was correctly published to the Internet and there are no performance concerns. Once the number of on-premises mailboxes has been reduced, they deploy Exchange 2016. The CAS namespaces are cut over to Exchange 2016, and the hybrid wizard is then executed on Exchange 2016, to update the configuration. The remaining mailboxes can then be moved over to Exchange 2016, if desired, and the legacy Exchange 2010 servers are retired. Note that this assumes the Exchange 2016 deployment was correctly planned and implemented. Because any migration takes time and resources, some customers do not have the appetite to do both an Exchange on-premises and Office 365 migration at the same time. By performing them in a serial fashion, the Exchange 2016 on-premises migration is simplified, because there are fewer mailboxes to move to the destination Exchange 2016 infrastructure.

Public Folders can be migrated to Office 365. Typically, this is done after all users who use them have been moved to Office 365. Prior to migrating the content to Office 365, the on-premises public folders can be made available to Office 365 mailboxes.

See the following links for details on coexistence and migration of Public Folders from legacy Exchange servers to Office 365.

• Public Folder Coexistence with Office 365

  https://technet.microsoft.com/en-us/library/dn249373(v=exchg.150).aspx

• Public Folder Migration to Office 365

  https://technet.microsoft.com/en-us/library/dn874017(v=exchg.150).aspx