架构主机用来定义所有域对象属性,架构主机的所有者是负责对林架构进行更新和修改的域控制器,在林中只能有一个架构主机角色。
默认的架构主机角色所有者是林中第一台域控制器。架构主机只有你需要对架构进行更改时才会用到,这些一般都是事先计划好的,因此,架构主机允许短时间的脱机,如果你的架构主机角色所有的者的域控制器出现故障,你可以等待修复后重新联机。
说起爱呢,是因为在中国现况下Windows 网络还是组网的首选,简单便捷,易于上手,维护简单,而且稳定。Windows Server系列操作系统的图形化界面也使得入门门槛极低,无论有没有正经学过计算机都能上手搞两下。而说到恨,则是恨到骨子里。服务器往往承载了很多服务,一旦出现问题,信息管理ITer们可就有得忙了。光靠看微软文档很多时候是不能解决问题的。中文版文档晦涩难懂,英文文档更是难明其意。没办法上网一通搜,难得有一两个靠点边的,跟实际情况又总有差异,难以套用。即使是MCSE,实际上也是没什么卵用的。狠狠心咬牙重装吧,估计老板的脸色也不会好看,毕竟老板请你来就是要快速解决问题的啊!影响了业务,可担不起这个责任,只能顶着心理压力,硬着头皮排查,收集资料,各种试错,一不小心全盘崩坏。
域控复制失败,这个问题其实困扰了很多人。
先说一下案例背景吧。公司的网络采用的是Windows的活动目录,有一台Windows Server 2008 R2服务器作为域控,代号DC1。
因为网络规模不大,所以这台域控承担了GC、DC、DNS、DHCP、文件服务等多种角色。用了很多年也没出问题。
具体原因也就不详说了,把一台NAS做成了域控加到域里作为DC的复制伙伴。
后来因为服务器的性能问题,决定把域控、DNS、DHCP迁移到一台新的Windows Server 2012 R2服务器上,代号DC2。
进入正题,这篇文章主要讲域控复制失败的问题处理,DC1-->DC2的迁移过程不作重点描述。
先在DC1上检查了FSMO状态,正常。
DC2的安装过程一切顺利。配置IP地址,服务器名,添加角色,准备升级为域控。前面这部分所有IT都懂,如果有不懂,可以在公众号留言(请关注公众号miwencola)。
在服务器管理器中的“任务”启动“将此服务器提升为域控制器”。按步骤走流程。
到了先决条件检查这一步时出错。红色提示非常刺眼,它是这样说的:
架构主机上一次重新启动后未完成复制周期。架构可以被扩展之前,架构主机必须完成至Adprep无法扩展架构。
[状态/结果]
架构主机上一次重新启动后未完成复制周期。架构可以被扩展之前,架构主机必须完成至少
一次复制周期。
[用户操作]
验证架构主机是否连接到网络并可以与其他域控制器通信。请使用站点和服务管理单元在架构操作主机和至少一个复制伙伴之间复制。复制成功后,请重新运行 adprep。
后面自然无法继续。
本地网络的结构不复杂,一想便知是当时NAS充当了一回域控导致的问题。
回到DC1上,用命令检查了目录服务器
问题果然出跟NAS有关,而且是活动目录复制错误。
赶紧打开NAS配置界面,查看NAS的网络配置,退出网络认证,改成本地模式,问题依旧。
这个情况说明了虽然清除了NAS的网络认证,但活动目录中与DC1的复制伙伴关系依然存在。
那可能就要到DC1上去找找原因了。
在服务器管理器中,打开DNS服务器,清除NAS的相关信息。正向查找,反向查找,逐一排查,全部清除干净。
重启DC1,NAS,回到DC1,再次dcdiag,问题依旧。
在DC2上尝试了一下提升到域控,先决条件仍不能通过。
问题还是出在DC1上,回到服务器管理器。
与活动目录相关的服务主要还是集中在Active Directory域服务下,于是从此处入手。
Active Directory域服务下主要有两项服务:
Active Directory用户和计算机
Active Directory站点和服务
先在Active Directory用户和计算机中清除NAS所有相关记录。再次尝试无果。
来到 Active Directory站点和服务 – Site ,下有一项Default-First-Site-Name,点开Servers,里面出现两个服务器——NAS和DC1,下面分别有一项NTDS Settings。
直觉感到离答案很近了。来到DC下的NTDS Settings,属性打开,里面有一个连接页面。点开一看,立刻发现了问题:
在DC1上,有从NAS复制到DC1配置。
再打开NAS的NTDS Settings检查,发现正好有相反的配置。
这就是为什么在域中删除了NAS,域控依然要与它相互复制的原因。
但是却不敢直接贸然删除Servers下的NAS。因为DC1里有与NAS配置的连接,万一删除了NAS,而DC1这边不更新那数据库就更乱了,到时候到哪改去?
我是这样操作的:先删除NAS下的NTDS Settings,再删除NAS。
再回到DC1的NTDS Settings查看属性,连接里面已经空了。
重新dcdiag /a,全部通过。
来到DC2,重试先决条件测试,一次性通过。
虽然不知道问题的解决是不是跟删除了DNS中的NAS信息有关,但肯定是和Active Directory域服务有关。
处理问题的时候,也在网上搜索了很多答案,基本都不靠谱,也看到有人有相同的问题,却基本没有解决的,帖子中充满无奈的请求。于是把这次解决的过程分享出来,希望能帮助到一些有相同际遇的IT们。
但实际上并非如此,某些AD功能不允许在多台DC上完成,否则可能会造成AD数据库一致性错误,这些特殊的功能称为“灵活单一主机操作”,常用FSMO来表示,拥有这些特殊功能执行能力的主机被称为FSMO角色主机。在Win2003 AD域中,FSMO有五种角色,分成两大类:森林级别(在整个林中只能有一台DC拥有访问主机角色) 1:架构主机 (Schema Master)2:域命令主机 (Domain Naming Master)域级别(在域中只有一台DC拥有该角色3:PDC模拟器(PDC Emulator)4:RID主机 (RID Master)5:基础架构主机 (Infrastructure Master)1:架构主机控制活动目录整个林中所有对象和属性的定义,具有架构主机角色的DC是可以更新目录架构的唯一 DC。这些架构更新会从架构主机复制到目录林中的所有其它域控制器中。 架构主机是基于目录林的,整个目录林中只有一个架构主机。2:域命令主机向目录林中添加新域。从目录林中删除现有的域。添加或删除描述外部目录的交叉引用对象.3:PDC模拟器向后兼容低级客户端和服务器,担任NT系统中PDC角色时间同步服务源,作为本域权威时间服务器,为本域中其它DC以及客户机提供时间同步服务,林中根域的PDC模拟器又为其它域PDC模拟器提供时间同步!密码最终验证服务器,当一用户在本地DC登录,而本地DC验证本地用户输入密码无效时,本地DC会查询PDC模拟器,询问密码是否正确。首选的组策略存放位置,组策略对象(GPO)由两部分构成:GPT和GPC,其中GPC存放在AD数据库中,GPT默认存放PDC模拟器在\\windows\sysvol\sysvol\目录下,然后通过DFS复制到本域其它DC中。name域主机浏览器,提供通过网上邻居查看域环境中所有主机的功能4:主机角色:RID主机Win2003环境中,所有的安全主体都有SID,SID由域SID+序列号组合而成,后者称为“相对ID”(Relative ID,RID),在Win2003环境中,由于任何DC都可以创建安全主体,为保证整个域中每个DC所创建的安全主体对应的SID在整个域范围唯一性,设立该主机角色,负责向其它DC分配RID池(默认一次性分配500个),所有非RID主机在创建安全实体时,都从分配给的RID池中分配RID,以保证SID不会发生冲突! 当非RID主机中分配的RID池使用到80%时,会继续RID主机,申请分配下一个RID地址池!5:基础架构主机基础结构主机的作用是负责对跨域对象引用进行更新,以确保所有域间操作对象的一致性。基础架构主机工作机制是定期会对没有保存在本机的引用对象信息,而对于GC来说,会保存当前林中所有对象信息。如果基础架构主机与GC在同一台机,基础架构主机就不会更新到任何对象。所以在多域情况下,强烈建议不要将基础架构主机设为GC。二:标准图形界面查看和更改操作主机角色的方法1:查看和更改架构主机角色:步骤:注册:regsvr32 schmmgmt 在MMC中添加AD架构管理单元打开MMC控制台,选中“Active Directory架构”击“右键”,选择“操作主机”打开更改架构页面后,点击"更改"就可以进行架构主机角色的更改2.查看和更改PDC模拟器,RID主机以及基础结构主机步骤:开始-设置-控制面板-管理工具-Active Directory用户和计算机 选定当前域名,右键单击,选择“操作主机”在打开的页面中,通过点击“更改”按钮就可以对RID主机,PDC模拟器以及基础结构主机角色进行更改3.查看和更改域命名主机角色步骤:点击“开始-设置-控制面板-管理工具-Active Directory域和信任关系”: 选中“Active Directory域和信任关系”,右键单击,选择“操作主机”在打开的窗口中,点击“更改”按钮就可以实现对域命名主机角色进行更改四:使用命令行工具查看和更改操作主机角色有多个工具可以实现在命令行下查看操作主机角色,下面只列出几种常见方法注意,下面对应的工具有些需要安装Win2003 Support Tools工具1:使用Netdom工具查看操作主机角色Netdom Query FSMO3.利用自制监视器Replmon查看和检查操作主机角色复制监视器Replication Monitor(ReplMon)是针对Windows Server的故障查找工具,不但是定位活动目录复制故障强有利的工具,同时也可以使用该工具查看和检查操作主机角色状态。步骤:选中当前DC,右键单击,选择“Properties”在弹出窗口中,选择“FSMO Roles”分窗口,出现如下界面:在该窗口,列出所有的FSMO操作主机,同时通过“Query”按钮,可以检测出当前DC 与FSMO操作主机之间通讯是否正常。四:使用命令行工具查看和更改操作主机角色有多个工具可以实现在命令行下查看操作主机角色,下面只列出几种常见方法注意,下面对应的工具有些需要安装Win2003 Support Tools工具1:使用Netdom工具查看操作主机角色 Netdom Query FSMO2:使用Dsquery工具查看操作主机角色Dsquery Server –Hasfsmo Schema //查看架构主机Dsquery Server –Hasfsmo Name //查看域 主机Dsquery Server –Hasfsmo PDC //查看PDC模拟器主机Dsquery Server –Hasfsmo RID //查看RID主机Dsquery Server –Hasfsmo Infr //查看基础结构主机3:使用Ntdsutil工具更改操作主机角色Ntdsutil工具的功能非常强大,可以进行AD数据库维护,查看和更换操作主机角色以及删除无法通过图形界面删除的DC遗留的元数据。通过Ntdsutil工具不但可以清理无效的DC信息,也可以使用Transfer子命令转移操作主机角色,使用Seize子命令夺取操作主机角色。五:操作主机角色放置优化配置建议默认情况下,架构主机和域命名主机角色是在根域的第一台DC上,而PDC模拟器,RID主机和基础结构主机默认放置在当前域的第一台DC上。特别是在单域环境中,按默认安装,第一台DC会同时拥有这五种FSMO操作主机角色。万一这台DC损坏,会对域环境造成极大风险!常见的操作主机角色放置建议如下:1:架构主机:拥有架构主机角色的DC不需要高性能,因为在实际环境中不会经常对Schema进行操作的,除非是经常会对Schema进行扩展,不过这种情况非常的少。但要保证可用性,否则在安装Exchange等会扩展AD架构的软件时会出错。2:域命名主机:对占有域命名主机的DC也不需要高性能,在实际环境中也不会经常在森林里添加或者删除域的。但要保证高可用性是有必要的,以保证在添加删除当前林中域时可以使用。一般建议由同一台DC承担架构主机与域域命名主机角色,并由GC放置在同一台DC中。3:PDC模拟器:从上述PDC功能中可以看出,PDC模拟器是FSMO五种角色里任务最重的,必须保持拥有PDC的DC有高性能和高可用性。4:RID主机:对于占有RID Master的域控制器,没有必要一定要求高性能,因为给其它DC分配RID池的操作不是经常性发生,但要求高可用性,否则在添加用户时出错。5:基础架构主机:对于单域环境,基础架构主机实际上不起作用,因为基础架构主机主要作用是对跨域对象引用进行更新,对于单域,不存在跨域对象的更新。基础架构主机对性能和可用性方面的要求较低。欢迎分享,转载请注明来源:夏雨云
评论列表(0条)