最近完成了一例将整个ws2k3环境迁移至ws2k12r2环境的项目,也算是见识到大跨度升级的艰辛,一些感想和收获,赶紧写下来。
起因是客户用ocs2007,开发那边要求远程桌面协助异地用户调试产品,遂推销Lync2013,领导看了演示,大喜,遂批了。
于是牵一发动全身,Lync2013吧,装在12r2上咧,12r2加域了,干脆把03的dc也升上来咧,DHCP也迁到12上呗,还能Failover,证书、WSUS、NAP和DC一块的,也跟着走吧~
对了,exchange还是2007的,领导说,用着没什么不妥,暂时就不升了。
我同事:呵呵,明年03就停止支持了,看你升不升。
于是4台DC以及DHCP,CA,WSUS,NAP从03直接跳到12r2,这项目就这么干了。
DC:
12r2还是为迁移提供了很大便利的,提升域功能级别到ws2003,12r2在成为域控时就自动会adprep和forestprep,当然包括gpoprep。这点很方便,不用再插光盘敲命令了。
加域,升级成域控完了之后,进站点查查复制链接,发现连自己最近的DC都没发现,而是发现了远端机房的一台DC,不管了,直接手动建连接。等个10分钟,再手动复制一下,OK成功。
DHCP:
和迁移至08r2没什么区别,5个类改6个类,导出导入,完毕。正式切换的时候在cisco上配置一下,划进vlan里头。
再开个FailOver,新特性不用白不用,开热备模式。
配置FailOver的时候一定几率会报错,向友邻建区域失败,那么就把修改好的DHCP配置在两台DHCP上都导入一下,然后删掉其中一台上面已经导入了的区域,再从另一台配置FailOver邀请,(不勾选密钥)90%几率成功。
***DHCP的时候记得先解除授权,不然会有残留(站点和服务-打开服务节点-NetworkServices里头能卡到残留的DHCP服务器名)
所以…DHCP服务器在改名之前先不要起DHCP,改完了名字再建DHCP
DHCP数据库位置: C:\WINDOWS\SYSTEM32\DHCP
WSUS:
推倒重来,2003导出的是txt格式,而2012的配置导入要求XML格式,两边格式不兼容。
第一次建的时候还因为补丁存放目录名带了个符号,结果报错。于是尝试用wsusutil修改,修改成功,但是依然无法启动。
再推倒,发现服务账户出了问题,后来修改了服务账户,才OK。
WID数据库相关:
http://blog.csdn.net/hadstj/article/details/10157749
NAP:
推倒重来,顺便再加了一台,做个热备。
2003的NAP服务叫InternetAuthenticationService,12r2的NAP服务叫 NetworkPolicyServer。
配置完了之后检查一下端口有没有打开,如果没有就重启一下服务
netstat -an | findstr "1812"
netstat -an | findstr "1645"
服务启动之后在事件查看器的自定义视图里有网络策略和访问服务。
出现事件18的话就重新配一下无线设备与NAP服务器上的密钥,再确保加密连接和验证方式一致。
对端设备是CiscoWirelessController,
CA:
重头戏就是CA,做之前各种看文档,各种测试,动真格的还是会想,会不会客户内部有自己的应用申请了证书啥的。
而且主要这玩意儿没有回退操作的……
只能跟着文档一步步来了,回头有空写篇心得记录一下。在测试环境上做个几遍熟悉了就好。
尤其要注意的是CRL分发点与AIA位置,在企业PKI里头可以刷新以验证各位置的对错。
迁移好了之后执行一下certutil -crl 更新所有分发点和增量分发点的位置。
参考文档:
上面一篇是中文的03-08r2
下面一篇是英文的包括了12r2
http://technet.microsoft.com/zh-cn/library/ee126140(v=ws.10).aspx
http://technet.microsoft.com/zh-cn/library/65bf928e-ea43-4849-94b4-79ea2e5b6a48
最后依次down掉以前的DC,把新DC改名改IP移回去(12r2可以直接改,不要怕,改完了静候DNS更新,手动更新NS服务器列表,如果有残留的srv就手动干掉,没刷出来新的SRV也不要手动新建)。
ps:更名重启的过程中有一台老的03DC因为机器不行,估计卡住了,时至夜深…机房关门了…抱着试一试的心态敲了个
shutdown /r /f /t 0 /m \\X.X.X.X 试图远程关机。
没想到真管用了…
PS2:后来一台域控改名过于随意,导致msDs-additionalsamAccountName被占用(手动在ADUC里建计算机账户提示windows2000以前版本的计算机名被占用)…而且ADSI里还不能手动改,后来想了一下好像使用netdom computername DC04 /add:DC05 这样的形式加上去的
(正确的应是打FQDN netdom computername DC04.xxx.com /add:DC05.xxx.com)
于是用netdom computername DC04 /remove:DC05$ 执行了一下,返回结果有报错,但是ADSI里显示是多余的additionalsamAccountName已经被干掉了。ADSI让windowsAD变得和Linux服务一样透明。
PS3:WSUS在改名过程中又重新装了一次,试图像DHCP那样***的彻底点,结果就把c:\windows\WID下边儿的文件都***掉了,后来再增加角色和功能的时候报错,日志显示是wid\bin目录下的可执行文件找不到了,也就是说,微软在wsus的处理上不够完善,移除wsus角色但并不移除增加(第一次)角色时上的wid数据库可执行文件和原始数据库(在data)里面,而且不移除wsus注册的服务,***掉WID文件夹之后,相关的服务都显示描述错误无法读取;于是弄了一台虚拟机,起了个wsus,然后将那上面WID里的内容全复制过来,再起一次WSUS,才回复正常。
PS4:想起来再加……
转载于:https://blog.51cto.com/sodaxu/1418885