Configuring an Exchange 2013 Hybrid Deployment and Migrating to Office 365 (Exchange Online)

Body:

In this articles series by Henrik Walther, will give you an insight into the New Office 365 and then take you through the steps necessary to configure an Exchange 2013 hybrid deployment followed by migrating mailboxes from on-premises to the New Office 365 (Exchange Online).

Introduction

Back on February, 27th 2013, Microsoft released a major new update (third generation also known as wave 15) of the Office 365 service now simply referred to as the New Office 365.

Not surprisingly, this is Microsofts most complete Office cloud service to date. Microsoft Lync, SharePoint and Exchange has all been updated to the respective 2013 versions and the rich Office Pro Plus client applications (of course also 2013 versions) are now provided as streamed applications that a user can install up to five devices of their choice on. In addition, the New Office 365 now includes Yammer and SkyDrive Pro as part of the service. Lastly, the Forefront Online Protection Service (FOPE) spam filtering service has been rebranded and is now known as Exchange Online Protection or simply EOP.

It’s no secret that since the launch in mid-2011, Office 365 has been one of the fastest growing businesses in Microsofts history. After only 18 months, one in five of Microsofts enterprise customers were using the service. And the success is continuing. It should be said though, that some countries are moving faster than others. Fortunately, I’m living in the leading European country when it comes to enterprises moving to Office 365, so I have the pleasure of dealing with multiple Office 365 projects on a daily basis at Microsoft Services Denmark and none of them are boring!

Okay, so my previous article series focused on deploying ADFS-based identity federation, Directory Synchronization (DirSync) and an Exchange 2010 based hybrid deployment into an on-premises infrastructure containing an Exchange 2007 organization. With tenants moved to or created in the new Office 365, we are encouraged to replace our Exchange 2010 hybrid servers with hybrid servers running Exchange 2013 Customer Update 1 (CU1).

Note:
Existing Office 365 customers that have deployed Exchange 2010 based hybrid servers and are upgraded to the New Office 365 can still use these hybrid servers for coexistence, but will not get all the advantages that customers running Exchange 2013 hybrid server will get. Also, bear in mind that you must apply Exchange 2010 Service Pack 3 in order to be able to manage Exchange Online objects using the Exchange Management Console (EMC).

The intention with this article series is to first provide you with an insight into the new Exchange Online version based on Exchange 2013. Then, I will go through all the required steps in order to configure ADFS-based identity federation, DirSync and Exchange 2013 based hybrid servers. When it comes to both Exchange 2013 based hybrid deployments, a lot of stuff has changed and several new coexistence features and improvements to existing ones have been introduced. When it comes to ADFS and DirSync, we now support Windows Server 2012. Specifically for DirSync, which now is known as the Windows Azure Active Directory Sync tool (WAAD Sync tool), we can also do password synchronization from the on-premises Active Directory to the Office 365 tenant. However, details around this new option will be included in another articles series.

Just like it’s the case with many of my previous articles series, you could call this one a lab deployment guide with a bit of extra information provided.

Alright, we have a lot to cover so let’s get started.

Available Migration Paths to the New Office 365

Just like was the case with migrations from an on-premises Exchange environment to Exchange Online (part of the previous Office 365 offering), the migration path from an on-premise messaging environment to the new Exchange Online (part of the New Office 365 offering) will differ based on criteria such as size of the on-premise environment, number of users, the messaging environment an organization is migrating from, as well as the expectations revolving around coexistence.

So if we leave third party migration solutions out of the picture, we have four different migration approaches at our disposal:

Exchange Cutover migrations
Staged Exchange migrations
Hybrid Exchange Deployment-based migrations
IMAP-based e-mail migrations

Note:
When migrating from an on-premises Domino/Notes environment, the approach is to use a third party tool such as CMT from Binary Tree or Notes migrator from Quest Software (Dell).

In this particular multi-part article series, I’ll go through the steps necessary to configure an Exchange 2010 hybrid configuration in a pure Exchange 2010 on-premises organization followed by migrating mailboxes to the new Exchange Online. I’ll also uncover the advantages you get by choosing a hybrid configuration based migration.

Ok so the primary targets for an Exchange hybrid deployment based migration to the new Exchange Online are large enterprises that wish to move mailboxes to Exchange Online over a longer period of time or only want to move a subset of the total mailboxes. An Exchange hybrid deployment based migration to the new Exchange Online usually involves the following deployment steps:

Configure ADFS based identity federation in order to provide users with a single sign-on (SSO) experience when accessing services part of the new Office 365 offering.
Configure directory synchronization (DirSync) so that on-premise users, groups and contacts are synchronized to Office 365. By doing so, there will only be one source of authority (the on-premise Active Directory forest), which means that users migrated to Office 365 will be managed from the on-premise environment. Changes made to a user in the on-premise environment will then be reflected in Office 365 via DirSync delta changes.
Deploy Exchange 2013 hybrid deployment servers into the on-premises Exchange organization so that rich coexistence can be set up between the on-premise Exchange organization and Exchange Online. A hybrid deployment provides functionality such as free/busy & calendar sharing, MailTips integration (between Exchange Online & Exchange on-premise), Exchange Online-based online archiving support, option to offboard mailboxes from Exchange Online (move mailbox back to Exchange on-prem) as well as the option to manage Exchange Online users using the Exchange Administration Center (EAC) on the on-premises Exchange 2013 servers.

As most of you know, the new Office 365 not only consists of Exchange Online but also Lync Online and SharePoint Online, SkyDrive Pro, Yammer, the rich Office application, Office Web Apps etc. However in this article series we only focus on the Exchange side of things. Said in another way, the steps required to configure and move from on-premise solutions to Lync Online and SharePoint Online are outside the scope of this article series.

The other above listed migration approaches will be covered in separate articles here on MSExchange.org.

Exchange Online Changes & Improvements

Since the Exchange Online version part of the New Office 365 offering is based on Exchange 2013, we have several new changes and improvements in the new Exchange Online version. I have listed the most significant one below.

Exchange Administration Center Just like the Exchange 2013 product for on-premises environments, the Exchange Control Panel (ECP) in Exchange Online has been replaced by the new Exchange Administration Center (EAC). The EAC can be used to do most of the configuration and management that the Exchange Management Console (EMC) could in Exchange 2010. EAC is browser-based and it gives us the option to add our Office 365 tenant, so that both Exchange Online and on-premises Exchange can be managed from within the same browser window. We even have transparent SSO, when switching between management of Exchange Online and Exchange on-premises. Yes pretty darn cool! Although the new Exchange Online has support for Exchange 2010 SP3 based hybrid servers and therefore also the EMC, let’s face it, the EMC is becoming history as it has been discontinued with Exchange 2013. We’ll look much more at what’s possible in the EAC later on in this article series.

Figure 1: Exchange Online Administration Center

Exchange Online Protection (EOP) EOP replaces Forefront Online Protection (FOPE) and is just like with FOPE and EOP instance is automatically associated with a tenant. EOP is used to protect your organization from viruses, spam, phishing scams, and policy violations. In addition, EOP is used to control routing between the Internet, Exchange Online and your on-premises mail environment.
Outlook Web App (OWA) Once again OWA has been getting a serious facelift and has now been developed with touch in mind. OWA 2013 also provides users with so called OWA apps and connects much better with your social networks.

Figure 2: Outlook Web App (OWA)

Reporting The reporting feature in Office 365 have been heavily improved. We can now view information mailboxes and groups in your organization, spam and malware sent to and from your organization, and the total volume of mail sent to and from your organization, rules that affected mail sent to and from your organization, and Data Loss Prevention (DLP) policies and rules that affected mail sent to and from your organization.

Figure 3: Improved reporting

New Migration Features With Exchange 2013, we can now create so called batch moves and migration endpoints. Migration endpoints are management objects, that describes the remote server as well as connections that can be associated with one or multiple batch moves. By using the new batch move architecture, we improve the Mailbox Replication Service (MRS) moves by enhancing the management capability. More specifically, we can move multiple mailboxes in large batches, we get email notifications with reporting during the moves, have automatic retry and prioritization of the moves, the primary and personal archive mailboxes can be moved together or separately and finally, we get periodic incremental syncs that update the migration changes. All of this of course occurs form within the Exchange Administrator Center (EAC) no matter if you’re dealing with on-premises moves or online moves.
Public Folders Just like for on-premises Exchange organizations, organizations that move to Exchange Online can take advantage of public folder functionality. Organizations with on-premises public folders can even migrate their on-premises public folder data to public folders in Exchange Online. Public folders in Exchange 2013 are based on mailboxes, so we now have the same high availability history for public folders as for “normal” mailboxes as both PF mailboxes also are stored in DAG protected mailbox databases.

Figure 4: Public Folders in Exchange Online

Message Trace The search functionality within the message trace tool has been improved. Every time a trace result is viewed for a message, the subject line text is provided for each message. Finally, a detailed view is provided that describes all the events that happened to the message.
Address Book Policies (ABPs) A feature that many enterprises missed in the previous Exchange Online version was the option to create custom address lists and do GAL segmentation. This is now possible, but must be configured via PowerShell.

This concludes part 1 of this multi-part article in which I explain how you configure Exchange 2013 hybrid environment and migrate to Office 365 (Exchange Online).

In this article I’ll provide an overview of the on-premises lab environment used for this article series and go through the sign-up process for a tenant in the new Office 365 as well as take a look at the new Office 365 portal. Finally, we will add our on-premises domain to Office 365.

Introduction

In part 1 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to Office 365 or more precisely Exchange Online, I talked about Office 365 in general and provided you an insight into some of most significant new features included with the new Exchange Online. Moreover, I explained what migration approaches we have at our disposal, when migrating from an on-premises mail environment to the Exchange Online part of the new Office 365.

In this part 2, we will continue where we left off in part 1. That is, I’ll provide an overview of the on-premises lab environment used for this article series. In addition, we’ll go through the sign-up process for a tenant in the new Office 365 as well as take a look at the new Office 365 portal. Finally, we will add our on-premises domain to Office 365.

Let’s get started.

Overview of the Lab Environment

The lab environment used as the basis of this article series consists of the following servers:

2 x Windows Server 2012 Domain Controllers
2 x Exchange Server 2013 with CU1 multi-role (CAS & Mailbox) servers

The Active Directory forest name is ”clouduser.dk” and split-brain DNS is used, which means that the same namespace is used internally as well as externally. Forest and domain functional level is running in Windows Server 2012 mode.

The two Exchange 2013 multi-role servers (CAS & Mailbox) have been installed using Exchange 2013 Customer Update 1 (CU1) bits, which is required in order to set up a hybrid configuration with Exchange Online in the new Office 365 service. A wildcard certificate (*.clouduser.dk) has been installed and configured on the Exchange 2013 servers. Moreover, the Exchange 2013 servers have been configured in a Windows NLB cluster in order to provide load balancing and failover on the CAS level.

All mailboxes that we wish to migrate to Exchange Online are stored on these servers. Bear in mind, the databases on the servers aren’t part of a availability group (DAG) as I didn’t want to involve an external load balancer in this lab environment.

Public folders also exist on the Exchange 2013 servers. We will also take a look at how these can be migrated to the new Exchange Online.

Outlook Anywhere, Exchange ActiveSync and the Outlook Web App (OWA) service has been published to the Internet.

When moving through this article series, we will deploy the following new servers into the on-premises environment:

2 x Windows Server 2008 R2 Active Directory Federation Services (ADFS) Servers (for identity federation)
2 x Windows Server 2008 R2 Active Directory Federation Services (ADFS) Proxy Servers (for identity federation)
1 x Windows Server 2012 domain member server with DirSync configured (yes the latest DirSync tool bits supports installation on Windows Server 2012)

Below is a conceptual diagram of the environment after the new servers have been deployed.

Figure 1: Conceptual diagram of lab environment

Signing-Up for Tenant in the New Office 365

It’s time to sign up for a tenant in the new Office 365. To do so, go to the respective Office 365 web page and click on the “Try now” button.

Note:
In this article, we want to sign up for an Office 365 Enterprise E3 plan. If you want to try out another plan, you must go to the relevant Office 365 web page.

Figure 2: Clicking on the “Try now” button on the Office 365 Sign-up page

We are then taken to a “start your free 30-day trial” from that must be filled out.

Figure 3: Filling out the ”Start your free 30-day trial” form

As you can see, you must fill out things such as residing country, name, e-mail address for primary contact and organization name. In addition, you must specify the user ID and tenant name you wish to use. With all the organizations hosted in Office 365, there’s a good chance the first tenant name you choose will already be in use. But you will get a warning if this is the case. When filled out, you will be automatically signed into the new Office 365 portal. But first, you are asked to enter a mobile phone number and email address that can be used to reset the password for the global administrator account.

Figure 4: Enter mobile phone number and email address used for reset password purposes

When clicking “Save and continue”, you are taken to the Office 365 portal. As you can see, it follows the new blue theme just like all the services offered in Office 365. Also, you can see the miscellaneous services (Exchange, Lync, Office subscription and SharePoint) are currently being provisioned. This will take a minute or two, but you can still navigate around in the portal and begin to configure stuff.

Figure 5: The New Office 365 portal (services being provisioned)

When you have signed up for a tenant, you will also receive a welcome email with information such as Global Administrator name and email address, organization name, service plan and trial start/end date.

Figure 6: Welcome e-mail

A Look at the New Office 365 Portal

So as you can see in the following figure, the Office 365 Portal got a facelift with the new Office 365 service. It now follows the blue theme as most other products and services from Microsoft. With that said, we still have a navigation pane, a work pane and an action pane. The different features, configuration and options can still be accessed via the navigation pane to the left. Depending on what is selected, we can configure the respective thing in the work pane.

Figure 7: The new Office 365 Portal

In addition to the three panes, we also have a nifty toolbar in the top right corner. From here, we can access our mailbox (via OWA), the calendar, people hub newsfeed, SkyDrive Pro and SharePoint sites. In addition, we can click on “Admin”, which will bring up a drop-down menu, where we can quickly switch between Office 365, Exchange, Lync and SharePoint.

Figure 8: Admin drop-down menu in the Office 365 Portal

Let’s click on “Exchange” in the drop-down menu. This takes us to the “Exchange admin center”, which those of you with Exchange 2013 experience can see is very similar to the Exchange Administration Center (EAC) we have in the on-premises Exchange 2013 product.

Figure 9: The Exchange Online admin center

As you may have guessed, this is where we configure all the Exchange related things. Also notice, that like in the previous version of Exchange Online, we do not have a servers node in the left pane as Exchange 2013 Online servers are shared among the customers.

Adding a Domain to the Office 365 Tenant

By default, our Office 365 tenant is configured with what we call a vanity domain (tenant_name.onmicrosoft.com). Since we want to be able to use our primary on-premise domain (clouduser.dk) with this tenant, the first thing we want to do in order to prepare for a hybrid deployment is to add our on-premise domain name to our new Office 365 tenant. The procedure for this has not changed much, but the steps in the Office 365 portal have changed a bit. To add a domain to an Office 365 tenant, click “Domains” under the Management work center. On the “Domains” page, you see the default “clouduserdk.onmicrosoft.com” domain listed.

Figure 10: Domains section in Office 365 portal

Click “start step 1”.

Figure 11: Add a domain to Office 365

Specify the domain you wish to add (in this case “clouduser.dk”) as shown in Figure 12 then click “next”.

Figure 12: Specifying the domain you wish to add

Figure 13: Instructions for verifying the added domain

To add a TXT record, log on to the DNS control panel at your DNS hosting provider then click ”Add TXT record” or whatever its called in the web UI you’re using. The steps differ a bit from DNS provider to provider, but basically, you need to add a host name and the ”Destination” for that host name as shown in Figure 14.

Figure 14: TXT record added in the DNS Control Panel at public DNS provider

When Office 365 can verify the domain successfully, you are taken to the page shown in Figure 15. Click “finish”.

Figure 15: Ownership of domain confirmed

We have now reached “Step 2”. Click “start step 2”

Figure 16: Step 2 reached

