Update SharePointHybrid.md

Author: atupal

markdown_snippet/SharePointHybrid.md

@@ -49,3 +49,49 @@ ee323428(v=office.13).aspx。这个指南现在已经非常老了，但它在检
 - 重新从头开始运行 Azure AD Connect Configuration 工具
 - 在 MIISClient 工具中修改帐号密码
 
+我们不推荐在 MIISClient 工具中修改密码，除非您对 Microsoft Identity Management 产品有深入的理解。相反，我们推荐运行 Azure AD Connect Configuration 工具，然后提供更新后的凭证。
+
+当您确信 directory synchronization 正确地工作了并且在 Office 365 Admin Portal 的 DirSync tile 上没有任何错误信息之后，就可以进入下个诊断的步骤了。
+
+验证 Azure Access Control Services server-to-server trust
+=========================================================
+SharePoint Server 和 Office 365 的 hybrid workloads 的核心是一个桥接 on-premiese 和 Online 环境的配置元素。Windows Azure Active Directory Access Contrl Service (ACS) 是一个基于云的 federation service，它提供了一种易用的方式来对 identiy providers 来认证用户，最重要的 identiy provider 便是 Azure Active Direcotory。因为 ACS 是所有 hybrid 场景的核心，如果它出了毛病会影响到所有的工作。第一章已经描述过如何配置 ACS，您可以一步一步地按照着配置。这也意味着我们同样也可以一步一步地去验证所有的一切都在正常工作。实现验证的最好的方式就是使用 Windows PowerShell。
+
+您可以使用下面的脚本块来验证 server-to-server (S2S) trust，ACS 被正确配置好了。
+
+首先，让我们确保有足够来进行诊断。这将包含一个被创建或者从某处获取到的原先用于配置 ACS trut 的证书。我们还需要 Offie 365 SharePoint Online App ID。
+> Note 如果您使用了 Hybrid Picker 或者 Cloud Search Service Application onboarding script，您不会有这个证书。在这种情况下，我们可以安全地假定脚本将会是一致的，因为它就是我们用来配置 trust 的同一个证书。
+
+当您创建或者获取一个证书时，您需要确认它正在被 SharePont on-premises 用于对 token 签名。您可以比较证书的拇指纹是否一致来判断。
+
+这个脚本的输出将会显示正在匹配证书的拇指纹。
+
+您接下来需要验证用于 token 签名的证书没有过期。如果过期了，将会导致 token 签名问题，通常表现为在用户界面或者 Unified Loging Service (ULS) 日志中出现 JWT token 错误。
+
+这个阶段的输出将会显示当前的证书和可能已经被替换了的以前部署的证书。下面的例子显示了两个注册到 Office 365 Application Principal 的两个证书。其中一个已经过期了，另外一个是更新的一个证书且过期时间更长。仅供参考，一个过期时间为 1/1/999 的 hybrid 证书通常表示内置的 SharePoint Security Token Signing Certificate 被用来组成 trust。如果您没有任何用于 ACS trust 的合法证书，您必须得部署一个新的。您可以依照第一章中相关的步骤来部署一个新的证书，或者重新运行 Hybrid Picker 或者 Cloud Search Servide Application onboarding script 来重新创建 trust。
+
+为了让 ACS 配置工作，您下一件需要检查的事情是验证注册到 Office 365 application principal 上的 Service Principal Names (SPNs) 和期望的 on-premises 用户请求的来源是一致的。
+
+脚本的输出显示了一个或多个 SPN，这些 SPN 涵盖了 outbound request 会收到和 inbound request 会被发送的 SharePoint web appliation URL。在下面的例子中，您可以看到 SPN 是一个匹配 *.contoso.com 的通配符。这个通配符意味着所有的 full qulified domain name (FQDN) 以 contoso.com 结尾的 web application 都会被这个 SPN 所覆盖。
+
+对 SPN 需要小心的一点不要让多余的 SPN 覆盖同同样的 URL。举例来说，如果从脚本的输出是下面这样的，我们就有了一个重复的 SPN 冲突，因为通配符已经覆盖了所有的可能性，intranet.contoso.com 这个显示的 SPN 就不再需要了。这是我们应该避免的。
+
+要移除一个重复的 SPN，您可以使用下面的脚本：
+
+这里的索引值(1)，应该被替换成需要移除的 SPN 的 ID。在前面的例子中，这会移除掉 intranet.contoso.com 这个 SPN 而留下通配符。这是因为通配符可能还会被用于其他的目的，但是通配符也覆盖了我们正在移除的 SPN，所以不会功能上的丢失。
+
+验证 ACS trust 被正确设置的最后一步就是确保 ACS ServiceApplicatinProxy 已经被成功地部署好了。SharePont 通过 ServiceApplicationProxy 来和 ACS service endpoint 通信，所以确保它被部署了且在线对 ACS trust 实现是非常重要的。
+
+脚本的输出应该显示 proxy 在线和它配置的 ACS endpoint。
+
+这个时候另外一个额外的诊断验证步骤是检查 on-premises SharePoint 服务器能够访问 MetaDataEndpointUri。如果您把这个 URL 复制到浏览器中并打开，一个下载文件，1.json，的对话框应该会弹出到您的面前，这个文件包含了证书和一些关键细节，这对 Microsoft Support 诊断来说可能会很有用。如果您不能访问这个文件，您应该检查服务器能够访问外网。
+
+单独验证证书
+============
+我们当前的主题是证书，对证书进行通常的检查值得一看。如果您怀疑或者有证据表明证书因为一些原因可能损坏了，您可以使用 Active Directory Certificate Services tool, CertUtil.exe, 来进行证书验证。CertUtil.exe 有许多特性，您可以在 https://technet.microsoft.com/
+library/cc732443.aspx 阅读更多，但在这一章中，我们关注的只有一个：验证。
+
+用管理员的身份运行下面的命令行：
+
+这里的输出被重定向到 certverfiy.txt 文件中去了，您可以检查这个文件，查看是否有证据表面这个证书出现了问题。在这个例子中，我们故意检查了一张已经过期了的证书，这是最常见的错误。certverify.txt 文件的内容看起来会像下面这样：
+