前段时间在给客户做一个SQL Server 2005新旧服务器之间迁移的动作，原环境是群集，新环境新服务器也必须是群集，并且影响最小，最后综合考虑采用添加新服务器到原群集节点，然后卸载旧服务器，在此过程中，出现了许多问题，最后顺便做了一个总结，如下：

1.       确认在这三个节点上能够相互访问Task Scheduler。

2.       确认在这三个节点上以下的服务都是开启的。

a.       Cryptographic Service

b.      Remote Registry

c.       Task Scheduler

3.       给下面的注册表文件夹下的Local Service和SQL Server安装账号赋予Full Control权限。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg\AllowedPaths

4.       确认下面的注册表键值为0.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\DisableDomainCreds

5.       在Group Policy下，保证SQL Server的安装账号被赋予以下权限。

-          Act as part of the operating system

-          Allow log on locally

-          Bypass traverse checking

-          Log on as a batch job

-          Log on as a service

6.       在Group Policy下的Security Policy中，确认Network access: Do not allow storage of credentials or .NET Passports for network authentication的状态为Disabled。

7.       将SQL Server群集迁移到节点03上，并将节点02和07的远程访问全部Log off。

8.       在节点03上开始SQL Server节点添加的安装。

9.       在输入SQL Server服务账号的地方，“无法识别SQL Server服务账号”的问题得到重现。

10.   发现SQL Server Agent和Browser的服务账号及密码并没有输入。在输入了全部三个服务账号的密码后，问题得以解决。

11.   安装继续，但是仍报安装失败。（出现此问题的真正原因是sql Server 2005上面的趋势防病毒软件后台扫描引起的）

12.   在检查了SQL Server安装日志和07节点上的Task Scheduler日志后，我们发现安装程序在07节点上建立安装任务后，并没有执行成功，而且返回了访问被拒绝的错误。

13.   我们将SQL Server群集切换到节点02上后，重试安装程序，不过得到了相同的结果。

14.   而后，我们在三个节点上检查了Task Scheduler的权限设置，发现完全一样。

15.   在节点02上，我们共享了文件夹C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\Bin。

16.   从节点02上Log off，然后用mstsc /console的方法重新远程连接到节点02。

17.   在重试添加节点后，发现添加节点成功。

18.   而后，我们确认了当前SQL Server的版本为9.00.5057。该版本是SP4加MS11-049安全补丁。

19.   将SP4和安全补丁的安装包下载后，我们将SQL Server的群集切换到新加节点07上，一次安装了SP4和MS11-049安全补丁。

20.   成功后，我们多了切换测试，正常通过。我们也检查了SQL Server在节点07上的版本，与其他两个节点完全一致。

21.   至此，添加节点的工作全部完成。