活动目录的建设3

十五、活动目录的排错

­

    一般来说，活动目录的错误有5%左右是网络有故障，最可能的是网络可靠性不高，例如掉包，一般测试的时候通，可是实际应用的时候又发现不是那么一回事，这样的网络故障烦人，所以一定先排除网络方面的原因。然后，有10%左右是管理员由于不能正确理解AD的结构而造成的错误，这时候最好检查信任关系。还有30%以上的故障是DNS的故障，剩下的比例分别是数据库复制故障和操作主机带来的故障，还有就是~~搞不明白的故障。

我们分别对这些故障进行分析，以及给出解决方案。

首先我们在排除故障的时候要查看活动目录的日志，如果你有把握（经验十足）也不用看日志。底层日志默认并没有打开，先修改注册表得到底层日志记录。

HKEY_LOCAL_MacHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics，里面的值有20多个，每个代表要记录的一项。建议值是0~3，越大收集的越多，记录出来的日志也越大。当然不是你的每个客户都有这种记录的习惯。

认识一下工具

我们平时排错，在基础阶段用到的工具有

Netdiag dcdiag netdom三个

Netdiag监测网络功能是否正常，可以帮助分析DNS等故障

dcdiag分析DC状态，针对DC特定的功能测试

netdom管理和检查信任关系，确认数据库复制是否正常

通常先检查网络故障（我前边也说了）

Netdiag /v 详细输出

如果嫌不够，可以加/all，netdiag /all这样就可以了

但是cmd里面你看到的是卷啊卷的一直卷上去的那样，实在难看，你可以把这个东西输出到文本文件netdiag /all >路径*.txt，这样就存在文本文件里面了，你可以在里面分析，方便的多。

我们要看的东西是，每块测试后边是否是PASS，不是PASS的看错误去，这样就能找到哪里的网络错误。

当然排除网络错误还要看防火墙等设置，自己考虑一下

用netdom，比图形界面来的快的多

Netdom query dc

Dcdiag，测试的是本地计算机

Dcdiag /c开启所有的测试

Dcdiag /a整个站点内DC的诊断分析

Dcdiag /e整个森林DC诊断分析

一般dcdiag在用的时候也转存到文本里，因为这样方便查看。

如果你感觉dcdiag的输出不详细

你可以去查日志

如果dcdiag都找不到错误，就有点晕了，证明故障不是很容易找，也就是有点复杂。

常见的故障如下

DNS/复制故障/操作主机故障

DNS故障

DNS服务器在AD中，除了提供名称格式的支持服务，一般的名称到IP地址的查询外（A记录），最重要的作用是记录DC与GC的相关信息，并向客户端提供这些重要信息

DC名在DNS上注册，注册的记录不仅仅包括A记录，而且包括相应的SRV记录

客户端需要查询这些记录，才能找到DC，并完成用户登录、AD查询等工作

AD的正常工作，依赖于DNS服务的正确配置和正常工作

这里，复习一下DNS在AD中的工作

略

介绍一个最重要的区域

_msdcs 区域

_msdcs区域中已含所有DC的SRV

AD森林的根与中的_msdcs区域中还额外包含森林中所有GC的记录

_msdcs区域的作用是为了定位DC和GC，如果该区域不存在或记录不正确，AD会出现故障

2000和2003有点不一样，2000里面_msdcs在开始建立的区域下边，2003的是独立区域，在开始区域里面建个区域做委派。要注意！

验证DNS问题

使用nslookup来验证DNS记录是否完整

如果DNS记录缺失，通过以下方法进行修复：刷新netloGon服务，方法不用教了吧

注意DNS配置要求：允许动态更新

区域名称和AD域名相一致，DNS服务器本身需要配置DNS域名后缀等

刷新netlogon服务有点不好的地方，要断开服务，这样客户机不能连接到DC，影响正常工作，当然，你域中有多台DC，就没有这个问题了。如果你安装了support的东西，你这样

Nltest.ext /dsregdns，就可以重建DNS区域。如果还不行，你需要找到system32\config\netlogon.dns全部复制到system32\dns下的相应区域文件里面（当然是普通主区域，如果是AD的，你那个DNS文件没用）

涉及到多台DNS服务器时，建议在每台DNS上安装AD，因为DNS区域配置为AD集成时与AD一起复制，情况会比普通的好一些。

­

[url]Http://www.microsoft.com/technet/prodtechnol/windowsserver2003/zh-chs/library/ServerHelp/a1b7ce04-708b-4145-830a-cadfc003acd3.mspx?mfr=true[/url]

­

­

复制故障

DC和DC之间，存在两种复制

目录服务复制（数据库）

FRS（sysvol）

通常关注目录服务复制，不过sysvol的脚本也不可以忽略

一些故障

拒绝访问

由于存在DNS查找故障，DSA操作无法继续

操作被排除或者没有显示任何复制链接

复制访问被拒绝或者正在删除名称上下文

站点之间存在重复的连接对象

多个DC中所应用的组策略不一致

目录服务应为太忙而无法完成操作

解决复制问题用到的工具

1、 图形界面replmon，功能，检查AD复制，图形化显示复制拓扑，强制复制

2、命令行的 repadmin，功能，诊断DC间复制故障，确认复制伙伴，确认AD对象复制来源，强制复制

DC间的FRS

日常管理课程已经讲了，回去翻笔记去

命令行排错工具

NTFRSUTL，功能 检查文件复制服务状态，检查复制日程安排，强制轮询，检查复制集

DSASTAT，检查目录服务状态

通常，系统KCC会尽量生成一个圈的复制拓扑

你可以在连接上执行强制复制。当然连接的双方都要复制，才叫同步~~如果你单方向呵呵。

