Windows Server 2003 AD应用程序目录分区深入了解 ----------------江小帅
江小帅的作品我很喜欢，大家可以读一下，很有名气！他目前在WINITPRO工作，之前有幸跟他本人通过电话！希望他会继续出更好的文章，这是文章是他N年前发的
不过还是不会过时！
Windows Server 2003 AD应用程序目录分区深入了解
作者：江小帅
微软的技术知识库实在是太庞大了，以至一些新的功能我们在彻底熟悉的时候会花费太多的时间，没办法，这是由于产品的复杂性决定的。面对OS或服务组件及AD我们应该经常问的是：默认为什么会出现这个？为什么要有这样的功能？这个功能如何实现？这个功能有什么限制？拿此文做例子，可能一些人认为不去了解活动目录的应用程序目录分区或DNS区域中随DC增加而带来的新记录的变化，网络环境也一样运行。呵呵！那就大可不必看了。
一、Windows Server 2003 AD应用程序目录分区
1) 什么是应用程序目录分区？
应用程序目录分区是仅复制到特定域控制器的目录分区。参与特定应用程序目录分区复制的域控制器寄存该分区的副本。只有运行 Windows Server 2003 的域控制器可以寄存应用程序目录分区的副本。应用程序目录分区可包含任何类型的对象（除了安全主体）。在Windows 2000的DC时代默认DC上会存留三个常规的目录分区：Schema目录分区，Configuration目录分区，Domain目录分区（如果是GC的话，那么还存在GC的目录）。Schema目录分区全森林复制，一般也很少对其做修改设置，除非当安装像Exchange这样的应用程序或需要添加雇员的ID和Number到AD的时候这个分区的内容才会需要更改。Configuration目录分区也是全森林复制的，对于域配置的变化，DC的增加减少，站点的变化等而随之变化。所以对于一个成熟的企业域环境，这个变化也会很少。Domain目录分区为全域复制的分区，这个分区微软当初定义的时候是用来容纳一些user、computer、OU、GPO等对象。基本上一个公司的这些对象在使用Domain目录分区存储的时候变化是客观的，用户或计算机、策略的变化必然要使维持这个目录分区的宿主DC之间同步。那为什么Windows 2003还要提供应用程序目录分区的功能呢？
2) 为什么Windows 2003 AD要支持应用程序目录分区？
AD的对象一般都是相对静态的，这样对提高DC的性能、提高KCC之间的平衡有很大的帮助。所以在“向AD中发布对象”的时候对于经常，频繁性变化的对象不适合使用AD这样的分布数据库来进行存储。在Windows 2000 DC时代，DNS的区域是可以集成到AD的，这是因为AD的数据库为了优化客户程序定位DC必须需要DNS来实现底层的定位，而将DNS的区域文件保存在AD的数据库里可以实现客户程序以任意形式来定位任意DC，那么DNS的区域保存在哪里？答案是保存在Domain目录分区里（图5指出了DNS区域文件如果存储在Domain目录分区时它的位置），它将在域的范围内复制，这就让一些不提供DNS服务但身份是DC的计算机干了“狗拿耗子”的事情（也有备份的考虑在内）。DNS的区域记录对于一些网络也是经常变化的，比如客户计算机名字频繁变化的环境，所有的同域DC都在跟着复制变化的DNS区域记录，不管你到底提不提供DNS服务（类比一下电影《大腕》里王小柱说的话：直播要覆盖到全球每个角落，允许你不看，但不允许说你收不到）。所以活动目录应用程序分区才在Windows 2003中出现了。
3) 目录应用程序的命名
提前理解这个有利于帮助我们理解2003AD默认的DNS应用程序目录分区。应用程序目录分区是整个林名称空间的一部分，就像域目录分区一样。它与域目录分区遵循相同的域名系统 (DNS) 和可分辨名称命名约定。应用程序目录分区可出现在林名称空间中可出现域目录分区的任何地方。在林名称空间中，应用程序目录分区可能出现在三处：域目录分区的子项、应用程序目录分区的子项、林中的新树。
二、Windows Server 2003 DNS应用程序目录分区（创建jzlld.org的AD环境，所有计算机全部为2003SP1的操作系统）
1) 默认的DNS应用程序分区
默认全新装Windows Server 2003 DC的时候AD会自动创建两个应用程序目录分区：ForestDnsZones目录分区、DomainDnsZones目录分区。这两个目录分区都可以存储DNS的区域记录。但复制的范围（复制作用域）是不一样的，一个是整个森林范围内的DC间复制，一个域范围内的DC间复制。
2) DNS区域的创建向导
DNS区域的创建向导会出现一个特殊的选项如图1，理解这些选项的区别将帮助我们理解区域的复制，更涉及到DC上KCC的运行性能。
一、Windows Server 2003 AD应用程序目录分区
1) 什么是应用程序目录分区？
应用程序目录分区是仅复制到特定域控制器的目录分区。参与特定应用程序目录分区复制的域控制器寄存该分区的副本。只有运行 Windows Server 2003 的域控制器可以寄存应用程序目录分区的副本。应用程序目录分区可包含任何类型的对象（除了安全主体）。在Windows 2000的DC时代默认DC上会存留三个常规的目录分区：Schema目录分区，Configuration目录分区，Domain目录分区（如果是GC的话，那么还存在GC的目录）。Schema目录分区全森林复制，一般也很少对其做修改设置，除非当安装像Exchange这样的应用程序或需要添加雇员的ID和Number到AD的时候这个分区的内容才会需要更改。Configuration目录分区也是全森林复制的，对于域配置的变化，DC的增加减少，站点的变化等而随之变化。所以对于一个成熟的企业域环境，这个变化也会很少。Domain目录分区为全域复制的分区，这个分区微软当初定义的时候是用来容纳一些user、computer、OU、GPO等对象。基本上一个公司的这些对象在使用Domain目录分区存储的时候变化是客观的，用户或计算机、策略的变化必然要使维持这个目录分区的宿主DC之间同步。那为什么Windows 2003还要提供应用程序目录分区的功能呢？
2) 为什么Windows 2003 AD要支持应用程序目录分区？
AD的对象一般都是相对静态的，这样对提高DC的性能、提高KCC之间的平衡有很大的帮助。所以在“向AD中发布对象”的时候对于经常，频繁性变化的对象不适合使用AD这样的分布数据库来进行存储。在Windows 2000 DC时代，DNS的区域是可以集成到AD的，这是因为AD的数据库为了优化客户程序定位DC必须需要DNS来实现底层的定位，而将DNS的区域文件保存在AD的数据库里可以实现客户程序以任意形式来定位任意DC，那么DNS的区域保存在哪里？答案是保存在Domain目录分区里（图5指出了DNS区域文件如果存储在Domain目录分区时它的位置），它将在域的范围内复制，这就让一些不提供DNS服务但身份是DC的计算机干了“狗拿耗子”的事情（也有备份的考虑在内）。DNS的区域记录对于一些网络也是经常变化的，比如客户计算机名字频繁变化的环境，所有的同域DC都在跟着复制变化的DNS区域记录，不管你到底提不提供DNS服务（类比一下电影《大腕》里王小柱说的话：直播要覆盖到全球每个角落，允许你不看，但不允许说你收不到）。所以活动目录应用程序分区才在Windows 2003中出现了。
3) 目录应用程序的命名
提前理解这个有利于帮助我们理解2003AD默认的DNS应用程序目录分区。应用程序目录分区是整个林名称空间的一部分，就像域目录分区一样。它与域目录分区遵循相同的域名系统 (DNS) 和可分辨名称命名约定。应用程序目录分区可出现在林名称空间中可出现域目录分区的任何地方。在林名称空间中，应用程序目录分区可能出现在三处：域目录分区的子项、应用程序目录分区的子项、林中的新树。
二、Windows Server 2003 DNS应用程序目录分区（创建jzlld.org的AD环境，所有计算机全部为2003SP1的操作系统）
1) 默认的DNS应用程序分区
默认全新装Windows Server 2003 DC的时候AD会自动创建两个应用程序目录分区：ForestDnsZones目录分区、DomainDnsZones目录分区。这两个目录分区都可以存储DNS的区域记录。但复制的范围（复制作用域）是不一样的，一个是整个森林范围内的DC间复制，一个域范围内的DC间复制。
2) DNS区域的创建向导
DNS区域的创建向导会出现一个特殊的选项如图1，理解这些选项的区别将帮助我们理解区域的复制，更涉及到DC上KCC的运行性能。
“至Active Directory林jzlld.org中的所有DNS服务器”---将创建的DNS区域存储在默认的ForestDnsZones.jzlld.org应用程序目录分区，所以将导致创建的DNS区域被复制到森林jzlld.org中所有运行2003DC并提供DNS服务的服务器上。
“至Active Directory域jzlld.org中的所有DNS服务器”---将创建的DNS区域存储在默认的DomainDnsZones.jzlld.org应用程序目录分区，所以将导致创建的DNS区域被复制到域jzlld.org中所有运行2003DC并提供DNS服务的服务器上。
“至Active Directory域jzlld.org中的所有域控制器”---将创建的DNS区域存储在Domain目录分区，所以将导致创建的DNS区域被复制到域jzlld.org中所有的域控制器上。因为2000不支持应用程序目录分区，所以当域中包含2000操作系统的DC时推荐选择此项。
“到在以下应用程序目录分区的范围内指定的所有域控制器”（默认灰色）---只有当使用应用程序目录分区创建命令创建一个新的应用程序目录分区的时候才可以使用，小帅在后面的部分中将创建一个应用程序目录分区之后，这个部分就可以选择了。
3) 建立森林jzlld.org中的第一台域控制器：dc01.jzlld.org
默认建立林中第一台DC的时候都会让Dcpromo向导自动安装DNS服务，安装过程小帅在这里忽略了。建立好的该DC之后，我们来仔仔细细看看DNS区域及DNS特殊记录。如图2
“至Active Directory域jzlld.org中的所有DNS服务器”---将创建的DNS区域存储在默认的DomainDnsZones.jzlld.org应用程序目录分区，所以将导致创建的DNS区域被复制到域jzlld.org中所有运行2003DC并提供DNS服务的服务器上。
“至Active Directory域jzlld.org中的所有域控制器”---将创建的DNS区域存储在Domain目录分区，所以将导致创建的DNS区域被复制到域jzlld.org中所有的域控制器上。因为2000不支持应用程序目录分区，所以当域中包含2000操作系统的DC时推荐选择此项。
“到在以下应用程序目录分区的范围内指定的所有域控制器”（默认灰色）---只有当使用应用程序目录分区创建命令创建一个新的应用程序目录分区的时候才可以使用，小帅在后面的部分中将创建一个应用程序目录分区之后，这个部分就可以选择了。
3) 建立森林jzlld.org中的第一台域控制器：dc01.jzlld.org
默认建立林中第一台DC的时候都会让Dcpromo向导自动安装DNS服务，安装过程小帅在这里忽略了。建立好的该DC之后，我们来仔仔细细看看DNS区域及DNS特殊记录。如图2
DNS区域：
默认Dcpromo创建了两个DNS区域：_msdcs.jzlld.org、jzlld.org，小帅自己手工创建了一个DNS反向搜索区域：10.0.0.x subnet，下面小帅一个个的说明这些区域。
DNS区域_msdcs.jzlld.org的“复制作用域”为“至Active Directory林jzlld.org中的所有DNS服务器”，所以该DNS区域实际上是存储在ForestDnsZones.jzlld.org这个默认创建的DNS应用程序分区中了。注意该区域是被默认委派的，因为在jzlld.org的区域里面有一个委派记录。图3是利用ADSI显示该应用程序分区的情况。
DNS区域_msdcs.jzlld.org的“复制作用域”为“至Active Directory林jzlld.org中的所有DNS服务器”，所以该DNS区域实际上是存储在ForestDnsZones.jzlld.org这个默认创建的DNS应用程序分区中了。注意该区域是被默认委派的，因为在jzlld.org的区域里面有一个委派记录。图3是利用ADSI显示该应用程序分区的情况。
提示：Dcpromo默认创建的名为_msdcs.jzlld.org的DNS区域是主持 Active Directory 林中所有域控制器的域控制器定位器 DNS 资源记录。它还可用于在 Active Directory 域或 Active Directory 林中定位具有特定角色的域控制器（PDC、GC），如果域已重命名，则可通过搜索域控制器的 GUID 来定位它（那个长长数字）。另外
http://support.microsoft.com/kb/817470/zh-cn
中详细说明了Windows 2000及Windows 2003在创建默认的DNS区域时的不同、升级到Windows 2003的DNS做配置全林性应用程序目录分区的修改、理解_msdcs区域在windows 2003域控制器中的任一的两中存储方式。另外注意在Windows Server 2003 SP1 中，当创建一个已位于现有区域下的新的正向查找区域时，向导会在该现有区域下自动创建一个新的委派。
DNS区域jzlld.org的复制作用域为“至Active Directory域jzlld.org中的所有DNS服务器”，所以该DNS区域实际上是存储在DomainDnsZones.jzlld.org这个默认创建的DNS应用程序分区中了。图4是利用ADSI显示该应用程序分区的情况。
DC=RootDNSServers容器中保存的是根提示
特殊的DNS记录：
回到图2上，在区域jzlld.org下有两个“域”：ForestDnsZones和DomainDnsZones。这两个位置是用来说明：在哪台DC宿主ForestDnsZones.jzlld.org应用程序目录分区（所以该记录的格式只有tcp.sitename._site.forestdnszones.jzlld.org.或tcp.forestdnszones.jzlld.org形式，别忘了该目录分区是林复制性的，所以没域什么事儿），哪台DC是宿主DomainDnsZones.jzlld.org应用程序目录分区的，此时的SRV记录都应该时dc01.jzlld.org，
图6是利用Replmon.exe显示的dc01.jzlld.org上的目录分区情况（由于是第一台DC，所以没有任何复制链接）
特殊的DNS记录：
回到图2上，在区域jzlld.org下有两个“域”：ForestDnsZones和DomainDnsZones。这两个位置是用来说明：在哪台DC宿主ForestDnsZones.jzlld.org应用程序目录分区（所以该记录的格式只有tcp.sitename._site.forestdnszones.jzlld.org.或tcp.forestdnszones.jzlld.org形式，别忘了该目录分区是林复制性的，所以没域什么事儿），哪台DC是宿主DomainDnsZones.jzlld.org应用程序目录分区的，此时的SRV记录都应该时dc01.jzlld.org，
图6是利用Replmon.exe显示的dc01.jzlld.org上的目录分区情况（由于是第一台DC，所以没有任何复制链接）
利用LDP.exe也显示了dc01.jzlld.org上存在5个NamingContexts（目录分区），如图7高亮显示的部分（注意他们的DN格式）
4) 建立域jzlld.org中的第二台域控制器：dc02.jzlld.org
在建立域jzlld.org的第二台域控制器的时候，默认都是将要成为dc02.jzlld.org的计算机的DNS服务器地址指向dc01.jzlld.org。Dcpromo向导不会有是否选择安装DNS服务的提示。安装步骤小帅这里省略。安装完dc02.jzlld.org重启后并没有安装DNS服务，所以dc02.jzlld.org上不应该宿主ForestDnsZones.jzlld.org和DomainDnsZones.jzlld.org这两个应用程序目录分区。图8是利用LDP.exe显示dc02.jzlld.org的名称上下文
在建立域jzlld.org的第二台域控制器的时候，默认都是将要成为dc02.jzlld.org的计算机的DNS服务器地址指向dc01.jzlld.org。Dcpromo向导不会有是否选择安装DNS服务的提示。安装步骤小帅这里省略。安装完dc02.jzlld.org重启后并没有安装DNS服务，所以dc02.jzlld.org上不应该宿主ForestDnsZones.jzlld.org和DomainDnsZones.jzlld.org这两个应用程序目录分区。图8是利用LDP.exe显示dc02.jzlld.org的名称上下文
下面的图9是利用Replmon.exe查看的复制情况（两台DC都属于一个站点，形成的是站点内部的复制）
大家也可以在c:\windows\debug\下找到Dcpromo.txt。该文件内详细说明了，当dc02被提升为DC的时候从dc01上复制了哪些目录分区。（只有3个）
在DNS控制台中jzlld.org区域下面的两个特殊“域”中仍然只有dc01的SRV记录，因为此时dc02上根本就没有任何应用程序目录分区。
接下来在dc02.jzlld.org上安装DNS服务，安装步骤小帅省略，这样经过一定的复制周期，站点链接建立完成，同步完成之后，dc02.jzlld.org将与dc01.jzlld.org一样拥有5个名称上下文。如图10所示
在DNS控制台中jzlld.org区域下面的两个特殊“域”中仍然只有dc01的SRV记录，因为此时dc02上根本就没有任何应用程序目录分区。
接下来在dc02.jzlld.org上安装DNS服务，安装步骤小帅省略，这样经过一定的复制周期，站点链接建立完成，同步完成之后，dc02.jzlld.org将与dc01.jzlld.org一样拥有5个名称上下文。如图10所示
在DNS的控制台中我们也可以看到jzlld.org区域下面的两个特殊的“域”内包含了两个DC提供LDAP服务的SRV记录。如图11我们以“DomainDnsZones”域为例证明目前应用程序分区DomainDnsZones.jzlld.org存在两个副本。应用程序目录分区ForestDnsZones.jzlld.org也是一样的。
其他识别应用程序目录分区的工具和办法：
Configuration目录分区中的Partition容易下包含了所有的应用程序目录分区，这样每个域的DC在复制这个名称上下文的时候都可以查看到森林中有哪些应用程序目录分区。在每一个应用程序目录分区的属性中有一个属性叫msDS-NC-Replica-Locations，这个属性的值决定着该目录分区的副本有几个，也就是都由哪几台DC来宿主的。如图12
Configuration目录分区中的Partition容易下包含了所有的应用程序目录分区，这样每个域的DC在复制这个名称上下文的时候都可以查看到森林中有哪些应用程序目录分区。在每一个应用程序目录分区的属性中有一个属性叫msDS-NC-Replica-Locations，这个属性的值决定着该目录分区的副本有几个，也就是都由哪几台DC来宿主的。如图12
图12中ForestDnsZones应用程序目录分区的msDS-NC-Replica-Locations属性值有两个：
CN=NTDS Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configureation,DC=jzlld,DC=org
CN=NTDS Settings,CN=DC02,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configureation,DC=jzlld,DC=org
msDS-NC-Replica-Locations属性值请参考以下链接：
http://msdn.microsoft.com/librar ... ctive_directory.asp
应用程序目录分区的对象类型是crossRef，请参考以下链接：
http://msdn.microsoft.com/librar ... hema/c_crossref.asp
你也可以使用dnscmd的一个子命令来查询某个DNS应用程序目录分区的情况。比如在dc01上查看DNS应用程序目录分区ForestDnsZones.jzlld.org的信息可以使用如下命令：
“dnscmd.exe dc01.jzlld.org /DirectoryPartitionInfo ForestDnsZones.jzlld.org”
5) 建立子域sub.jzlld.org并建立该域的第一台域控制器：dc03.sub.jzlld.org
在建立子域sub.jzlld.org的第一台域控制器的时候，将dc03的DNS服务器的地址指向dc01，这样可以使其联系到域命名FSMO（dc01.jzlld.org），以便对新域命名及对新DC的添加给予允许操作。Dcpromo同样也不会出现安装DNS服务的提示。建立的步骤小帅省略（3台DC都在一个站点内部）。这样的3台DC的KCC同步是需要时间的，所以等“AD站点和服务”中出现了环状链接说明KCC服务已经达到平衡了。dc03会在dc01的jzlld.org区域创建一个“子域”sub，并将自己的一些SRV记录登记在下面，当然也会在dc01的_msdcs.jzlld.org区域注册一些记录，别忘了上面我们提到的这个DNS区域的作用。
利用replmon.exe查看的目录分区及应用程序分区复制情况如图13，（请看仔细，略微有点儿长）
CN=NTDS Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configureation,DC=jzlld,DC=org
CN=NTDS Settings,CN=DC02,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configureation,DC=jzlld,DC=org
msDS-NC-Replica-Locations属性值请参考以下链接：
http://msdn.microsoft.com/librar ... ctive_directory.asp
应用程序目录分区的对象类型是crossRef，请参考以下链接：
http://msdn.microsoft.com/librar ... hema/c_crossref.asp
你也可以使用dnscmd的一个子命令来查询某个DNS应用程序目录分区的情况。比如在dc01上查看DNS应用程序目录分区ForestDnsZones.jzlld.org的信息可以使用如下命令：
“dnscmd.exe dc01.jzlld.org /DirectoryPartitionInfo ForestDnsZones.jzlld.org”
5) 建立子域sub.jzlld.org并建立该域的第一台域控制器：dc03.sub.jzlld.org
在建立子域sub.jzlld.org的第一台域控制器的时候，将dc03的DNS服务器的地址指向dc01，这样可以使其联系到域命名FSMO（dc01.jzlld.org），以便对新域命名及对新DC的添加给予允许操作。Dcpromo同样也不会出现安装DNS服务的提示。建立的步骤小帅省略（3台DC都在一个站点内部）。这样的3台DC的KCC同步是需要时间的，所以等“AD站点和服务”中出现了环状链接说明KCC服务已经达到平衡了。dc03会在dc01的jzlld.org区域创建一个“子域”sub，并将自己的一些SRV记录登记在下面，当然也会在dc01的_msdcs.jzlld.org区域注册一些记录，别忘了上面我们提到的这个DNS区域的作用。
利用replmon.exe查看的目录分区及应用程序分区复制情况如图13，（请看仔细，略微有点儿长）
为什么dc01.jzlld.org有一个“DC=sub,DC=jzlld,DC=org”的名称上下文，而且是单向的？因为dc01.jzlld.org是GC（注意dc01上的特殊标记），需要从sub域内的基础机构主控（dc03.sub.jzlld.org）抄写该域对象的属性子集。如果dc02.jzlld.org也是GC的话，那么它也会有这样一个名称上下文。
此时，应用程序目录分区的msDS-NC-Replica-Locations属性仍然是两个值，因为dc03目前还不是DNS服务器。而且dc01和dc02的DNS控制台中的两个特殊的“域”（ForestDnsZones和DomainDnsZones）也不会有什么变化，依然是两个LDAP服务的SRV记录，分别是dc01和dc02的。
接下来对jzlld.org区域做区域分割，将目前的DNS区域名称空间分割成两个区域：jzlld.org和sub.jzlld.org，然后做授权给dc03.sub.jzlld.org来维护DNS区域sub.jzlld.org的操作并在dc03.sub.jzlld.org上安装DNS服务并建立相应的区域，修改dc03.sub.jzlld.org网卡上的DNS服务器地址的指向，配置对jzlld.org区域的所有查询转发到dc01.jzlld.org（一定要注意配置转发）。建立的步骤小帅省略。此时dc03应该有默认的ForestDnsZones.jzlld.org的应用程序目录分区（DNS区域_msdcs.jzlld.org能够自动复制到dc03就说明了这点），还应该有自己本域的一个默认应用程序目录分区：DomainDnsZones.sub.jzlld.org（这个应用程序目录分区与DomainDnsZones.jzlld.org是不同的，可以查看两个应用程序目录分区的GUID及他们的宿主来区别）如图14
此时，应用程序目录分区的msDS-NC-Replica-Locations属性仍然是两个值，因为dc03目前还不是DNS服务器。而且dc01和dc02的DNS控制台中的两个特殊的“域”（ForestDnsZones和DomainDnsZones）也不会有什么变化，依然是两个LDAP服务的SRV记录，分别是dc01和dc02的。
接下来对jzlld.org区域做区域分割，将目前的DNS区域名称空间分割成两个区域：jzlld.org和sub.jzlld.org，然后做授权给dc03.sub.jzlld.org来维护DNS区域sub.jzlld.org的操作并在dc03.sub.jzlld.org上安装DNS服务并建立相应的区域，修改dc03.sub.jzlld.org网卡上的DNS服务器地址的指向，配置对jzlld.org区域的所有查询转发到dc01.jzlld.org（一定要注意配置转发）。建立的步骤小帅省略。此时dc03应该有默认的ForestDnsZones.jzlld.org的应用程序目录分区（DNS区域_msdcs.jzlld.org能够自动复制到dc03就说明了这点），还应该有自己本域的一个默认应用程序目录分区：DomainDnsZones.sub.jzlld.org（这个应用程序目录分区与DomainDnsZones.jzlld.org是不同的，可以查看两个应用程序目录分区的GUID及他们的宿主来区别）如图14
dc01.jzlld.org的DNS区域jzlld.org的两个“域”（ForestDnsZones和DomainDnsZones）的变化如图15、如图16
ForestDnsZones.jzlld.org应用程序目录分区的3个宿主分别在该“域”内注册了LDAP的SRV记录。
DomainDnsZones.jzlld.org应用程序目录分区的2个宿主分别在该“域”内注册了LDAP的SRV记录，因为这个应用程序目录分区是在jzlld.org域内的DC兼DNS的计算机上宿主的。所以没有dc03的LDAP服务的SRV记录，只有dc01和dc02的。
当小帅在dc03.sub.jzlld.org的自己的DNS控制台上创建一个DNS区域sub.jzlld.org，并且复制作用域设置为“至Active Directory域sub.jzlld.org中的所有DNS服务器”的时候，在该DNS区域下将出现DomainDnsZones“域”，其内的记录为DomainDnsZones.sub.jzlld.org应用程序目录分区宿主dc03上的LDAP服务注册的SRV记录，如图17
当小帅在dc03.sub.jzlld.org的自己的DNS控制台上创建一个DNS区域sub.jzlld.org，并且复制作用域设置为“至Active Directory域sub.jzlld.org中的所有DNS服务器”的时候，在该DNS区域下将出现DomainDnsZones“域”，其内的记录为DomainDnsZones.sub.jzlld.org应用程序目录分区宿主dc03上的LDAP服务注册的SRV记录，如图17
为什么反向查找区域没有区域？？
因为小帅在dc01上创建10.0.0.x subnet区域的时候设置该区域是在jzlld.org域内的全域复制的，所以它包含在jzlld.org域的Domain目录分区内，当然不会被复制过来。
为什么sub.jzlld.org的DNS区域下面没有名为ForestDnsZones“域”？
因为宿主ForestDnsZones.jzlld.org应用程序目录分区的宿主SRV记录保存在dc01和dc02的DNS区域jzlld.org下面，是不会复制到该位置的。_msdcs.jzlld.org区域能够出现（不是小帅手工创建的，是复制出来的）能够出现本身也意味着dc03.sub.jzlld.org计算机是ForestDnsZones.jzlld.org应用程序目录分区的宿主。
既然这样，那如果子域sub中的一些应用程序目录分区的客户端应用程序需要定位企业中的某些应用程序目录分区那怎么办？？
别忘了，小帅说过Configuration目录分区中包含了企业中的所有名称上下文，也就是包含了所有AD林中的目录分区（目录分区和应用程序分区），并且该目录分区是全林性复制的。另外从一个应用程序分区的命名上客户端程序就知道应该上哪台DNS上去定位记录了。如图18
因为小帅在dc01上创建10.0.0.x subnet区域的时候设置该区域是在jzlld.org域内的全域复制的，所以它包含在jzlld.org域的Domain目录分区内，当然不会被复制过来。
为什么sub.jzlld.org的DNS区域下面没有名为ForestDnsZones“域”？
因为宿主ForestDnsZones.jzlld.org应用程序目录分区的宿主SRV记录保存在dc01和dc02的DNS区域jzlld.org下面，是不会复制到该位置的。_msdcs.jzlld.org区域能够出现（不是小帅手工创建的，是复制出来的）能够出现本身也意味着dc03.sub.jzlld.org计算机是ForestDnsZones.jzlld.org应用程序目录分区的宿主。
既然这样，那如果子域sub中的一些应用程序目录分区的客户端应用程序需要定位企业中的某些应用程序目录分区那怎么办？？
别忘了，小帅说过Configuration目录分区中包含了企业中的所有名称上下文，也就是包含了所有AD林中的目录分区（目录分区和应用程序分区），并且该目录分区是全林性复制的。另外从一个应用程序分区的命名上客户端程序就知道应该上哪台DNS上去定位记录了。如图18
jzlld.org企业森林中到目前为止有7种不同的名称上下文（目录分区），至于它们各自的复制作用域，各位自己分析吧。
6) 命令行工具dnscmd
这个工具可以用来管理DNS应用程序目录分区，大家可以参看如下链接
http://www.microsoft.com/technet ... a5cc2.mspx?mfr=true
http://www.microsoft.com/technet ... a5cc2.mspx?mfr=true
http://www.microsoft.com/technet ... a5cc2.mspx?mfr=true
http://www.microsoft.com/technet ... a5cc2.mspx?mfr=true
默认情况下，DNS 服务器服务将尝试在 Active Directory 中定位和创建默认的 DNS 应用程序目录分区。如果 DNS 服务器服务无法做到这一点，那么管理员可以使用该过程手动创建应用程序目录分区。如果当前在 Active Directory 中默认的 DNS 应用程序目录分区可用，在 DNS 控制台中创建默认应用程序目录分区的选项将不可用。可以使用DNS控制台，也可以使用命令行工具dnscmd.exe来完成该操作。
默认情况下，只有 Enterprise Admins 组的成员才可以创建 DNS 应用程序目录分区。
利用dnscmd.exe命令来创建一个DNS应用程序分区。
小帅在dc01.jzlld.org上利用dnscmd.exe命令行工具来创建一个DNS应用程序分区，FQDN名字为TestDnsZones.jzlld.org。如图19
6) 命令行工具dnscmd
这个工具可以用来管理DNS应用程序目录分区，大家可以参看如下链接
http://www.microsoft.com/technet ... a5cc2.mspx?mfr=true
http://www.microsoft.com/technet ... a5cc2.mspx?mfr=true
http://www.microsoft.com/technet ... a5cc2.mspx?mfr=true
http://www.microsoft.com/technet ... a5cc2.mspx?mfr=true
默认情况下，DNS 服务器服务将尝试在 Active Directory 中定位和创建默认的 DNS 应用程序目录分区。如果 DNS 服务器服务无法做到这一点，那么管理员可以使用该过程手动创建应用程序目录分区。如果当前在 Active Directory 中默认的 DNS 应用程序目录分区可用，在 DNS 控制台中创建默认应用程序目录分区的选项将不可用。可以使用DNS控制台，也可以使用命令行工具dnscmd.exe来完成该操作。
默认情况下，只有 Enterprise Admins 组的成员才可以创建 DNS 应用程序目录分区。
利用dnscmd.exe命令来创建一个DNS应用程序分区。
小帅在dc01.jzlld.org上利用dnscmd.exe命令行工具来创建一个DNS应用程序分区，FQDN名字为TestDnsZones.jzlld.org。如图19
此时，在dc01上的DNS控制台中创建一个DNS区域jxs.org并将其存储在小帅刚建立好的DNS应用程序目录分区TestDnsZones.jzlld.org中，此时在选择上有区别了。如图20
注意，由于此时DNS应用程序目录分区TestDnsZones.jzlld.org只登记了dc01.jzlld.org这台计算机，所以只能在dc01上建立区域的时候有这个特殊的选项，在dc02、dc03上的DNS控制台上创建区域的时候都不会出现该选项。
图21是在dc01上建立好名为jxs.org的DNS区域之后出现的一个特殊的“域”TestDnsZones及dc01上LDAP服务注册的SRV记录
图21是在dc01上建立好名为jxs.org的DNS区域之后出现的一个特殊的“域”TestDnsZones及dc01上LDAP服务注册的SRV记录
注意，由于此时DNS应用程序目录分区TestDnsZones.jzlld.org只登记了dc01.jzlld.org这台计算机，所以只能在dc01上建立区域的时候有这个特殊的选项，在dc02、dc03上的DNS控制台上创建区域的时候都不会出现该选项。
图21是在dc01上建立好名为jxs.org的DNS区域之后出现的一个特殊的“域”TestDnsZones及dc01上LDAP服务注册的SRV记录
图21是在dc01上建立好名为jxs.org的DNS区域之后出现的一个特殊的“域”TestDnsZones及dc01上LDAP服务注册的SRV记录
![clip_image038[1]](http://img1.51cto.com/attachment/201002/3/209800_1265185882p2KO.jpg "clip_image038[1]")
接下来小帅将 dc02、dc03登记到该目录分区，让dc01、dc02和dc03这三台DC兼DNS的计算机来宿主这个DNS应用程序目录分区TestDnsZones.jzlld.org。要执行此过程，必须是 Active Directory 中 DnsAdmins组（默认域管理员不是这个组的成员，另外注意DnsAdmins是本地组） 或域管理员组的成员，或者被委派了适当的权限。如图22、图23
下面是DNS控制台中和DNS应用程序目录分区TestDnsZones.jzlld.org的msDS-NC-Replica-Locations属性的截图及DNS控制台中该应用程序目录分区的注册记录。如图24
当然你也可以利用“dnscmd.exe servername /UnenlistDirectoryPartition FQDN”命令来删除某个服务器在某个应用程序分区的登记。
注意：因为DNS应用程序目录分区也是应用程序目录分区的一种，所以使用dnscmd命令是无法删除该应用程序目录分区的，只能使用ntdsutil命令来删除应用程序目录服务分区，下面的部分小帅会介绍利用ntdsutil命令对应用程序目录分区的操作。
注意：因为DNS应用程序目录分区也是应用程序目录分区的一种，所以使用dnscmd命令是无法删除该应用程序目录分区的，只能使用ntdsutil命令来删除应用程序目录服务分区，下面的部分小帅会介绍利用ntdsutil命令对应用程序目录分区的操作。
三、 自定义应用程序目录分区
应用程序目录分区不一定就是为了DNS这个应用程序使用，以上AD默认创建的ForestDns.jzlld.org、DomainDnsZones.jzlld.org和小帅手工创建的TestDnsZones.jzlld.org几个DNS应用程序目录分区是专为DNS这个应用程序设置的目录分区，当然我们也可以根据企业的相关需要来为可行的应用程序定义应用程序目录分区，并设置他们的复制范围。比如很多企业使用的TAPI就是一个很好的例子，TAPI的详细内容请参考： http://msdn.microsoft.com/librar ... ming_interfaces.asp
http://www.microsoft.com/technet ... 1f6ae.mspx?mfr=true
在使用ntdsutil命令来管理应用程序目录分区的之前需要先理解一些概念
1) 应用程序分区的命名（在第一部分中我们已经解释了）
2) 应用程序目录分区复制
信息一致性检查器 (KCC) 自动生成和维护企业中所有应用程序目录分区的复制拓扑。当应用程序目录分区在多个站点拥有副本时，那些副本和域目录分区有着相同的站点间复制日程安排。
3) 安全描述符参考域
网络的每个容器和对象都有一组附加于其中的访问控制信息。此信息称为安全描述符，可控制用户、组和计算机所允许的访问类型。如果对象或容器未被创建它的应用程序或服务分配安全描述符，那么它将被分配架构中定义的该对象类的默认安全描述符。这种默认的安全描述符是不明确的，它向 Domain Admins 组的成员分配对对象的读取权限，但不指定域管理员属于哪个域。当在某个域命名分区中创建该对象时，此域命名分区就用来指定读取权限实际上分配给了哪个 Domain Admins 组。
在应用程序目录分区中创建对象时，默认安全描述符的定义是不同的，因为应用程序目录分区可以在属于不同域的不同域控制器上拥有副本。因为存在这种潜在的不确定性，所以在创建应用程序目录分区时会分配一个默认的安全描述符参考域。
默认的安全描述符参考域定义了当该应用程序目录分区中的对象需要为默认安全描述符定义域值时应使用什么域名。默认的安全描述符参考域是在创建时分配的。如果该应用程序目录分区是某个域目录分区的子项，那么在默认情况下，父域目录分区将变成安全描述符参考域。如果该应用程序目录分区是另一个应用程序目录分区的子对象，则父应用程序目录分区的安全描述符参考域将变成新的子应用程序目录分区的参考域。如果新的应用程序目录分区创建为新树的根，那么此林根域将用作默认的安全描述符参考域。
4) 应用程序分区和DC的升、降级
如果域控制器拥有某个应用程序目录分区的副本，则必须从该应用程序目录分区的副本集中删除此域控制器，或者删除该应用程序目录分区，然后才能降级此域控制器。
如果域控制器拥有某个应用程序目录分区的“最新”副本，则必须删除该应用程序目录分区，然后才能降级此域控制器。
理解以上的应该差不多了，其他的相关资源请参考Windows Server 2003帮助或
http://www.microsoft.com/technet ... 949f2.mspx?mfr=true
5) 小帅先利用ntdsutil将在上面建立的TestDnsZones.jzlld.org的应用程序目录分区的3个副本删除，然后将该应用程序目录分区删除，如图25，在此小帅使用的命令全部为缩写并且没有显示帮助。
应用程序目录分区不一定就是为了DNS这个应用程序使用，以上AD默认创建的ForestDns.jzlld.org、DomainDnsZones.jzlld.org和小帅手工创建的TestDnsZones.jzlld.org几个DNS应用程序目录分区是专为DNS这个应用程序设置的目录分区，当然我们也可以根据企业的相关需要来为可行的应用程序定义应用程序目录分区，并设置他们的复制范围。比如很多企业使用的TAPI就是一个很好的例子，TAPI的详细内容请参考： http://msdn.microsoft.com/librar ... ming_interfaces.asp
http://www.microsoft.com/technet ... 1f6ae.mspx?mfr=true
在使用ntdsutil命令来管理应用程序目录分区的之前需要先理解一些概念
1) 应用程序分区的命名（在第一部分中我们已经解释了）
2) 应用程序目录分区复制
信息一致性检查器 (KCC) 自动生成和维护企业中所有应用程序目录分区的复制拓扑。当应用程序目录分区在多个站点拥有副本时，那些副本和域目录分区有着相同的站点间复制日程安排。
3) 安全描述符参考域
网络的每个容器和对象都有一组附加于其中的访问控制信息。此信息称为安全描述符，可控制用户、组和计算机所允许的访问类型。如果对象或容器未被创建它的应用程序或服务分配安全描述符，那么它将被分配架构中定义的该对象类的默认安全描述符。这种默认的安全描述符是不明确的，它向 Domain Admins 组的成员分配对对象的读取权限，但不指定域管理员属于哪个域。当在某个域命名分区中创建该对象时，此域命名分区就用来指定读取权限实际上分配给了哪个 Domain Admins 组。
在应用程序目录分区中创建对象时，默认安全描述符的定义是不同的，因为应用程序目录分区可以在属于不同域的不同域控制器上拥有副本。因为存在这种潜在的不确定性，所以在创建应用程序目录分区时会分配一个默认的安全描述符参考域。
默认的安全描述符参考域定义了当该应用程序目录分区中的对象需要为默认安全描述符定义域值时应使用什么域名。默认的安全描述符参考域是在创建时分配的。如果该应用程序目录分区是某个域目录分区的子项，那么在默认情况下，父域目录分区将变成安全描述符参考域。如果该应用程序目录分区是另一个应用程序目录分区的子对象，则父应用程序目录分区的安全描述符参考域将变成新的子应用程序目录分区的参考域。如果新的应用程序目录分区创建为新树的根，那么此林根域将用作默认的安全描述符参考域。
4) 应用程序分区和DC的升、降级
如果域控制器拥有某个应用程序目录分区的副本，则必须从该应用程序目录分区的副本集中删除此域控制器，或者删除该应用程序目录分区，然后才能降级此域控制器。
如果域控制器拥有某个应用程序目录分区的“最新”副本，则必须删除该应用程序目录分区，然后才能降级此域控制器。
理解以上的应该差不多了，其他的相关资源请参考Windows Server 2003帮助或
http://www.microsoft.com/technet ... 949f2.mspx?mfr=true
5) 小帅先利用ntdsutil将在上面建立的TestDnsZones.jzlld.org的应用程序目录分区的3个副本删除，然后将该应用程序目录分区删除，如图25，在此小帅使用的命令全部为缩写并且没有显示帮助。
此时存储在该DNS应用程序目录分区TestDnsZones.jzlld.org内的DNS区域jxs.org中的数据也将被删除，从整个AD中消失，你也可以使用上面小帅介绍的各种方法来检验该DNS目录分区的存在。如图26
小帅然后建立一个新的应用程序目录分区名为AppDS.sub.jzlld.org（注意命名和默认参考域），并将dc01,dc03作为该应用程序目录分区的副本集。如图27
因为在运行ntdsutil的时候connect的就是dc01，所以当创建该应用程序目录分区的时候dc01就已经是该目录分区的副本了，所以只添加dc03就可以了。
该应用程序分区当你在创建DNS区域并选择“复制作用域”的时候也是可见的，就跟图20选择的位置类似。
图28显示的是使用LDP查看dc01上存储的目录分区及查看AppDS.sub.jzlld.org应用程序分区属性msDS-NC-Replica-Locations值的情况。
该应用程序分区当你在创建DNS区域并选择“复制作用域”的时候也是可见的，就跟图20选择的位置类似。
图28显示的是使用LDP查看dc01上存储的目录分区及查看AppDS.sub.jzlld.org应用程序分区属性msDS-NC-Replica-Locations值的情况。
到此其他操作应该非常简单了。请参考ntdsutil.exe帮助信息或Windows Server 2003 AD帮助或
http://www.microsoft.com/technet ... 949f2.mspx?mfr=true
四、 从媒体安装域控制器的应用程序目录相关
2003SP1提供了一个功能就是从媒体来安装新的域控制器，如果想实现从媒体的无应答安装，并复制相应的应用程序目录分区需要提升林功能，并安装2003SP1。下面小帅将jzlld.org林提升功能（要求森林中的每个域都为2003模式才可以提升整个森林的模式），并将dc04利用媒体的安装形式将其提升为jzlld.org域的第三台DC，还要将我们在上面刚刚建立的应用程序目录分区AppDS.sub.jzlld.org及默认的DNS应用程序目录分区之一ForestDnsZones.jzlld.org复制到dc04，注意dc04上没有安装DNS服务（小帅省略所有操作步骤，只将应答文件及最终结果呈现）。如图29、图30
http://www.microsoft.com/technet ... 949f2.mspx?mfr=true
四、 从媒体安装域控制器的应用程序目录相关
2003SP1提供了一个功能就是从媒体来安装新的域控制器，如果想实现从媒体的无应答安装，并复制相应的应用程序目录分区需要提升林功能，并安装2003SP1。下面小帅将jzlld.org林提升功能（要求森林中的每个域都为2003模式才可以提升整个森林的模式），并将dc04利用媒体的安装形式将其提升为jzlld.org域的第三台DC，还要将我们在上面刚刚建立的应用程序目录分区AppDS.sub.jzlld.org及默认的DNS应用程序目录分区之一ForestDnsZones.jzlld.org复制到dc04，注意dc04上没有安装DNS服务（小帅省略所有操作步骤，只将应答文件及最终结果呈现）。如图29、图30
注意：其中c:\Ntdsretore为小帅将备份好的dc01的系统状态SystemState.bkf恢复到dc04上的“备用位置”生成的临时文件夹。
验证AppDS.sub.jzlld.org应用程序分区如图31
验证AppDS.sub.jzlld.org应用程序分区如图31
具体步骤请参考
http://support.microsoft.com/kb/311078/zh-cn
五、注意事项及相关资源
http://support.microsoft.com/def ... appliesto#appliesto
“Event ID 4515 is logged in the DNS Server log in Windows Server 2003”。理解完应用程序目录分区就知道为什么会出现4515的错误了。
http://windowssdk.msdn.microsoft ... a_dnstombstoned.asp
应用程序目录分区的限制
http://msdn.microsoft.com/librar ... ctive_directory.asp
该链接从目录架构的方面描述了应用程序目录分区
http://technet2.microsoft.com/Wi ... 43a403b4361033.mspx
DNS与AD应用程序之间的关系（包扩GC）
http://support.microsoft.com/kb/817470/zh-cn
在从 Windows 2000 升级到 Windows Server 2003 时，如何将 _msdcs 子域重新配置为全林性 DNS 应用程序目录分区
http://www.microsoft.com/technet ... 81ff7.mspx?mfr=true
Active Directory 的新功能概述
http://support.microsoft.com/kb/311078/zh-cn
五、注意事项及相关资源
http://support.microsoft.com/def ... appliesto#appliesto
“Event ID 4515 is logged in the DNS Server log in Windows Server 2003”。理解完应用程序目录分区就知道为什么会出现4515的错误了。
http://windowssdk.msdn.microsoft ... a_dnstombstoned.asp
应用程序目录分区的限制
http://msdn.microsoft.com/librar ... ctive_directory.asp
该链接从目录架构的方面描述了应用程序目录分区
http://technet2.microsoft.com/Wi ... 43a403b4361033.mspx
DNS与AD应用程序之间的关系（包扩GC）
http://support.microsoft.com/kb/817470/zh-cn
在从 Windows 2000 升级到 Windows Server 2003 时，如何将 _msdcs 子域重新配置为全林性 DNS 应用程序目录分区
http://www.microsoft.com/technet ... 81ff7.mspx?mfr=true
Active Directory 的新功能概述
六、总结
其实本文小帅很早就想写了，不过进度却一直拖拖拉拉，可能是由于不是每天都很快乐的原因吧，郁闷和烦恼就象家常便饭一样，快乐的时光越来越少，如果某一天出现了快乐的事儿，那小帅会觉得算很幸运捡了个便宜，不快乐和郁闷的时候就纯属是正常状态了。转念又一想谁又能每天都快乐呢？傻子也许可以。谁也不愿意永远做傻子，就像不能永远快乐一样……
深入理解全局编录服务器GC
其实本文小帅很早就想写了，不过进度却一直拖拖拉拉，可能是由于不是每天都很快乐的原因吧，郁闷和烦恼就象家常便饭一样，快乐的时光越来越少，如果某一天出现了快乐的事儿，那小帅会觉得算很幸运捡了个便宜，不快乐和郁闷的时候就纯属是正常状态了。转念又一想谁又能每天都快乐呢？傻子也许可以。谁也不愿意永远做傻子，就像不能永远快乐一样……
|
版权声明：原创作品，如需转载，请与作者联系。否则将追究法律责任。
|
|
概述：
在Win2003AD域环境中，除了FSMO操作主机角色外，全局编录服务器(GC)也是有着特殊含义的域控制器。通过GC，可以提高在活动目录中搜索对象的速度，可以加快用户登录验证等。 简单的说，GC是森林中所有对象的只读调整缓冲存储器( Read Only Cache),目录只用于搜索。GC服务器存储本域中所有对象的所有属性，同时会存储林中其它域中所有对象的部分属性。一般来说，属性是否存储在GC中，取决于该属性在搜索中使用的频率,由系统自动进行决定。但AD架构管理员也可以定义对象的哪些属性保存的GC中，同时决定该属性是否可以进行索引。 本文拟就与GC相关的内容一一阐述，希望能起抛砖引玉作用，与有兴趣的朋友一起更好的了解和熟悉全局编录服务器。 GC出现的原因 GC的作用 查看当前环境中GC服务器 提升DC为全局编录服务器 验证全局编录服务器的提升 验证全局编录服务器是否工作正常 删除全局编录服务器 使用AdsiEdit工具查看全局编录服务器中的数据
一：GC出现的原因
在Win2003活动目录中有两种目录服务，分别是DNS以及LDAP，两个目录服务互为补充。DNS的目的比较简单，用于简单快速的定位域控制器，但定位到具体的域控制器后，对活动目录信息的更细致访问，如活动目录中关于用户，计算机，打印机等对象信息搜索，DNS就无能为力。此时就需要通过LDAP服务来访问。 如果用户知道某个对象处于哪个域，也知道对象的标识名，那么用LDAP搜索对象就非常容易。但如果用户只知道某个对象的某个属性，根本不知道对象所处的域，也不知道该对象的标识名，那么使用LDAP来搜索对象是一件非常困难的事，AD不得不对当前环境中每一个域的每个对象都搜索一遍。为了解决这个问题，活动目录提供了全局编录服务器(GC，到Global Catalog)。GC中包含了当前林中每个域中所有对象的副本，如果在一次LDAP搜索中，涉及到搜索中多个域的名称上下文时，AD会选择搜索GC服务器，从而实现加快搜索速度，减少网络通信量的目的。
二：GC的作用
1：存储对象信息副本，提高搜索性能 全局编录服务器中除了保存本域中所有对象的所有属性外，还保存林中其它域所有对象的部分属性，这样就允许用户通过全局编录信息搜索林中所有域中对象的信息，而不用考虑数据存储的位置。通过GC执行林中搜索时可获得最大的速度并产生最小的网络通信量。 2：存储通用组成员身份信息，帮助用户构建访问令牌 全局组成员身份存储在每个域中，但通用组成员身份只存储在全局编录服务器中。 我们知道，用户在登陆过程中需要由登录的DC构建一个安全的访问令牌，而要构建成功一个安全的访问令牌由三方面信息组成：用户SID，组SID，权力。其中用户SID和用户权力可以由登录DC获得，但对于获取组SID信息时，需要确定该用户属不属于通用组，而通用组信息只保存在GC中。所以当GC故障，负责构建安全访问令牌的DC就无法联系GC来确认该用户组的SID，也就无法构建一个安全的访问令牌。 注：在Win2003中，可以通过通用组缓存功能解决GC不在线无法登录情况，具体操作本文略过。 3：提供用户UPN名称登录身份验证。 当执行身份验证的域控制器没有用户UPN帐号信息时，将由GC解析用户主机名称(UPN)进行身份验证，以完成登录过程 4：验证林中其他域对象的参考 当域控制器的某个对象的属性包含有另一个域某个对象的参考时，将由全局编录服务器来完成验证。
三：查看当前环境中GC服务器
1：通过“Active Directory 站点和服务”查看 步骤： 点击“开始-设置-控制面板-管理工具-Active Directory站点和服务”: 选中具体的“NTDS Setting"。 
选中"NTDS Setting",右键选择“属性”
在弹出的“NTDS Setting 属性”对话框中，有“全局编录”复选框,如果选中，表示是一台全局编录服务器， 如果没有选中，则表示当前的服务器不是全局编录服务器。
2：利用复制监视器Replmon查看
复制监视器Replication Monitor(ReplMon)是针对Windows Server的故障查找工具,不但是定位活动目录 复制故障强有利的工具，同时也可以使用该工具查看和检查操作主机角色状态。 详细Replmon工具使用方法本文不做过多说明，这里只列出如何使用Replmon工具GC角色。 步骤：选中当前DC，右键单击，选择“Show Global Catalog Servers in Enterprise” 
在弹出窗口中，清楚列出当前林中所有的全局编录服务器
3：通过命令行方式查看全局编录服务器
在Supprot Tools和Resource Tools工具中，有多个命令行工具可以查看全局编录服务器，这里只列出两个最常见的命令行工具 使用dsquery命令查看当前域中的GC dsquery server -domain superlan.com -isgc 
使用nltest命令查看当前域中的GC
nltest /dsgetdc:superlan.com 
四：提升DC为全局编录服务器
将一台域控制器提升为全局编录服务器操作很简单，方法见通过“Active Directory 站点和服务”管理单元查看全局编录服务器， 将“全局编录”复选框选中即可。 注意：设置完成后，并不代表当前的全局编录服务器已经提升完成，因为全局编录服务器中包含有多个域的所有对象，需要时间来进行全局编录数据库同步。 ![clip_image058[1]](http://img1.51cto.com/attachment/201002/3/209800_126518589792eE.gif "clip_image058[1]")
五：验证全局编录服务器的提升
通过提升DC为全局编录服务器操作，需要时间同步全局编录服务器，同步完成后，全局编录服务器才开始真正运行。 下面介绍如何查看全局编录服务器是否已经开始工作。 1：使用LDP工具查看当前DC的IsGlobalCatalogReady属性 LDP(LDAP浏览器工具)是一个轻量目录访问协议 (LDAP) 客户端实用工具,可以用来查询和浏览 LDAP目录服务，详细用法本文不做具体介绍， 可以搜索相关的说明文档或后期的Blog文章介绍。这里只给出简单的使用说明 步骤： 与LDAP目录绑定 “运行”，输入“LDP”，打开LDP窗口后，选择“Connection|Bind",打开Bind对话框，输入身份凭证。 
单击”OK“按钮，LDP连接到”Superlan.Com"域控制器，显示检测结果，从下图可以看出“IsGlobalCatalogReady"属性为True
2：查看DNS管理工具查看GC记录是否已更新到DNS中。
从下图可以看出当前哪个域控制器是GC，且使用的端口是多少，默认的GC使用端口是3268。 
六：验证全局编录服务器是否工作正常
全局编录服务器正确提升后，可以通过查看注册表信息和端口状态来查看 全局编录服务器是否工作正常。 1：查看注册表信息(HKLM\System\CurrentControlSet\Services\NTDS\Parameters) 健值：Global Catalog Promotion Complete，值为1，表示GC工作正常 
2：全局服务编录器默认使用3268/3269端口，通过查看端口是否处于监听状态可以判断GC是否工作正常
使用netstat -an命令查看当前正在运行的端口,可以看到3268/3269端口已经处于正常监听状态 
七：删除全局编录服务器
删除全局编录服务器方法请参见”四：提升全局编录服务器“，将”全局编录“复选框取消即可，此处略过。
八：使用AdsiEdit工具查看全局编录服务器中的数据
因篇辐较长，拟定以独立的文章介绍，见后续文章!
http://alligator.blog.51cto.com/36993/101261
|
![clip_image055[1]](http://img1.51cto.com/attachment/201002/3/209800_1265185901eZvv.gif "clip_image055[1]"){kind=small}
2008-09-23 12:02:51
标签：
GC
活动目录
架构
AdsiEdit
全局编录
[
推送到技术圈
]
AD管理维护与排错工具系列一：DcDiag
|
版权声明：原创作品，如需转载，请与作者联系。否则将追究法律责任。
|
|
阅读前请参考：
深入理解全局编录服务器(
http://alligator.blog.51cto.com/36993/101190
)
全局编录服务器并不是一个独立的实体，域控制器也没有单独为GC准备一个独立的DIT文件，GC服务器与当前的域公用同一个NTDS.DIT文件，两者的区别只是使用的端口号不同，前者使用3268端口，后者使用389端口。理解了这一点，也就理解了如何来查看GC数据。
AdsiEdit工具是一个超级强大的AD查看与编辑工具，我们可以使用这个工具做一些其它工具无法实现的功能。 比如本文准备阐述的查看全局编录服务器中的数据等。
为了更好的说明如何使用AdsiEdit工具查看GC数据，先介绍一下当前的演示环境：
两个域，父域为Superlan.Com,子域为Sub.Superlan.Com,其中Superlan.Com域中有一台DC(PriDomDemo.Superlan.Com), 同时担任GC角色，子域中有一台DC(SubDomDemo.Sub.Superlan.Com),非GC。 域结构如下： 
因PriDomDemo.Superlan.Com为父域DC，同时又为GC，所以在PriDomDemo AD数据库中，应该包含有子域Sub.Superlan.Com数据。
那么如何在PriDomDemo中查看子域数据，同时验证GC相关的概念，比如 GC是森林中所有对象的只读调整缓冲存储器 包含有子域所有对象的部分属性。 自定义对象的哪些属性保存的GC中，同时决定该属性是否可以进行索引等等。 本文利用AdsiEdit工具，分别连接GC以及Sub.Superlan.Com域，通过比较标准的Sub域数据与保存在GC中Sub域数据，就上述问题做深入阐述!
具体操作如下
一：使用AdsiEdit查看AD数据
1：连接到GC服务器 在AdsiEdit中,连接到GC服务器很简单，唯一需要注意的是，需要在“高级”中指定使用Global Catalog协议 具体如下： 在“运行”窗口输入“AdsiEdit.msc",打开AdsiEdit编辑器。 选中"AdsiEdit",右键选择”Connect to“ 
在"Connection Setting"弹出框，输入相应的名称上下文
输入名称上下文后，打开"Advanced "按钮，选择”Global Catalog"协议
选择两次OK按钮，确定输入无误后，就可以正确连接到GC服务器
2：新建一个连接到Sub.Superlan.Com域
操作与连接到GC步骤类似，保留“Advanced"中默认的LDAP协议 
建立好上述两个连接后，AdsiEdit工具窗口中存在两个连接，分别是GC服务器数据和Sub子域数据。
从上图我们可以看出，在GC服务器数据中，有一个“DC=Sub”容器。
展开该容器后，我们可以看到该容器中所包含的信息与Sub子域数据完全相同 
从上图我们也可以看出，GC中确实保存着林中其它域的所有对象
二：验证GC是林中所有对象的只读存储器 任意展开GC中容器中任意对象的任意属性，点击“Edit"按钮，都可以看到， 所有的属性都是处于ReadOnly状态，无法进行修改。 
而在非GC连接中，可以直接进行修改编辑，从中我们可以看出不论是对于当前域，还是非本地域，GC中保存的都只是对象的只读副本。
三：验证GC中只包含林中其它域所有对象的部分属性
为验证这个结论，在Sub子域新建一个OU：User Demo,其中建立有一个用户：itTrainer.分别在GC服务器和Sub子域中查看该对象属性，我们可以看出，GC中该对象有值的属性比Sub子域中该对象有值的属性少得多。GC中只保留有系统属性以及明确指出保存在GC中的属性。 而Sub子域中会保存该对象的所有属性值。
四：如何自定义哪些属性保存在GC中
要自定义哪些属性保存在GC中，需要使用AD架构管理单元。 注意，默认情况下，只有父域的Administrator属于架构管理组，而子域管理员不属于该管理组。 1：注册AD架构管理单元 步骤：注册：regsvr32 schmmgmt 在MMC中添加AD架构管理单元 打开MMC控制台，选中“Active Directory架构”，点击“属性”,在右侧内容栏列出当前域架构中存在所有属性。 
2：自定义属性保存在GC中
选择任一个属性，右键选择”属性“，在弹出的”属性编辑器“中，可以自定义该属性是否保存在GC中， 同时也可以决定该属性在GC中是否编制索引，以提高搜索性能。 
因为篇幅关系，本文不再演示如何自定义某个属性是否存在到GC。 有兴趣的朋友可以试着将某一个属性自定义为保存在GC中，同时建立某个对象，在该对象中对这个属性赋值，在GC中检查是否存在该属性值。甚至于可以通过架构管理单元取消某个默认保存到GC中的某个属性，然后通过GC检查该属性是否仍然保存在GC中。 相信通过相应的操作，一定会对GC相关的概念有更深入的理解! |
2008-09-12 01:00:09
标签：
管理工具
AD
维护工具
排错工具
DcDiag
[
推送到技术圈
]
深入理解AD域环境中操作主机角色
|
版权声明：原创作品，如需转载，请与作者联系。否则将追究法律责任。
|
|
写在前面：
这是一直想写但一直在犹豫的系列，因为系列准备介绍的没有那种包治百病,灵丹妙药式的工具，只有日常维护和排错过程中常用工具。这些工具都包含在MS Support Tools或Resource Tools中，微软网站或工具自带的使用帮助中已有相应的使用说明，网络中也有许多类似的文章可以参考。从这点来说，再整理这样的系列，未免有画蛇添足之嫌。但另一方面，MS Support Tools和Resource Tools包含的工具如此之多，多数又缺少工具功能和使用范围介绍，在实际环境中遇到故障时，有时无法确定该使用哪种适当工具进行故障定位和排错。且对于部分人而言，阅读英文说明文档是一件痛苦的事情，以至于对这些经典工具望而却步，在论坛中也经常可以看到“某某AD工具如何使用”诸如此类的求助帖子。 整理这个系列，一方面是帮助自己梳理常用的这些工具使用文档，方便日常的工作和管理。另一方面也希望能对刚接触活动目录管理的新手如何使用这些工具起指导入门的作用。 至于文章中工具功能和参数的解释，大部分是通过查看工具自带帮助翻译理解而成，由于英文水平和理解能力有限，肯定存在理解偏差或完全错误的地方，欢迎大家指正，毕竟良好的交流和沟通氛围，是学习技术重要的途径!
工具名称：DcDiag
工具出处：MS Support Tools 工具类型：命令行工具 当前环境：Win2003 SP1 + R2,DC 主要功能： DcDiag是域控制器诊断工具，通过各种诊断测试，用来分析当前林或域中域控制器状态，生成相应的检测报告。DcDiag可以说是域控制器诊断全能工具，当DC出现问题却无法判断具体故障原因时，首选使用DcDiag工具对DC进行一次全面诊断，查看检测报告，从而缩小问题范围以及定位问题! DcDiag工具由对系统的一系列测试和校验构成，可以根据用户的选择，针对不同的范围（林，域）对域控制器进行不同项目的诊断测试，主要测试项目有： 1：连通性 2：复制 3：拓朴完整性 4：检查NC Head安全描述符 5：检查登录权 6：获取DC位置 7：验证安全边界 8：验证FSMO角色 9：验证信任关系 10：DNS
一：DcDiag工具语法格式
DcDiag.exe /s:<Domain Controller> [/u:<Domain>\<Username> /p:*|<Password>|""] [/hqv] [/n:<Naming Context>] [/f:<Log>] [/ferr:<Errlog>] [/skip:<Test>] [/test:<Test>]
二：主要参数说明：
/s:Domain Controller - 指定测试的DC，默认测试本机。 /n:Naming Context - 指定测试时关联的名称上下文。似乎只能使用域名称上下文，无法测试Schema,Configration等名称上下文。 域名称上下文可以使用域的DNS名称，NetBios名称或DN名称。 /u:Domain\Username /p: - 用指定的帐号密码连接DC，此时该帐号的密码为显示密码。 如：DcDiag /u:superlan.vmtest.com\administrator /p:1qa2ws3ed /a - 测试当前站点所有DC /e - 测试整个企业(整个林)中所有DC的状况 /q - 只显示错误信息 /v - 显示详细检测报告 /i - 忽略多余的错误信息 /fix - 仅对 MachineAccount 测试有影响。此参数会使测试过程对目录服务器的计算机帐户对象上的服务主体名称 (SPN) 进行修复 /f - 将信息报告输出到指定的文件 /ferr - 将致命错误输出重定向指定的文件 /c - 诊断除 DcPromo 和 RegisterInDNS 之外的所有测试项目，包括非默认的测试。 非默认测试项包括：拓扑，对方服务器是否关闭，安全通道输出范围以及DNS动态注册等。 /skip:Test - 指定不进行诊断的测试项，必须与/c配合使用。 /test:Test - 只运行单一测试项，但连通测试不跳过 具体测试项有： Connectivity - 连通性。测试DC是否在DNS中登记注册，Ping测试以及LDAP/RPC的可用性。 Replications - 检测DC之间的复制情况 Topology - 检查KCC是否为所有DC生成完整的链接拓扑 CutoffServers - 检查因复制伙伴不可用而没有接受到的复制的DC NCSecDesc - 检查在名称上下文头中的安全描述符是否有适当的复制权限 NetLogon - 检查是否有进行复制的适当登录权限 Advertising － 检查每个DC是否已公告它自己能够执行的角色。如果 Net Logon 服务停止或未能启动，则此测试将失败。 KnowsOfRoleHolders － 检查DC是否可以与FSMO操作主机正常联系 Intersite - 检查会阻止或暂时中止站点间复制的故障，并尝试预测 KCC 能够恢复之前需要的时间。 FSMOCheck - 检查DC是否能联系密钥发行中心 (KDC)、时间服务器、首选时间服务器、主目录服务器（主域控制器 (PDC)）和全局编录服务器。 RidManager - 检查是否可访问 RID 主机，以及 RID 主机是否包含正确的信息。 MachineAccount － 检查机器的帐户是否包含正确信息。 如果本地计算机帐号丢失，使用/RecreateMachineAccount进行尝试修复 如果本地计算机帐号标志不正确，使用/FixMachineAccount进行尝试修复 Services - 检查DC服务是否在运行正常 OutboundSecureChannels 检查当前域中所有DC的安全通道。 ObjectsReplicated - 检查 Machine Account 和 DSA 对象是否已复制 frssysvol - 检查SYSVOL文件夹共享状态。 frsevent - 检查FRS是否存在错误记录 kccevent - 检查 KCC是否存在错误记录。 systemlog - 检查系统是否无错误运行。 DCPromo - 检查DC上的DNS记录是否正常 RegisterInDNS - 检查DC是否在DNS中注册 CrossRefValidation - 检查交叉引用是否有效 CheckSDRefDom - 检查目录分区的安全 VerifyReplicas - 检查复制服务器上目录分区的安全性 VerifyReference - 检查对于 FRS 和“复制”基础结构系统参数的正确与完整性 VerifyEnterpriseReferences - 检查整个企业范围内的所有DC上系统参数是否正确与完整
(Win2003 SP1新增功能)
CheckSecurityError - 检测可能会造成AD复制失败的安全配置 DNS - 检查整个企业内的DNS健康性。 DNS测试子项有： /DnsBasic - 基本DNS测试，包括网络连接性、DNS客户端配置、服务可用性和区域存在性。 /DnsForwarders - /DnsBasic 测试，还检查转发器的配置 /DnsDelegation - /DnsBasic 测试，还检查委派配置 /DnsDynamicUpdate - /DnsBasic测试,还检查是否配置动态更新 /DnsRecordRegistration - /DnsBasic测试,检查是否已注册A、CNAME和已知的SRV记录。此外，还根据结果创建清单报告 /DnsResolveExtName - /DnsBasic测试，还尝试解析指定的域名名称. /DnsInternetName - /DnsBasic测试，还尝试解析指定域名 /DnsAll - 除了/DnsResolveExtName外的所有DNS测试项
三：使用示例
DcDiag参数众多，且可以组合使用，下面只给出基本的使用示例，对用法做一简单描述。 1：最简单的用法,诊断当前DC状况 >DcDiag
2：测试当前DC的连通性
>dcdiag /s:vmtest /test:connetivity 3：测试整个林拓扑结构 >dcdiag /e /test:Topology 4：DCPromo参数用法。注：DcPromo主要是当使用AD安装向导或通过DCPromo命令安装AD出错时使用 测试是否可以在当前服务器上新建一个林 >dcdiag /test:dcpromo /dnsdomain:vmtest.com /newforest 
测试是否可以在当前服务器上新建树 >dcdiag /test:DCpromo /dnsdomain:vmtest.com /newtree /forestRoot:vmtest.com
测试是否可以在当前服务器上新建子域
>dcdiag /test:dcpromo /dnsdomain:vmtest.com /childDomain 测试是否可以在当前服务器上安装辅助DC >dcdiag /test:dcpromo /dnsdomain:vmtest.com /ReplicaDC
5：测试DC是否在DNS中注册
>Dcdiag /v /test:RegisterInDns /Dnsdomain:vmtest.com
6：DNS诊断
最简单用法,测试除/DnsResolveExtName之外的六项子测试 >dcdiag /test:dns
基本测试：执行基本 DNS 测试，包括网络连接性、DNS 客户端配置、服务可用性和区域存在性
>dcdiag /test:dns /DnsBasic
测试DnsBasic和转发器
>dcdiag /v /test:dns /dnsForwarders 测试DnsBasic和解析指定的域名 >Dcdiag /v /test:dns /dnsinternetname: www.baidu.com
四：一个完整的DcDiag诊断信息注解
参考链接： http://hi.baidu.com/maxhan/blog/item/783ccafceb979d87b901a0c5.html
五：参考资料 http://technet2.microsoft.com/windowsserver/zh-chs/library/5237db58-a1e8-40cd-ae8a-7f52848a90f22052.mspx?mfr=true |
![clip_image055[2]](http://img1.51cto.com/attachment/201002/3/209800_126518590886Pf.gif "clip_image055[2]"){kind=small}
2008-09-03 20:15:26
标签：
域
操作主机
AD
FSMO
[
推送到技术圈
]
|
版权声明：原创作品，如需转载，请与作者联系。否则将追究法律责任。
|
|
概述
在Win2003多主机复制环境中，任何域控制器理论上都可以更改ActiveDirectory中的任何对象。但实际上并非如此，某些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)
本文分别从以下几个方面深入理解操作主机
・ FSMO操作主机角色功能
・ 查看和更改操作主机角色的方法
・ 操作主机放置优化建议
一：FSMO角色功能
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\<domain
name>目录下，然后通过DFS复制到本域其它DC中。
・ 域主机浏览器，提供通过网上邻居查看域环境中所有主机的功能
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域和信任关系”，右键单击，选择“操作主机”
在打开的窗口中，点击“更改”按钮就可以实现对域命名主机角色进行更改
三：利用复制监视器Replmon查看和检查操作主机角色
复制监视器Replication Monitor(ReplMon)是针对Windows Server的故障查找工具,不但是定位活动目录复制故障强有利的工具，同时也可以使用该工具查看和检查操作主机角色状态。
详细Replmon工具使用方法本文不做过多说明，这里只列出如何使用Replmon工具查看和检查操作主机角色状态。
步骤：选中当前DC，右键单击，选择“Properties”
在弹出窗口中，选择“FSMO Roles”分窗口，出现如下界面：
在该窗口，列出所有的FSMO操作主机，同时通过“Query”按钮，可以检测出当前DC 与FSMO操作主机之间通讯是否正常。
四：使用命令行工具查看和更改操作主机角色
有多个工具可以实现在命令行下查看操作主机角色，下面只列出几种常见方法
注意，下面对应的工具有些需要安装Win2003 Support Tools工具
1：使用Netdom工具查看操作主机角色
Netdom Query FSMO
2：使用Dsquery工具查看操作主机角色
Dsquery Server �CHasfsmo Schema //查看架构主机
Dsquery Server �CHasfsmo Name //查看域 主机
Dsquery Server �CHasfsmo PDC //查看PDC模拟器主机
Dsquery Server �CHasfsmo RID //查看RID主机
Dsquery Server �CHasfsmo Infr //查看基础结构主机
3：使用Ntdsutil工具更改操作主机角色
Ntdsutil工具的功能非常强大，可以进行AD数据库维护，查看和更换操作主机角色以及删除无法通过图形界面删除的DC遗留的元数据。通过Ntdsutil工具不但可以清理无效的DC信息，也可以使用Transfer子命令转移操作主机角色，使用Seize子命令夺取操作主机角色。Ntdsutil具体使用方法请参考KB：
http://support.microsoft.com/kb/255504/
五：操作主机角色放置优化配置建议
默认情况下，架构主机和域命名主机角色是在根域的第一台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：基础架构主机：对于单域环境，基础架构主机实际上不起作用，因为基础架构主机主要作用是对跨域对象引用进行更新，对于单域，不存在跨域对象的更新。基础架构主机对性能和可用性方面的要求较低。
建议将PDC模拟器，RID主机以及基础结构主机放置在一台性能较好的DC中，且尽量不要配置成GC。
|