Since we will add users using the DirSync tool later, select the option “I don’t want to add users right now” and click “next”.

Figure 17: Selecting to add users at a later time

Click “start step 3”.

Figure 18: Step 3 reached

In step 3, we need to specify how the “clouduser.dk” domain will be used with Office 365. In this article, we will only focus on the Exchange Online service, so will only tick that one. However, we plan to have a mix of Exchange Online and Exchange on-premises mailboxes, so there’s some extra configuration to perform.

Figure 19: Specifying how we wish to use the domain with Office 365

Selecting that we have a hybrid scenario means we need to go through some extra primarily mail flow related steps. More specifically, we need to create inbound and outbound connectors. But that’s a thing we will look at later on in this article series.

Figure 20: Making sure on-premises mailboxes are ready to work with Office 365

This concludes part 2 of this multi-part article in which I explain how you configure Exchange 2013 hybrid environment and migrate to Office 365 (Exchange Online).

In this article we will begin deploying the Active Directory Federation Service (ADFS) servers that is required for identity federation with the new Office 365.

Introduction

In part 2 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, I provided you with an overview of the on-premises lab environment used for this article series. In addition, we went through the sign-up process for a tenant in the new Office 365 as well as looked at the new Office 365 portal. Finally, we added our on-premises domain to Office 365.

In this part 3, we will continue where we left off in part 2. That is, we will begin deploying the Active Directory Federation Service (ADFS) servers that are required for identity federation with the new Office 365. More specifically, we will deploy and configure two ADFS servers. In order to achieve high availability, the ADFS servers will be configured in an ADFS farm and load balanced using Windows Network Load Balancing (WNLB).

Important:
Before you start deploying and configuring the servers required to achieve rich coexistence between the Exchange on-premise and Exchange Online, you should run the Microsoft Office 365 Deployment Readiness Tool in the respective Active Directory forest. The tool will provide an analysis of the environment in preparation for the actual Office 365 enterprise deployment and it’s important you fix any issues caught by the tool prior to deploying the rich coexistence servers. You can download the tool here.

A Brief Explanation of Office 365 Identity Federation

By using the WS-Federation (WS-Fed) and WS-Trust protocols, Active Directory Federation Services (ADFS) 2.0 provides claims-based single sign-on (aka identity federation) for the services in the Office 365 service offering. The benefits of using identity federation is to provide the users in the enterprise with a single sign-on (SSO) experience no matter if they are located on an external network or on the internal corporate network.

Basically, ADFS 2.0 is a Security Token Service (STS) that is capable of issuing, validating and exchanging security tokens on behalf of the users in the enterprise.

Although ADFS can be deployed using stand-alone federation servers, the identity federation service usually consists of two or more ADFS Proxy servers placed in the perimeter network and two or more ADFS servers located on the internal corporate network. The internal ADFS servers are configured in a so called federation server farm, which then again is load balanced using some form of load balancing solution. The ADFS Proxy servers are not configured in a federation server farm per se, but incoming sessions hitting these servers are simply load balanced using WNLB or an external load balancer.

Figure 1: Conceptual diagram of the identity federation authentication flow

The reason why it is recommended to deploy at least two ADFS Proxy and ADFS servers is in order to achieve redundancy. This is critical since an unavailable ADFS infrastructure means users will not be able to access any used services in the new Office 365.

By default, the ADFS configuration is stored in a Windows Internal Database (WID) both when it comes to ADFS Proxy and ADFS servers. If you need more than five federation servers in a farm or need to spread them over multiple locations, it’s possible to store the ADFS configuration in a SQL database, but generally such a configuration should be avoided because of costs as well as complexity.

It is also worth noting that the ADFS Proxy servers can be eliminated in certain scenarios where a TMG array or an UAG farm is located in the perimeter network. Finally, bear in mind that identity federation requires directory synchronization (DirSync) from the on-premise Active Directory forest to the Office 365 tenant, so that a shadow user is created for each on-premise user in the Office 365 tenant.

I will not go much more into the details of identity federation in this article, as the authentication experience will be covered later on in this article series.

Configuring Windows Load Balancing on the ADFS Servers

When configuring rich coexistence between an Exchange on-premise environment and the new Office 365, it’s crucial identity federation works all the time. As already mentioned, if the identity federation service becomes unavailable, it means that the Active Directory users within the enterprise cannot authenticate against an Office 365 service such as Exchange Online. Since the user cannot authenticate he cannot access an Office 365 service, as he does not know the password set for the Office 365 user object itself. Because of this, it’s highly recommended to load balance all ADFS servers as well as ADFS Proxy servers using Windows Network Load Balancing (WNLB), a virtual load balancing appliance or a hardware load balancer solution. Since ADFS does not require layer 7 based session affinity, WNLB is fully supported.

Before we configure ADFS on the two ADFS servers, we’ll configure them in a WNLB. To do so, first install the ”Network Load Balancing” component. This can be done by opening the “Server Manager” and under “Manage”” in the top right corner, selecting ”Add Roles and Features” as shown in Figure 2. On the ”Before you begin” page, click “Next” then select “Role-based or Feature-based installation” and click “Next” again.

Figure 2: Adding the NLB Role

On the “Server Selection” Page, click “Next”.

Figure 3: Server Selection page

Click “Next” on the “Server Roles” page and on the “Features” page, tick “Network Load Balancing” and click “Next” again.

Figure 4: Ticking Network Load Balancing on the features page

On the “Confirmation” page, click “Install”.

Figure 5: Confirmation page

When the component has been installed, click ”Close” to exit the wizard.

Figure 6: NLB component installed

Now launch, in the Server Manager, click ”Tools” and select ”Network Load Balancing Manager” in the drop-down menu.

Figure 7: Launching the Network Load Balancing Manager

In the NLB Manager, select ”Cluster” in the menu and then click ”New”.

Figure 8: NLB Manager

Figure 9: Opening the New NLB Cluster creation wizard

In ”New Cluster: Connect” type the server name of the ADFS server you currently are logged on to then click ”Connect”.

Select the interface name listed and click ”Next”.

Note:
In this article series I’ll configure the Windows NLB in unicast mode which is the reason why I only have one interface connected to the server.

Figure 10: Specifying the name of the first node and the associated interface

On the ”New Cluster: Host Parameters” page, leave the defaults as is and click ”Next”.

Figure 11: Host Parameters page

On the ”New Cluster: Cluster IP Addresses” page, click ”Add”.

Figure 12: Adding a virtual IP address to the NLB cluster

Now enter the IP addresses (virtual IP address) that should accept incoming sessions for the Windows NLB cluster.

When done, click ”OK” and ”Next”.

Figure 13: Specifying the virtual IP address

Figure 14: Virtual IP address

On the ”New Cluster: Cluster Parameters” page, enter the FQDN for the Windows NLB in the ”Full Internet Name” text field and then select the cluster operation mode.

In this article series, we use ”sts.clouduser.dk” as the FQDN and will run the Windows NLB in unicast mode.

Click ”Next”.

Figure 15: Specifying the full internet name and cluster operation mode

On the ”New Cluster: Port Rules” page, leave the defaults so the NLB cluster listens on all ports.

Click ”Finish”.

Figure 16: Port rules

The NLB cluster has now been configured although only with a single node.

Figure 17: NLB cluster created

In order to add the other ADFS server as a node, right-click on the cluster name and then select ”Add Host To Cluster” in the context menu.

Figure 18: Adding another node to the NLB cluster

On the ”Add Host to Cluster: Connect” page, enter the server name of the other ADFS server and then click ”Connect”. Select the listed interface and click ”Next”.

Figure 19: Specifying the name and interface of the other node

Leave the defaults and click ”Next”.

Figure 20: Host Parameters

Click ”Finish”.

Figure 21: Port rules

After a little while, the other node has been added to the NLB cluster.

Figure 22: NLB cluster now includes two nodes

Okay so although we now have an NLB cluster set with ”sts.clouduser.dk” associated with the specified virtual IP address, there’s no way traffic that hits ”sts.clouduser.dk” can be directed to the NLB cluster since the FQDN doesn’t exist in DNS.

So let’s open the DNS Manager on a domain controller in the Active Directory forest and add a new host record (A-record).

Figure 23: Creating a DNS record in AD DNS

Name it ”sts” and then enter the VIP address that was set when the NLB cluster was created.

Figure 24: Naming the record and specifying the VIP of the NLB cluster

Important:
In this article series all servers including the ADFS servers are based on virtual machines in a Hyper-V environment. This means that we need to enable spoofing of MAC addresses on the interface for servers participating as nodes in an NLB cluster running in unicast mode. To do so, shut down each node and then open the property page for each respective virtual machine. On the property page, select the virtual network adapter, then check ”Enable spoofing of MAC addresses”.

Figure 25: Enabling spoofing of MAC addresses

Now start each cluster node and then verifiy you can ping ”sts.clouduser.dk” or whatever FQDN you use in your environment.

Figure 26: Ping the FQDN associated with the NLB Cluster

This concludes part 3 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to the new Office 365 (Exchange Online).

In this article we will install and configure Active Directory Federation Service (ADFS) 2.1 on the two ADFS servers on the internal network. After we have configured the servers, we will verify they work as expected.

Introduction

In part 3 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, I explained what identity federation against the new Office 365 is. In addition, we configured the two ADFS servers in a Windows Network Load Balancing (WNLB) cluster in order to load balance incoming authentication sessions.

In this part 4, we will continue where we left off in part 3. That is, we will install and configure Active Directory Federation Service (ADFS) 2.1 on the two ADFS servers on the internal network. After we have configured the servers, we will verify they work as expected.

Importing the Server Authentication Certificate into IIS

Since all client authentication against ADFS occurs via SSL, we need to import a server authentication certificate on each ADFS server. Because all clients should trust this certificate, it is recommended to import a certificate from a third party certificate provider. Although we use a wildcard certificate in this article series, a single name SSL certificate is sufficient. If you use a single name certificate, the FQDN included should match the FQDN we configured in the previous article (in this example sts.clouduser.dk).

To import the certificate, first install the Windows Server 2012 “Web Server (IIS)” role. You can do this just like you installed the Network Load Balancing component earlier on. That is by opening the Server Manager > click “Manage” > Add Roles and Features and then tick the Web Server (IIS) role in the wizard.

Figure 1: Selecting the Web Server (IIS) role

To import the server authentication certificate, open the IIS Manager, and select the web server object followed by opening “Server Certificates” in the middle pane.

Figure 2: Launching the IIS Manager

Figure 3: Selecting Server Certificates in IIS Manager

Under Server Certificates, click ”Import” in the action pane as shown in Figure 4.

Figure 4: Clicking “Import” under Server certificates in the IIS Manager

Point to the certificate you wish to import and then specify the password, then click ”OK”.

Figure 5: Pointing to the certificate we wish to import As can be seen in Figure 6, the certificate has now been imported to IIS.

Figure 6: Certificate has been imported

Next step is to bind the certificate to the “Default Web Site”. To do so, expand ”Sites” then select the ”Default Web Site” and click on the ”Bindings” link in the ”Action Pane”.

Figure 7: Clicking “Bindings” under Sites in IIS Manager

Under ”Site Bindings” click ”Add”. In ”Add Site Bindings”, select ”HTTPS” in the ”Type” drop-down box and then point at the imported certificate under ”SSL certificate”.

Figure 8: Adding a new site binding for HTTPS

Click ”OK” twice.

Repeat the above steps on the secondary ADFS server.

Installing & Configuring the ADFS Farm

With the two ADFS servers configured in a WNLB cluster and the required certificate imported, it is time to get the Windows Server 2012 Active Directory Federation service (AD FS) role installed and configured on both servers.

Important:
With Windows Server 2008 R2 based servers, we had to use the separate ADFS 2.0 RTW package, that could be downloaded here. However, with Windows Server 2012 we use the native ADFS role (ADFS 2.1).

To install the ADFS role, open the “Server Manager” and click “Add Roles and Features” launch “AdfsSetup.exe” and then accept the license agreement.

Figure 9: Installing the ADFS 2.role

When the ADFS role has been installed, click “Run the AD FS Management snap-in” in order to perform the rest of the post-deployment configuration.

Figure 10: Launching the ADFS Management console

With the ADFS Management console opened, click “ AD FS Federation Server Configuration Wizard”.

Figure 11: Launching the AD FS Federation Server Configuration wizard

On the “Welcome” page, we need to specify which to configure. Since these are the two internal ADFS servers we wish to configure a “Federation service” so select that and click “Next”.

Figure 12: Selecting “Federation Server” in the ADFS Setup wizard

On the “Select Deployment Type” page, select “New federation server farm”.

Figure 13: ADFS Deployment Type page

Now we need to specify the federation service name which in this case is “sts.clouduser.dk”. Well, actually based on the common name in the certificate the wizard will do this automatically, but since we use a wildcard certificate in this article series, the wizard cannot determine the name meaning we need to specify it manually.

Figure 14: Wizard cannot determine the federation service name as a wildcard certificate is used

Replace the “*” with “sts” in the federation service name and click “Next”.

Figure 15: Replacing “*” with “sts” in the federation service name

On the next page, we need to specify the service account that should be used for the federation server farm. This account must be the one that is used on all federation servers in the respective farm.

The service account specified should just be an Active Directory user account with “domain user” permissions.

Important:
Make sure the account is created with the following set: “User cannot change password” and “Password never expires”.

Figure 16: Creating a service account for the federation server farm

When the account has been created enter the username and password and click “Next”.

Figure 17: Specifying the username and password for the federation server farm service account

On the appearing page, we can see a list of the settings that will be configured for AD FS 2.0 (Figure 18).

Click “Next”.

Figure 18: Settings that will be configured for ADFS

When the wizard has configured each component with success, click “Close” to exit the wizard.

Figure 19: Each component has been configured with success

As we can see in the AD FS console, we need to add a trusted relying party in order to manage SSO for our Office 365 users. We will actually do this using PowerShell, but first we want to add the other ADFS server to the federation server farm.

Figure 20: AD FS Console

So switch to the other ADFS server and install the ADFS role and then launch the ADFS Federation Server Configuration wizard.

On the “Welcome to the AD FS Federation Server Configuration Wizard”, select “Add a federation server to an existing Federation Service” and click “Next”.

Figure 21: Adding the server to an existing federation service

On the “Specify the Primary Federation Server and Service Account” page, enter the “adfs1.clouduser.dk” (or whatever the server FQDN name is for the primary ADFS server in your environment) and then enter the credentials for the federation server farm service account followed by clicking “Next”.

Figure 22: Specifying the FQDN of the federation server farm as well the service account credentials

Make sure the server certificate is selected and the correct federation service FQDN is configured and then click “Next”.

Figure 23: Server certificate and federation service name

Once again we’re now ready to apply the settings, so click “Next”.

Figure 24: Ready to apply settings

On the configuration results page, click “Close” when all components have been configured successfully.

Figure 25: Configuration results

You will now see in the AD FS Management console that this server is not the primary federation server in the farm and that you must perform configuration changes on the primary ADFS server.

Figure 26: AD FS Management console on the second federation server

We have now configured the federation server farm.

Verifying the Federation Server farm is working properly

With the federation server farm configured, let’s check that it behaves as expected. First let’s try to see if we can reach the XML with the service description document. To do so, open a browser on a client located in the same AD forest as the ADFS server and enter (replace the ADFS server FQDN with the one in your environment):

https://ADFS1.clouduser.dk/FederationMetadata/2007-06/FederationMetadata.xml

If things work as expected, you should see something similar to Figure 27.

Figure 27: Accessing the XML service description document via a browser from an internal client using ADFS server FQDN

Repeat this step but point to the other ADFS server.

Lastly, try to access the XML service description document using the federation service FQDN (in this case sts.clouduser.dk).

Figure 28: Accessing the XML service description document via a browser from an internal client using federation service FQDN

Also, open the AD FS Admin log and look for event 100. If you see event 100, it means that the federation service was able to communicate with the federation service.

Figure 29: Event 100 in the ADFS Admin log

This concludes part 4 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to the new Office 365 (Exchange Online).

