单位采用带有域的局域网，域内有一台名为paqserver2的主域控制器，该服务器也是域内唯一一台DC。该服务器同时运行了与AD集成的DNS。
前几天由于打印室的服务器出现了打印机的共享问题，于是我查看了DC的日志，发现一切正常，唯有DNS日志中有如下的警告信息：
事件ID：7062
描述：DNS服务器遇到一个发给自己的数据包 – IP地址10.37.40.100
DNS服务器不应该发给自己数据包。这种情况通常说明有一个配置问题。
……
有可能委任操作正确，但子区域的主要 DNS 有指回该服务器的不正确的 NS 记录。
如果在该服务器缓存这个不正确的 NS 记录，则会导致自送。
如果被发现，子区域 DNS 服务器管理应该删除不正确的 NS 记录。
根据日志提示检查了一下DNS，发现的确有一些NS记录有问题，比如其中显示网内有另外几台 域控制器STJJ-DC、ZFLW、Proxy1…等等，因为这几台机器事实上根本不存在了，于是删掉，(其实这些记录一直存在，只是因为服务正常所以没去管它，正好借这次机会删掉)结果问题没有解决，又在“文件复制服务”日志中出现了文件复制服务的错误提示：
事件ID：13568
描述：文件复制服务检测到副本集 "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" 正处于JRNL_WRAP_ERROR。
副本集名称是 : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
副本根路径是 : "c:\windows\sysvol\domain"
……
设置 "Enable Journal Wrap Automatic Restore" 注册表参数为1将导致下面的恢复步骤将被执行以自动从此错误状态中恢复。
[1] 第一次轮询将在 5 分钟内执行，此计算机将 从副本集中删除。如果您不想等待 5 分钟，那么 运行 "net stop ntfrs" 然后运行 "net start ntfrs" 以重新启动文件复制服务。
[2] 在删除后的轮询中，此计算机会被重新添加到复制集中。此重新添加将会为此复制集触发一个树的完全同步。
注意: 在恢复过程中副本树中的数据可能不可用。如果此错误情况再次发生，您应当重置上述注册表参数为0以阻止自动恢复导致数据意外的不可用。
要更改此注册表参数，运行 regedit。
展开 HKEY_LOCAL_MACHINE。
单击键路径: "System\CurrentControlSet\Services\NtFrs\Parameters"
双击此值名称"Enable Journal Wrap Automatic Restore" 并更新值。
如果此值名称不存在，您可以使用编辑菜单项下的 “新建->DWORD值”功能添加它。
既然删了就删干净一些。(正常域控删除应该通过命令dcromo实现，这些记录显然是之前没有正确进行AD降级造成的残留记录，只好直接删除)
此时打开“Active Directory用户和计算机”控制台，在Domain Controller 里面可以看到若干台主机记录(其中只有paqserver2本身是正确的)，错误记录无法删除，提示“不能删除DSA对象”，但是可以“所有任务-移动” 到普通的Computers组里面。
打开“AD站点和服务”控制台，在“Sites/Default-first-site /Servers”里面同样可以看到这些错误的服务器，但是只有paqserver2和stjj-dc两台机器存在NTDS Settings，在此处其他无效服务器记录可以删除，但stjj-dc依然无法删除，最后用ntdsutil工具(在系统安装盘 support/tools下)删掉了(按网上资料进行的，具体步骤记不清了，同上面的错误同时出现的还有一个与stjj-dc有关的文件复制错误，用 ntdsutil删除后提示消失，但问题仍未解决)。
然后又按照上述日志提示增加了注册表键值Enable Journal Wrap Automatic Restore，并重启了FRS服务，结果问题似乎变得更加严重：“文件复制服务”在FRS服务启动信息出现后，又出现了如下警告提示：
事件ID：13566
描述：File Replication Service正在扫描系统卷上的数据。在此进程完成之前，计算机SV-01不能成为域控制器。系统卷将被共享为SYSVOL。
要检查 SYSVOL 共享，在命令提示下，输入：net share
File Replication Service 完成扫描进程后，SYSVOL 共享会出现。
初始化系统卷要花时间。所花时间基于系统卷上的数据。
而该操作始终无法完成，SYSVOL共享也没有出现，尝试手动共享该目录无效，在Directory Service 日志里面出现如下错误提示：
事件ID：1126
描述：无法与全局编录建立连接
此时发现的问题是客户机无法再加入域，而已加入的机器退出以后也无法再加入，在XP上的提示为“指定的域不存在或者无法联系”，查看详细则显示可能是DNS解析错误。
用nslookup 进行DNS测试，反向解析出错，正向解析没有问题。(因为该DNS是安装AD时系统自动创建的，默认并不需要配置反向搜索区域，所以解析是正常的。事实上 后来手工配置了反向搜索区域后，双向解析都没有问题，而且最初的“发给自己数据包”的警告也消失了，变成了“DNS服务器写入区域DominName的版本12697到文件DominName.dns”的正常信息提示。)
在任何客户机使用 nslookup –type=ns DominName 命令都可以解析出正确的IP，在另外一台服务器上配置了辅助DNS服务器，并配置为“标准辅助区域”亦可以正常与该DNS进行记录的传递，证明DNS服务其实是正常的。
现在回想整个操作过程，在检查并清理NS记录的时候，只有那台名为STJJ-DC的服务器比 较特殊，因为其他几台机器只是作为A记录出现的，只有这一台曾作为DC和GC出现，而这台机器并非一台真正的机器，有可能是域控paqserver2本身 曾经使用过的一个机器名(印象中是这样，否则没有理由解释这台机器的存在，具体事实记不清了)，于是机器名修改造成了一台物理上的服务器逻辑上被识别成两台服务器，并互相进行文件复制服务，而这条NS记录的删除则导致了文件复制服务执行失败，从而导致全局编录的建立失败。
按照这个思路，又在DC上执行了dcdiag，输出结果没有记录下来，但跟该链接提供的情况大致相同，且都显示了如下错误信息：
Starting test: FsmoCheck
Warning: DcGetDcName(GC_SERVER_REQUIRED) call failed, error 1355
A Global Catalog Server could not be located - All GC's are down.
Warning: DcGetDcName(TIME_SERVER) call failed, error 1355
A Time Server could not be located.
The server holding the PDC role is down.
Warning: DcGetDcName(GOOD_TIME_SERVER_PREFERRED) call failed, error 1355
A Good Time Server could not be located.
Warning: DcGetDcName(KDC_REQUIRED) call failed, error 1355
A KDC could not be located - All the KDCs are down.
......................... DESIGN.ARK failed test FsmoCheck
在微软知识库中搜索其中反复出现的error 1355，找到下面的文章：
症状
从备份, 还原域控制器后 Sysvol 和 Netlogon 共享可能已丢失。并且Dcdiag.exe 没有通过 FsmoCheck 测试并生成以下错误信息：
警告: DcGetDcName(GC_SERVER_REQUIRED) 调用失败, 1355 错误
问题通常发生只如果域控制器， 还原是域, 中只域控制器或如果已还(例如,) 来复制实验室中生产环境还原所有域中域控制器。
原因
因为文件复制服务 (FRS) 无法找到有效的复制伙伴来同步 Sysvol 副本集发生此行为。
与预料的情况相同，于是按其提供的解决方案执行了如下操作：
解决方案
您必须将一个域控制器为正在对 Sysvol 副本集授权。 如果所有域中域控制器已经还原, 选择在主域控制器仿真器灵活单主机操作 (FSMO) 角色承担:
1. 停止文件复制服务在域控制器上。
2. 启动注册表编辑器 (Regedt 32 .exe)。
3. 找到并单击注册表中以下项下 BurFlags 值：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/ Restore\Process
4. 单击DWORD在 "编辑" 菜单, 单击Hex，键入D4 ,然后单击 确定 。
5. 退出注册表编辑器。
6. 移动 PreExisting 夹出的数据。
7. 重新启动文件复制服务。
注意 此注册表值标记作为对整个副本集授权 FRS 副本。 设置此值仅一个副本, 上和仅要解决此特定问题。 如果配置多个副本作为权威, 冲突和冲突可能出现在副本集中。
所有其他域控制器上, 一个域控制器上设置 D4 注册表设置时， 必须设置 D2 注册表设置。 有关其他信息, 请单击下列文章编号以查看 Microsoft 知识库中相应：
操作完成后重启FRS服务，FRS顺利执行完成，并在文件复制服务日志中记录了如下信息：
文件复制服务不再阻止计算机 PAQSERVER2 成为 域控制器。系统卷已成功 初始化 ,而且 Netlogon 服务已经收到信息表明系统卷已经准备好共享为 SYSVOL。
Directory Services日志里面显示如下信息：
AD找到了以下全局目录
AD服务终于恢复正常，亦可以成功将客户机加入域，本以为结束了，但是查看应用程序日志里面却出现了如下两条错误信息：
事件 ID: 1000
描述:Windows不能为GPO访问文件gpt.ini。此文件必须位于 < >。()。组策略处理被放弃。
事件 ID: 1000
描述:Windows 无法查询组策略对象列表。描述发生这个故障原因的消息是由这个策略引擎记录的。
关于这个问题在微软知识库中查找了以下两篇文章：
http://support.microsoft.com/kb/887303/zh-cn —— 应用组策略导致运行 Windows Server 2003、Windows XP 或 Windows 2000 的计算机上发生 Userenv 错误和事件
原因：如果您将不适当的权限分配给 %SystemRoot%\Winnt\Sysvol 文件夹或将不适当的组分配给 Bypass Traverse Checking User Rights Assignment(跳过遍历检查用户权利指派)，可能会发生此问题。另外，如果 sysvol 共享权限限制过多，也可能会发生此问题。
想到之前的sysvol文件夹是手动共享的，并且6. 移动 PreExisting 夹出的数据。(系统中并没有该文件夹，但是存在名为NtFrw_PreExisting__See_Eventlog的文件夹，于是把它修改了)于是按文 章提供的解决方法进行了如下操作：
1.设置文件夹安全权限。请按照下列步骤操作：
a. 在Windows资源管理器中，右键单击 %SystemRoot%\Winnt\Sysvol 文件夹，然后单击属性。
b. 在安全性选项卡上，清除“允许从父系来的继承权限传播到这个对象”复选框，然后确保安全设置与下列设置匹配：
管理员：完全控制
经身份验证的用户：读取、读取和执行、列出文件夹内容
创建者所有者：没有选中项
服务器操作员：读取、读取和执行、列出文件夹内容
系统：完全控制
c. 单击确定。
d. 右键单击 %SystemRoot%\Winnt\Sysvol\Sysvol 文件夹，然后单击属性。
e. 在安全性选项卡上，选中“允许从父系来的继承权限传播到这个对象”复选框，然后单击确定。
f. 右键单击 %SystemRoot%\Winnt\Sysvol\Sysvol\domain:文件夹，然后单击属性。
g. 在安全性选项卡上，选中“允许从父系来的继承权限传播到这个对象”复选框，然后单击确定。
h. 右键单击 %SystemRoot%\Winnt\Sysvol\Sysvol\domain\Policies 文件夹，然后单击属性。
i. 在安全性选项卡上，清除“允许从父系来的继承权限传播到这个对象”复选框，然后确保安全设置与下列设置匹配：
管理员：完全控制
经身份验证的用户：读取、读取和执行、列出文件夹内容
创建者所有者：没有选中项
组策略创建者所有者：读取、读取和执行、列出文件夹内容、修改、写入
服务器操作员：读取、读取和执行、列出文件夹内容
系统：完全控制
j. 单击确定。
k. 对于位于 %SystemRoot%\Winnt\Sysvol\Sysvol\domain\Policies 文件夹中的文件或文件夹，分别右键单击这些文件或文件夹，然后单击属性。在安全性选项卡上，选中“允许从父系来的继承权限传播到这个对象”复选框，然后单 击确定。
2. 打开“Active Directory 用户和计算机”：单击开始，单击程序，然后单击管理工具。
3. 展开“Active Directory 用户和计算机”，然后展开域名。
4. 右键单击域控制器，然后单击属性。
5. 在组策略选项卡上，单击“默认域控制器策略”，然后单击编辑。
运行到第五步时，点击编辑后出现“无法打开组策略，可能是没有权限”的对话框，回头重新检查 权限设置没有问题，于是将NtFrw_PreExisting__See_Eventlog文件夹下的文件恢复回去，继而检查了DFS服务、运行net time \\(domain controller name) /set /y使时钟时间与域控同步、文件和打印共享，均没有问题，但错误依然出现，最后重新检查日志，注意到此文件必须位于< >。()。的奇怪提示，于是跟知识库文章中对照发现这里的路径应该是%SystemRoot%\Winnt\Sysvol\Sysvol \domain\Policies，而这台机器domain文件夹下面并没policies文件夹，只有一个名为NtFrw_PreExisting__See_Eventlog的文件夹，而该文件夹下面则有一个名为Policies的文件夹。于是把这个Policies手动复制到了domain文件夹下，错误居然停止了，并出现如下信息提示：
ID：1704
描述：组策略对象中的安全策略被成功应用
组策略亦可以正常编辑，于是继续完成配置如下：
6. 展开下面的文件夹：
计算机配置 - Windows 设置 - 安全设置 - 本地策略
7. 单击用户权限分配，然后双击“跳过遍历检查”。应该出现下列默认设置：
经身份验证的用户
所有人
管理员
如果没有出现，而您又需要添加这些组，请单击添加，然后单击浏览。
8. 在命令提示符下，键入：
secedit /refreshpolicy machine_policy /enforce (因为显示正常，这一步跳过)
9. 请验证 sysvol 共享权限设置是否正确，如下所示：
管理员 = 完全控制
经身份验证的用户 = 完全控制
所有人 = 读取
至此，所有错误均已消失，服务恢复正常，故障修复完毕。
后记：因为之前并未深入学习过Windows的活动目录，所以在排查简单错误的时候导致了更严重的错误发生，并且在后继的错误修复过程中亦有尝试或者冒险的成分在里面，最后虽然成功修复，但过程很不专业。
这一过程的收获是修正了本单位原来域中元素混乱的局面，清除了许多之前残留的错误记录，并对活动目录有了一次较深入的接触。对应用于活动目录的一些术语和工具的使用也有了初步的了解。
最后的感觉是，Microsoft的东西 很多很复杂，坏了通常都能够解决，但是不知道的话找到这个机关则很不容易。希望有机会能系统的学习一下，毕竟在一般层次的服务应用中，Windows还是占很重要的位置的
相关资源：dns查询/响应实例pcap包_DNS查询请求与响应-其它其他资源-CSDN文库
————————————————
版权声明：本文为CSDN博主「贾温悦」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_34603528/article/details/113544876
支付宝微信扫一扫，打赏作者吧～本文链接：https://www.kinber.cn/post/2651.html 转载需授权！
推荐本站淘宝优惠价购买喜欢的宝贝:
您阅读本篇文章共花了： 
