前段时间在给客户做一个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. 至此，添加节点的工作全部完成。