In this article we will deploy the Active Directory Federation Proxy (ADFS) servers that are required for external identity federation with Office 365.

Introduction

In part 4 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we installed and configured Active Directory Federation Service (ADFS) 2.1 on the two ADFS servers on the internal network. After we configured the servers, we verified they worked as expected.

In this part 5, we will continue where we left off in part 4. That is we will deploy the Active Directory Federation Proxy (ADFS) servers that are required for external identity federation with Office 365. More specifically, we will deploy and configure two ADFS Proxy servers. In order to achieve high availability, the ADFS Proxy servers will be load balanced using Windows Network Load Balancing (WNLB).

Configuring Windows Load Balancing on the ADFS Proxy Servers

When configuring rich coexistence between an Exchange on-premise environment and Office 365, it’s crucial identity federation that works all the time. As already mentioned in previous parts of this article series, if the identity federation service becomes unavailable, it means that the Active Directory users within the enterprise cannot authenticate against an Office 365 service such as Exchange Online. Since the user cannot authenticate he cannot access an Office 365 service as he does not know the password set for the Office 365 user object itself. Because of this, it’s highly recommended to load balance all ADFS servers as well as ADFS Proxy servers using Windows Network Load Balancing (WNLB), a virtual load balancing appliance or a hardware load balancer solution. Since ADFS doesn’t require layer 7 based affinity, WNLB is fully supported.

Before we configure ADFS on the two ADFS Proxy servers, we will configure them in a WNLB. To do so, first install the ”Network Load Balancing” feature. This can be done by opening the Server Manager and launching the ”Add Roles and Features Wizard” as shown in Figure 1. On the ”Select Features” page, tick ”Network Load Balancing”.

Figure 1: Selecting the Network Load feature

When the WNLB feature has been installed, click ”Close” to exit the wizard.

Figure 2: NLB feature installed

Now launch ”Network Load Balancing Manager” by clicking “Tools” > “Network Load Balancing Manager” in the “Server Manager”.

Figure 3: Launching the NLB Manager

In the NLB Manager, select ”Cluster” in the menu and then click ”New”. In ”New Cluster: Connect” type the server name of the ADFS server you currently are logged on to then click ”Connect”.

Select the interface name listed and click ”Next”.

Note:
In this article series I’ll configure the Windows NLB in unicast mode which is the reason why I only have one interface connected to the server.

Figure 4: Specifying the name of the first node and the associated interface

On the ”New Cluster: Host Parameters” page, leave the defaults as is and click ”Next”.

Figure 5: Host Parameters page

On the ”New Cluster: Cluster IP Addresses” page, click ”Add”.

Now enter the IP addresses (virtual IP address) that should accept incoming sessions for the Windows NLB cluster. When done, click ”OK” and ”Next”.

Figure 6: Adding a virtual IP address to the NLB cluster

On the ”New Cluster: Cluster Parameters” page, enter the FQDN for the Windows NLB in the ”Full Internet Name” text field and then select the cluster operation mode.

In this article series, we use ”sts.clouduser.dk” as the FQDN and will run the Windows NLB in unicast mode.

Click ”Next”.

Figure 7: Specifying the full internet name and cluster operation mode

On the ”New Cluster: Port Rules” page, configure the NLB cluster to only listen on port 443/TCP.

Click ”Finish”.

Figure 8: Port rules

The NLB cluster has now been configured although only with a single node.

In order to add the other ADFS Proxy server as a node, right-click on the cluster name and then select ”Add Host To Cluster” in the context menu.

Figure 9: NLB cluster created and adding a second node

On the ”Add Host to Cluster: Connect” page, enter the IP address of the other ADFS Proxy server and then click ”Connect”. Select the listed interface and click ”Next”.

Figure 10: Specifying the IP address and interface of the other node

Leave the defaults and click ”Next”.

Figure 11: Host Parameters

Click ”Finish”.

Figure 12: Port rules

After a little while, the other node has been added to the NLB cluster.

Figure 13: NLB cluster now includes two nodes

Okay, so although we now have an NLB cluster set with ”sts.clouduser.dk” associated with the specified virtual IP address, there’s no way traffic that hits ”sts.clouduser.dk” from the Internet can be directed to the NLB cluster since the FQDN doesn’t exist in external DNS.

So now is the time to create an A record named “sts” in the parent for the “clouduser.dk” domain at the external DNS provider hosting our domain. In my case, I’ll need to open the web GUI at my provider and created the record as shown in Figure 14.

It will be named ”sts” and as you can see, is associated with a public IP address that forward traffic to the VIP address was set to when the ADFS Proxy NLB cluster was created.

Figure 14: Creating the federation DNS record in external DNS

Adding Federation FQDN to the hosts file on the ADFS Proxy servers

Because the ADFS Proxy servers has been configured with the same virtual name (sts.clouduser.dk) as the ADFS servers on the internal network, we need to make sure that when the ADFS Proxy servers are going to route 443 traffic to ”sts.clouduser.dk” that it goes to the ADFS servers on the internal network. An easy way to achieve this is to add ”sts.clouduser.dk” to the local hosts file on each ADFS Proxy pointing to the VIP of the ADFS servers on the internal network.

Figure 15: Adding federation FQDN to the hosts file on the ADFS Proxy servers

After having added ”sts.clouduser.dk” to the hosts file on both ADFS Proxy servers, open a command prompt and type ”IPConfig /Flushdns” to flush the NBT remote cache name table and then try to ping ”sts.clouduser.dk”. This should now resolve to the VIP configured on the ADFS servers on the internal network.

Figure 16: ”sts.clouduser.dk” resolving to the VIP configured on the ADFS servers on the internal network

Enable MAC Spoofing on the Hyper-V Virtual Machines

In this article series all servers including the ADFS Proxy servers are based on virtual machines in a Hyper-V environment. This means that we need to enable spoofing of MAC addresses on the interface for servers participating as nodes in an NLB cluster running in unicast mode. To do so, shut down each node and then open the property page for each respective virtual machine. On the property page, select the virtual network adapter, then check ”Enable spoofing of MAC addresses”.

Figure 17: Enabling spoofing of MAC addresses

Now start each cluster node again.

This concludes part 5 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to the new Office 365 (Exchange Online).

In this article we will install and configure Active Directory Federation Service (ADFS) 2.1 on the two ADFS Proxy servers in the perimeter network.

Introduction

In part 5 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we deployed the Active Directory Federation Proxy (ADFS) servers that are required for external identity federation with Office 365. More specifically, we deployed and configured two ADFS Proxy servers. In order to achieve high availability, the ADFS Proxy servers have been load balanced using Windows Network Load Balancing (WNLB).

In this part 6, we will continue where we left off in part 5. That is we will install and configure Active Directory Federation Service (ADFS) 2.1 on the two ADFS Proxy servers in the perimeter network. After we have configured the servers, we will verify they work as expected.

Let’s get going…

Importing the Server Authentication Certificate into IIS

Since all client communication against ADFS occurs via SSL and because the ADFS Proxy servers communicate with the ADFS servers on the internal network via SSL, we need to import a server authentication certificate on each ADFS Proxy server. Because all clients (and the ADFS servers on the internal network) must trust this certificate, it is recommended to import a certificate from a 3rd party certificate provider. Although we use a wildcard certificate in this article series, a single name SSL certificate is sufficient. If you use a single name certificate, the FQDN included should match the FQDN we configured in the previous article (in this example sts.clouduser.dk).

Figure 1: Selecting the Web Server (IIS) role

To import the server authentication certificate, open the IIS Manager, and select the web server object followed by opening “Server Certificates” in the middle pane.

Figure 2: Launching the IIS Manager

Figure 3: Selecting Server Certificates in IIS Manager

Under Server Certificates, click ”Import” in the action pane as shown in Figure 4.

Figure 4: Clicking “Import” under Server certificates in the IIS Manager

Point to the certificate you wish to import and then specify the password, then click ”OK”.

Figure 5: Pointing to the certificate we wish to import As can be seen in Figure 6, the certificate has now been imported to IIS.

Figure 6: Certificate has been imported

Figure 7: Clicking “Bindings” under Sites in IIS Manager

Figure 8: Adding a new site binding for HTTPS

Click ”OK” twice.

Repeat the above steps on the secondary ADFS server.

Installing & Configuring the ADFS Proxy Server Settings

With the two ADFS Proxy servers configured in a WNLB cluster and the required certificate imported, it is time to get the Windows Server 2012 Active Directory Federation service (AD FS) role installed and configured on both servers.

To install the ADFS role, open the “Server Manager” and click “Add Roles and Features” > Next > ADFS Proxy.

Figure 9: Installing the ADFS role

Tick “Federation Service Proxy” and click “Next”.

Figure 10: Selecting Federation Service Proxy

When the ADFS role has been installed, click “Run the AD FS Management snap-in” in order to perform the rest of the post-deployment configuration.

Figure 11: Launching the ADFS Proxy Management console

On the “Welcome” page, in the “AD FS Federation Proxy Server Configuration Wizard”, click “Next”.

Figure 12: Launching the AD FS Federation Proxy Server Configuration Wizard

Enter the name of the federation service to which the ADFS Proxy server will redirect client requests (in this case it’s “sts.clouduser.dk”) and then click “Test Connection”.

Figure 13: Specifying the name of the federation service to which the ADFS Proxy server will redirect client requests

If things are configured properly and you have access to the federation service via port 443, then you will see the dialog box in Figure 14.
Figure 14: The Federation Service was contacted successfully

Click “OK” and then “Next”. You will be prompted for credentials that have the permissions to establish a trust between the ADFS Proxy server and the ADFS servers on the internal network.

Do so and click “OK”.

Note:
You can use the ADFS service account that is used for the ADFS servers on the internal network. Bear in mind that you have to specify these one time only and that they are not configured for a service on the ADFS Proxy servers.

Figure 15: Entering credentials that have permissions to establish trust with ADFS Servers

Click “Next”.

Figure 16: Settings that will be configured for ADFS 2.1

When the wizard has configured each component with success, click “Close” to exit the wizard.

Figure 17: Each component has been configured with success

Repeat the above steps on the other ADFS Proxy server.

The ADFS Proxy servers have now finished the required configuration steps for the ADFS Proxy servers.

Verifying the ADFS Proxy Servers has been configured properly

In order to verify the ADFS Proxy servers are operating as expected, we can open the AD FS log and look for event id 198. If you see this event id, the ADFS Proxy server has been configured properly.

Figure 18: Event id in the AD FS Admin log

This concludes part 6 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online).

In this article we will install the Windows Azure Active Directory Module for Windows PowerShell and convert our custom Office 365 domain to a federated domain.

Introduction

In part 6 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we deployed the Active Directory Federation Proxy (ADFS) servers that are required for external identity federation with Office 365. More specifically, we deployed and configured two ADFS Proxy servers. In order to achieve high availability, the ADFS Proxy servers have been load balanced using Windows Network Load Balancing (WNLB).

In this part 7, we will continue where we left off in part 6. That is we will install the Windows Azure Active Directory Module for Windows PowerShell and convert our custom Office 365 domain to a federated domain. In addition, we will enable directory synchronization for our Office 365 tenant, so that it’s ready for part 8.

Let’s get going…

Converting the Custom Domain to a Federated Domain

So during the last four articles in this series, we prepared for identity federation between the on-premises environment and Office 365. We did so by deploying and configuring two ADFS servers on the internal network and two ADFS Proxy servers in the perimeter network.

Despite creating the federation service farm, we have yet to configure the actual federation with our Office 365 tenant in order to achieve single sign-on (SSO) for clients connecting to Office 365. We can do this using Windows PowerShell on a machine that has the Windows Azure Active Directory Module for Windows PowerShell installed. Personally, I like to install this PowerShell module on the primary ADFS server in a federation farm as you then do not have to set the ADFS context using the “Set-MsolAdfscontext” cmdlet prior to converting the respective custom domain to a federated domain.

All right, let us log on to the primary ADFS server. Now open a browser and download the Microsoft Online Services Sign-In Assistant for IT Professionals, which is a prerequisite for installing the Windows Azure Active Directory Module for Windows PowerShell. When downloaded, launch the Setup wizard.

Accept the “License Agreement” and click “Next”.

Figure 1: MOS Sign-In Assistant Setup License Agreement

When installed, click “Finish” to exit the setup wizard.

Figure 2: MOS Sign-in Assistant installed successfully

Despite having installed .NET Framework 4.5 on the server, we also need to install .NET Framework 3.5 in order to be able to install the Windows Azure Active Directory Module for Windows PowerShell. This can be done via the Server Manager.

Figure 3: Adding the .NET Framework 3.5 Features via the Server Manager

After having installed .NET Framework 3.5, we are ready to install the Windows Azure Active Directory Module for Windows PowerShell. This tool can be downloaded from the Office 365 portal. More specifically under “users and groups” > “Single sign-on”, where you click “Manage”.

Now under “step 3”, select the “Windows 64-bit version” and click the “download” button.

Figure 4: Downloading the Windows Azure Active Directory Module for Windows PowerShell

With the module downloaded, double-click the “AdministrationConfig-en” MSI file to launch the module setup wizard.

Click “Next”.

Figure 5: WAAD Module for Windows PowerShell setup wizard – Welcome page

Accept the license agreement and click “Next”.

Figure 6: WAAD Module for Windows PowerShell setup wizard – License Terms page

Accept the default installation path and click “Next”.

Figure 7: WAAD Module for Windows PowerShell setup wizard – Install Location page

Click “Install”.

Figure 8: WAAD Module for Windows PowerShell setup wizard – Ready to Install page

Click “Finish”.

Figure 9: WAAD Module for Windows PowerShell setup wizard – Completion page

Launch the Windows Azure Active Directory Module for Windows PowerShell.

Figure 10: Launching the Windows Azure Active Directory Module for Windows PowerShell

Type “Connect-MSOLService” and then authenticate using an Office 365 global administrator account.

Figure 11: Connecting to the Office 365 tenant using Powershell

Now type “Get-MSOLDomain –DomainName clouduser.dk” to list the custom domain(s) and authentication type.

Figure 12: Listing custom domain(s) and authentication type

Now convert the domain that you wish to use for federation using the below command. In this example, it is “clouduser.dk”:

Convert-MsolDomainToFederated –DomainName “clouduser.dk”

Figure 13: Converting the domain to a federated domain

When the command has finished, let us verify that the domain has been converted to a federated domain. We can do so using: Get-MsolDomain | fl

Figure 14: Domain converted to a federated domain

Finally, let’s open the ADFS Management console. Here we can see that AD FS now provides single sign-on (SSO) access for client computers.

Figure 15: AD FS Management console

Okay the domain has now been converted with success.

Note:
If you need to configure support for multiple UPN domains, check out this blog post I wrote on the topic. The steps have been written for Windows Server 2008 based ADFS servers.

Next up, let us test whether the “login.microsoftonline.com” site detects the respective domain as a federated domain. To do so, enter a fictive UPN with a UPN domain suffix matching the one we just federated. When you have entered the UPN and pressed “tab”, you should see the password field grey out as shown below. This means that Office 365 will redirect all authentication requests for the respective domain to the ADFS Proxy servers in our on-premises federation service infrastructure.

Note:
If you haven’t seen the below sign-in page before, I can inform you that it’s the new Office 365 login page that the Office 365 product team has been working on. The redesign goals with it was to create a simple experience that’s optimized for modern devices, reduces the number of times users need to sign in, and provides the best possible experience across the many devices that you want to use.

Figure 16: Testing federation is detected by the Microsoft Online Login Page

After a few seconds, we should be taken to the ADFS Proxy server page in our on-premises infrastructure as shown in Figure 17.

Figure 17: Forms based login based on on-premises ADFS Proxy server

This concludes part 7 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online).

In this article we will install and configure the Windows Azure Active Directory (WAAD) Sync tool on our Windows Server 2012 domain-member server and start object synchronization from our on-premises Active Directory to the Office 365 tenant.

Introduction

In part 7 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we converted our custom managed domain to a federated domain, so that users will be able to authenticated against Office 365 using their UPN login.

