Люди поле средства выбора, встроенное в документы Office, не отображает диалоговое окно "Добавление Люди"

• Применяется к:

  Microsoft SharePoint

Признак

Рассмотрим следующий сценарий.

• Вы используете файлы Office, такие как документы Word или формы InfoPath, в которых есть встроенное поле "Выбор Люди" на панели сведений о Office.
• Клиенты подключаются к сайту Microsoft SharePoint по адресу https.
• Прокси-сервер или подсистема балансировки нагрузки существует между клиентами и серверами SharePoint 2010 или SharePoint 2013. Ssl завершается на прокси-сервере или подсистеме балансировки нагрузки.

В этом сценарии, когда файлы открываются в клиентском приложении, во внедренных полях средства выбора Люди не отображаются видимые результаты. Кроме того, при трассировке сети отображается ошибка http 500 для https-запроса, отправляемого на сайт SharePoint по следующему пути:

/_vti_bin/spclaimproviderwebservice.https.svc

При возникновении этой проблемы Просмотр событий на веб-интерфейсном сервере SharePoint может отображать событие, похожее на следующую запись:

Log Name: Application  
Source: System.ServiceModel 4.0.0.0  
Date: <Date and Time>  
Event ID: 3  
Task Category: WebHost  
Level: Error  
User: <Service account>  
Computer: <FQDN>  
Description:  
WebHost failed to process a request.  
 Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/57709411  
 Exception: System.ServiceModel.ServiceActivationException: The service '/_vti_bin/spclaimproviderwebservice.https.svc' cannot be activated due to an exception during compilation. The exception message is: Could not find a base address that matches scheme https for the endpoint with binding BasicHttpBinding. Registered base address schemes are [http]..  
 ---> System.InvalidOperationException: Could not find a base address that matches scheme https for the endpoint with binding BasicHttpBinding. Registered base address schemes are [http].  
 at System.ServiceModel.ServiceHostBase.MakeAbsoluteUri(Uri relativeOrAbsoluteUri, Binding binding, UriSchemeKeyedCollection baseAddresses)  
 at System.ServiceModel.Description.ConfigLoader.LoadServiceDescription(ServiceHostBase host, ServiceDescription description, ServiceElement serviceElement, Action`1 addBaseAddress, Boolean skipHost)  
 at System.ServiceModel.ServiceHostBase.ApplyConfiguration()  
 at System.ServiceModel.ServiceHostBase.InitializeDescription(UriSchemeKeyedCollection baseAddresses)  
 at System.ServiceModel.ServiceHost..ctor(Type serviceType, Uri[] baseAddresses)  
 at System.ServiceModel.Activation.ServiceHostFactory.CreateServiceHost(Type serviceType, Uri[] baseAddresses)  
 at System.ServiceModel.Activation.ServiceHostFactory.CreateServiceHost(String constructorString, Uri[] baseAddresses)  
 at System.ServiceModel.ServiceHostingEnvironment.HostingManager.CreateService(String normalizedVirtualPath, EventTraceActivity eventTraceActivity)  
 at System.ServiceModel.ServiceHostingEnvironment.HostingManager.ActivateService(ServiceActivationInfo serviceActivationInfo, EventTraceActivity eventTraceActivity)  
 at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath, EventTraceActivity eventTraceActivity)  
 --- End of inner exception stack trace ---  
 at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath, EventTraceActivity eventTraceActivity)  
 at System.ServiceModel.ServiceHostingEnvironment.EnsureServiceAvailableFast(String relativeVirtualPath, EventTraceActivity eventTraceActivity)  
 Process Name: w3wp  
 Process ID: <PID> ULS logs from the SharePoint server may contain entries that resemble the following:  

<Date and Time> w3wp.exe SharePoint Foundation Runtime fx7n Medium Cannot find factory type for service at /  
_vti_bin/spclaimproviderwebservice.https.svc   

Причина

Эта проблема возникает из-за того, что SharePoint использует разные веб-службы для веб-сайтов в зависимости от того, имеют ли сайты адреса "http" или "https". Если веб-сайт использует "http", ожидаемым адресом веб-службы будет spclaimproviderwebservice.svc . Если веб-сайт использует "https", ожидаемым адресом веб-службы будет spclaimproviderwebservice.https.svc .

В этом сценарии пользователь переходит по адресу https, но ssl завершается на прокси-сервере или подсистеме балансировки нагрузки. Так как серверы веб-интерфейса SharePoint получают HTTP-запросы, они ожидают, что путь запроса веб-службы будет использоваться для http-версии службы. То есть они ожидают /_vti_bin/spclaimproviderwebservice.svc вместо /_vti_bin/spclaimproviderwebservice.https.svc.

Поэтому запросы /_vti_bin/spclaimproviderwebservice.https.svc для веб-службы SSL вызывают ошибку HTTP 500.

Решение

Для решения этой проблемы воспользуйтесь одним из описанных ниже способов.

Метод A

Добавьте iRule в подсистему балансировки нагрузки или в службах IIS, чтобы запросы для сайта HTTPS, включающего путь spclaimproviderwebservice.https.svc, изменялись на http и spclaimproviderwebservice.svc перед перенаправлением запроса на роль сервера веб-интерфейса SharePoint (WFE).

Метод B

Настройте топологию веб-сайта так, чтобы ssl завершалось на серверах SharePoint, а не на прокси-сервере или подсистеме балансировки нагрузки.

Дополнительные сведения

Для метода A для устранения этой проблемы подтверждается следующая логика:

Правило IIS:

<rule name="SpClaimProviderWebService" stopProcessing="true">  
< match url="^(.*)spclaimproviderwebservice.https.svc$" />  
< action type="Rewrite" url="{R:1}spclaimproviderwebservice.svc" />  
< /rule>  

Правило F5/NLB:

when HTTP_REQUEST {  
if { [[string tolower] [HTTP::path]] contains "spclaimproviderwebservice.https.svc"} {  
HTTP::path [string map {.https ""} [HTTP::path]]  
}  
}  

Требуется дополнительная помощь? Посетите сайт сообщества SharePoint.