原因是在域环境下，域用户登录从远程桌面登录，是需要从域控制器的SYSVOL共享目录中获取一些数据，Server服务禁用导致了共享文件服务失效，于是登录就出现了问题。
首先要想办法进入域控制器桌面，根据Windows的特性，在无法连通网络的情况下，如果使用物理终端（就是走到服务器面前，接上鼠标键盘显示器，你说你有KVM！Lucky！不用去机房了）直接登录，Windows默认是可以使用缓存的之前成功登陆的N个帐号中的某个成功登陆的；这个特性可以在组策略中调整次数，默认为10个。
使用这个方法，虽然是一个比较缓慢的登录过程，但是还是成功进入了域控制器的桌面，但此时无法使用组策略工具连接域进行配置，同样提示域可能不存在。
组策略最终也是放置在SYSVOL共享目录下的，实际是文本文件可以编译，考虑到如此，可以手工修改，删除禁用Server服务的策略，路径为%systemroot%/sysvol/sysvol/域名/Policies/策略的GUID/MACHINE/Microsoft/Windows NT/SecEdit/GptTmpl.inf
策略的GUID：
默认域的策略的GUID为31B2F340-016D-11D2-945F-00C04FB984F9
默认域控制器的策略的GUID为6AC1786C-016F-11D2-945F-00C04FB984F9
这里我们由于是错误设置了域策略，所以修改GUID为31B2F340-016D-11D2-945F-00C04FB984F9目录下的GptTmpl.inf。使用记事本打开，发现有[Service General Setting]中有一行"lanmanserver",4,""，将这行删除，保存文件。
为了使修改后的组策略生效，还需要修改组策略的版本号，路径为%systemroot%/sysvol/sysvol/域名/Policies/策略的GUID/GPT.ini，将版本号数字增加100（看你喜好）。
先重启登录修改的域控制器，再重启其他域控制器，故障消失。
一组双节点的Windows 2003群集，配合IBM DS4300磁盘阵列，安装了SQL Server 2000，A机安装完最新的安全补丁之后，将此节点上的SQL Server 2000服务切换到B机，重启A机之后发现Cluster Service无法启动，使用事件查看器检查系统日志，发现有以下错误记录：
Event Type: Warning
Event Source: ql2300
Event Category: None
Event ID: 118
Date: 2008-6-11
Time: 20:10:42
User: N/A
Computer: IAMS-DB2-1
Description:
The driver for device \Device\Scsi\ql23001 performed a bus reset upon request.
Event Type: Error
Event Source: ClusSvc
Event Category: Startup/Shutdown
Event ID: 1009
Date: 2008-6-11
Time: 20:11:19
User: N/A
Computer: IAMS-DB2-1
Description:
Cluster service could not join an existing server cluster and could not form a new server cluster. Cluster service has terminated.
Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7031
Date: 2008-6-11
Time: 20:11:20
User: N/A
Computer: IAMS-DB2-1
Description:
The Cluster Service service terminated unexpectedly. It has done this 3 time(s). The following corrective action will be taken in 240000 milliseconds: Restart the service.
开始怀疑是磁盘阵列状态迁移记录问题，类似的问题原来遇到过（/bo-blog/read.php?549），本计划找机房的同事协助将两个节点和磁盘阵列都关闭，然后先开磁盘阵列，再开一个节点，正常后，最后再开另外一个节点。但这个准备作为最后一招，先看能不能远程解决。
先将节点A又重启，群集服务依然无法启动；在节点A中进入设备管理器，将RDAC Muti-Path Pseudo-Bus和两个QLogic QLA2340 PCI Fiber Channel Adapter禁用，重启节点A之后再启用这些设备，还是无效。
在正常启动的节点B上检查，突然发现在资源管理器中只看到SQL Server群集组下面的一个磁盘分区，本来是绑定了两个的。在磁盘管理中可以看到对应的几个分区，进入命令行，切换盘符到这个看不到的分区，提示驱动器没有准备好，在SQL Server企业管理器中尝试打开一些数据文件放在这个看不到分区的时候，企业管理器出现挂死状态，在群集管理器中看到SQL Server组自动脱机又重新联机，再查看之前有问题的那个分区，竟然正常了。再重启节点A，群集服务正常启动，也正常加入了群集，各个应用组切换也正常，问题消失。
最后检查之前出现问题的磁盘，发现里面有两个补丁安装文件的临时目录，考虑到补丁安装需要重启，且这些目录没有被正常清除掉，所以判断引起故障的原因是安装的补丁占用了SQL Server一个分区作为临时文件存放，安装之后某些文件挂起，需要重启之后才能被清理，但是这时又将节点A上的应用切换到了B上，导致这个磁盘未能被节点B正常获取（或者是某些资源状态），进而在节点A启动的时候，群集也在尝试抓取这个分区，导致出现“The driver for device \Device\Scsi\ql23001 performed a bus reset upon request.”错误，群集服务也就无法正常启动。
最后总结就一句话：群集上安装补丁，先将此节点上的全部应用组全部转移走后，再进行补丁安装！
PS. 如果采用之前准备的最后一招，我想应该也是可以解决这个问题的。
一直很忙，今天下午得空来看了看，发现系统日志有以下错误：
事件类型: 错误
事件来源: NetBT
事件种类: 无
事件 ID: 4311
描述:
由于驱动程序设备无法创建，初始化操作失败。
发现ipconfig /all看到的Node Type是Unkonwn，而不是一般的Hybrid
怀疑是之前卸载了Norton或者其他什么东西出的问题，最后焦点集中到注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters，发现TransportBindName的值是空字符串，找了另一台正常的机器对比，填写上“\Device\”（不包含引号），重启后访问正常。
根据M$知识库http://support.microsoft.com/?kbid=177078的指引，创建键值HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\IRPstackSize，类型为DWORD，取值设置为0x32，重启之后问题解决。