In this part 8, we will continue where we left off in part 7. That is we will install and configure the Windows Azure Active Directory (WAAD Sync tool on our Windows Server 2012 domain-member server and start object synchronization from our on-premises Active Directory to the Office 365 tenant.

Note:
The WAAD Sync tool was formerly known as the Directory Synchronization tool (DirSync tool).

Let’s get going…

Activating Active Directory Synchronization

The first preparation step we want to complete before concentrating on installing and configuring the WAAD Sync tool on the respective domain member server in our on-premises environment is to activate directory synchronization for our Office 365 tenant. This can be done by logging on to the Office 365 portal followed by clicking on the “users and groups”. and from here click “Set up” to the right of “Active Directory synchronization” in the top of the page as shown in Figure 1 below.

Figure 1: Users and groups page in the Office 365 portal

Under “Set up and manage Active Directory synchronization”, click on the “activate” button in “step 3”.

Figure 2: Clicking on the activate button

You will now be asked whether you really wish to activate directory synchronization from your on-premises environment to Office 365. Since this is exactly what we want to do, click “activate” once again.

Figure 3: Do we really wish to activate directory synchronization?

Although we just activated directory synchronization, this will not occur instantly. As you can see in Figure 4, we need to wait up to 24 hours before it’s activated.

Figure 4: Activation in progress

Creating the WAAD Sync Service Account

While we wait for directory synchronization to complete, let’s create the service account that should be used for configuring directory synchronization. We should create this account in the Office 365 tenant. To do so, click “users and groups” and then hit the “plus” sign as shown in Figure 5.

Figure 5: Clicking “plus” sign

Enter the name and UPN logon for the account and click “next”.

Figure 6: Naming the account and giving it a UPN logon name

On the “settings” page, make sure to assign the account “Global Administrator” permissions. Also, specify the email address that should be used if there’s a need to someday reset the password for this account.

Click “next”.

Figure 7: Assigning the account Global Administrator permissions

Since the account should not be used to access any Office 365 services, leave all of them unticked and click “next”.

Figure 8: No need for any licenses

Now specify the email address to which the temporary password should be sent and click “create”.

Figure 9: Send results in email

On the “results” page, click “finish”.

Figure 10: Results page

Now log off the portal and log on again using the new accounts credentials.

Figure 11: Logging on to the portal with the new account

You will be asked to specify a new password for the account. Do so and click “save”.

Figure 12: Specifying a new password for the new account

Now you need to decide whether the new account, which can be considered a service account should follow the Office 365 password expiration policy meaning you need to change the password for the account every 90 days or if you rather want to set the password to never expire.

I’ll do the latter.

Since this can’t be done via the Office 365 portal, we need to connect to the Office 365 tenant using Windows PowerShell.

When connected to the Office 365 tenant, we can check the “PasswordNeverExpires” value with the following command:

Get-MsolUser –UserPrincipalName “svc-dirsync@clouduserdk.onmicrosoft.com” | fl

Figure 13: Value of the “PasswordNeverExpires” attribute for the new service account

To change this value to “True”, we can use the following command:

Set-MsolUser –UserPrincipalName “svc-dirsync@clouduserdk.onmicrosoft.com” –PasswordNeverExpires “true”

Figure 14: Changing the password never expires attribute to “true”

Ok let’s see whether active directory synchronization has been activated. As you can see in Figure 15, this is the case so we can move on to the next action, which is to install and configure the WAAD Sync tool.

Figure 15: Active directory synchronization is now activated

Installing and Configuring the WAAD Sync Tool

When directory synchronization has been activated, let’s switch back to the server on which we wish to install the WAAD Sync tool. You can download the latest version of the WAAD Sync tool from the Office 365 portal. More specifically under “users and groups” > “Set up” and here click the “download” button under “step 4”.

Figure 16: Downloading the WAAD Sync tool

From there launch the WAAD Sync tool setup wizard. On the “Welcome” page, click “Next”.

Figure 17: WAAD Sync tool setup wizard – Welcome page

Accept the license terms and click “Next”.

Figure 18: Accepting the license terms

On the “Select Installation Folder” page, click “Next”.

Figure 19: Select installation folder page

Let the installation finish. This can take a few minutes.

Figure 20: WAAD Sync tool is being installed

When installation has completed, click “Next”.

Figure 21: Installation complete

On the “Finished” page, make sure “Start Configuration wizard now” is ticked then click “Finish”.

Figure 22: Finish page

The WAAD Sync tool Configuration wizard will now launch. On the “Welcome” page, click “Next”.

Figure 23: WAAD Sync tool Configuration wizard

On the “Windows Azure Active Directory Credentials” page, enter the credentials for the service account we created in the previous section and click “Next”.

Figure 24: Entering the credentials for the WAAD Sync service account

On the “Active Directory Credentials” page, enter the credentials of an account with domain administrator permissions in the on-premises Active Directory.

Note:
This does not need to be a dedicated service account as these credentials aren’t saved.

Click “Next”.

Figure 25: Entering the credentials of a domain administrator

We’re now taken to the Exchange hybrid deployment page. If the DirSync Configuration setup wizard detects Exchange 2010 SP1 (or later) servers in the on-premises Active Directory we will be able to tick “Enable Exchange hybrid deployment”.

Note:
If the setup wizard doesn’t detect any Exchange 2010 SP1 (or later) servers, the tick box will be greyed out. Since we, in this article series, are dealing with an Exchange hybrid deployment based configuration based on Exchange 2013 servers, we wish to tick this option.

When ticking the “Enable Exchange hybrid deployment” box, we allow the WAAD Sync tool to perform write-back from Office 365 to the on-premises Active Directory for specific attributes. This is in order to allow support for features such as archive on-premises mailboxes in the cloud, off-board mailboxes from the cloud to on-premises Exchange servers, have on-premises filtering software take advantage of user made safe and blocked senders in the cloud and UM online voice mail.

With Exchange hybrid deployment enabled, write-back will be performed for the following attributes:

Write-Back attribute	Exchange “full fidelity” feature
SafeSendersHash BlockedSendersHash SafeRecipientHash	Filtering Coexistence: Writes back on-premises filtering and online safe and blocked sender data from clients.
msExchArchiveStatus	Online Archive: Enables customers to archive mail in Microsoft Online.
ProxyAddresses (LegacyExchangeDN as X500)	Enable Mailbox: Off-boards an online mailbox back to on-premises Exchange.
msExchUCVoiceMailSettings	Enable Unified Messaging (UM) – Online voice mail: This new attribute is used only for UM-Microsoft Lync Server 2010 or later integration to indicate to Lync Server 2010 or later on-premises that the user has voice mail in online services.

Table 1: Write-back attributes when hybrid deployment is enabled

When you have ticked “Enable Exchange hybrid deployment”, click “Next”.

Figure 26: Ticking enable “Hybrid Deployment”

Now we reach the new “Password Synchronization” page, where we have the option to enable password synchronization from the on-premises Active Directory users to the user objects in the Office 365 tenant. With password synchronization we can achieve SSO as in “same sign-on” not SSO as in “single sign-on”, which is possible with ADFS based federation between the on-premises environment and the Office 365 tenant.

Since we use ADFS based federation in this article series, make sure “Enable Password Sync” is unticked and click “Next”.

Figure 27: Password synchronization page

Wait for the WAAD Sync tool configuration wizard to complete the configuration.

Figure 28: Completing configuration

When configuration has completed, click “Finish”.

Figure 29: Configuration complete

Now make sure “Synchronize directories now” is selected and then click “Finish”. This will initiate the first synchronization from the on-premise Active Directory to the metaverse and the export from the metaverse to the Office 365 tenant.

Figure 30: Finished page

You will receive the warning shown in Figure 31, which includes a link to a TechNet page that explains how you can verify synchronization works properly. Click “OK”.

Figure 31: Warning message explaining how to verify synchronization is occurring properly

This concludes part 8 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online).

In this part of our article series we will take a look at the WAAD Sync tool engine and verify that objects synchronize as expected from our on-premises Active Directory to the Office 365 tenant.

Introduction

In part 8 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we installed and configured the Windows Azure Active Directory (WAAD) Sync tool on our Windows Server 2012 domain-member server and started object synchronization from the on-premises Active Directory to the Office 365 tenant.

In this part 9, we will continue where we left off in part 8. We will take a look at the WAAD Sync tool engine and verify that objects synchronize as expected from our on-premises Active Directory to the Office 365 tenant. In addition, I will talk a bit about what objects and attributes are synchronized to the Office 365 tenants as well as directory synchronization filtering.

Note:
The WAAD Sync tool was formerly known as the Directory Synchronization tool (DirSync tool).

Let’s get going…

Verifying Active Directory Object Synchronization

When it comes to verifying directory synchronization, what I usually do first is to launch the WAAD Sync tool UI shell by navigating to “C:Program FilesWindows Azure Active Directory SyncSYNCBUSSynchronization ServiceUIShell” and double-click on “miisclient” as shown in Figure 1.

Figure 1: Launching the MIIS client

In the “Synchronization Service Manager on DIRSYNC” console, you can see the status for the last run of each management agent. You can also see the number of added, updated and deleted objects etc.

If you have MIIS/ILM/FIM experience this is probably the best place to look in order to verify synchronization is running as expected.

Figure 2: Synchronization Service Manager on directory synchronization server

Besides the Synchronization Service Manager console, you can also look in the Application log. Here you can see event IDs that can give you a quick indication of the health state for the directory synchronization.

Figure 3: Directory Synchronization related event IDs in the Application log

Finally, we can check the Office 365 portal for when the last directory synchronization occurred (Figure 4).

Figure 4: Checking the time for the last synchronization in the Office 365 portal

You can also try to update a few attributes for a couple of users or create new users to see if the changes are reflected on the Office 365 user. To force a synchronization, see the next section.

Forcing a Directory Synchronization

Since delta synchronizations from your on-premises Active Directory forest to Office 365 are scheduled to run every 3 hours, there may be situations where you want to force a synchronization. This can be done using the “Start-OnlineCoexistenceSync” cmdlet. But in order to run this cmdlet, you must first launch a Windows Powershell console on the server and then navigate to “C:Program FilesWindows Azure Active Directory Sync” folder and from here run the “DirSyncConfigshell.psc1” script.

Figure 5: Windows PowerShell console

This will open another Windows PowerShell console where you can enter the “Start-OnlineCoexistenceSync” cmdlet. Doing so will immediately force a synchronization.

Figure 6: Running the Start-OnlineCoexistenceSync cmdlet

Switching back to the synchronization Service Manager, we can see that a delta import is in progress.

Figure 7: Delta Import in progress

List of Attributes Synchronized to Office 365 Tenant

So when it comes to object attributes that can be synchronized from the on-premises Active Directory to the Office 365 tenant, the WAAD Sync tool can sync approximately 140 different object attributes (for a complete list, see this KB article). In order for an object to be valid for sync, the following attributes need to contain values:

cn
member (applies only to groups)
samAccountName (applies only to users)
alias (applies only to groups and contacts)
displayName (for groups with a mail or proxyAddresses attribute populated)

Object-wise, the following five objects types are synchronized:

User accounts
Contact objects
Service accounts
Distribution groups
Security groups

By default the following objects are filtered based on name and value:

Any object is filtered if:

