我遇到了一个问题，即在没有可行解决方案的情况下耗费了很长时间。我没有关于Sharepoint的经验，而且我可能过度使用它，如果解决方案比我预期的要简单得多，我也不会感到惊讶。
方案如下：
1）我们在客户端（A）安装了SharePoint。客户端（A）环境包括测试和生产环境。 生产环境为每个WFE和BEDS提供单独的服务器。 测试环境包括WFE＆amp; BEDS在一台服务器上。两个环境都位于同一个域中。
2）Sharepoint版本是2013年。
3）客户（A）与客户（B）域建立双向信任关系。
问题：生产Sharepoint PeoplePicker可以成功地从域（B）获取用户在PeoplePicker完全没有配置。但是，测试Sharepoint PeoplePicker无法获取域（B）可信用户。并且＆＃34;无法找到完全匹配＆＃34;错误。
我在测试环境中尝试了以下解决方案（WFE和BEDS共处）以找到问题：
1-检查所有PeoplePicker相关属性（Peoplepicker-searchadcustomquery，Peoplepicker-onlysearchwithinsitecollection，Peoplepicker-searchadforests，setsiteuseraccountdirectorypath等），什么都没有。此外，我在两个环境（生产和测试）上运行人员选择器端口测试器来比较任何防火墙配置差异，即使一些端口抱怨并且UDP端口（445,135）之间存在差异，仍然，我不要认为这是问题，因为Wireshark后面的步骤（3）将告诉为什么它不可能。从我在互联网上看到的内容来看，我必须在双向信任场景中为人们选择器配置任何东西，仍然尝试单向信任配置，没有任何工作和我还原了这些变化。
PeoplePicker port tester run results
2-配置Sharepoint以详细记录（所有组件，因为我不知道哪个负责PeoplePicker）收集了日志并搜索了查询用户的日志。没有有用的信息，从ULS Viewer附加截图，用户被屏蔽。
3-收集Wireshark流量转储并通过LDAP过滤。我可以清楚地看到LDAP响应包含来自受信任的查询用户以及所有用户属性和域名。这就是我排除任何人员选择过滤原因，域名搜索限制或网络端口问题的原因。屏幕截图已附上。
4-排除网络问题后（当LDAP查询成功返回WFE时），我决定在PeoplePicker中显示结果之前看看Sharepoint内部的流程如何。如果找到Microsoft的this文章，则说明PeoplePicker工作流程。从下图中，我可以得出结论，LDAP请求成功通过了步骤1,2和3.我需要检查从4到11的步骤，这些步骤是MS-WSSFO协议握手。我读到了协议，发现它包含从WFE到BEDS的一组存储过程调用。我尝试使用SQL Server Profile调试协议并搜索（proc_GetTpWebMetadataAndListMetadata）＆amp; （proc_GetListMetadataAndEventReceivers）存储过程但没有找到。
5-我的一位朋友建议配置UPSA（用户配置文件服务应用程序）连接到可信域（域B）活动目录，我授予Sharepoint服务用户在（域B）活动目录上所需的权限，配置连接和测试同步，它确实加载了用户，我可以从Synchronization Service Manager看到，但是，PeoplePicker仍然失败。但是，我认为这一步是不必要的，因为就我所知，PeoplePicker和UPS没有关联，因为Production Sharepoint PeoplePicker在没有配置UPSA的情况下工作正常。 有什么帮助吗？
答案 0 :(得分：-1)
尝试运行此命令。 stsadm -o setproperty -pn peoplepicker-searchadforests -pv“ forest：name，domain \ serviceid，password” -url https://webapplicationurl
添加多个用;分隔的林
