Thursday, January 29, 2015
In my preceding blog posts, I was able to migrate mailboxes from Exchange 2010 (SP3) to Exchange Online (Office 365). After the move, the migrated user was still able to communicate with both external recipients - and users whose mailbox remained on premises. Client access (with OWA) and hub transport functionality were maintained.
We were able to achieve this even with the added complexity of Active Directory Federation Services (ADFS) and third-party load balancing of both Exchange traffic (client access, hub transpot) and ADFS communications. In this case, we used a KEMP VLM-200 but I may also attempt to achieve the same results with a Citrix NetScaler virutal appliance in the future.
Unfortunately, the limitations of my test network prevented me from accessing the migrated mailbox with Outlook (admittedly a significant shortcoming). It would have been necessary to create another 1-to-1 NAT relationship on my firewall device between external ADFS traffic and the ADFS server in my LAN (or possibly create a DMZ and place an ADFS proxy there).
Note: the existing 1-to-1 NAT is for traffic between external sources and the Exchange servers (using a VIP on the load balancer).
With enough time and effort, this obstacle could probably be overcome. However, there are other Active Directory and Exchange projects that have recently attracted my attention and I intend to dedicate some time to them as well.
Note that Outlook access to migrated mailboxes was possible with the staged migration I completed in 2013. The inability to access Outlook in a single-sign on (SSO) environment is a limitation of ADFS (in my test environment) and not a limitation of Exchange or Outlook per se.
I would like to conclude this set of blog posts with some links to resources on Office 365 administration and migration (beyond the subject of hybrid migration in particular).
Websites (articles or blogs)
First, the msexchange.org website has published articles on various types of migration scenarios to Office 365.
Henrik Walther's articles in particular are very useful. His latest article (at the time I wrote this) demonstrates the configuration of an Exchange test lab in Windows Azure (note that currently Exchange in not supported in Azure for production). If you want to move back from the Cloud to on-premises, there is even an article by Steve Goodman on such a scenario (Exchange 2010 on-premises is the target system).
There is a multitude of Technet articles on Exchange Online and Office 365. My advice would be to consult the Exchange Server Deployment Assistant, select your migration scenario and then refer to the links provided.
At the time I wrote this, this was the link to the online tool:
In case the link is no longer valid, just perform a search for "Exchange Server Deployment Assistant". Of course, that advice is valid for any of the links posted here.
Anders Eide compiled a list of resources for Office 365 certification (exam 70-346) but that could also prove useful in general:
Of course, the best place to ask questions is the Office 365 Community forum:
You could also ask questions in various TechNet forums, although you may be directed to the site above.
Video training - Microsoft, for free
This is an older series so some information is out-of-date (for example, Public Folders can now exist in Office 365 and DirSync can now synch passwords - password hashes in fact). Other general concepts remain valid however.
The Ignite series is newer.
Video training - third party, for pay
Both PluralSight and CBTNuggets advertise a number of training videos on Office 365 administration:
I have used both sites, watching videos on various subjects (Active Directory, Exchange, CCNA certification), and would state that quality varies depending on the presenter. I have not yet viewed any on Office 365 yet, so I cannot make specific recommendations. Judging from his previous series on Exchange 2010 and 2013, anything by J. Peter Bruzzese would be worth a look.
Note that "Train Signal" was purchased by Pluralsight and is no longer a separate company.
This video series by David Elfassy (MVP and well-reviewed author on amazon.com) may be worth a look as well:
You can search for these titles at your preferred bookseller:
Office 365: Migrating and Managing Your Business in the Cloud
December 29, 2013
Matthew Katzer, Don Crawford
Microsoft Office 365 Administration Inside Out
October 25, 2013
Anthony Puca, Julian Soh, Marshall Copeland
Microsoft Office 365: Exchange Online Implementation and Migration
May 25, 2012
David Greve, Loryan Strant
I've included titles dealing with administration or migration. There are other titles more suitable for the end user as well.
Saturday, January 24, 2015
Active Directory Federated Services (ADFS) provides one major advantage, Single-Sign On (SSO), but makes availability of the ADFS server an absolute requirement. Authentication to Office 365 (with federated identities) is impossible without ADFS. In such a context, a single ADFS server would be a single point of failure. Therefore, most organizations using Office 365 (with federated identities) will need at least two ADFS servers and most likely at least two ADFS Proxy servers.
If these concepts are not clear, you can consult one of my previous post about ADFS...
As well as these articles:
Note: as I explained in my blog post referenced above, I have not implemented ADFS Proxy servers so we will not examine that aspect any further.
So, if we have two or more ADFS servers, we need to implement a load balancing solution, either Windows Network Load Balancing (WNLB) or a third party load balancer. KEMP, Citrix and F5 are some of the major vendors in this market.
Note: I will not retain "DNS Round Robin" as an acceptable load balancing solution for ADFS - or Exchange - because of its very significant limitations.
In my test network, I will use a Kemp VLM-200 which is actually a virtual load balancer that operates as a ESXi (or Hyper-V) guest.
If you intend to use WNLB, you might want to consult Henrik Walter's blog posts on the subject:
As I stated in my blog post about load balancing for Exchange, I will not demonstrate how to install the VLM-200 in ESXi.
Exchange 2010 - High Availability - Client Access and Hub Transport roles - example of the KEMP VLM-200
Moreover, I will refer the reader to that blog post for information on downloading a template from the KEMP website and then installing it in the VLM-200.
The template for ADFS can be found in the Resources | Documentation section of the KEMP Technologies website.
Once downloaded, the template can be imported just as I imported the Exchange 2010 template in the blog post referenced above.
The template functions "as is" without much additional configuration.
We do have to assign a virtual IP address, install the certificate used by the ADFS server(s) and then designate the ADFS server(s) as "Real Servers", in other words the target servers to which the load balancer directs incoming ADFS authentication requests. Once this is completed, we can adjust DNS records for the ADFS server(s) so they now point to the load balancer.
I'll illustrate these operations with some screenshots below. As a point of clarification, please note that, in my test network, these are the IP addresses related to ADFS:
10.0.0.41 -> ADFS server (the "real server" in KEMP terminology)
10.0.0.29 -> VLM-200 (this IP address is different from the VLM-200 management IP)
Of course, in a real network, I would have built a second ADFS server and added it to the list of "Real Servers" in the VLM-200.
Assign virtual IP and select ADFS template
We assign a virtual IP address (and port) when we add the "ADFS Internal Farm" virtual service (click on image for a larger view).
This IP address / port combination must be different from other IP / port combinations. We cannot use 10.0.0.28/443 for both Exchange CAS traffic and ADFS traffic. We either need a different IP address or a different port. Since ADFS uses port 443 also, we must use another port.
Also note (above) that this is where we import the "ADFS Internal Farm" template. This template is extremely useful because it configures most of the parameters for the ADFS load balancing service.
Import ADFS certificate
On the ADFS server, we export the 3rd party certificate that was installed on that server and then import it into the VLM-200 certificate store. On the VLM-200, we click on "Import Certificate", browse to the location of the .pfx file (for example "STS-ADFS-export.pfx") and import it, entering the password when prompted. Make sure you assign the certificate to the appropriate virtual service. This is what we should see when we have finished:
Note: it was apparently not necessary to import the intermediate certificates as we had to on the ADFS server itself. Load balancing functions fine without them. I would have imported them but encountered a problem. KEMP Tech Support informed me that they were not necessary. The reader may want to consult KEMP on this matter since results could vary based on firmware or particular configurations.
Add "Real Servers"
In a production environment with more than one ADFS server, we would add the other servers as well. Of course, load balancing would make no sense with a single target server.
Adjust DNS records for ADFS (STS)
In my case, the DNS record previously pointed directly to the ADFS server at 10.0.0.41. I had already modified the record so it points to the VLM-200 load balancer:
In my case, since I am using ADFS 3.0, it was necessary to upgrade the VLM-200 firmware to version 7.1-22b (for VMware). Firmware is upgraded in the System Configuration | System Administration | Update Software section of the LoadMaster web interface. One simply browses for the "software update file" downloaded from the KEMP website. A reboot is required.
Configuration may vary, even with other KEMP load balancers or with other firmware versions. In case of problems, the best advice would be to contact their tech support.
Saturday, January 17, 2015
In this blog post, I'll examine the client experience after the migration of a mailbox.
Only OWA (Outlook Web App - formerly Access) will be discussed. Unfortunately, because of certain limitations in my test network, Outlook will not connect to Office 365. It seems that with OWA, Internet "cookies" can transmit any necessary data through the connection opened with Office 365, thus requiring no further firewall reconfiguration at the perimeter. On the other hand, Outlook functions differently and would apparently require another 1 to 1 NAT relationship at the firewall. This was not possible for a number of reasons that I will not detail here (limit on number of external ISP-provided IP addresses, licensing issues on the firewall itself).
So with OWA then, this is how we would proceed.
Having logged in as the user migrated to Office 365, I create a desktop shortcut with the target URL shown below:
That is: http://outlook.com/owa/mitservnet.onmicrosoft.com
Of course, an Internet favorite could be used as well.
We could also enter the usual (for my domain) https://mail.mitserv.net/owa
In that case (for migrated users), we would be redirected to Office 365 anyway.
That's why I opted to create a simple and direct shortcut instead.
So the Office 365 portal displays and the user has to enter their credentials:
Once the user enters their username (and before they can enter their password), they are redirected to the local ADFS server where they have to enter their username again and then (finally...) their password:
The advantages of Single-Sign On (SSO) are not clear here. In fact, SSO does not seem to function with OWA at all, since I have to enter my username and password once to logon to the workstation itself, then the username a second time, and then a third time (with the password) when I provide my credentials to ADFS.
On the other hand, a call to Microsoft Tech Support confirmed that ADFS was at least configured correctly and I could indeed connect to the user's mailbox in Office 365:
At this point, the user can send and receive messages as usual.
I did notice one problem: if the user signs out (with "Sign Out" - see below), OWA would automatically re-open. I had to close the browser (IE11) to end my session.
Sunday, January 11, 2015
This blog post will start with an observation.
In my on-premises Exchange environment, I was working with four users that were "mailbox enabled" some time ago:
- Aisha Bhari
- Alan Reid
- Alannah Shaw
- Alex Heyne
Note: these users were created with Andy Grogan's script for use in practice environments: Creating LAB users with a Powershell Script
That means that I had four mailboxes, one for each of the users listed above (this view is of the EMC Recipients Mailbox section) :
Note: Alex Heyne is not visible but he's there...
When the Hybrid Configuration Wizard is run, a mail user is created for each of them in Office 365. We can see this in the "Office 365 | Mailbox | Mail Contact" section of the EMC (on-premises Exchange server):
Note that these are indeed "Mail Users" even though they exist in the "Mail Contact" section.
When we migrate the mailbox...
- The migrated mailbox replaces the corresponding mail user in Office 365.
- A mail user replaces the migrated mailbox in the on-premises Exchange environment.
Mail enabled users must be distinguished from mailbox enabled users.
Both are associated with an Active Directory account and allow a user to connect to the network.
However, the mailbox enabled user has a local mailbox.
The mail enabled user has a remote (external) mailbox.
In general, this could be a Gmail or Hotmail mailbox.
So, although the user (a consultant for example) could connect to the local network, messages for them would be sent to their externally located mailbox.
In a hybrid migration, the mail user object plays the same role: mail sent to the address in question will continue to be directed to the on-premises Exchange servers (since the MX records have not been changed) but will be redirected to the mailbox migrated to Office 365.
Note that the MX records cannot be changed until ALL the mailboxes have been moved to Office 365. As long as some mailboxes remain on-premises, we have to direct mailflow onsite.
Having provided those clarifications, we can now migrate our first mailbox.
Open the EMC and navigate to Recipient Configuration | Mailbox. Right-click on the mailbox to be migrated and select "New Remote Move Request":
The Introduction presents what will be done. If we have archive mailboxes, we can (optionally) migrate those as well:
In the next step, we have to indicate the "Mailbox Replication service proxy server". I entered the FQDN used for client access (mail.mitserv.net). We also have to enter credentials for the source forest. I used an account with enterprise administrator rights (among others):
We then enter the target domain, in my case: mitservnet.mail.onmicrosoft.com.
Note: mail.onmicrosoft.com is common to all Office 365 / Exchange Online clients.
We have a summary of the operation to be executed:
The wizard is working...
And then completes:
That's the way it is supposed to work. In fact, I did not succeed on the first try.
Despite the successful completion message (last screenshot above), the mailbox was simply not migrated. It still appeared among the on-premise mailboxes. Moreover, there was no sign of the mailbox in Exchange Online (Office 365). I attempted the migration once more: same result.
Microsoft Tech Support recommended that I attempt the migration from the command line and then view any error messages. I discovered that when using the command line I could obtain a detailed error message (as opposed to the apparent success message in the GUI).
First, we must establish a connection with Office 365...
We create a variable representing our login credentials
PS C:\> $TenantCreds = Get-Credential
Note: here we would be prompted to enter our credentials which are stored in the variable.
We then enter this command:
PS C:\> $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $TenantCreds -Authentication Basic -AllowRedirection
We will see a message like this (it is strictly informational):
WARNING: Your connection has been redirected to the following URI:
We import the session:
PS C:\> Import-PSSession $Session
Note: at this point, there is a warning about the imported commands. It has no effect on our objective so I will omit the message for concision.
In the following lines, we'll define a variable representing or login credentials once more and execute the command to migrate the mailboxes. We will then see the error message explaining why the mailbox was, in fact, NOT migrated.
PS C:\> $RemoteCredential = Get-Credential
Note: here we supply the credentials when prompted.
PS C:\> New-MoveRequest -id "email@example.com" -Remote -RemoteHostName "mail.mitserv.net" -TargetDeliveryDomain mitservnet.mail.onmicrosoft.com -RemoteCredential $RemoteCredential
You can't use the domain because it's not an accepted domain for your organization [...].
These are my accepted domains according to Office 365:
PS C:\> Get-AcceptedDomain | fl
On-premises I have another accepted domain: mynet.lan
The solution was to remove references to this domain from the "Email addresses" tab in the user's mailbox properties. The change did not seem to take effect immediately since the migration failed once more but finally succeeded on the next attempt.
Saturday, January 3, 2015
Now that we have prepared ADFS and DirSync (please see my previous blog posts), we can use the "Hybrid Configuration Wizard" (HCW) to allow interaction between our on-premises Exchange server(s) and Exchange Online (the messaging component of Office 365).
Adding the Office 365 tenant to the EMC
First, it is necessary to add our Office 365 tenant to the Exchange Management Console (EMC). We open the EMC on our Exchange 2010 server (any server if we have several), right-click on the "Microsoft Exchange" icon and select the "Add Exchange Forest" option:
We then provide a name for the new Exchange Forest and select (in this case) "Exchange Online":
Since Office 365 will not recognize my local domain administrator credentials, I have to enter credentials that are valid for my Office 365 tenant. This could be the account used to configure the tenant initially or another account with "Global Administrator" rights:
Note: optionally, we can check "Remember my credentials" so we do not have to enter them each time I open the EMC.
We should then see a new icon in the EMC: Office 365. We can explore the various sections at this point, remarking, for example, that there is only one mailbox entry, a "Discovery Search Mailbox". This is normal since we have not yet migrated any mailboxes to Office 365 / Exchange Online.
Hybrid Configuation Wizard (HCW)
Now that we have added "Office 365" as an additional forest to our EMC, we can execute the HCW.
We right-click on the "Organization Configuration" icon and select the option "New Hybrid Configuration":
We can read a brief description about hybrid configuration:
Note: click "New" (not shown in screenshot above).
The wizard creates a self-signed certificate and a "Federation Trust" with Office 365 (the "Microsoft Federation Gateway" (MFG) acts as a sort of "broker" between the two domains):
Now we will manage the hybrid configuration....
In the EMC, under the Microsoft Exchange On-Premises section, we select Organization Configuration and then right-click on Hybrid Configuration. We select "Manage Hybrid Configuration":
On the Introduction page, we are reminded about prerequisite tasks that must be completed first:
On the page that appears next, we must enter credentials for an account that is a member of the Organization Management role group and then Global Administrator credentials for our Office 365 tenant (for example, the account used to create the tenant would have this role by default):
Note: we can optionally check the boxes "Remember my credentials".
Next, on the "Domains" page, we add the on-premises domain that will be part of the hybrid configuration:
At this point, the configuration becomes somewhat more complex.
Microsoft wants proof that we own the domain that we are adding to the hybrid configuration.
In the screenshot below, we see that the HCW creates a value (obscured) that we need to paste into a public DNS text record. We do this with the interface used to manage our external DNS records, most likely the same interface where we manage MX records for the domain name.
In my case, I will create a DNS text record in the NO-IP interface:
- When I first did this, I was not sure if the value should be confidential or not. In the screenshot above, I show most of it but obscure the last part - just in case.
- I did not provide step-by-step instructions for the creation of a DNS record in NO-IP since many readers will be using some other system, especially in a production environment using a static IP address.
- In the NO-IP interface, the text records seem to be listed one above in the other in the same text block. I had an SPF record in first position that I removed because the HCW would not complete successfully with this record present. Once again, however, I will not insist on this point since most readers are probably not using NO-IP to manage their DNS. If in fact you are using NO-IP, you can contact their technical support for any questions.
In the following step "Servers", we select the Client Access and Hub Transport servers, which may be the same if we have multi-role servers:
In the "Mail Flow Settings", we indicate the public IP address and the FQDN of the (hybrid) Hub Transport servers. In practice, this will usually be, for the IP address, the external IP address of the on-premises location (often the IP address of an external interface of a firewall) and for the FQDN, the domain name associated with the mail system in external DNS:
Note: to add your IP address, you would click on "Add" (green plus sign) and then enter it. The FQDN can be entered directly.
We still have a couple more steps to complete and then we will have finished...
On this screen, "Mail Flow Security", we indicate the certificate to use for mail transport. I have a third party certificate that I will select:
As for the "Mail Flow Path", I will keep the default selection: mailboxes in Office 365 will send messages directly to external recipients.
We're almost there... We can review the configuration on the following screen and then click on "Manage":
If all goes well, the configuration will complete successfully:
In the following posts, I'll review some of the changes to onsite Exchange, migrate a mailbox to Exchange Online, access the migrated mailbox and send and receive messages.