Object is a conflict object (DN contains 0ACNF:

Contact objects are filtered if:

DisplayName contains “MSOL” AND msExchHideFromAddressLists = TRUE
mailNickName starts with “CAS_” AND mailNickName contains “{“

SecurityEnabledGroup objects are filtered if:

isCriticalSystemObject = TRUE
mail is present AND DisplayName isn’t present
Group has more than 15,000 immediate members

MailEnabledGroup objects are filtered if:

DisplayName is empty
(ProxyAddress doesn’t have a primary SMTP address) AND (mail attribute isn’t present/invalid – i.e. indexof (‘@’) <= 0)
Group has more than 15,000 immediate members

User objects are filtered if:

mailNickName starts with “SystemMailbox{“
mailNickName starts with “CAS_” AND mailNickName contains “{“
sAMAccountName starts with “CAS_” AND sAMAccountName has “}”
sAMAccountName equals “SUPPORT_388945a0”
sAMAccountName equals “MSOL_AD_Sync”
sAMAccountName isn’t present
isCriticalSystemObject is present
msExchRecipientTypeDetails == (0x1000 OR 0x2000 OR 0x4000 OR 0x400000 OR 0x800000 OR 0x1000000 OR 0x20000000)

Directory Synchronization Filtering

Some (mostly large enterprise organizations) often wish to configure filtering, so that the WAAD Sync tool doesn’t synchronize each and every valid object in the on-premises Active Directory to Office 365. Fortunately, directory synchronization filtering is supported as long as one or a combination of the following methods are used:

Organizational-unit (OU)–based: You can use this filtering type to manage the properties of the SourceAD Management Agent in the Directory Synchronization tool. This filtering type enables you to select which OUs are allowed to synchronize to the cloud.
Domain-based: You can use this filtering type to manage the properties of the SourceAD Management Agent in the directory synchronization tool. This type enables you to select which domains are allowed to synchronize to the cloud.
User-attribute–based: You can use this filtering method to specify attribute-based filters for user objects. This enables you to control which objects should not be synchronized to the cloud.

For information about how you comfigure the above three directory synchronization methods, see this piece of TechNet documentation.

Directory Synchronization Limitations

There is a default limitation to how many objects that can be synchronized to an Office 365 tenant. The limitation is 50.000 by default. If you have a need to synchronize more than 50.000 objects into the tenant, then you need to open a service ticket with Office 365 support through the Office 365 portal or via phone.

When you do a default installation of the WAAD Sync tool, it will be configured to use a SQL Express 2012 instance locally on the directory synchronization server which has a database size limit of 10 GB.

If you have more than 50.000 objects that need to be synchronized to the Office 365 tenant, it’s recommended to configure the WAAD Sync tool to use a dedicated SQL instance on a SQL server. If this is relevant for your specific scenario, you need to install the WAAD Sync tool using the command prompt. See instructions on how this is accomplished here.

This concludes part 9 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online).

In this article, we will talk about what’s remaining when it comes to completing the Office 365 “Set up domain” wizard that we began configuring back in part 2.

Introduction

In part 9 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we took a look at the WAAD Sync tool engine and verified that objects synchronized as expected from our on-premises Active Directory to the Office 365 tenant. In addition, I talked a bit about what objects and attributes are synchronized to the Office 365 tenant as well as directory synchronization filtering.

In this part 10, we will continue where we left off back in part 2. Yes, that is right! Now that we have gone through the ADFS and directory synchronization configuration, we can again focus on the Exchange hybrid side of things. In this article, we will talk about what’s remaining when it comes to completing the Office 365 “Set up domain” wizard that we began configuring back in part 2. Then we will talk about the mail routing options you have at your disposal in an Exchange hybrid deployment and which one you should select to fit your specific scenario.

Let us get started.

Completing the Office 365 Add a Domain wizard

Okay so back in part 2 of this article series (seems like long time ago right?), we added our custom domain to the new Office 365 tenant. We confirmed ownership of the domain using a TXT record, specified how we wanted to add users and assign licenses (via directory synchronization) and finally specified the domain purpose for the custom domain (Exchange Online). However as you probably observed, we did not complete all steps under “Step 3”. After having selected the domain purpose and ticked the option that we will have mailboxes in the on-premises environment (Advanced Setup), we reached the page shown in Figure 1 below.

Figure 1: Step 2 of the “Set Up Domain” wizard

Before moving on with the “Set Up Domain” wizard, I want to talk a bit about the mail routing options, we have in regards to Exchange hybrid deployments. When it comes to mail routing in an Exchange hybrid configuration, we need to decide whether we want inbound messages from the Internet to route through the on-premises environment or if it should route through Exchange Online Protection in Office 365. Before deciding which mail routing path to go with, it’s critical you understand how each of them works as well as how they affect your environment.

Routing Inbound Messages through the Exchange Hybrid Servers

When it comes to how inbound messages from the Internet should be delivered to mailboxes in your environment, no matter if they are located on-premises or in Exchange Online, you can choose to keep the existing mail routing that is in place. That is, you can select to have all inbound messages from the Internet go through SMTP gateways in the on-premises perimeter network (such as Edge Transport servers or SMTP servers from 3rd party), directly to the Exchange Hub Transport servers on the internal network, or perhaps to a 3rd party online filtering service.

Note:
If you decide to keep the existing mail routing, that is have all mail route through your on-premises environment before it reaches one or more mailboxes on-premises or in Exchange Online, you can leave the MX record unchanged.

From my personal experience, most organizations choose to keep the existing mail routing because of one or more of the following reasons:

Compliance policies Organizations that need to apply compliance policies to messages sent to mailboxes on-premises as well as in Exchange Online.
3rd party application integration Organizations that have an on-premises or online service based application that need to manipulate or journal messages in transit.
Switch MX record at a later stage Organizations may not wish to switch the MX record to Exchange Online Protection until the migration to Exchange Online has been completed.

Depending on the complexity of the existing mail routing, it is generally a good idea to wait with switching the MX record to point to Exchange Online Protection (EOP).

When choosing to route inbound messages destined for an on-premises mailbox or a mailbox in Exchange Online through the existing mail route, the mail routing is as follows:

Sender from external organization sends an e-mail message to a recipient with a mailbox in the on-premises Exchange organization or in Exchange Online.
The e-mail message is either received by a:

third party filtering service on the Internet
SMTP servers in the perimeter network
by the Exchange Client access servers on the internal network

When the Client Access server in the on-premises organization receives the e-mail message depending on whether the destination mailbox is located in the on-premises Exchange organization or in Exchange Online, the e-mail message is routed to the on-premises mailbox servers on which the mailbox database holding the mailbox is stored or if the recipient has a mailbox in Exchange Online, it is routed on to Exchange Online Protection (EOP) based on the external e-mail address (targetAddress attribute) of the on-premises mail-enabled user object (MEU object) representing the mailbox in Exchange Online.
If the recipient has a mailbox in Exchange Online, Exchange Online Protection (EOP) routes the e-mail message on to a Client Access Server (remember in Exchange 2013, the CAS acts as SMTP front-end proxy) in Exchange Online.
The Client Access server in Exchange Online delivers the e-mail message to the respective mailbox server that currently have the active copy of the database in which the mailbox is stored.

Figure 2: Inbound & Outbound Routing via on-premises Hybrid servers

Note:
When moving a mailbox from on-premises Exchange to Exchange Online in a hybrid deployment, the mailbox-enabled user object in the on-premises Active Directory is converted to a mail-enabled user object once the mailbox move has completed.

Routing Inbound Messages through Exchange Online Protection

If you wish, and more importantly, are ready to route messages coming from the Internet through Exchange Online Protection (EOP) before they are delivered to either Exchange Online or on-premises mailboxes, you need to switch the MX record for your respective domain to point to EOP. Doing so will have all e-mail messages coming from the Internet to route through EOP, where spam and malware infected messages are filtered, prior to being delivered to the Exchange Online or on-premises mailboxes. A big pro of doing so is that you typically can get rid of the existing either Internet based filtering service or perimeter network based filtering servers, you have in place.

Note:
If you have compliance requirements such as journaling of all inbound e-mail messages, be aware that you can configure Exchange Online to achieve this. Over the recent years, a lot of energy and resources have been put into including features that can help fulfil legal and compliance requirements both for small and large organizations.

When choosing to route inbound messages destined for an on-premises mailbox or a mailbox in Exchange Online directly through Exchange Online Protection (EOP), the mail routing is as follows:

Sender from external organization sends an e-mail message to a recipient with a mailbox in the on-premises Exchange organization or in Exchange Online.
The e-mail message is received by Exchange Online Protection (EOP).
If the recipient has a mailbox in Exchange Online, EOP routes the e-mail message to a Client Access server in Exchange Online (If the mailbox is store in the on-premises Exchange organization, go to 5.)
The Client Access server in Exchange Online delivers the e-mail message to the respective mailbox server that currently has the active copy of the database in which the mailbox is stored.
If the recipient has a mailbox in the on-premises Exchange organization, EOP either routes the e-mail message to an Edge Transport server in the on-premises perimeter network or directly to an Exchange Client Access server on the internal network (if the latter, go to 7.).
The Edge Transport server routes the e-mail message to an Exchange Client Access server on the internal network.
The Client Access server delivers the e-mail message to the respective mailbox server that currently have the active copy of the database in which the mailbox is stored.

Figure 3: Inbound & Outbound Routing via Exchange Online Protection

Routing Outbound Messages directly to Destination

When it comes to messages sent from internal users in Exchange Online or the on-premises Exchange organization to external recipients, we have the option of having Exchange Online Protection and the on-premises Client Access server (or if used the Edge Transport server) route the e-mail message directly to the external recipient. This is also known as non-centralized transport.

When choosing to route outbound messages from an internal Exchange Online or on-premises mailbox directly to the recipient, the mail routing is as follows:

Internal sender with a mailbox in Exchange Online or on-premises Exchange organization sends an e-mail message to external recipient.

If the internal sender has a mailbox in on-premises Exchange organization, go to 2.
If the internal sender has a mailbox in Exchange Online go to 4.

If the internal sender has a mailbox in on-premises Exchange organization, the e-mail message is submitted from the respective Mailbox server to a Client Access server
The Client Access server routes to recipient (could be via an SMTP server in perimeter network or a filtering service on the Internet).
The e-mail message is submitted from the respective Mailbox server to a Client Access server in Exchange Online.
The Client Access server routes the message to Exchange Online Protection.
Exchange Online Protection routes the e-mail message to the destination.

Routing Outbound Messages through On-Premises Hybrid Servers

Lastly, when it comes to messages sent from internal users in Exchange Online or the on-premises Exchange organization to external recipients, we have the option of having all e-mail messages to be routed through the on-premises Client Access servers (or if used the Edge Transport server) prior to reaching the external recipient. This is also known as centralized transport.

When choosing to route outbound messages from an on-premises mailbox or Exchange Online mailbox through the Client Access servers in the on-premises Exchange organization and from there on to the external recipient, the mail routing is as follows:

Internal sender with a mailbox in on-premises Exchange organization or in Exchange Online sends an e-mail message to an external recipient.

If the internal sender has a mailbox in on-premises Exchange organization, go to 2.
If the internal sender has a mailbox in Exchange Online go to 4.

The on-premises Mailbox server submits the e-mail message to a Client Access server in the on-premises Exchange organization.
The Client Access server routes to recipient (could be via an SMTP server in perimeter network or a filtering service on the Internet).
The e-mail message is submitted from the respective Mailbox server to a Client Access server in Exchange Online.
The Client Access server routes the message to Exchange Online Protection.
Exchange Online Protection routes the e-mail message to hybrid servers in on-premises organization (could be via an Edge Transport server in the perimeter network).
The hybrid server routes to recipient (could be via an SMTP server in perimeter network or a filtering service on the Internet).

In this article series, we will route inbound mail through Exchange Online Protection (EOP). Outbound mail will be routed directly to the destination, which means outbound messages coming from Exchange Online won’t route through the on-premises Exchange hybrid servers.

This concludes part 10 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online).

In this article we will enable and configure the Exchange hybrid and have the on-premises hybrid servers, Exchange Online and Exchange Online Protection updated with the specified settings.

Introduction

In part 10 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we talked about what’s remaining when it comes to completing the Office 365 “Set up domain” wizard, we began configuring back in part 2. Then we will talked about the mail routing options, you have at your disposal in an Exchange hybrid deployment and which one you should select to fit your specific scenario.

In this part 11, we will continue where we left off back in part 10. That is we will enable and configure the Exchange hybrid and have the on-premises hybrid servers, Exchange Online and Exchange Online Protection updated with the specified settings..

Let’s get started.

Enabling Hybrid Mode

So back in part 10 of this article series, I took you through the different mail routing options we have when it comes to Exchange hybrid deployments and told you which mail routing option we will choose for this specific scenario. In this article series, we will have inbound messages route through Exchange Online Protection (EOP) before they reach Exchange Online as well as Exchange on-premises mailboxes. For outbound message routing, we will choose the non-centralized mail transport option, which allows outbound messages from Exchange Online to go directly to external recipients instead of through the hybrid servers in the on-premises Exchange organization.

Let’s get going with enabling hybrid mode. To do so, first logon to one of the Exchange 2013 servers that are to act as hybrid servers. Then open the “Exchange admin center” and click “hybrid” in the bottom of the left pane.

Under the “hybrid” page, click the “Enable” button.

Figure 1: Enabling Hybrid Mode using the Hybrid Configuration wizard

You will then be asked to login to Office 365 before you can continue. Do so by click on “sign in to Office 365”.

Figure 2: Signing into Office 365 with a global admin account

We will be taken to the Office 365 sign in page as shown in Figure 3.

Figure 3: Signing into the tenant using the Office 365 login page

If you now get an error message about cookies not being enabled for your Exchange Administration Center URL, you will need to add it to the local intranet zone or trusted zones in your browser. In addition, I suggest you add the Office 365 login page URL and the Office 365 portal to this zone.

Figure 4: Adding used URLs to the local intranet zone in Internet Explorer

After having added the respective URLs to the local intranet zone, try to authenticate against the Office 365 tenant again. This time it should go a little better. Now you should be able to switch between the “Enterprise” and “Office 365” modes without the need to authenticate.

Figure 5: Switching between “Enterprise” and “Office 365” mode

Let us continue with enabling and configuring hybrid mode by clicking “Yes” on the “Set up Exchange Hybrid”.

Figure 6: Set Up Exchange Hybrid page

On the next page, we see our custom domain, we are to configure Exchange federation for listing. Before clicking “Next” on this page, we need to copy the token and add it as a TXT record in external DNS in order to confirm ownership of the domain.

Figure 7: Confirming domain ownership using a TXT record

When you have added to TXT record to external DNS, go back and click the “Next” button shown in Figure 7.

Figure 8: TXT record added to external DNS

On the next page, we need to specify whether we have Edge Transport server in the perimeter network to route through or if it should go directly to the Client Access server (hybrid servers) on the internal network. In addition, this is where we can choose to use centralized transport (routing mail from Exchange Online through the on-premises hybrid servers).

Since we do not have any Edge Transport servers in this specific scenario or have a need for centralized transport, we will select the first option and leave centralized transport unticked.

Figure 9: Configuring mail routing options

On the next page, we need to specify one or more Client Access servers (hybrid servers) in which the receive connectors for bi-directional mail transport with Exchange Online will be created and configured.

In this specific scenario, we will add both our Exchange 2013 multi-role servers.

Figure 10: Adding Exchange 2013 Client Access servers as bi-directional transport servers

Click “Next”.

Figure 11: Client Access servers added to the hybrid wizard

Now we need to add the Exchange 2013 Mailbox servers that should host the send connectors used for bi-directional transport with Exchange Online. Since we use multi-role Exchange 2013 servers as hybrid servers in this specific scenario, we will add the same servers as those we added to host the receive connectors.

Figure 12: Adding the servers that should host send connectors

When the servers have been added, we can click “Next”.

Figure 13: Servers that should host send connectors added to the hybrid wizard

On the appearing page is where we should specify the certificate to be used with the hybrid configuration. In this specific scenario, we use the wildcard certificate that also was used for the ADFS based federation.

The certificate should be issued by a trusted CA provider. When the respective certificate has been selected, click “Next”.

Figure 14: Specifying the certificate to be used for Exchange federation

Sidebar: Exchange Hybrids with multiple SMTP Domains

When we had to configure Exchange 2010 hybrid servers against the previous version of Exchange Online, when our on-premises Exchange organization had multiple SMTP domains (address spaces), we needed to include all the SMTP domains in the SAN certificate that were used for the on-premises Exchange > Exchange Online federation. If we only included the “primary” SMTP domain, autodiscover would be in a broken state for external users that had a different primary SMTP address (i.e. “user@office365lab.dk”) than for the one included in the certificate (i.e. “clouduser.dk”).

In addition, we had to publish the autodiscover endpoint for each SMTP domain. This is because external users must have an SMTP address (i.e. “user@office365lab.dk”) that can be used to lookup autodiscover information (i.e. “autodiscover.office365lab.dk”).

Note:
The SRV based autodiscover redirect method is not supported for on-premises Exchange > Exchange Online federation. Also, in order to use the CNAME based autodiscover method, you would need to have all domain names present in a SAN certificate.

So at the end of the day, you had to do the following:

Include “autodiscover.domain.com” for each SMTP domain in the SAN certificate
Publish ”autodiscover.domain.com” for each used SMTP domain

There are organizations that use lots of SMTP domains (some are in the hundreds!) and as you can see, for these types of organizations, this isn’t really a feasible solution.

Now here is the good news! This all changed with Exchange 2013 CU1. With Exchange 2013 CU1, we now have the option of adding multiple SMTP domains to our Exchange federation/hybrid configuration and we can specify which of these domains should act as the “autodiscover” domain. By doing so we can eliminate the need for both adding “autodiscover.domain.com” for all SMTP domains to a SAN certificate as well as the need for publishing autodiscover for each of these.

Cool stuff eh?

To configure an SMTP domain as the autodiscover domain, you can use the following command:

Set-HybridConfiguration –Domains “domain1.com, domain2.com, domain3.com”, “autod:domain.com”

Below I’ve just two domains and specified one of them to be the autodiscover domain.

Figure 15: Configuring an autodiscover domain

After having run the command, you can run “Get-HybridConfiguration | fl” to see the domains as well as which one is configured as the autodiscover domain.

Figure 16: Autodiscover domain configured

Minor but extremely useful new feature in Exchange 2013 CU1. Oh and by the way, this feature has also been backported to Exchange 2010 SP3 RU1 in case you have to base a hybrid setup on Exchange 2010 hybrid servers.

Okay, let’s switch back to our hybrid mode configuration shall we?

We now have to specify the FQDN (in this case “smtp.clouduser.dk”, which is our MX record pointing directly to the Exchange 2013 Client Access servers) to which the Exchange Online Protection (EOP) service in Office 365 should connect for secure mail transport to the on-premises Exchange organization.

After having entered the FQDN, click “Next”.

Figure 17: Specifying the FQDN for secure mail transport to the on-premises Exchange organization

We now need to specify the credentials for an on-premises AD user member of the Organization Management group.

Do so and click “Next”.

Figure 18: Specifying the credentials for an on-premises AD user member of the Organization Management group

Then we need to specify the credentials for a global admin account in Office 365.

Do so and click “Next.

Figure 19: Specifying the credentials for a global admin account in Office 365

We have now completed the hybrid configuration and all there is left to do is to click “Update” in order for the specified hybrid servers on-premises, Exchange Online and Exchange Online Protection to be updated with the specified configuration settings.

Figure 20: Updating the Exchange hybrid configuration and enabling hybrid features

The update process will go through several processes. It will connect to the Office 365 tenant, configure recipient settings, create the organization relationships, configure mail flow and more.

Figure 21: Connecting to the Office 365 tenant

Figure 22: Configuring recipient settings

Figure 23: Configuring organization relationship

Figure 24: Configuring mail flow

After a few minutes, it should complete with the page shown in Figure 25.

Figure 25: Hybrid configuration update complete

Good job mate. You can now lean back and be proud of the progress you made so far.

This concludes part 11 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online).

In this article we will finish the configuration for the custom domain in Office 365, for which Exchange hybrid should be set up.

Introduction

In part 11 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we talked about what’s remaining when it comes to completing the Office 365 “Set up domain” wizard we began configuring back in part 2. Then we talked about the mail routing options you have at your disposal in an Exchange hybrid deployment and which one you should select to fit your specific scenario.

In this part 12, we will continue where we left off back in part 11. That is we will finish the configuration for the custom domain in Office 365, for which Exchange hybrid should be set up.

Let’s get started.

Creating DNS Records in External DNS

