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.

Cannot convert value Microsoft.Exchange.Data.MultiValuedProperty

I recently needed a script to add new individuals to the accept message only permissions on a large list of distribution groups. It needed to be additive so that it was not overwriting the existing permissions.  I found several examples and modified them to suite my needs:

$allowedDL = gc C:\scripts\AllUserLock\allowedDL.txt

$People = gc C:\scripts\AllUserLock\People.txt

$Groups = gc C:\scripts\AllUserLock\Groups.txt

ForEach ($Group in $Groups) {

   Set-DistributionGroup $Group -AcceptMessagesOnlyFrom((Get-DistributionGroup $Group).AcceptMessagesOnlyFrom + $People)

   Set-DistributionGroup $Group -AcceptMessagesOnlyFromDLMembers((Get-DistributionGroup $Group).AcceptMessagesOnlyFromDLMembers + $alloweddl)

}

This worked great until I realized I’d missed adding a couple groups due to interruptions as I was working on this task. When I added the new groups to the allowedDL.txt file and ran the script again I got this error - Cannot convert value Microsoft.Exchange.Data.MultiValuedProperty.  I knew the syntax was correct.  The values that could not be converted were clearly the new distribution lists in the allowedDL.txt file. My web searches found several references to this error but no solutions or explanations. In fact I recognized it from an issue I have had previously importing trusted domains into Office 365 EOP.  A call to Microsoft support services was no help on that.

What I eventually found was that when I added the 2 new DL’s to allowedDL.txt I had added several trailing carriage returns. What happens is the scripts builds a text string and added it to the existing permissions.  It looks like “DL1,DL2,DL3DL4”.  Those carriage returns cause the string to look like “DL1,DL2,DL3DL4                    ” You cannot add white space to a multi-property string as that white space has value.White space is not interpreted a null value.

Removing the trailing carriage returns in the input file fixed the issue….. now I need to return to working on importing my trusted senders :

We use DirSync to synchronize our AD to MSOL. Today I found the following errors. 

Looking at the DirSync console I found many stopped-extension-dll errors. I also found corresponding errors in the event log.

A quick search online suggested that this is most often caused by the service account password expiring.  I was sure this was not the case as I went through this previously during the initial setup and mailbox migrations.  I was also able to log into the server using RDP with the service account.  I checked it anyway. The password was already set to never expire.

I found the C drive was full. After checking in with the system admin that manages our monitoring to see why I did not receive a disk space alert, I started digging to see what was eating all of my drive space.  I found that the DirSync tracing logs were the culprit.  I don't think I'd ever need more than 14 days of logs. I setup a scheduled task to delete them, leaving 14 days worth using forfiles.exe