Moving Exchange 2013 Databases Hangs at Validating Path

The consultant that set up my hybrid environment did a very basic install and loaded the mailbox database on the application drive and put the log files in the same folder with the database. We've not bothered backing up the Exchange system as we were not really using the local database.  Now I'm ready to use these on premise databases.  The backup app won't even load with the system configured with the logs and database on the same drive.  When I attempted to move the database the command hung while validating the path.

The problem is that the move database command checks to make sure that you have ~33% free disk space after the move has been completed for both the database and the log files.  Even though they would not be needed and would not be moved by the command there was a huge number of log files because we have not been completing an Exchange aware backup of these servers. 

I had to move the database manually:

1. Dismount the database

Dismount-Database "Mailbox Database

2. Verify clean shut down
Get-MailboxDatabase -Status | % { eseutil /mh $_.edbfilepath } | Select-String -Pattern "State:"

3. Manually copy the database to the new location

4. Verify the command with “what if”
Move-Databasepath “Mailbox Database” –EdbFilepath “F:\MailboxDatabase\Mailbox Database.edb” –LogFolderpath “E:\MailboxLogs” –ConfigurationOnly –whatif

 This checks the path so you’ll get an error if you don’t move the database ahead of time or there is a typo like this - WARNING: The Exchange database file path that you specified, "F:\MailboxDatabase\Mailbox Database.edb", doesn't exist.

5. Move the database using the configuration only command
Move-Databasepath “Mailbox Database” –EdbFilepath “F:\MailboxDatabase\Mailbox Database.edb” –LogFolderpath “E:\MailboxLogs” -ConfigurationOnly

6. Rename the old database to prevent confusion

7. Mount the database
mount-Database "Mailbox Database"

8. Verify logs are being created in E:\MailboxLogs

9. Verify the database is healthy
Get-MailboxDatabase -status |FL AutoDatabaseMountDial, EdbFilePath, LogFolderPath, Mounted

Can you hear me now? - There was no endpoint listening errors during migration

I recently attempted to migrate an admin account mailbox from the cloud back to our on premise Exchange environment.  It failed with the error below. 

There was no endpoint listening at <my target domain> that could accept the message.
 This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

The process is very straight forward and was fully documented as part of my roll back plan and was tested this successfully during the initial migration to Office 365. I tried several times using both available databases with no success. 

We recently rebranded the company and ended up replacing all of our SSL certificates with new wildcard certificates supporting both the old domain and our new domain. The new Exchange certificates were configured for IIS,SMTP and TLS.  However, due to the limited time frame for the change I neglected to remove the old certificate and simply let it expire in place.  

Once I removed the invalid certificate I was able to complete the migration to an on premise database.

Office 365 Fast track deployment process

I spent some time preparing for the MS 70-346 exam by reviewing "Managing Office 365 Identities and Services" on the Microsoft Virtual Academy site. A few of their comments explain all of the frustration I experienced with my consultant when it came to implementing the expanded pilot:

They explain the the fast track deployment process is designed to "Get the customer on to office 365 in a matter of hours."

They also stated, "You don’t need to go through all of that risk assessment that you would normally typically do if you were deploying servers on premise.…..simply because there is no risk. You’re not changing things like the mail delivery architecture. You’re not changing MX records. You’re not doing any of that sort of stuff."

We ran into quite a few issues with the deployment all of which were played down by the consultants:

• Mobile Devices had to be reconfigured
• Initially unable to connect to on premise public folders
• Public folders were dropped from distribution lists that were sync’ed from AD
• Migrated users were no longer able to manage sync’ed distribution lists
• No allowances were made for on premise anti-spam and anti-virus solutions.

There were just the highlights.  All of these issues should have been addressed before the first mailbox was moved.  I never understood the rush to production exhibited by the consultant and our Microsoft reps until I sat though this video.