So back in part 11 of this article series, when we set up the Exchange hybrid, you probably noticed that although the Exchange hybrid wizard completed successfully, we got an informational notice that said Office 365 was unable to communicate with the on-premises Autodiscover endpoint and that this issue usually is caused by incorrect DNS or firewall configuration. So in my specific case, the explanation is simple. I haven’t created the Autodiscover record in external DNS yet.

So before continuing, let’s make sure Office 365 can resolve our Autodiscover endpoint. I’ll do this by logging in to the web interface of the external DNS provider I use and then add an A-record (autodiscover.clouduser.dk) pointing to public IP address that NATs to the VIP address associated with the Exchange 2013 server in my lab environment. I do not use TMG , UAG, ARR or a third party solution to publish my server as I do not have any requirements for pre-authentication. In fact even though, I used TMG or another solution I wouldn’t be able to use pre-authentication for Autodiscover or EWS for that matter as it simply isn’t supported when setting up an Exchange hybrid.

Figure 1: Creating the Autodiscover A-record in external DNS

In addition to publishing Autodiscover, it’s also important that Outlook Web App (OWA), Outlook Anywhere (OA), Exchange Active Sync (EAS) and Exchange Web Services (EWS) is accessible from the Internet. In my lab these services can be reached via “webmail.clouduser.dk”.

Figure 2: URL used to reach OA, OWA, EAS and EWS

With the Autodiscover service now being accessible from the Internet, let’s move on to the next step, which is to have the “Set up domain” wizard in the Office 365 portal to verify the required outbound connectors have been created by the hybrid configuration wizard.

To do so, select the respective custom domain and then under “step 2”, click “done, go check”.

Figure 3: Verifying outbound connectors has been created by the HCW

So as we can see, the “Set up domain” wizard in my scenario verified outbound connectors are set up for the domain with success.

The “Set up domain” now recommends we run the Microsoft Remote Connectivity Analyzer in order to verify that the required DNS records are in place. They are in this case as OA, OWA, EAS, EWS and Autodiscover are accessible from the Internet.

Let’s click “next”.

Figure 4: Verification of outbound connectors successful

This brings us to “step 3” which also is about adding DNS records to the external DNS provider. All records except the last are Exchange Online specific:

MX Record Because we wish to route inbound mail for both users with a mailbox in Exchange Online and users with a mailbox in the on-premises Exchange organization through Exchange Online Protection (EOP) part of Office 365, we need to change our MX record so that it points to the address listed under MX in Figure 5 more specifically “clouduser-dk.mail.protection.outlook.com”. Bear in mind that the MX record is tenant specific.
Autodiscover CNAME record In scenarios where all user mailboxes have been moved to Exchange Online, we can switch the autodiscover record to point directly to Exchange Online instead of at the on-premises Exchange organization. In our case, we will have user mailboxes in both Exchange Online and the on-premises Exchange organization over a period (which is the case in most scenarios that involve an Exchange hybrid), so we’re not interested in pointing the autodiscover record at Exchange Online as that would break autodiscover lookups for on-premises user mailboxes. Said in another way, we will skip this step. If we wanted to point autodiscover to Exchange Online, we would need to direct “autodiscover.clouduser.dk” to “autodiscover.outlook.com” using a CNAME record.
TXT record You probably already have an SPF TXT record in place, that includes the public IP addresses associated with your Edge servers in the perimeter network or directly to the Exchange servers on the internal network. In short, an SPF TXT record helps to prevent other people from using your domain to send spam or other malicious email. Sender policy framework (SPF) records work by identifying the servers that are authorized to send email from your domain. We need to add “spf.protection.outlook.com” to this record.
MSOID CNAME record This record was added as an additional record recently. As mentioned, it’s not Exchange Online specific but is used by Office 365 to direct authentication to the correct identity platform (there are two OrgIDs in Office 365 now). For my tenant, I would need to create a CNAME record that redirect “msoid.clouduser.dk” to “clientconfig.microsoftonline-p.net”.

Figure 5: Required Exchange Online and authentication DNS records

In the following figures, you can see the DNS records created on my DNS provider.

Figure 6: MX record pointing to Exchange Online Protection (EOP) in Office 365

Figure 7: SPF record

Figure 8: Authentication CNAME record

In Figure 9, we can see each created record is returned, when doing an NSLookup.

Figure 9: NSLookup for MX, TXT and CNAME records

After creating the required DNS records and we have made sure they have replicated, let’s click “done, go check”.

Figure 10: Clicking “done, go check” to verify the required DNS records are in place

If DNS records have replicated, you will now see this page shown in Figure 11. Notice, we get an error informing us the autodiscover record couldn’t be found. This is expected if you do not point autodiscover to Exchange Online. When dealing with Exchange hybrid scenarios, the error can be ignored.

Figure 11: Autodiscover record pointing to Exchange Online missing

Click “close, and return later” and then “cancel”.

We have now set up the custom domain for Exchange hybrid purposes.

This concludes part 12 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online).

In this article we will take a look behind the scenes by looking at the hybrid configuration settings performed by the hybrid configuration wizard.

Introduction

In part 12 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we finished the configuration for the custom domain in Office 365, for which Exchange hybrid should be set up.

In this part 13, we will continue where we left off back in part 12. That is we will take a look behind the scenes by looking at the hybrid configuration settings performed by the hybrid configuration wizard.

Let’s get started.

A Look at the Hybrid Configuration Settings

So back in part 11 and 12, we established a hybrid configuration between our on-premises Exchange 2013 organization and Exchange Online in Office 365. Let’s take a look at the things that were created behind the scenes when we ran the Hybrid Configuration Wizard (HCW).

Let’s first look at the hybrid configuration object itself. We can do so by launching the Exchange Management Shell (EMS), and run the following command:

Get-HybridConfiguration

Figure 1: Listing the configuration for the hybrid configuration object in the on-premises Exchange organization

As you can see above in Figure 1, the settings (such as receiving and sending transport servers, on-premises smart host and domains) you specified when we ran the wizard have been set on the hybrid configuration object. But, this is far from the only thing that has been configured. You can also see which features have been enabled (“FreeBusy”, “MoveMailbox”, “MailTips”, “MessageTracking”, “OwaRedirection”, “OnlineArchive”, “SecureMail”), which are all features we wish to have enabled between the on-premises Exchange organization and the Exchange Online organization in Office 365.

Important:
The “ClientAccessServers” parameter is deprecated and will be removed from Exchange Server 2013 sometime in the future, which explains why it is blank. Also, bear in mind that we no longer need to have any public IP addresses configured for the hybrid configuration. This was required in Exchange 2010 based hybrid deployments, so that we could specify the IP addresses that were allowed to send to the inbound connector in FOPE.

Note:
Since we either use Exchange 2010 Edge Transport servers or have enabled centralized transport, the “EdgeTransportServers” attributes is blank and “CentralizedTransport” is missing under “Features”.

In addition, the following has also been performed in the on-premise Exchange organization:

A federation trust with the Microsoft Federation Gateway (MFG) has been established for the specified domain:

Figure 2: Federation Trust in the Exchange Management Console

Creating a federation trust with the MFG is required in order to be able to set up an organizational relationship, which again is required in order to share free/busy information and calendars between the on-premises Exchange organization and the Exchange Online organization in Office 365. With that said, it’s important to note that a trust isn’t set up with the MFG, instead the MFG merely acts as a trust broker between the involved Exchange organizations.

“tenant_name.mail.onmicrosoft.com” (in our scenario “clouduserdk.onmicrosoft.com”) has been added as an accepted domain:

Figure 3: New accepted domain in the Exchange admin center (EAC)

Adding the “tenant_name.mail.onmicrosoft.com” domain to the “Accepted Domains” list as an authoritative domain is required in order for the on-premises Exchange organization to accept inbound e-mail messages destined for a mailbox user located in Exchange Online. When a mailbox is moved from the on-premises Exchange organization to Exchange Online, the source mailbox user object is converted to a mail user object, which is configured with an external address of “alias@clouduserdk.onmicrosoft.com“. We will look more at this later in this article series.

“tenant_name.mail.onmicrosoft.com” (in our scenario “clouduserdk.onmicrosoft.com”) has been added as a remote domain. Since remote domains are not exposed in the Exchange admin center (EAC), we must use the “Get-RemoteDomain” cmdlet to see this.

Figure 4: New remote domains in the Exchange Management Console

A remote domain is an SMTP domain that is external to our Exchange organization. When a new remote domain is created, it’s possible to specify the remote domain is used for Exchange Online purposes. With a remote domain, we can configure out of office and message formatting settings. The HCW sets the ideal setting for a hybrid and enables the SMTP domain as the domain used for an Office 365 tenant, which is important in relation to provisioning of new remote mailbox users (users that get a mailbox created directly in Exchange Online).

The default E-Mail Address policy has been updated, so that it stamps a secondary proxy address (alias@clouduserdk.mail.onmicrosoft.com) on mailbox user objects:

Figure 5: New SMTP address added to the default E-mail Address Policy

The SMTP address “alias@clouduserdk.mail.onmicrosoft.com“ is added to the default E-mail address policy, so that it can be stamped as an additional proxy address on the mail objects in the organization. As mentioned earlier, when a mailbox is moved to Exchange Online, the source mailbox user object is converted to a mail user object and in order to be able to set “alias@clouduserdk.mail.onmicrosoft.com“ as the external e-mail address, it must already be stamped on the object.

Figure 6: Secondary proxy address stamped on mailbox user object

In addition, the HCW will create a send connector that will route all e-mail messages destined for “tenant_name.mail.onmicrosoft.com” (in this scenario “clouduserdk.mail.onmicrosoft.com”) in our on-premises Exchange 2013 environment to Exchange Online in Office 365 (see Figure 7).

Figure 7: Outbound connector to Office 365

The send connector is configured to use DNS to look up the MX record of the destination server.

Figure 8: DNS used to lookup the MX record for the destination server

The send connector is configured with an address space of “clouduserdk.mail.onmicrosoft.com”, so that only e-mail messages destined for Exchange Online users in Office 365 is routed via this send connector.

Figure 9: Address space for the outbound connector to Office 365

Unlike with Exchange 2010 based hybrid deployments, the HCW no longer creates an Office 365 specific receive connector on our hybrid servers (see Figure 10).

Figure 10: No Office 365 specific receive connectors created by the HCW

Finally, as we could also see back in Figure 2, an organizational relationship has been created to establish Exchange federation with the Exchange Online organization in Office 365.

Figure 11: Listing details for the organizational relationship

Just like it’s the case with Exchange 2010 based hybrid deployments, by default, free/busy is enabled with limited details. In addition, mailbox moves, delivery reports, mailtips and online archive are enabled. Moreover, a target OWA URL is specified and by default, which is set to: “http://outlook.com/owa/tenant_name.onmicrosoft.com”. The target OWA URL is the URL that a user will be non-transparently redirected to (we will look at this later in this article series), when he tries to access his mailbox using the existing OWA namespace (i.e. http://mail.domain.com/owa) after his mailbox has been moved to Exchange Online. Lastly, a target autodiscover Epr has been set by the HCW. This is the endpoint used to reach out to the Exchange Online organization for the configured features, when a request comes from the on-premises Exchange organization to the Exchange Online organization.

This concludes part 13 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online).

In this article we will take a look behind the scenes by looking at the hybrid configuration settings set by the hybrid configuration wizard in the Exchange Online organization in Office 365.

Introduction

In part 13 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we took a look behind the scenes by looking at the hybrid configuration settings performed by the hybrid configuration wizard on the Exchange hybrid servers on-premises.

In this part 14, we will continue where we left off back in part 13. That is we will take a look behind the scenes by looking at the hybrid configuration settings set by the hybrid configuration wizard in the Exchange Online organization in Office 365.

Let’s get started.

A Look at the Hybrid Configuration Settings in Office 365

So back in part 13, we focused on the Exchange hybrid related configuration settings that were set on the Exchange 2013 servers on-premises, when we ran the hybrid configuration wizard. Of course, the hybrid configuration wizard also performs several configuration settings in the Exchange Online organization in Office 365. Let’s take a look at what was configured. To do so, open the “Exchange admin center” and then click on the “Office 365” link in the top left of the screen.

Just like for the on-premises Exchange organization, the respective domains used for routing between on-premises and Exchange Online has been added as “Accepted Domains” in the Exchange Online organization in Office 365.

Figure 1: Accepted domains in the Exchange Online organization

For the mailbox-enabled user objects in the on-premises Active Directory that has been synchronized to the Office 365 tenant as mail-enabled user (MEU) objects, the external email address (targetAddress attribute) on the MEU object has been set to “alias@clouduser.dk”, so that all email messages sent from the Exchange Online organization (and from the Internet since we have chosen to route mail from external senders via Exchange Online Protection) to a user that hasn’t had his mailbox migrated yet is routed to his mailbox on-premises. In addition, the MEU objects in the Exchange Online organization also have a “alias@clouduserdk.mail.onmicrosoft.com” proxy address, so that email messages sent to a migrated mailbox from a non-migrated mailbox is routed to the mailbox in the Exchange Online organization – again via the external email address (targetAddress attribute) set on the MEU object after the object is converted from a mailbox enabled object to a MEU object. We’ll look closer at this later.

Figure 2: External E-Mail address on MEU object on-premises

Unlike in wave 14 of Office 365, we no longer configure any remote domains added in the Exchange Online organization.

Figure 3: No remote domains in Exchange Online

And by the way, before you try to find the “Remote Domains” tab in the Exchange admin center (EAC), I should probably tell you it’s not there. You need to use PowerShell for this.

When it comes to connectors, then the hybrid configuration wizard (HCW) has created an inbound and an outbound connector in Exchange Online Protection (EOP) as shown below. So far, it’s identical to how it was done back in FOPE in the old Office 365 (wave 14).

Figure 4: Inbound and Outbound connectors in Exchange Online Protection (EOP)

However back with FOPE, the hybrid configuration wizard (HCW) created an inbound and an outbound connector that couldn’t be modified directly via FOPE administration console. In EOP, the connectors can be modified as you wish. Not that you generally should do this, but we have the permissions to modify them as required.

In addition, the connectors created in EOP are configured slightly different than those in FOPE. As some of you may recall, the inbound connector the HCW created in FOPE was locked down so that only the public IP addresses we specified in the Exchange 2010 HCW were allowed to route mail to the Exchange Online organization. And of course forced TLS based on certificate domain matching was also configured.

The outbound connector created in FOPE was configured to point to a specific endpoint FQDN (depending on the on-premises scenario something like hybrid.contoso.com). And again, it was configured with forced TLS based on certificate domain matching.

Figure 5: Inbound and Outbound connectors back in FOPE (wave 14)

In EOP the inbound connector is configured as follows. The “Connector Type” is set to “On-Premises” and “Retain service headers on transmission” is enabled.

Figure 6: General configuration settings for the Inbound connector in Exchange Online Protection (EOP)

On the “security” property page, we are forcing TLS based on certificate domain matching. “Domain Restrictions” is set to “None”.

Figure 7: Security configuration settings for the Inbound connector in Exchange Online Protection (EOP)

On the “scope” property page, an asterisk (*) representing all domains has been added to “Domains”.

Figure 8: Scope configuration settings for the Inbound connector in Exchange Online Protection (EOP)

In EOP, the outbound connector is configured as follows. Just like it’s the case with the inbound connector, “Connector Type” is set to “On-Premises” and again “Retain service headers on transmission” is enabled.

Figure 9: General configuration settings for the Outbound connector in Exchange Online Protection (EOP)

On the “security” property page, “Connection Security” is set to “Recipient certificate matches domain”.

Figure 10: Security configuration settings for the Outbound connector in Exchange Online Protection (EOP)

On the “delivery” property page, “Outbound Delivery” is set to “Route mail through smart hosts” pointing to “smtp.clouduser.dk”, which is the SMTP endpoint for my lab environment.

Figure 11: Delivery configuration settings for the Outbound connector in Exchange Online Protection (EOP)

On the “scope” property page, my custom domain “clouduser.dk” has been added under domains.

Figure 12: Scope configuration settings for the Outbound connector in Exchange Online Protection (EOP)

Finally, like in the on-premises Exchange organization, an organizational relationship has been created to establish Exchange federation with the on-premises Exchange organization.

