Saturday, August 30, 2014

Exchange 2010 (SP3) - Migration - Part 7 - Mailbox Migration

And now the moment that we've been waiting for: moving the mailboxes.

In this post, I'll test client access (after the move) with Outlook, which uses MAPI over RPC. For web-based access (HTTP/S), there are some CAS URL adjustments to be made as well. I'll address that in another blog post.

Like most actions in Exchange 2010, mailboxes can be moved with either the EMC or the EMS. We'll start with the EMS, then use the EMC.

Mailbox migration with the EMS 

Although additional optional parameters exist, it is possible to migrate a mailbox with a cmdlet as simple as this:

[PS] C:\>New-MoveRequest "" -TargetDatabase "DB1"

We can simply indicate the mailbox as above. The -identity parameter (-id for short) is positional here and as such does not need to be stated explicitly.

There will be some output indicated, for example:

DisplayName        Aisha Bhari
Status                   Queued
TotalMailboxSize  564.8 KB (578,340 bytes)
TotalArchiveSize   -
PercentComplete  0
This may be (and probably will be) displayed on the screen differently.

We can see the status of a mailbox move with the following cmdlet:

[PS] C:\>Get-MoveRequest | fl displayname,status,TargetDatabase

DisplayName    : Aisha Bhari
Status         : Completed
TargetDatabase : DB1

Optionally, we can indicate the threshold of "bad" (or corrupt) items that we are willing to skip (and essentially lose):

[PS] C:\>New-MoveRequest "" -TargetDatabase "DB1" -BadItemLimit 100 -AcceptLargeDataLoss

The default is 0.

Mailbox migration with the EMC

Now we'll see the process with the Management Console. I'll also take into account the user's perspective as well.

First, we go to the "Recipients" section of the EMC (below the Organization and Server sections), locate the mailbox in question, right-click on it and select "New Local Move Request".

We then select the target database (click "Next" as needed):

Then we decide the threshold for "bad items" (this is the equivalent of what we did at the command line earlier with the -badItemLimit parameter):

We click "Next/Finish" and if all goes well, we should see this:

The User Experience

In theory, we should be able to move mailboxes from an Exchange 2007 server to an Exchange 2010 server while the user is in Outlook. This is called an "online move" since the user can remain online... except for the very last part of the migration.

Here are some more technical details (from the Exchange Team blog):

In fact, there will be some loss of functionality during the move.

Logged in as one of my test users, I attempted to open Outlook and send a message while the mailbox move was in progress.

Note: this was with Outlook in "Exchange Online Mode" as opposed to "Cached Mode". Results may differ with cached mode.

This was the result:

Since the print is small, I'll rewrite the first part of the message: "The item cannot be saved to the folder" - presumably the "Sent Items" folder which is not accessible because of the migration.

Otherwise, the first time the user opens Outlook after the move, they will most likely see this message:

Even so, despite these messages, both of my test users were able to access their mailbox after re-opening Outlook.

All things considered, it may be preferable to perform the mailbox moves after work hours.


This concludes the mailbox migration process in itself.

It can be interesting, and useful for troubleshooting, to compare "Connection Status" and "Autoconfiguration" results before and after the migration.

For example, this...

Note: the server name is "EX1" (the Exchange 2007 server).

Compared to this:

Some comments are necessary. First, as we can see, we do not see the name of "the" Exchange 2010 server (or any Exchange 2010 server for that matter) because I created a "CAS Array" instead. In conjunction with a load balancer (KEMP, F5, etc.), I can direct Outlook clients to whichever Exchange 2010 server the load balancer selects.

But why does the EX1 server still appear?

This is something specific to my test environment. The Outlook profile of test user Aisha Bhari includes a shared mailbox that still resides on the Exchange 2007 server. Once we move the shared mailbox, we should see something like this:

Notice that the name of the CAS Array is also what we see in the account "Server Settings":

Friday, August 22, 2014

