我已经安装了2个节点的NLB集群，并使用以下命令在它们之间共享IISconfiguration。
http://blogs.technet.com/b/meamcs/archive/2012/05/30/configuring-iis-7-5-shared-configuration.aspx
IISconfiguration和内容通过UNCpath位于networking共享上。 这可以工作 – 更新一个节点上的IIS设置，在另一个节点中可见，而且我的网站在单个节点和整个群集上工作。
我能够设置一个FTP站点，并成功连接到我的Windowslogin。 但是，我想要使用如下定义的IISpipe理器身份validation：
http://www.iis.net/learn/publish/using-the-ftp-service/configure-ftp-with-iis-manager-authentication-in-iis-7
我已经尝试使用“networking服务”与FTP COM对象以及所有三个主机上存在的专用用户帐户，但每次我尝试login与IIS用户时，我得到如下所示：
IISWMSVC_AUTHENTICATION_UNABLE_TO_READ_CONFIG
检索authentication信息时发生意外错误。
exception：System.Runtime.InteropServices.COMException（0x8007052E）：文件名：错误：
Microsoft.Web.AdminManager.GetAdminSection（String bstrSectionName，String bstrSectionPath）在Microsoft.Web.Administration.Configuration.GetSectionInternal（ConfigurationSection部分，String sectionPath，stringlocationPath）在Microsoft.Web.Management.Server.ConfigurationAuthenticationProvider。 GetSection（ServerManager服务器pipe理器）
进程：dllhost用户= NT AUTHORITY \ NETWORK SERVICE
任何人都可以在这里指出正确的方向吗？
过去一周，我们一直在和这个问题进行斗争，并find了解决办法。
当IIS处于共享configuration模式（它可以在本地configuration下正常工作）时，自定义IISManager身份validation提供程序似乎有一些额外的（未logging的）权限需求。
事件日志：应用程序
types：错误
来源：Microsoft-Windows-IIS-IISManager
类别：
事件：1106
信息：
IISWMSVC_AUTHENTICATION_UNABLE_TO_READ_CONFIG
检索validation信息时发生意外错误。
exception：System.Runtime.InteropServices.COMException（0x8007052E）：文件名：错误：
Microsoft.Web.AdminManager.GetAdminSection（String bstrSectionName，String bstrSectionPath）在Microsoft.Web.Administration.Configuration.GetSectionInternal（ConfigurationSection部分，String sectionPath，stringlocationPath）在Microsoft.Web.Management.Server.ConfigurationAuthenticationProvider。 GetSection（ServerManager服务器pipe理器）
进程：dllhost进程：dllhost用户= NT AUTHORITY \ NETWORK SERVICE
我可以确认， 即使我们在所有地方都应用了“networking服务”权限 （例如，已经提到的以下命令）， 我们仍会收到这样的结果 ：
ICACLS "%SystemDrive%\Windows\System32\inetsrv\config" /Grant "Network Service":R /T ICACLS "%SystemDrive%\Windows\System32\inetsrv\config\administration.config" /Grant "Network Service":R ICACLS "%SystemDrive%\Windows\System32\inetsrv\config\redirection.config" /Grant "Network Service":R 除上述文件夹外，我们还将“networking服务”帐户[完全权限]添加到：
以上都不影响这个问题。
问题是这个错误信息与正常的错误信息不同，因为在这种情况下，“文件名：”和“错误：”的详细信息都是空白的 （如果权限丢失，通常会列出xxx.config文件名）。 所以这是别的…
我们也运行了进程监视器，并且在那里也看不到任何拒绝访问的消息。 我认为这可能是从IIS用户pipe理进程首次启动并尝试（并失败）读取configuration时的caching错误。 我们已经发现了一些奇怪的caching行为，当我们find方法使其工作（ 见下文 ）。
当我们将FTP可扩展性进程标识更改为“{域} \pipe理员” ，并重新启动机器后，突破就出现了 ！
注意：IISReset不起作用 – 这就是我相信这里有一些东西（弹性地）被caching的原因。
作为进一步的testing，我们：
然后我们再次得到相同的错误消息（用空白的用户名/错误）。
最后，当我们将新的“FTPService”用户作为“Domain Admins”的成员，并重新启动 （再次，一些caching防止立即修复） 它的工作。
我们也在Windows 2008 / IIS7（使用FTP7.5插件），Windows 2008 R2 / IIS 7.5，Windows 2012 / IIS8和Windows 2012 R2 / IIS8.5中尝试过这种方法，每个问题（和解决scheme）都是相同的。
因此，似乎有一些错误或“未经证实”的权限，使得这项工作与自FTP 7.5出现以来一直存在的共享configuration和networking服务帐户（不提供FTP可扩展性过程pipe理权限）一起工作。
虽然这是一个解决方法，但find使用networking服务或非域pipe理用户帐户进行此项工作所需的额外权限将是一件好事。