Figure 13: Organization and individual sharing policies

Figure 14 shows the configuration for the organization relationship in detail.

Figure 14: Configuration of the organization relationship in the Exchange Online organization

Just like is the case with Exchange 2010 based hybrid deployments, by default, free/busy is enabled with limited details. In addition, delivery reports and mailtips are enabled. Moreover, a target autodiscover Epr has been set by the HCW. This is the endpoint used to reach out to the on-premises Exchange organization for the configured features, when a request comes from the Exchange Online organization to the on-premises Exchange organization.

This concludes part 14 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online).

In this part 15, we will continue where we left off back in part 14. That is we will take a look at the mailbox migration options at our disposal when moving on-premises Exchange mailboxes to Exchange Online in an Exchange hybrid deployment.

Introduction

In part 14 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we took a look behind the scenes by looking at the hybrid configuration settings performed by the hybrid configuration wizard in the Exchange Online organization in our Office 365 tenant.

Let’s get started with this part 15.

Enable Mailbox Replication Service (MRS) Proxy

So as some of you probably know, the Mailbox Replication Service (MRS) Proxy service helps facilitate cross-forest remote mailbox moves. It’s often used when performing a cross-forest migration from a legacy Exchange organization (containing at least one Exchange 2010 or 2013 CAS server as the MRSProxy must be enabled in the source organization) to an Exchange 2010 or 2013 organization. The MRSProxy makes remote mailbox moves more seamless because it, among other things, encapsulates all communication between the organizations in HTTPS packets. If an organization decides to move to Exchange Online in Office 365 (which is the case in this article series) and the organization uses an Exchange hybrid deployment, they also use the MRS Proxy.

With Exchange 2010 based hybrid deployments, the MRS Proxy was enabled when running the hybrid configuration wizard (HCW), but with Exchange 2013 based hybrid deployments, we must enable MRS Proxy manually.

To enable MRS Proxy, open the Exchange admin center (EAC) on an Exchange 2013 hybrid server, then click “servers” and then the “virtual directories” tab.

Figure 1: Virtual directories on Exchange 2013 hybrid servers

Under the “virtual directories” tab, open the property page for each EWS (Default Web Site) virtual directory on each hybrid server and tick “MRS Proxy enabled” and then click “save”.

Figure 2: Enabling MRS Proxy on the Exchange 2013 hybrid servers

Moving a Mailbox to Exchange Online

It’s time to move a few mailboxes to Exchange Online. Unlike with Exchange 2010 based hybrids, we use so called migration batches and migration endpoints behind the scenes for this task in Exchange 2013.

In order to do so in a hybrid deployment scenario where we have Exchange 2013 on-premises and the Exchange 2013 based Exchange Online version, we can create new remote move requests using the following methods:

Via the Exchange admin center on an Exchange 2013 hybrid server on-premises
Via the Exchange admin center in Exchange Online
Via Remote PowerShell connected to Exchange Online

In this article, we will use the first method, but I will also show you the differences between method 1 and 2 as well as provide you with sample cmdlets for method 3.

Using the Exchange admin center on an Exchange 2013 hybrid server on-premises

To move mailboxes to Exchange Online using the Exchange admin center on an Exchange 2013 hybrid server in the on-premises environment, we need to go to “recipients” and click “mailboxes” as shown in Figure 3. Here we can select the mailbox or mailboxes, we wish to move to Exchange Online followed by clicking ”To Exchange Online” under “Move Mailbox” in the “Action Pane”.

Figure 3: Selecting user mailboxes that should be migrated to Exchange Online

This launches the “new migration batch” wizard and on the first page, we need to provide the credentials for a user that is a member of the “Organization Management” role group in our on-premises Active Directory.

Click “next”.

Figure 4: Specifying credentials of on on-premises Exchange administrator

The “new migration batch” wizard will now try to automatically determine the migration endpoint (MRS Proxy FQDN) to be used. If it doesn’t succeed, you have the option to enter it manually. The migration endpoint usually matches the external URL configured for the EWS virtual directory. In my case, it’s “webmail.clouduser.dk”.

Note:
On this page you will also be notified about whether the MRS Proxy is enabled or not.

Click “next”.

Figure 5: Remote MRS Proxy FQDN

Okay, it’s time to name the migration batch. The name can be anything, but if you are going to create multiple migration batches, it’s a good idea to just call them “Migration Batch 1”, “Migration Batch 2” etc.

On this page, you should also make sure the correct target delivery domain is listed. This should be “yourtenantname.mail.onmicrosoft.com”.

Finally, you have the option to specify whether an associated archive mailbox should be moved and configure the bad and large item limit.

Click “next”.

Figure 6: Remote Move configuration

We’re now taken to the “start the batch” page. Here we can specify the recipient that should receive an email with migration information and a link to a CSV based migration report.

On this page, you also have the option to specify whether the migration batch should be started manually, automatically or whether it should be scheduled to occur sometime in the future. Same goes for the completion of the migration batch.

Click “new”.

Figure 7: Starting the migration batch

The migration batch will now be created and you will be faced with the dialog box shown in Figure 8. Let’s click “yes” so we’re taken to the migration dashboard.

Note:
As can be seen in Figure 8, an alert is also generated that can be seen by all global administrators logging into the portal, while the migration batch is running.

Figure 8: Opening the migration dashboard.

In the migration dashboard, we can see the actual status for the mailboxes included in the migration batch. To see more details about the migration batch, let’s click “view details” in the highlighted area in Figure 9.

Important:
When we click “yes” to the dialog box shown in Figure 8, notice we are taken to the migration dashboard in Exchange Online and not the migration dash board on the Exchange 2013 hybrid servers. The reason for this is that when you create a migration batch, the batch is created in Exchange Online not on-premises and the MRS service pulls the mailbox data from the on-premises mailboxes using the MRS Proxy on the Exchange 2013 hybrid servers.

Figure 9: Viewing details of the migration batch

On the migration batch detail page, we can see the mailboxes listed, the status for each and how many items that have been synched to the mailbox that is provisioned in Exchange Online.

Figure 10: Further migration batch details

In the migration dashboard, we also have the option to click “Status for all batches”, which takes us to the page shown in Figure 11.

Figure 11: Status for all migration batches

Back in Figure 7, I chose to complete the migration batch manually, so once the mailbox data for each mailbox has been fully synched to Exchange Online, I need to click “Complete this migration batch” to finalize the migration batch.

Figure 12: Migration batch fully synched

Click “yes”.

Figure 13: Migration batch completion warning

After a little while, the status for the migration batch will changed to completed (remember to refresh the page).

Figure 14:

The recipient that was specified in the migration batch has now received an email similar to the one shown in Figure 15. In this email is included a link to a CSV based migration report.

Figure 15: Email sent to specified recipient after migration batch has completed

When a migration batch has completed, it’s recommended to delete it so that errors don’t occur should the same users be moved again.

Note:
The migration endpoint that was created for migration batch will not be deleted and can be re-used for new migration batches created in the future.

You can find the migration endpoint by clicking the dots (“…”) in the migration dashboard or by connecting to Exchange Online using Windows PowerShell and run:

Get-MigrationEndPoint | fl

Figure 16: Migration endpoints page

Figure 17: Migration endpoint details in Exchange Online using Windows PowerShell

Using the Exchange admin center in Exchange Online

If you want to create a migration batch directly in Exchange Online instead of selecting the users via the Exchange 2013 hybrid servers, you will need to go the EAC and then click “Office 365” as shown in Figure 18.

Now click “recipients” and then the “migration” tab.

Figure 18: Opening migration dashboard in Exchange Online

Click on the “plus” icon and select “Migrate to Exchange Online”.

Figure 19: Selecting migrate to Exchange Online in drop-down menu

Now you need to select the “migration type”, which of course is the first type listed.

Figure 20: Specifying migration type

Like was the case with method 1, you now need to select the users to be migrated to Exchange Online. Notice that you also have the option of specifying a CSV file with a list of the user mailboxes to be migrated.

Figure 21: Options for selecting users to be migrated

The rest of the pages are more or less identical to method 1, so no need to go through them here.

Using Remote PowerShell connected to Exchange Online

If you want to use Remote PowerShell to migrate user mailboxes, you first need to connect to Exchange Online using Windows PowerShell. You can do this using:

$LiveCred = Get-Credential

In the appearing dialog box, enter the credentials for a Global Administrator in the Office 365 tenant and then run the following command:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic –AllowRedirection

When the session has been created, you can import using this command:

Import-PSSession $Session

Now that we are connected to Exchange Online, we first need to create the migration endpoint. To do so, first enter the following and then specify the credentials of an account that is member of the “Organization Management” role group in the on-premises Active Directory.

$OnPremCreds = Get-Credential

You can now create the migration endpoint with this command:

$MigrationEndpointOnPrem = New-MigrationEndpoint -ExchangeRemoteMove -Name OnpremEndpoint -Autodiscover -EmailAddress administrator@clouduser.dk -Credentials $OnPremCreds

You will need to replace the domain part in the email address with the one used in your environment.

In this example, we will migrate all users listed in a CSV file located on our system partition:

$OnboardingBatch = New-MigrationBatch -Name MigrationBatch1 -SourceEndpoint $MigrationEndpointOnprem.Identity -TargetDeliveryDomain clouduserdk.mail.onmicrosoft.com -CSVData ([System.IO.File]::ReadAllBytes(“C:MigrationBatch1.csv”))

To start the migration batch, we use the following command:

Start-MigrationBatch -Identity $OnboardingBatch.Identity

For details around how the CSV file should be constructed, see this piece of TechNet documentation.

This concludes part 15 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online).

In this article we will log on to the mailbox using Outlook Web App (OWA), Outlook Anywhere and Exchange ActiveSync (EAS) so that we can verify that the mailbox that has been moved from on-premises Exchange to Exchange Online behaves as expected.

Introduction

In part 15 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we took a look at the mailbox migration options at our disposal when moving on-premises Exchange mailboxes to Exchange Online in an Exchange hybrid deployment.

In this part 16, we will continue where we left off back in part 15. That is, we will log on to the mailbox using Outlook Web App (OWA), Outlook Anywhere and Exchange ActiveSync (EAS) so that we can verify that we see the expected behavior for a mailbox that has been moved from on-premises Exchange to Exchange Online. Moreover, we will verify that availability lookups between Exchange Online and Exchange on-premises mailboxes work as expected.

Let’s get started.

What Happens when a Mailbox is moved to Exchange Online?

Before we start to look at how a mailbox moves to Exchange Online affects the miscellaneous Exchange clients, let’s quickly talk about what happens server-side when a mailbox is moved to Exchange Online.

As mentioned back in part 13, the SMTP address “alias@clouduserdk.mail.onmicrosoft.com“ is added to the default e-mail address policy so that it can be stamped as an additional proxy address on the mail objects in the organization.

Figure 1: Exchange Online routing address stamped on user mailboxes in on-premises Exchange organization

When a mailbox is moved to Exchange Online, the source mailbox user object is converted to a mail user enabled (MEU) object and the secondary proxy address “alias@clouduserdk.mail.onmicrosoft.com“ is set as the external e-mail address. Back with Exchange 2010 based hybrids, the mailbox would be removed from the mailbox view and could instead be found listed as a Remove User Mailbox under the “Recipient Configuration” > “Mail Contacts” node.

With an Exchange 2013 based hybrid deployment, it can still be found under the “mailboxes” tab as an “Office 365” mailbox type as shown in Figure 2.

Figure 2: Mailbox type for move mailbox

MEU objects are required in an Exchange hybrid in order for mail flow, availability lookups and autodiscover to work seamlessly between the on-premises Exchange organization and the Exchange Online organization in Office 365. As some of you might know, when an Exchange client such as Outlook queries availability of another mailbox, it will use autodiscover to find the Exchange organization in which the mailbox is located. For typical on-premises Exchange organization, the availability information will be retrieve on the local Exchange servers. However, in an Exchange hybrid deployment the autodiscover service will detect the MEU object and send the request on to the respective domain based on the external email address. So when an on-premises mailbox user queries availability for a mailbox in Exchange Online, the request will be sent to alias@clouduserdk.mail.onmicrosoft.com.

How are the miscellaneous Exchange clients affected by a Mailbox move to Exchange Online?

In the following, I’ll explain how a mailbox move to Exchange Online will affect the miscellaneous Exchange clients used to access the respective mailbox.

Outlook Web App

If a user is logged on to his on-premises Exchange mailbox using the Outlook Web App (OWA) client, the session will break when the migration batch is completed automatically or manually, depending on what you choose to do. This means that a user that is logged on to his on-premises mailbox, when the mailbox move for his mailbox is completed, will need to establish a new OWA session against Exchange Online.

Just like with Exchange 2010 hybrid deployments, the user will still be able to use the OWA URL pointing to the on-premises Exchange 2013 servers. He will just be presented with the redirection page shown in Figure 3, where he can choose to save the new URL to his browser favorites and click on the URL.

Important:
If you do not run Exchange 2013 CU3, the OWA redirection to Exchange Online will not work. For more information, see this KB article.

Figure 3: OWA redirection page

When clicking on the URL, the user will be taken through the authentication process. For OWA, that means the user will try to access his mailbox in Exchange Online and Exchange Online will redirect the user to “login.microsoftonline.com”, where he can enter his UPN. Once the UPN is entered and he switches to the password field, Office 365 will detect that the UPN domain is federation with an Office 365 tenant. This results in a redirect to the on-premises federation endpoint (in this case sts.clouduser.dk) and depending on whether the user is domain-joined and domain-connected or uses an external client, he will get single sign-on (SSO) or be required to enter his UPN and password.

Figure 4: OWA in Exchange Online

Because of the organization relationship that was set up between Exchange Online and Exchange on-premises during the Exchange hybrid configuration, availability lookups when booking meetings, Mailtips etc. also works as expected from Exchange Online to Exchange on-premises and vice versa.

Figure 5: Availability lookups between user mailboxes in Exchange Online and Exchange on-premises

Outlook Anywhere

If a user is logged on to his on-premises Exchange mailbox using the Outlook client, then the client will be disconnected from the on-premises mailbox (as the AD object is converted to a MEU object), when the migration batch is completed automatically or manually depending on what you choose to do. This means that a user that is logged on to his on-premises mailbox using Outlook, when the mailbox move for his mailbox is completed, will see the status shown in Figure 6 at the bottom of the Outlook client.

Figure 6: Outlook in disconnected state

If we open the connection status windows, we can also see this.

Figure 7: Disconnected state in the Outlook connection status windows

And after a little while the dialog box shown in Figure 9 pops up prompting the user to restart Outlook.

Figure 8: User prompted to restart Outlook

When he launches Outlook again, he will be prompted for credentials. This is expected as the Outlook client uses basic authentication against Exchange Online. The user should enter his UPN and password and if he ticks “Remember my credentials”, they will be saved in the credential manager on the client resulting in single sign-on next time the user launches Outlook.

Note:
When a user changes password (i.e. password expires), then the user will be prompted for credentials in Outlook until the password is updated in the credentials manager.

Figure 9: User prompted for credentials when launching Outlook after the mailbox move to Exchange Online

Now Outlook is in a connected state again and if we open the connection status window, we can see that the client now is connected to Exchange Online.

Figure 10: Connection status window after client has connected to Exchange Online

Just like is the case with OWA, because of the organization relationship that was set up between Exchange Online and Exchange on-premises during the Exchange hybrid configuration, availability lookups when booking meetings, Mailtips etc. also work as expected from Exchange Online to Exchange on-premises and vice versa.

Figure 11: Availability lookups between user mailboxes in Exchange Online and Exchange on-premises

Exchange ActiveSync

When dealing with mailbox moves from Exchange on-premises to Exchange Online, the Exchange ActiveSync client will not be able to automatically update the ActiveSync profile via the autodiscover redirect to Exchange Online. The profile must be reconfigured manually. This is true for all ActiveSync client types (Windows Phone, iPhone, Android etc.).

This concludes part 16 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online).

This article concludes the series on how to configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online).

Introduction