Exchange 2010 (SP3) - Migration - Part 6 - Offline Address Book: generation and migration

The "Offline Address Book" (OAB) is a copy of the Global Address List (GAL) and potentially other custom address lists that Outlook downloads when functioning in "Exchange cached mode". This means that there is a copy of the mailbox that is stored or "cached" on the client machine. This is the opposite of  "online" mode where users work with the "master copy" of their mailbox directly on the Exchange server. So the OAB is the address book used when Outlook is running in cached mode.

The OAB is created (or "generated") on a mailbox server and distributed by a client access server (usually the same if the servers are multirole). There are two mechanisms by which the OAB can be distributed: Public Folder distribution and web-based distribution. Although it is still possible to distribute them by Public Folders, the web-based mechanism is preferred because of its greater efficiency, regarding use of bandwidth for example.

In the context of a Exchange 2007 to 2010 migration, we need to accomplish two operations:

  1. Transfer the OAB generation process to an Exchange 2010 server.
  2. Designate the Client Access Servers (CAS) that will distribute the OAB (and select the mechanism used: Public Folder and/or web-based distribution). 

Later, when we uninstall the Exchange 2007 server, we would want to remove it as a distribution point (this may happen automatically for that matter) but that is not an immediate concern.

Transfer the OAB generation role to Exchange 2010

We can do this using the EMC or the EMS. First the EMC...

We go to the Organization Configuration section, Mailbox role, and then the Offline Address Book tab.

We right-click on "Default Offline Address Book" as shown below, choose "Move" and then the server to which we want to move the generation process (in this case, EX13-1 instead of EX1):

Upon completion, a message will display indicating that we can delete the OAB files on the now former OAB generation server:

In the EMS, this cmdlet would produce the same effect:

Move-OfflineAddressBook -id "\Default Offline Address Book" -Server EX13-1

Add the Exchange 2010 server(s) as an OAB distribution point

Once again, this can be accomplished with the EMC or EMS.

First, the EMC. We open the properties of the "Default Offline Address Book"

We click on Add...

And select the OAB Virtual Directories that we want to use.

Here is the EMS equivalent:

Set-OfflineAddressBook -AddressLists '\Default Global Address List' -VirtualDirectories 'ex1\OAB (Default Web Site)','EX13-1\OAB (Default Web Site)','EX13-2\OAB (Default Web Site)' -Identity '\Default Offline Address Book'

Note: we have to indicate all the virtual directories. If we indicate only...

"EX13-1\OAB (Default Web Site)"

Exchange will replace existing virtual directories with that one and that one alone.

Sunday, August 17, 2014

Exchange 2010 (SP3) - Migration - Part 5 - CAS Urls

Web-based access to the client's mailbox is provided by methods such as OWA (Outlook Web Access/App), ActiveSync, EWS (Exchange Web Services - for calendar and out-of-office functionality) as well as OAB (Offline Address Book). Exchange 2010 also introduces a new web-based management interface in addition to the EMC and EMS: the ECP or "Exchange Control Panel".

All these methods require a pair of URLs: internal and external.

Moreover, access is validated by a certificate (preferably issued by a third party like Comodo or Digicert) and the "subject names" on the certificate must match the URLs used for client access (and management) mentioned above.

We'll see some examples below but in general, the URLs are composed of three parts:

  1. https://
  2. The FQDN of the server: for example
  3. Some reference to the IIS virtual folder, for example: /owa, /ecp or /oab (other variations are possible here).
In fact, this holds true for the internal URL. Depending on choices made at installation time, there will either be no external URL or a URL like "".

One common practice is to change the internal URL (with the server FQDN) so it is the same as the external URL (if present). Why? Some prefer that the names of internal servers are not exposed to the outside world (although these names appear elsewhere - in message headers for example). Another reason is to simplify the use of certificates. In organizations with multiple servers, the list of names on the certificate could be quite long. Since cost increases with the number of names (sometimes priced in increments of five), that is also a consideration.

