The Move-Mailbox cmdlet, a Cross-Forest move, and a complex password

Long complex passwords cause the Move-Mailbox cmdlet to fail when moving mailbox between forests.

From time to time, I come across things that just frustrate the hell out of me. Today was no exception as I again stumbled across something that just boggles the mind.

As the story goes… As of recent, I’ve been working on Exchange projects again. On this particular day (today), I was working on a Cross-Forest Exchange Server 2007 migration. Easy enough one might think. After all, this is a scenario that the Move-Mailbox cmdlet was partly designed for. Additionally, the entire migration process was verified within a lab environment, tested step-by-step, and written down.

Today, we were going through the migration process with a series of test users. Things were looking good, our automation script dump mail to be archived into a PST, ADMT moved the account over, and we fired up the automation script to start moving the mailboxes over. There was just one problem, the Move-Mailbox cmdlet was crapping out with the following error when objects on the target side were being merged:

“Error occurred in the step: Updating attributes. The action could not be completed because the Microsoft Exchange Information Store service is unavailable. Be sure the service is running and you have network connectivity to the Microsoft Exchange Server computer.”

Odd… considering that the process had been vetted using a lab environment that “mirrored” the production environment. So, I naturally, started walking through the production setup to “ensure” something was not missed (like permission etc.). As expected, I found nothing that differed and was left scratching my head. In fact, the only difference that I could come up with was with the password that was being used by source and target migration accounts. After all, being a security geek, I had asked the client to set the production migration accounts password to a complex password.

Hmmmm…. That could not be it? I had a lab environment, so I beamed in and started playing with the cmdlet. I soon found that when you had a password that was longer than 14 characters for either the source or target credentials the cmdlet failed with the noted error message. The password that was being used in the client’s production environment was 15 characters long.

Can someone say: lame! If someone from the Exchange product team is reading this entry, can you please chime in and explain why there password length limitation for the credentials? Also it seems that there are special character limitations per another blog entry I found: Link

Like I said, lame. But, what really bothered me was the poor error message. At least give me a bone.

If you like this, check out some other posts from Tyson:

Or if you want, you can also check out some of Tyson's latest publications:

Lastly, visit the Microsoft Subnet for more news, blogs, and opinions from around the Internet. Or, sign up for the bi-weekly Microsoft newsletter. (Click on News/Microsoft News Alert)

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2009 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)