概述：
在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 站点和服务”管理单元查看全局编录服务器，将“全局编录”复选框选中即可。
注意：设置完成后，并不代表当前的全局编录服务器已经提升完成，因为全局编录服务器中包含有多个域的所有对象，需要时间来进行全局编录数据库同步。
五：验证全局编录服务器的提升
通过提升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工具查看GC数据
全局编录服务器并不是一个独立的实体，域控制器也没有单独为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中。