It is possible to have as few as two names on the certificate. For example:

The first name can be used for all client access related services (OWA, ActiveSync, OAB) but autodiscover requires a name of its own.

In the context of an Exchange 2007 to 2010 migration, there is one more aspect to consider... and one more name to add to the certificate.

Here is the status quo of my test lab...

All URLs are configured with... (or

In DNS, there is an "A" record in the zone that links "mail" to the IP address which happens to be the IP address of the Exchange 2007 multirole (CA,HT,MB) server.

Note: all my servers are multirole servers with each server holding the CA, HT and MB roles.

Everything works fine at present.

But what happens when we start to migrate mailboxes from Exchange 2007 to 2010?

This is what we have to do...

  1. We create a entry in DNS for "legacy". This record points to the Exchange 2007 server (to the 2007 CAS to be exact).
  2. Just before we start mailbox migration, we point the DNS records for "mail" and "autodiscover" to the Exchange 2010 server (or a load balancer).
  3. We change the Exchange 2007 URLs from to

After these changes, clients will first be directed to the Exchange 2010 CAS (or load balancer distributing access requests between a group of 2010 servers). If the mailbox in question is located on the Exchange 2010 server, the 2010 server provides access to that mailbox.

If the mailbox is still on the Exchange 2007 server, the 2010 CAS redirects the request to the 2007 CAS.

The "legacy" entry in DNS allows this redirection.

Note: if the Exchange 2007 server is not "Internet facing", the Exchange 2010 server "proxies" client access requests to the 2007 server (CAS role).

The fundamental point here is that the Exchange 2007 CAS cannot provide access to mailboxes on a Exchange 2010 MBX server and vice versa.


At this point, I am not quite ready to migrate any mailboxes - or change DNS entries, and URLs on the Exchange 2007 server. What I do want to accomplish at this time is the configuration of URLs on the Exchange 2010 server.

I write "Exchange 2010 server" and describe the scenario above with only one Exchange 2010 server present, making only some vague references to "load balancers". That was to simplify the explanation as much as possible. In fact, there will be two Exchange 2010 servers in my test network and that will be reflected in the lines that follow.



I'll begin with the "ECP", the Exchange Control Panel.

First, we'll see how the URLs are configured:

[PS] C:\>Get-ECPVirtualDirectory | fl Server,ExternalUrl,InternalUrl

Server      : EX13-1
ExternalUrl :
InternalUrl : https://ex13-1.mynet.lan/ecp

Server      : EX13-2
ExternalUrl :
InternalUrl : https://ex13-2.mynet.lan/ecp

So, as mentioned in my introduction, the internal URL uses the FQDN specific to each server. We can adjust that with this cmdlet:

Get-ECPVirtualDirectory | Set-EcpVirtualDirectory -InternalUrl

And verify the changes:

[PS] C:\>Get-ECPVirtualDirectory | fl Server,ExternalUrl,InternalUrl

Server      : EX13-1
ExternalUrl :
InternalUrl :

Server      : EX13-2
ExternalUrl :
InternalUrl :


Some of you may know that we do not need to configure the autodiscover URL because Exchange does not use it. If not, you can learn more with this Technet article by Rhoderick Milne:

Therefore, I will not waste any time adjusting this parameter (even though I have in the past for a sense of "completeness").

On the other hand, we do need to configure the autodiscover URI which I will do next:

[PS] C:\>Get-ClientAccessServer | select identity,autodiscoverserviceinternaluri | ft -auto

Identity AutoDiscoverServiceInternalUri
-------- ------------------------------
EX13-1   https://ex13-1.mynet.lan/Autodiscover/Autodiscover.xml
EX13-2   https://ex13-2.mynet.lan/Autodiscover/Autodiscover.xml

We want the value of the parameter to be the same as it is for EX1 (the Exchange 2007 server).

There are several possible methods. We could use the Get-* cmdlet as for the ECP, above, and pipe the result to the Set-* cmdlet. Below, I'll use the Set-* cmdlet directly. Note that we have to identify the server explicitly then.

[PS] C:\>Set-ClientAccessServer EX13-1 -autodiscoverserviceinternaluri

[PS] C:\>Set-ClientAccessServer EX13-2 -autodiscoverserviceinternaluri

[PS] C:\>Get-ClientAccessServer | select identity,autodiscoverserviceinternaluri | ft -auto

Identity AutoDiscoverServiceInternalUri
-------- ------------------------------


Since the name of the server appears in the URL (see below), I''ll just display the URLs themselves in an effort to be as concise as possible.

[PS] C:\>Get-OwaVirtualDirectory | fl ExternalUrl,InternalUrl

ExternalUrl :
InternalUrl : https://ex13-1.mynet.lan/owa

ExternalUrl :
InternalUrl : https://ex13-2.mynet.lan/owa

[PS] C:\>Get-OwaVirtualDirectory -Server Ex13-1 | Set-OwaVirtualDirectory -InternalUrl

[PS] C:\>Get-OwaVirtualDirectory -Server Ex13-2 | Set-OwaVirtualDirectory -InternalUrl

Note: you may receive a warning about the ECP, stating you should adjust its URL as well. I've edited that (out) for concision.

We do not see the server name below, but now both URLs for both servers use "mail" instead of the server FQDN.

[PS] C:\>Get-OwaVirtualDirectory | fl ExternalUrl,InternalUrl

ExternalUrl :
InternalUrl :

ExternalUrl :
InternalUrl :

ActiveSync (for mobile devices, Smartphones, etc.)

[PS] C:\>Get-ActiveSyncVirtualDirectory | fl ExternalUrl,InternalURL

InternalUrl      : https://ex13-1.mynet.lan/Microsoft-Server-ActiveSync
ExternalUrl     :

InternalUrl       : https://ex13-2.mynet.lan/Microsoft-Server-ActiveSync
ExternalUrl      :

[PS] C:\>Get-ActiveSyncVirtualDirectory -Server EX13-1 | Set-ActiveSyncVirtualDirectory -InternalUrl

[PS] C:\>Get-ActiveSyncVirtualDirectory -Server EX13-2 | Set-ActiveSyncVirtualDirectory -InternalUrl

[PS] C:\>Get-ActiveSyncVirtualDirectory | fl ExternalUrl,InternalURL

InternalUrl    :
ExternalUrl   :

InternalUrl    :
ExternalUrl   :

EWS (Exchange Web Services)

[PS] C:\>Get-WebServicesVirtualDirectory | fl ExternalUrl,InternalURL

InternalUrl : https://ex13-1.mynet.lan/EWS/Exchange.asmx
ExternalUrl :

InternalUrl : https://ex13-2.mynet.lan/EWS/Exchange.asmx
ExternalUrl :

[PS] C:\>Get-WebServicesVirtualDirectory -Server Ex13-1 | Set-WebServicesVirtualDirectory -InternalURL

[PS] C:\>Get-WebServicesVirtualDirectory -Server Ex13-2 | Set-WebServicesVirtualDirectory -InternalURL

[PS] C:\>Get-WebServicesVirtualDirectory | fl ExternalUrl,InternalURL

ExternalUrl :
InternalUrl :

ExternalUrl :
InternalUrl :

OAB (Offline Address Book)

In this case, I configured the servers separately. It's just one more approach - among others.

OAB - EX13-1

[PS] C:\>Get-OabVirtualDirectory -Server EX13-1 | fl *url*

InternalUrl : http://ex13-1.mynet.lan/OAB
ExternalUrl :

C:\>Get-OabVirtualDirectory -Server EX13-1 | Set-OabVirtualDirectory -InternalUrl

[PS] C:\>Get-OabVirtualDirectory -Server EX13-1 | fl *url*

InternalUrl :
ExternalUrl :

OAB - EX13-2

[PS] C:\>Get-OabVirtualDirectory -Server EX13-2 | fl *url*

InternalUrl : http://ex13-2.mynet.lan/OAB
ExternalUrl :

[PS] C:\>Get-OabVirtualDirectory -Server EX13-2 | Set-OabVirtualDirectory -InternalUrl

[PS] C:\>Get-OabVirtualDirectory -Server EX13-2 | fl *url*

InternalUrl :
ExternalUrl :

Friday, August 8, 2014

Exchange 2010 (SP3) - Migration - Part 4 - Send and Recieve Connectors, Transport Rules

In the context of a migration (or more correctly, a "transition") from Exchange 2007 to 2010, most of the Hub Transport settings at the Organization configuration level, will be migrated automatically. These settings are stored in the Configuration partition of Active Directory. When the Exchange 2010 server is installed, it will query Active Directory and these settings will populate the tabs such as "Remote Domains", "Accepted Domains", "Email Address Policies" and so forth.

However, there are some exceptions and particularities that should be taken into consideration...

Send Connectors

In particular, this is true of the Send Connector settings. However, there is at least one major exception. If we look under the "Source Server" tab of the Send Connector properties, we will notice that the new Exchange 2010 server is not present (only EX1, the Exchange 2007 server).

This is sometimes forgotten and someone will ask, on the Technet forums for example, why they can send mail internally from the new server but not externally (they also remark that existing servers can send email both internally and externally).

First, let's remember that Exchange has ïmplicit connectors for internal email trafic. These connectors do not need to be configured and cannot even be accessed in the normal interface for configuration. They just work "as is".

Second, it's simply a matter of adding the Exchange 2010 server to the Source Server list.

Of course, we can add another server using Powershell as well:

Set-SendConnector -SourceTransportServers 'ex1','EX13-1' -id 'MYNET-SendConn-1' 

Note: with the Powershell cmdlet, we must indicate all servers after the -SourceTransportServers parameter. If we only list EX13-1, only EX13-1 will be included.

Lastly, on the subject of send connectors, if there is a second (or third, etc.) Exchange 2010 server, we must add it also. It will not be added automatically.

Receive Connectors

Unlike Send Connectors, Receive Connector settings exist at the Server Configuration level and must be configured on each server, manually or with a script. One parameter in particular requires attention : the Permission Groups tab.

By default, "Anonymous users" are not allowed to connect to the Receive Connector. This prevents external users from sending email to the organization, since they have no means to authenticate (they would have no username or password, much less a smart card or security token). If we want to receive messages from the outside world, we must check the appropriate box above.

Transport Rules

Transport rules are a special case. The rules existing on the Exchange 2007 server are migrated to the 2010 server when we install the latter but that's it. There is no further synchronization. So, if we create a new transport rule on either the Exchange 2007 or 2010 server AFTER the installation of Exchange 2010, that rule will only exist on the server on which we created it.

This is because transport rules are stored in different locations. For Exchange 2007:

CN=Transport,CN=Rules,CN=Transport Settings,CN=MYNET,CN=Microsoft Exchange,CN=Services

And for Exchange 2010:

CN=TransportVersioned,CN=Rules,CN=Transport Settings,CN=MYNET,CN=Microsoft Exchange,CN=Services

Here's an example.

On my Exchange 2007 server, I created a transport rule to test something for someone that asked a question about blocking spam (the details of the rule are not essential for this discussion).

Note the Exchange 2007 icon in the upper left-hand corner.

This rule was migrated to the Exchange 2010 server:

Note the Exchange 2010 icon in the upper left-hand corner.

Now I create a new rule (TR2) on the Exchange 2007 server...

And a new rule (TR3) on the Exchange 2010 server...

Neither replicate to the other server (which we can observe on the Exchange 2010 server above: the rule TR2 does not appear, only TR3 which was created on the Exchange 2010 server).


At this point, mailbox users that will be migrated to the Exchange 2010 server should be able to send email to both internal and external recipients and also receive email from both internal and external senders.