Exchange 问答：获取正确的信息

邮件跟踪

问：您可以共享提示或对你如何做邮件跟踪两个？ 我们发现要使用有限的 GUI。 我们正在寻求建议如何获取所需的信息的邮件跟踪日志。

答：使用 Windows PowerShell 的邮件跟踪是可取的做法。 它为您提供更多的查询参数控制，快得多。 典型的一行程序将是：

          Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM"
        

这会将你的所有邮件跟踪记录从所有传输服务器在您的环境中，有的 test@contoso.com，2012 年 3 月 18 日，起价 9 上午的发送地址 如果要将结果导出到您的用户或客户，管道进入出口-CSVcmdlet 的结果：

          Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | Export-CSV –Path c:\temp\messagetracking.csv
        

要深入进行故障诊断的结果吗？ 为命令添加格式-listcmdlet：

          Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | fl
        

为便于使用和抽出大量的输入，它是写自己小的 Windows PowerShell 函数的一个好主意。 这样可以快速和有效的搜索。 此示例将搜索所有集线器传输服务器中的日志、 接受汇作为参数并搜索数据值得最后 24 小时：

          functionmt {param ($sender)
$SDate = (get-date).adddays(-1)
get-transportserver | get-messagetrackinglog -sender $sender -start $SDate
}
        

随意适应此函数来满足您的需要。 此外可以将这段代码放置在 $ 配置文件.ps1 文件，所以它获取启动时加载。 从此以后，您只需键入：

          mt –sender test@contoso.com
        

使用更新汇总

问：我们听说我们可以使用 Exchange 2010 安装源媒体上更新文件夹安装在安装过程中的汇总。 是这是准确的吗？

答：是的这是准确的 — — 至少部分。 您可以使用更新目录以新鲜的 Exchange 2010 安装过程中安装匹配的汇总并减小所需的安装时间。 只是.msp 文件放到相应的目录中，如中所示图 1。

图 1 添加到更新目录.msp 允许您安装匹配的汇总。

请不要尝试这对于升级安装，例如，发布的第二次的服务包，或第一的服务包，到第二个服务包的制造。 这将不起作用，安装将会失败。 升级需要按顺序进行，不能以这种方式将它们合并。 更多的信息，在 TechNet 库页中，"安装最新的更新汇总，对于 Exchange 2010."

SP1 或 SP2 吗？

问：我们已到第二个服务包升级我们的 Exchange 2010 边缘服务器。 安装完成，没有错误。 不过，在用 Get ExchangeServer 望内部版本号，他们仍然显示为 14.1.xx，aka SP1。 在这里哪里出了问题？

答：这是有点误导，但实际上预期的行为。 边缘订阅后，Microsoft 不会更新生成数字作为定期 EdgeSync 进程的一部分。 如果您需要重做整个订阅 （例如，如果您的证书用于 EdgeSync 过期），您将看到生成数字也会更新。

权限的延误

问：当我试图授予 Exchange 2010 年的邮箱的邮箱完全控制权限时，邮箱列表需要很长的时间来填充 （任意位置从几分钟到小时）。 有什么可以做那件事吗？

答：这是一个常见的问题。 在"选择帐户"窗口，慢慢地不当的 LDAP 查询填充的理由。 您正在读取的所有邮箱，并随后应用筛选器。 如果你正在寻找一个名为"弗雷德"的邮箱，例如，将第一次获得的所有安全主体的列表。然后你会检查之后是否其中之一是弗雷德的。 这一过程是缓慢的尤其是在大用户计数装置。

幸运的是不够的安全增强功能的 Microsoft Exchange 或 Exchange(SE)，决定针对 Exchange 2010 SP2，即汇总 1 的最新和最大汇总中解决此问题。此修复程序的直接链接这里。

集成身份验证

问：我们试图启用 Windows 集成身份验证为动用 Outlook Web 应用程序 （OWA） 以获得体面单一登录经验为我们内部的加入域的客户。 客户端访问一个称为 https://mail.contoso.com 的网络负载平衡 (NLB) URL。

我们第一次启动代理程序禁用，OWA 虚拟目录上启用 Windows 集成身份验证。 但是，当试图访问 https://mail.contoso.com/owa，我们是仍然获取凭据的提示。 当我们通过直接输入一个客户端访问服务 (CAS) URL，例如，https://cas1.contoso.com/owa 或 https://cas2.contoso.com/owa，访问 OWA 页面时我们就被记录没有提示了。 要使它实际上更光怪陆离，如果我们在我们的案例 https://10.1.1.150/owa，键入的 mail.contoso.com，解决的 IP 我们是也登录无须身份验证。 你能帮吗？

