我有一个Windows服务，承载主要的WCF服务。此服务的客户端都在IIS 7中托管，第一个是IIS托管的WCF服务，第二个是标准的Asp.Net应用程序。这两个IIS托管的客户端都通过命名管道与Windows服务进行通信。Win2008中奇怪的通信错误
IIS托管的WCF服务可以完美地与Windows托管的WCF服务进行通信，但Asp.Net服务失败并出现此错误： 无法从管道URI获取管道名称：访问被拒绝。
我的第一反应是，这是一个权限问题的地方，但我不知道在哪里。其次，为什么IIS托管的WCF服务能够正常通信，但Asp.Net应用程序失败？
好的，我解决了，或者说我想出了许可问题。
事实证明，匿名身份验证设置使用了由我们的客户（物理人员，而不是我们的WCF客户端）创建的一些奇怪的用户，而不是NetworkService用户（应用程序池使用的身份）。
但是，这几乎产生了另一个问题：为什么甚至新创建的网站默认这个IUSR，而不是系统默认值？在任何情况下，我只希望这被谷歌索引，因为几乎没有任何文章与它有关。
检查WCF和ASP.NET服务驻留在应用程序池的身份。
也许WCF服务的应用程序池具有比其它的应用程序池不同权限的身份？
我以为同样的事情，但他们都使用相同的应用程序池。我甚至尝试将用户从NetworkService切换到LocalSystem，切换到LocalUser。没有运气。 – 2009-02-02 16:04:39
另外，您可能需要注意的是，IUSR是匿名访问者的默认IIS7帐户。有关默认帐户的说明，请参阅Understanding the Built-In User and Group Accounts in IIS 7.0。
希望这是有帮助的。
有一点需要补充：这个系统的父网站是一个头盔网站，我不太熟悉的一个应用程序。当我切换用户时，AppPool正在使用从NetworkService到LocalSystem，导致父网站web.config中出现错误，我认为我是走错了路。 – 2009-02-02 16:07:02