用replmon可以干什么？自己去翻书，第八章复制讲的有，虽然那破书的错字多的跟啥似的，但是这点写的不错，不过少写东西了，所以显示不出来拓扑，你要先生成才能显示~~看不懂英语？去iciba。在生成复制拓扑的同时，也强制建立了复制通道（有时候虽然有连接但是通道不通）。

你还能干什么？去拓扑里面看属性，还能看到FSMO的显示~~这是我们一般用到的，其他的你去翻译一下就能看懂

  Replmon可以看出来，谁和谁在复制，可以看出来复制对象的USN从而看出来哪出现问题，可以看出来复制的错误。

Dsastat –s|dc|dc

对比多台DC的状态

复制的故障，如果解决不了（太麻烦）你考虑重装比较好。

安全问题，不要关掉一些好的服务和共享，例如admin$不要关掉，不然你的复制怎么行！

­

十六、活动目录案例

­

在森林根域PDC模拟器中，W32Time错误，2003里这个问题较少，因为2003默认与微软的时间服务器联系，如何排除这个W32time报警？

解答：在根域PDC模拟器配置外部时间源net time /setsntp：时间服务器 如：net time /setsntp:hnwenda.com等待客户机自动进行时钟或手动运行

Net stop W32time

W32time -once

Net Start W32time

在XP和2003上需要W32time /resync

需要在防火墙上允许PDC访问时间服务器，开启UDP123端口（简称时间协议）

以下情景：用户登录访问服务器时，经常出现“由于时间差异，访问拒绝”。

考虑：时间源不统一、防火墙、打补丁（文档830092）DC之间始终不能超过30分钟

知识：Kerberos协议

所用计算机（包括客户机和服务器、操作系统为Windows2000以上）全自动将根域PDC模拟器作为时间服务器，W32time访问按照一定的周期进行始终校正：从计算机启动开始，尝试以45分钟作为时间源，联系时间服务器，进行时钟同步。如果同步成功，以8小时为间隔，进行同步验证；如果同步失败，开始尝试进行时钟同步。为保证时间服务器正常工作，在根域PDC模拟器上建议设置外部时间源，指向公网上的时间服务器，在其他计算机上确保windows time服务正常启动。

某个客户报告说，客户端计算机启动缓慢，出现“正在配置网络连接”提示时，会有长时间的停留。初步怀疑DNS、客户端地址配置错误，发现配置没问题。虽然客户端计算机配置正确的DNS服务器地址，但在同时作为DC的DNS服务器上，发现没有相应DNS记录。客户使用了samedomain形式的域名，一般域名.com形式，一般表现在NT4.0管理升级。

故障原因：windows2000/2003/XP不在顶级域下注册DNS记录

解决方法：1、修改注册表

          2、使用组策略

在客户现场临时使用了手动加载netlogon.dns文件的方法netlogn.dns是安装DC后应该在DNS里注册的记录

修改注册表

Windows 2000 SP4/xp

HKEY_LOCAL\MACHINE\SYSTEM\CARRENT CONROL SET \SERVERS\DNSCACHE\

PARAMETERS

条目：update Toplevel Domainzones

类型：DWORO

值：1

HKEY_LOCAL\MACHINE\SYSTEM\CARRENT CONROL SET \SERVERS\NETLOGON\

PARAMETERS

条目：ALLOWSSING LET BALE DOMAIN

类型：DWORO

值：1

Windows server 2003

HKEY_LOCAL\MACHINE\SOFTWARE\POLICIES\MICROSOFT\WINDOWS\NT\DNSCLIENT

条目：update toplevel domain zones

类型：DWORO

值：1

HKEY_LOCAL\MACHINE\SYSTEM\CARRENT CONROL SET \SERVERS\DNSCACHE\

PARAMETERS

条目：ALLOWSSING LET BALE DOMAIN

类型：DWORO

值：1

也可以配置组策略

XP、2003

本地计算机、管理模板、网络、更新顶级域区域，启用手工加载，netlogon.dns记事本打开，放入DNS相应区域下DNS文件，做这个操作停掉DNS，不停也可以效果可能不好，此操作要在普通主要区域下做，不能在AD集成区域，事实上只有把所有DC上的都复制过来才能让用户找到所用资源，在此只是紧急情况下的临时方法。

某客户对网络结构进行了调整，以提高安全性。将所有服务器移动到同一个子网，并使用硬件防火墙在服务子网和客户端计算机所有在子网之间进行地址转换（NAT）两台windows2000DC被移动到服务器子网，所有客户端计算机位于另外子网。客户端计算机可以访问DC的共享文件夹，DNS服务但是客户端计算机无法登录域

问题原因：

    防火墙只是转换了IP包头中的地址，没有转换netbois数据包头中的源IP地址

    数据报的用途

    查找登录服务器

    发送请求

    进行域同步

浏览服务工作组、域宣告

浏览服务器存在和选择包

Net send /d<domain>“message”

需要确认防火墙支持NetbiOS数据包转换

某用户在注销时，后面提示域网络上的某个共享文件夹进行同步，但是实际上该文件夹并没有开启文件缓存功能，同时也没有任何登录和注销脚本与此相关。用户担心这是安全问题，但是经过检查发现该文件夹下存放了所用用户的Application Date 目录 ，应该是文件夹重定向策略引起的，但是检查所用目前策略对象，没有发现相应设置的策略对象。

解答：使用GPMC进行分析，确认是管理人员曾经的测试引起的，在组策略对象中重定向Application Date目录到用户本地计算机从而解决该问题。用户在登录一次，注销一次，问题解决。

某些组策略把GPO删除掉，这个动作不会被还原，而是在删除要复原，然后删除。