, 答： 工作后向上和向下通过 Netmon 和小提琴手痕迹的路上，我终于发现使用的身份验证方法的改变 （您可以看到这些在 小提琴手） 当我从 https://10.1.1.150/owa （工作，不提示） 切换到了 https://mail.contoso.com/owa （提示）。

原来访问时解决的 IP，我们使用 Windows NT LAN 管理器来对 OWA 进行身份验证。 切换到 NLB 完全限定域名时，我们开始使用 Kerberos 去反对，民安队。

多一点开挖施工和聪明地使用 setspn.exe – l 透露有人添加了一个称为 http/mail.contoso.com 到完全不相关的计算机帐户的服务主体名称 (SPN) 项。 这反过来使客户端计算机去 Kerberos 票证的 （因为在活动目录中找到对应的项），然后提出 CAS 框中的票。 CAS 框显然还不知道怎么处理 Kerberos 票证发出一些完全不同的框，所以它扔多次身份验证的提示。

假的 SPN 条目被删除后，Windows 集成身份验证开始工作立即针对 NLB URL 和身份验证提示不见了。

免责声明不和谐

问：我们试图创建传输规则将添加到所有传出邮件的免责声明。 在测试期间，我们发现的运输箱似乎忽略该规则。 它才添加所需的免责声明，即使之后重新启动所有集线器框，以确保他们实际装载该规则。 然而，同样的规则有魅力，在我们的测试环境中工作。 你有什么主意吗？

答： 要执行此功能的实际规则看起来像所示 图 2。

图 2 此规则的目的是在待发邮件的末尾添加免责声明。

在检查后像复制嫌疑，运输服务不知道有任何改变，等等，一切看起来都正确。 然后我们检查额外跟踪处理传出电子邮件时捕获.etl 规则引擎。

.Etl 透露运输服务充分意识到新的传输规则，但是无论是什么原因没有认出传出邮件作为"传出"。出于某些原因，他们被视为内部。

进一步跟踪显示规则引擎考虑为内部的远程域中的"默认远程域"条目。 因此，它才适用免责声明规则。

在查看的问题，我注意到它说 IsInternal： 远程域的默认值为 $true。 这会告诉治疗要的地址空间中的所有邮件交换 ＊ 为内部 — — 并因此不适用免责声明。 我们改回默认值设置为 false。 现在免责声明被成功应用。

原来访问时解决的 IP，我们使用 Windows NT LAN 管理器来对 OWA 进行身份验证。 切换到 NLB 完全限定域名时，我们开始使用 Kerberos 去反对，民安队。

多一点开挖施工和聪明地使用 setspn.exe – l 透露有人添加了一个称为 http/mail.contoso.com 到完全不相关的计算机帐户的服务主体名称 (SPN) 项。 这反过来使客户端计算机去 Kerberos 票证的 （因为在活动目录中找到对应的项），然后提出 CAS 框中的票。 CAS 框显然还不知道怎么处理 Kerberos 票证发出一些完全不同的框，所以它扔多次身份验证的提示。

假的 SPN 条目被删除后，Windows 集成身份验证开始工作立即针对 NLB URL 和身份验证提示不见了。

免责声明不和谐

问：我们试图创建传输规则将添加到所有传出邮件的免责声明。 在测试期间，我们发现的运输箱似乎忽略该规则。 它才添加所需的免责声明，即使之后重新启动所有集线器框，以确保他们实际装载该规则。 然而，同样的规则有魅力，在我们的测试环境中工作。 你有什么主意吗？

答： 要执行此功能的实际规则看起来像所示 图 2。

图 2 此规则的目的是在待发邮件的末尾添加免责声明。

在检查后像复制嫌疑，运输服务不知道有任何改变，等等，一切看起来都正确。 然后我们检查额外跟踪处理传出电子邮件时捕获.etl 规则引擎。

.Etl 透露运输服务充分意识到新的传输规则，但是无论是什么原因没有认出传出邮件作为"传出"。出于某些原因，他们被视为内部。

进一步跟踪显示规则引擎考虑为内部的远程域中的"默认远程域"条目。 因此，它才适用免责声明规则。

在查看的问题，我注意到它说 IsInternal： 远程域的默认值为 $true。 这会告诉治疗要的地址空间中的所有邮件交换 ＊ 为内部 — — 并因此不适用免责声明。 我们改回默认值设置为 false。 现在免责声明被成功应用。