笔者同事所用机器的IIS最近出了问题，访问本地asp文件时用“//localhost”或“//计算机名”可以正常访问，但如果用“//127.0.0.1”访问，就会弹出一个对话框要求输入密码。
因为只是用IP地址不能正常进行访问，所以感觉不会是大问题，根据以往的经验，首先查看用户组中的“IUSR_计算机名”、“IWAM_计算机名”两个账号是否被禁用了，结果发现状态正常。
接下来怀疑是IIS默认网站属性中“匿名访问和身份验证控制”（在“目录安全性”选项卡中）一项被不小心禁用了，打开相应对话框后发现并未禁用。难道是匿名访问账号（IUSR_计算机名）的密码与用户组中的密码不同步了？手工进行同步设置后，发现问题依旧。 IIS出现类似问题的原因不外乎这几种啊，还能是什么原因呢？没有办法，干脆重装IIS！几分钟后，IIS安装完毕，但一试却发现，刚才还只是用IP地址不能访问，结果现在用计算机名也不能访问了，总是提示DCOM+错误。查看系统日志，显示为“DCOM遇到错误。登录失败: 未知的用户名或错误密码”。 为了避免重新安装系统，笔者决定查找并修复这个DCOM错误。进入控制面板的“组件服务”中，发现“DCOM配置”上有红箭头标志，不能正常打开，看来问题就出在这儿。但是怎么处理呢？在经过多次无效的尝试后，笔者终于找到了解决的办法：查看系统的本地服务，发现DCOM正常；然后查看其依存关系，发现依存于“Remote Procedure Call (RPC)”服务；进一步查看RPC的状态，发现状态正常；再看RPC的依存关系，现在与其相关的“Distributed Transaction Coordinator”服务是禁止的，其描述为“协调跨多个数据库、消息队列、文件系统等资源管理器的事务”。将其开启后，发现IIS马上就可以用多种方式进行访问了。 事后得知，原来同事曾经在网上看到一篇关闭Windows不常用服务的文章，于是就把系统中的一些服务关闭了，其中就包括“Distributed Transaction Coordinator”服务。今后大家如果想关闭不常用服务以优化系统时，可千万要小心，拿不准的还是不要关为好。 小编提示：DCOM 是Microsoft的分布式COM技术，扩展了组件对象模型（COM）技术，使其能够支持在局域网、广域网甚至Internet上不同计算机对象之间的通讯。 RPC是“远程协助”（Remote Procesdure Call）的英文简称，是微软在Windows XP系统中新增的功能，允许远程用户对本地PC进行控制，帮助本地用户解决问题。去年大名鼎鼎的冲击波病毒就是利用Windows XP的RPC漏洞进行攻击的。