In part 16 of this multi-part article series revolving around Exchange 2013 hybrid deployment based migrations to the new Office 365 or more precisely Exchange Online, we logged on to the mailbox using Outlook Web App (OWA), Outlook Anywhere and Exchange ActiveSync (EAS) in order to verify we saw the expected behavior for a mailbox that had been moved from on-premises Exchange to Exchange Online. Moreover, we verified that availability lookups between Exchange Online and Exchange on-premises mailboxes worked as expected.

In this part 17, we will continue where we left off back in part 16.

Let’s get started.

Exchange On-Premises Servers going forward

So depending on your specific scenario, your plan is probably to keep a portion of your mailboxes on-premises and the other portion in Exchange Online or simply moving all mailboxes to Exchange Online in order to get rid of your on-premises Exchange servers altogether so you don’t waste money on what you may see as unnecessary things such as support, management, server licenses, power, cooling and hardware maintenance contracts.

Okay so here’s the thing. As you know, we have configured DirSync and made the on-premises Active Directory the so called source of authority. That means that we in general must perform any required changes on the objects in the on-premises Active Directory and not in Office 365 nor Exchange Online as most attributes on this side are read only.

As you know, we have also configured identity federation via ADFS in order to achieve single sign-on (SSO) for users that are domain-joined and domain-connected. With identity federation configured, we must provision new users via the on-premises Active Directory in order for the users to be able to leverage SSO.

Since users must be provisioned via the on-premises Active Directory, we also need to be able to provision them with the required mail attributes in order for Exchange Online to accept the object and convert them as necessary. This part is pretty simple and can be done relatively simple without using Exchange Management tools such as exchange admin center (EAC) and the Exchange Management Shell (EMS). As a matter of fact, in order for Exchange Online to accept an object synchronized from the on-premises Active Directory, we only need the following three mail related attributes (in addition to the other mandatory attributes that are stamped on an Active Directory user object, when created using a tool such as the Active Directory Users and Computers console or an iDM solution):

mail
proxyAddresses
targetAddress

An object with the above three attributes will be converted into a valid mail-enabled user (MEU) object in Exchange Online when it gets synchronized to the Office 365 tenant. And you would be able to simply assign it an Exchange license in order to make it a mailbox-enabled object.

So far so good. The place where things get tricky is if you need to enable more advanced Exchange features on the object. Things such as hiding the object from the global address list, adding additional email addresses would be relative easy to enable by using ADSI Edit or an iDM solution with this logic built-in. However, for most organizations configuring these features via direct attribute manipulation could quickly end in a nightmare. For this reason, the Exchange Product Group doesn’t support this approach. Not that it cannot be done, but you really need brilliant operational procedures in place in order to succeed via this route. There’s the Exchange PG recommends you keep an Exchange 2013 server with the Mailbox role on-premises in order to manage Exchange related features going forward no matter if all your mailboxes are located in Exchange Online or not.

Note:
If the on-premises Exchange is only used for hybrid and management and doesn’t host any mailboxes, you should bear in mind you aren’t required to pay for the Exchange license only the Windows server license as it then would be covered by the Exchange Hybrid edition license. With Exchange 2013 you don’t have to enter a product key. For further details, see the Exchange Online licensing FAQ here.

If you plan to have all your mailboxes hosted in Exchange Online and if you run Exchange 2013, you have the option to remove the Exchange hybrid configuration. You can do so with the Remove-HybridConfiguration cmdlet. Bear in mind though, this will only remove the HybridConfiguration object in Active Directory not the other configuration that the hybrid configuration wizard created and configured in Exchange. In order to get rid of all Exchange hybrid related configuration, you must also remove organization relationships (Remove-OrganizationRelationship cmdlet), federation trust (Remove-FederationTrust cmdlet), receive connector (Remove-ReceiveConnector cmdlet), send connector (Remove-SendConnector cmdlet), remote domains (Remove-RemoteDomain cmdlet) and the mail routing proxy address from the E-Mail Address Policy (tenant_name.mail.onmicrosoft.com). Depending on your scenario (centralized secure mail transport or not), you can delete the inbound and outbound connectors in Exchange Online Protection (EOP).

Switching SMTP Relaying to the Cloud

There is a pretty good chance that you have on-premises line of business (LOB) applications, printers, scanners, faxes, network devices, monitoring solutions etc. that are depending on being able to relay through your on-premises Exchange servers.

If you plan to only keep an on-premises Exchange server for management purposes, it’s recommended to point the applications or devices to either relay through non-Exchange SMTP servers located on-premises or simply relay through the cloud.

One of the things that has really been improved from the previous version of Exchange Online to the current version is the relaying possibilities. We now have the following three ways of relaying through Office 365:

Direct Send: Configure a user, device, or line-of-business (LOB) application to directly send email to Office 365 (& Internet) recipients
Exchange Online Relay: Configure a user, device, or line-of-business (LOB) application to send mail as a single SMTP address for a domain you own
Exchange Online Protection Relay: Configure a user, device, or line-of-business (LOB) application to send mail as multiple senders who may not have Office 365 mailboxes, including to Internet recipients

In the following, you can see a comparison chart between the three methods:

Table 1: Comparison of available relaying methods in Office 365 The above comparison chart is taken from the Ignite Webcast SMTP Relay, which is a great Webcast, I highly recommend you watch it to get a deep insight into each of these three relaying options. You can find it here.

Provisioning Mail Objects

Provisioning a new remote mailbox (mailbox created directly in Exchange Online) via your on-premises Exchange 2013 server(s) is a straightforward task. You simply open the exchange admin center and under the “Enterprise” tab point to “recipients” > “mailboxes”. On this page, click the “plus icon” and select Office 365 in the drop-down menu as shown in “Figure 1”.

Figure 1: Creating a mailbox in Exchange Online using an Exchange 2013 on-premises servers

In the “new Office 365 mailbox” wizard, fill out the required text fields and then click “save”.

Figure 2: Filling out mandatory text fields

After a little while the Active Directory user object will be created in the on-premises Active Directory.

Figure 3: New Active Directory User object in on-premises Active Directory

Since the object has been stamped with the mandatory mail attributes it is also visible in the EAC with mailbox type “Office 365”. Really just a MEU object associated with Exchange Online.

Figure 4: New MEU object visible in EAC

If we switch to the Office 365 in order to list mailboxes in Exchange Online, we can see the new user isn’t listed.

Figure 5: New User Mailbox not listed in EAC connected to Exchange Online

The reason for this is simple. DirSync only synchronized newly provisioned users and deltas to the Office 365 tenant every three hours, so in order to have the mailbox show up, we need to wait or force a DirSync.

Figure 6: Forcing a directory synchronization

We can see a new Add for the export connector, which means the newly provisioned object has been exported to Office 365.

Figure 7: New add on export connector

If we click “Adds”, we are dealing with the respective object.

Figure 8: Attribute information for exported object

Now if we refresh the mailbox list, the new mailbox user shows up.

Figure 9: New user mailbox in Exchange Online

Shared Resources

For shared resources (shared mailboxes, equipment and rooms), we should follow the same principles as when we create user mailboxes. That is they should be created via the EAC (or EMS if you prefer) and then they will be synchronized to Exchange Online.

Figure 10: Creating equipment and room mailboxes in EAC connected to an on-premises Exchange server

Figure 11: Creating shared mailboxes in EAC connected to an on-premises Exchange server

Distribution Groups

For groups, you would usually also create them on-premises and have them synchronized to Office 365 although it is possible to create them directly in Exchange Online. Bear in mind though the latter will result in objects being in two places. At the same time, creating them on-premises means it won’t be possible to manage group membership using the Outlook client or OWA as the GAL is read only in scenarios where DirSync is in use.

Figure 12: creating groups in EAC connected to an on-premises Exchange server

Sidebar: Managing Distribution Group created on-premises

Ok so you have setup coexistence between your on-premises Exchange based messaging infrastructure and Exchange Online using the Exchange hybrid configuration wizard. Since an Exchange hybrid deployment also requires directory synchronization from your on-premises Active Directory forest to the respective Office 365 tenant, you also configured DirSync between the two organizations.

Everything works as expected. You can move mailboxes to Exchange Online and off board them again. Users can also see the same global address list (GAL) and look up free/busy information for other users, no matter if they still have a mailbox on-premises or have had their mailbox moved to Exchange Online. In fact, everything is just super-duper. Well, at least it was because suddenly you are contacted by a user that recently had her mailbox moved to Exchange Online. The user is complaining about no longer being able to manage distribution groups in her Outlook client.

This user has managed distribution groups using her Outlook client for years without any issues, you’re told to fix the problem. So in order to see if this is a general issue, you add yourself as manager to the respective distribution group. This turns out to work just fine. Hmm this is just weird don’t you think. Only difference you can think of is your mailbox hasn’t been moved to Exchange Online yet. But why should moving a mailbox to Exchange Online break this functionality?

You decide to create a test mailbox in the on-premises Exchange environment. You then add the test user to the Manager list for the distribution group and just like with the case when testing with your own user mailbox, it worked just fine.

You move the test user mailbox to Exchange Online and connect to the mailbox using the Outlook client. And yes the test user mailbox now faces the same problem. It can’t manage the distribution group in question. You see the following error message after having removed a couple of users from the group and click “OK“.

Figure 13: Not able to modify group membership using Outlook

Then you try to create a new group directly in Exchange Online using the Exchange Online Control Panel (ECP) and add yourself as manager. This works!

You scratch your head (again).

Okay, so after contacting the Office 365 Front-end Support team, it all suddenly makes sense. It is explained to you that since you use DirSync, the group object synchronized to Exchange Online is considered read-only. You can’t make any writes to it using the Outlook client or the ECP for that matter. In order for a cloud user to manage a distribution group, the following options are available:

Let the IT department manage the groups using well-known methods such as the EMC, EMS, ECP or Active Directory Users and Computer (ADUC) snap-in.
Use cloud managed distribution groups (group created directly in Exchange Online). The drawback of using this method is that any on-premises mailboxes cannot see this group in the GAL since DirSync is one-way synchronization only (except for a few attributes).
Push a locked down version of ADUC to the respective user’s machine. The drawback here is that you need to install admin tools on the respective client machines.
Publish ADUC or EMC through Citrix or Terminal services.
Create a shortcut on the respective client machines that point to “C:WindowsSystem32rundll32.exe” dsquery.dll,OpenQueryWindow”. This will make it possible to access the “Find Users, Contacts and Groups” tool that normally is launched via “Find” in ADUC (thanks to Kyle Anna at MS for this tip!).
Use Forefront Identity Manager 2010 (FIM 2010). FIM 2010 includes a distribution group module that the user can access through a browser. The module lets a user manage his own groups and join or leave others. This is the approach used for group management internally at Microsoft.
Use a third party tool to accomplish the goal. There are many different ones to choose between and most uses a browser based approach.

The above story (from real life) is one of many reasons why the solution alignment workshop, assessment and remediation phases of an Office 365 migration project is so important.

Well well well, this concludes part 17 of this multi-part article in which I explain how you configure an Exchange 2013 hybrid deployment followed by migrating to Office 365 (Exchange Online). And you know what? This was the last article in this adventure. I hope you learned something along the way.

Many thanks for this great article The Author — Henrik Walther

Source: http://www.msexchange.org/articles-tutorials/office-365/exchange-online/configuring-exchange-2013-hybrid-deployment-and-migrating-office-365-exchange-online-part17.html

Cookie	Duration	Description
_clck	1 year	Microsoft Clarity sets this cookie to retain the browser''s Clarity User ID and settings exclusive to that website. This guarantees that actions taken during subsequent visits to the same website will be linked to the same user ID.
_clsk	1 day	Microsoft Clarity sets this cookie to store and consolidate a user''s pageviews into a single session recording.
_ga	1 year 1 month 4 days	Google Analytics sets this cookie to calculate visitor, session and campaign data and track site usage for the site''s analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognise unique visitors.
_ga_*	1 year 1 month 4 days	Google Analytics sets this cookie to store and count page views.
_gat_gtag_UA_*	1 minute	Google Analytics sets this cookie to store a unique user ID.
_gid	1 day	Google Analytics sets this cookie to store information on how visitors use a website while also creating an analytics report of the website''s performance. Some of the collected data includes the number of visitors, their source, and the pages they visit anonymously.
ai_session	1 hour	This is a unique anonymous session identifier cookie set by Microsoft Application Insights software to gather statistical usage and telemetry data for apps built on the Azure cloud platform.
CLID	1 year	Microsoft Clarity set this cookie to store information about how visitors interact with the website. The cookie helps to provide an analysis report. The data collection includes the number of visitors, where they visit the website, and the pages visited.
MR	7 days	This cookie, set by Bing, is used to collect user information for analytics purposes.
SM	session	Microsoft Clarity cookie set this cookie for synchronizing the MUID across Microsoft domains.

Cookie	Duration	Description
ai_user	1 year	Microsoft Azure sets this cookie as a unique user identifier cookie, enabling counting of the number of users accessing the application over time.
ANONCHK	10 minutes	The ANONCHK cookie, set by Bing, is used to store a user''s session ID and verify ads'' clicks on the Bing search engine. The cookie helps in reporting and personalization as well.
MUID	1 year 24 days	Bing sets this cookie to recognise unique web browsers visiting Microsoft sites. This cookie is used for advertising, site analytics, and other operations.

Introduction

Available Migration Paths to the New Office 365

Exchange Online Changes & Improvements

Introduction

Overview of the Lab Environment

Signing-Up for Tenant in the New Office 365

A Look at the New Office 365 Portal

Adding a Domain to the Office 365 Tenant

Introduction

A Brief Explanation of Office 365 Identity Federation

Configuring Windows Load Balancing on the ADFS Servers

Introduction

Importing the Server Authentication Certificate into IIS

Installing & Configuring the ADFS Farm

Verifying the Federation Server farm is working properly

Introduction

Configuring Windows Load Balancing on the ADFS Proxy Servers

Adding Federation FQDN to the hosts file on the ADFS Proxy servers

Enable MAC Spoofing on the Hyper-V Virtual Machines

Introduction

Importing the Server Authentication Certificate into IIS

Installing & Configuring the ADFS Proxy Server Settings

Verifying the ADFS Proxy Servers has been configured properly

Introduction

Converting the Custom Domain to a Federated Domain

Introduction

Activating Active Directory Synchronization

Creating the WAAD Sync Service Account

Installing and Configuring the WAAD Sync Tool

Introduction

Verifying Active Directory Object Synchronization

Forcing a Directory Synchronization

List of Attributes Synchronized to Office 365 Tenant

Directory Synchronization Filtering

Directory Synchronization Limitations

Introduction

Completing the Office 365 Add a Domain wizard

Routing Inbound Messages through the Exchange Hybrid Servers

Routing Inbound Messages through Exchange Online Protection

Routing Outbound Messages directly to Destination

Routing Outbound Messages through On-Premises Hybrid Servers

Introduction

Enabling Hybrid Mode

Sidebar: Exchange Hybrids with multiple SMTP Domains

Introduction

Creating DNS Records in External DNS

Introduction

A Look at the Hybrid Configuration Settings

Introduction

A Look at the Hybrid Configuration Settings in Office 365

Introduction

Enable Mailbox Replication Service (MRS) Proxy

Moving a Mailbox to Exchange Online

Using the Exchange admin center on an Exchange 2013 hybrid server on-premises

Using the Exchange admin center in Exchange Online

Using Remote PowerShell connected to Exchange Online

Introduction

What Happens when a Mailbox is moved to Exchange Online?

How are the miscellaneous Exchange clients affected by a Mailbox move to Exchange Online?

Outlook Web App

Outlook Anywhere

Exchange ActiveSync

Introduction

Exchange On-Premises Servers going forward

Switching SMTP Relaying to the Cloud

Provisioning Mail Objects

Shared Resources

Distribution Groups

Sidebar: Managing Distribution Group created on-premises

Leave a Comment Cancel reply

Office 365 Essentials Book

Nuno Árias Silva Website

Categories

Office 365 Essentials Book

Facebook