偶尔，我也会遇到一些让我沮丧的事情。今天也不例外，我又一次偶然发现了一些让人难以置信的事情。
最近，我又开始进行交换计划了。在这个特殊的日子(今天)，我正在进行跨森林Exchange Server 2007迁移。人们可能会认为这很简单。毕竟，移动邮箱cmdlet在一定程度上就是为这种场景设计的。另外，在实验室环境中验证整个迁移过程，逐步测试，并记录下来。
今天，我们与一系列测试用户一起经历了迁移过程。事情看起来很好，我们的自动化脚本转储邮件并将其归档到一个PST中，ADMT将帐户移到另一边，我们启动了自动化脚本，开始将邮箱移到另一边。只有一个问题，移动邮箱cmdlet在合并目标端的对象时出现以下错误:
"在更新属性的步骤中发生错误。由于microsoftexchange信息存储服务不可用，该操作无法完成。确保服务正在运行，并且您与Microsoft Exchange服务器计算机有网络连接。”
奇怪的是……考虑到该流程是使用“镜像”生产环境的实验室环境来审查的。因此，我很自然地开始遍历生产设置，以“确保”没有漏掉某些东西(比如许可等)。不出所料，我没有发现任何不同之处，这让我挠头。实际上，我能想到的唯一区别是源和目标迁移帐户使用的密码。毕竟，作为一个安全极客，我要求客户将生产迁移帐户的密码设置为一个复杂的密码。
嗯……不会吧?我有一个实验室环境，所以我微笑并开始玩cmdlet。我很快发现，当源或目标凭证的密码超过14个字符时，cmdlet会失败并出现提示的错误消息。在客户端生产环境中使用的密码为15个字符。
有人会说:lame!如果Exchange产品团队的某人正在阅读此条目，您能插话并解释为什么凭据有密码长度限制吗?我发现的另一个博客条目似乎也有特殊的字符限制:Link
就像我说的，没用。但是，真正让我困扰的是那可怜的错误信息。至少给我一根骨头。
如果你喜欢这篇文章，可以看看泰森的其他文章:
- 计算机科学学位什么时候重要，什么时候不重要
- 云计算从什么时候开始成为/需要一个宣言?
- 为什么要使用证书颁发机构(CA)作为诱饵?
- 如果所有人都信任你，我还会信任你吗?
- 这是一个很好的问题:是脚本编程还是仅仅是系统管理?
- PowerShell boy和cmdlet丢失的情况!
- 有趣的PowerShell 2.0事件!
- 创建一个自定义404页面来处理ASP的链接重定向。净的web应用程序
如果你愿意，你也可以看看泰森的最新出版物:
- Windows PowerShell释放(2nd版)
- Windows Server 2008发布(是的，我确实帮助了这本书)