当请求安全令牌时，Word自动化服务BatchGetSyncJobStatus失败

Question

我正在运行一个SharePoint 2013的前提服务器，我已经在该服务器上部署了一个简单的WCF服务作为一个农场解决方案。该服务接受包含单个MS文档的简单Http post请求作为有效负载，并返回转换为PDF的这些文件。匿名用户可以通过Http访问该服务。WordAutomationService作为SharePoint服务器的管理用户帐户运行。

服务类创建Microsoft.Office.Word.Server.Conversions.SyncConverter的一个新实例，并将SharePoint运行的WordAutomationService的代理传递给构造函数(连同一些ConversionJobSettings)。最后，它使用输入流( Word文档)和输出流( web )调用SyncConverter上的转换方法(web响应将包含WordAutomationService生成的结果PDF文档)。

在创建SyncConverter时，我不设置UserToken属性，因为对服务的访问是由匿名用户进行的。根据这里的评论，https://msdn.microsoft.com/en-us/library/microsoft.office.word.server.conversions.syncconverter.usertoken.aspx，这似乎很好：

此属性的默认值为空引用( Visual中为Nothing)，它是匿名的。

此设置对于带有几页的小Word文档可以很好地工作，并返回预期的PDF文件。但是，一旦WordAutomationService在SharePoint上的执行时间超过了一定的时间阈值(大约5秒)，服务就会失败，因为它永远不会返回(这会导致客户机上的读取超时)。根据日志，原因似乎是同步转换作业在一段时间后将工作转移到后台进程中：

同步流作业转换需要太长时间。别再等了。稍后检查它的状态

然后通过调用ConversionServiceApplicationProxy.BatchGetSyncJobStatus.定期轮询此作业的状态。不幸的是，这个调用失败了，因为在内部，它试图创建一个新的通道来与此进程对话，并要求提供一个安全令牌。但是，SecurityTokenService无法完成令牌请求并引发异常：

An unhandled exception has occurred. The security token request cannot be completed. System.InvalidOperationException: The security token request cannot be completed.    
at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForServiceContext(Uri contextUri)     
at Microsoft.SharePoint.SPChannelFactoryOperations.InternalCreateChannelActingAsLoggedOnUser[TChannel](ChannelFactory`1 factory, EndpointAddress address, Uri via)     
at Microsoft.Office.ConversionServices.Service.ConfigChannelFactory`1.CreateChannel(EndpointAddress address)     
at Microsoft.Office.ConversionServices.Service.ConversionServiceApplicationProxy.GetChannel(Uri uri)     
at Microsoft.Office.ConversionServices.Service.ConversionServiceApplicationProxy.ExecuteOnChannel(Uri endpointAddress, Action`1 action)     
at Microsoft.Office.ConversionServices.Service.ConversionServiceApplicationProxy.BatchGetSyncJobStatus(ICollection`1 ucids, Uri endpointAddress)     
at Microsoft.Office.ConversionServices.Service.BatchGetStatusPollingThread.Run()     
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)     
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)     
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)     
at System.Threading.ThreadHelper.ThreadStart() StackTrace:  
at onetnative.dll: (sig=37460b31-4453-4365-92f5-3a11c267be48|2|onetnative.pdb, offset=28F56) at onetnative.dll: (offset=15735)   

现在，我不知道如何消除令牌问题，以便系统能够创建必要的通道来轮询转换作业状态。任何帮助都是非常感谢的。谢谢!

(我不能发布完整的日志，因为它注册为垃圾邮件)

Answer 1

我发现，如果要在域控制器上安装SharePoint 2013 (微软表示该拓扑只对开发有好处，但对生产没有好处)，那么IIS中默认的匿名用户(IUSR)将无法可靠工作，任何通过具有匿名访问权限配置为使用IUSR帐户的IIS站点访问的WCF解决方案在尝试访问安全令牌服务时都会失败。

在这种情况下，最方便的解决方案是重新配置IIS以使用另一个匿名标识，即绑定到Application的标识。

例如，如果您的站点名为NameOfSite，则可以在提升的PowerShell中运行：

Set-WebConfigurationProperty `
  -Filter /system.WebServer/security/authentication/AnonymousAuthentication `
  -Name username `
  -Value "" `
  -location "NameOfSite"

这解决了眼前的问题，即SecurityTokenForServiceContext失败。但是，如果您已经将SharePoint 2013作为域控制器安装在Windows2012 R2上，那么它还没有结束：WordServerWorker实际上不会在此配置中启动。

不过，我也可以确认，如果您将SharePoint 2013安装在一个独立的服务器上(在无人值守的配置文件中有<Setting Id="SERVERROLE" Value="SINGLESERVER"/>角色)，那么整个解决方案就可以端到端地工作，WordServerWorker实际上会正常启动。

在此之前，最相关的(和未回答的)问题必须是这个MSDN公告，“无法完成安全令牌请求”。我假设在这种情况下，服务只处于元稳定状态，其中一个IIS工作人员将在本地测试期间通过NTLM获得凭据。

Answer 2

通常，当sharepoint服务应用程序相互交互时，这些服务通过使用服务应用框架 (SAF)调用wcf来维护当前的用户上下文。它允许这些服务使用SPContext.Current，保留调用日志之间的关联id，等等。当此上下文丢失时，服务将停止相互通信。例如，如果我们有一个启动新线程但没有为新创建的线程上下文设置用户的代码，就会发生这种情况。

根据您的描述，您的服务是匿名的，没有使用SAF来维护用户上下文，而是使用一些需要存在该上下文的服务。

可能的解决方案是使用SAF(简单地说是复杂的配置WCF )，而不是没有身份验证的普通WCF服务。

编辑：

另一种可能的解决方案可能是用RunWithElevatedPrivileges包装代码，使服务将sharepoint与应用程序池标识连接起来。