Answer for Stuck on last screen of wizard
Further detail about how the wizard performs its tests…
Purpose:
The purpose of the tests at the end of the wizard are to ensure that all connections to the source and target environments are working before starting the batch. These tests were added to provide confidence that, once the batch started, one could walk away from the migration and not be surprised later with simple issues like a database being offline, or a server being unavailable.
In a larger, more distributed environment, there may be multiple exchange databases and servers from which or to which a migration is focused. It was proven frustrating prior to these tests to find out after a batch started that one database out of several was offline – the result was such that the batch would start and begin migrating several mailboxes. This was enough for most administrators to assume that everything was ok. However, coincidences could occur where the active mailboxes were communicating properly, but after a few minutes, or hours, when the batch started work on other mailboxes from another database, failures would occur because that second database was offline or the server was unavailable. This pattern caused all other work to be block as the migrator would infinitely retry such failures (they appear as mapi issues).
Two Sets of Tests:
There are 2 sets of tests that occur on the last page of the mailbox migration wizard: server tests and database tests. The following will detail how the tests are performed in order to aid with any troubleshooting.
Server Tests
Server tests are performed first. These tests can be a bit complicated depending upon the architecture of exchange.
Exchange 2007 and earlier:
Tests to these older versions of exchange are simplified since connections are per-server. The meaning here is that there is not a “proxy” connection that can broker a connection to a different server, as there is with Exchange 2010 and later. The server tests, in order to be efficient, will exit the test on the first database success – this is enough to determine the server is online and accepting connections. Only if all database connection tests fail will the server be considered a failed test.
Exchange 2010 and later:
Tests to these versions of exchange are more complicated due to the existence of the CAS (Client Access Server). Since all mailbox connections must pass through these server types, we must validate that connections to all the CASs can be made. In Exchange 2010 and later, a CAS can accept a connection for a database that resides on a different server. In fact, any CAS in the same AD Site as a mailbox server can accept connections for that mailbox server – there is not a one-to-one relationship between a CAS and a mailbox server.
In order to determine if a mailbox server is online and available, testing is done by connecting through all CASs in the same AD Site for the mailbox server being tested. If ALL CAS connections fail, we consider the mailbox server to be offline or unavailable. The process is one of shortest path: as soon as a connection can be made to the mailbox server, we consider that server to be “ok”. Following such a success, the process then proceeds to repeat that test with all the other CASs that exist. In this way the application can understand which CASs are and are not available – CASs that fail a connection are marked as unavailable with a 10 minute timeout, after which it can be retried.
However, much like with the Exchange 2007 tests described above, a mailbox server is only considered to fail the test if ALL databases on that server fail connection tests. Testing in this way, when a server is unavailable, can take considerable time, especially if there are many CASs in the site.
Consideration has been made for cases where there may be a CAS that should not be used in testing – perhaps it is a DR site CAS or is down for maintenance. There exists an ability to exclude one or more CASs from being used. However, it is not recommended to exclude all CASs except for a single CAS as such creates a performance bottleneck. The migrator has the ability to aggregate its workload across multiple CASs (much like a load balancer).
Database Tests
Database tests are done by creating a new temporary Outlook (mapi) profile to the SystemMailbox of each source and target mailbox database, based on the databases of the selected source accounts and target database assignments – as such, not EVERY database in an environment is tested, but only those that are part of the batch. These tests allow the application to report any issues since a failure to connect in this manner will certainly cause mailboxes failures in the migration console.
Shimming
Priasoft has an industry only feature for Exchange 2013 environments where the application can “shim” the connection to force a connection to a specific CAS. Shimming is where the application intercepts the DNS query for a shared name (e.g. mail.company.com) and replaces the IP address with a CAS specific address. In order to explain the value of this feature, some background on Exchange 2013 connections is likely of value.
Exchange 2013 has CASs, but they are not site specific as with Exchange 2010. Furthermore, Exchange 2013 promotes the use of SSL for all connections to the mail system. A typical and recommended setup of Exchange 2013 is to have a common, shared connection name in DNS; mail.company.com for example. This common name allows for easier connection routing plans, some as simple as round-robin DNS with others being more complex, intelligent load-balancers. The issue this presents for migrations is that when multiple mailboxes are migrating simultaneously, all those connections can (and likely will be) routed to a single CAS – there’s no guarantee that round-robin DNS or a load balancer will evenly distribute the connection load across all the CASs behind the shared name.
The migrator does not immediately use the shared name however…it only uses the shared name if direct CAS connections fail to work. Connections to CASs are performed in the following order, exiting out on the first that succeeds:
- Unencrypted HTTP connection directly to the CAS
- Encrypted HTTPS connection directly to the CAS
- Shimmed HTTPS connection, directly to the CAS by IP address. The name ‘mail.company.com’ is intercepted and the IP address for exch-cas-01 is used instead. This forces and guarantees that we are talking to a specific CAS.
- Normal HTTPS connection. This final attempt is a standard connection but loses the ability for the tools to evenly distribute connection loads.
So, in summary, shimming is a way for the tools to discretely control which CAS is being used with the configuration does not allow direct CAS connections.
