☰

组策略和网络的网络登录问题

tag-icon • tag-icon windows-7 networking domain group-policy wmi
组策略和网络的网络登录问题

我非常需要您的帮助和援助。

我们的 Windows 7 Enterprise 系统登录和启动存在问题。校园内大约 20 多栋建筑中安装了 3000 多台 Windows 台式机。校园内几乎每台计算机都存在我将要描述的问题。我花了一个多月的时间仔细查看 Windows Performance Analyzer（一款出色的产品）中的 etl 文件和数十万个事件日志。今天我来找您，感到很惭愧，因为我无法解决这个问题。

问题很简单，我们的登录时间非常长。首次登录的平均时间大约为 2-10 分钟，具体取决于所安装的软件。所有计算机都是 Windows 7，最老的计算机已有 5 年历史。各种计算机的启动时间从良好（1-2 分钟）到非常糟糕（5-60 分钟）不等。我们的第二次登录时间从 30 秒到 4 分钟不等。

我们网络上的每台计算机之间都有千兆连接。我们有 5 个域控制器，它们也兼作 DNS 服务器。

最初的测试让我们相信这是一个软件问题。因此我花了几天时间测试机器，结果却发现 xperfview 的 etl 文件结果不一致。校园内的每一台计算机都存在不同的软件问题，但似乎没有一个问题会干扰登录，只会影响启动。

因此我开始查看我们的组策略并找到了一些非常有趣的事件 ID。

组策略 1129：由于缺少与域控制器的网络连接，组策略处理失败。

组策略 1055：组策略处理失败。Windows 无法解析计算机名称。这可能是由以下一个或多个原因造成的：a) 当前域控制器上的名称解析失败。b) Active Directory 复制延迟（在另一个域控制器上创建的帐户尚未复制到当前域控制器）。

NETLOGON 5719：由于以下原因，此计算机无法与域 OURDOMAIN 中的域控制器建立安全会话：当前没有可用的登录服务器来处理登录请求。这可能会导致身份验证问题。请确保此计算机已连接到网络。如果问题仍然存在，请联系您的域管理员。E1kexpress 27：Intel®82567LM-3 千兆网络连接 – 网络链接已断开。

NetBT 4300 – 无法创建驱动程序。

WMI 10 - 由于错误 0x80041003，无法在命名空间“//./root/CIMV2”中重新激活查询为“SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA "Win32_Processor" AND TargetInstance.LoadPercentage > 99”的事件筛选器。在问题得到解决之前，无法通过此筛选器传递事件。

通过时间戳，可以或多或少看出网络可能是问题所在。

1:25:57 - 组策略正在尝试发现域控制器信息

1:25:57 - 网络链接已断开

1:25:58 - 由于缺少与域控制器的网络连接，组策略处理失败。这可能是暂时的情况。一旦计算机连接到域控制器并且组策略已成功处理，就会生成一条成功消息。如果您几个小时内没有看到成功消息，请联系您的管理员。

1:25:58 - 进行 LDAP 调用以连接并绑定到活动目录。DC1.ourdomain.edu

1:25:58 – 0 毫秒后呼叫失败。

1:25:58——强制重新发现域控制器详细信息。

1:25:58 - 组策略未能在 1030 毫秒内发现域控制器

1:25:58 — 计算机 OURDOMAIN\%name%$ 的定期策略处理在 1 秒内失败。

1:25:59 - 已建立 1Gbps 全双工网络链路

1:26:00-网络连接已断开

1:26:02 - 由于发现错误，NtpClient 无法设置域对等体以用作时间源。NtpClient 将在 3473457 分钟后重试，然后将重试间隔加倍。

1:26:05 - 已建立 1Gbps 全双工网络链路

1:26:08 — 由于所有配置的 DNS 服务器均未响应，因此名称 %Name% 的名称解析超时。

1:26:10 – TCP/IP NetBIOS Helper 服务进入运行状态。

1:26:11 - 时间提供商 NtpClient 当前正在 dc4.ourdomain.edu 接收有效时间数据

1:26:14 – 客户体验改进计划的用户登录通知

1:26:15 — 组策略收到来自 Winlogon 的针对会话 1 的登录通知。

1:26:15 – 进行 LDAP 调用以连接并绑定到 Active Directory。dc4.ourdomain.edu

1:26:18 - 连接并绑定到 Active Directory 的 LDAP 调用已完成。dc4。ourdomain.edu。调用在 2309 毫秒内完成。

1:26:18 – 组策略在 2918 毫秒内成功发现域控制器。

1:26:18 - 计算机详细信息：计算机角色：2 网络名称：（空白）

1:26:18 - 连接并绑定到 Active Directory 的 LDAP 调用已完成。dc4.ourdomain.edu。调用在 2309 毫秒内完成。

1:26:18 – 组策略在 2918 毫秒内成功发现域控制器。

1:26:19 - WinHTTP Web Proxy Auto-Discovery Service 服务进入运行状态。

1:26:46 – 网络连接服务进入运行状态。

1:27:10 – 检索账户信息

1:27:10 – 获取账户信息的系统调用完成。

1:27:10 - 由于计算机 OURDOMAIN\%name%$ 的网络状态发生变化，开始策略处理

1:27:10 – 检测到网络状态变化

1:27:10——进行系统调用以获取帐户信息。

1:27:11 – 进行 LDAP 调用以连接并绑定到 Active Directory。dc4.ourdomain.edu

1:27:13 - 计算机详细信息：计算机角色：2 网络名称：ourdomain.edu（现在不为空白）

1:27:13 – 组策略在 2886 毫秒内成功发现域控制器。

1:27:13 — 连接并绑定到 Active Directory 的 LDAP 调用已完成。dc4.ourdomain.edu 该调用在 2371 毫秒内完成。

1:27:15 – 其中一个连接的估计网络带宽：0 kbps。

1:27:15 – 其中一个连接的估计网络带宽：8545 kbps。

1:27:15 - 检测到快速链接。估计带宽为 8545 kbps。慢速链接阈值为 500 kbps。

1:27:17 – Powershell – 引擎状态从可用更改为已停止。

1:27:20 – 4539 毫秒内完成组策略本地用户和组扩展处理。

1:27:25 – 5210 毫秒内完成组策略计划任务扩展处理。

1:27:27 – 1529 毫秒内完成组策略注册表扩展处理。

1:27:27 — 由于计算机 OURDOMAIN\%name%$ 的网络状态改变，策略处理在 16 秒内完成。

1:27:27 – 计算机的组策略设置已成功处理。自上次成功处理组策略以来未检测到任何更改。

任何帮助都将不胜感激。请询问任何相关信息，我们将尽快提供。

答案1

一些随机想法：

  1. 在每个 DC 上执行 DCDIAG 并解决问题。

  2. 检查 DNS。在 MMC 工具中打开“高级功能”，然后进入以下位置：

    \正向查找区域\<域>\_msdcs

  3. 检查是否列出了每个 AD 站点。检查非站点特定分支中所有 DC 是否出现在 _tcp 和 _udp 叶区域中（如果有意义的话）

  4. 如果有必要，强制 DC 使用以下方式在 DNS 中重新注册其 SRV 记录nltest /dsregdns

  5. 检查 DHCP，确保选项 006（DNS 服务器）设置为指向至少两个 DNS 服务器 (DC)。检查选项 015（域名）是否已设置。

  6. 检查 AD 复制（尽管 DCDIAG 会发现这一点），使用repadmin/replsummary从 DC

  7. 检查您的客户是否知道 DCs 在哪里使用nltest /dclist:<域>

  8. 检查您的客户是否知道他们正在使用哪个 AD 站点nltest /dsgetsite。如果这里有任何问题，请检查子网定义Active Directory 站点和服务。

  9. 检查您的 FMSO 是否全部运行netdom 查询 fsmo

  10. 检查您的 DC 是否都具有一致的时间（它们应该都与 PDC 仿真器同步）。检查您的 PDC 仿真器是否具有正确的时间。

  11. 检查您的客户端是否可以持续 ping 您的 DC

如果我想到别的，我会修改...

答案2

我的看法是 NETLOGON 5719 是问题的根源。看看这个： http://blogs.technet.com/b/instan/archive/2008/09/18/netlogon-5719-and-the-disappearing-domain.aspx

尤其是这一行：

如果您在启动时只看到 Netlogon 5719，那么当 Netlogon 启动时，机器连接到交换机的端口可能尚未完全启动。

这表明 http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10553-12.html

答案3

我建议设置（或确保）您的活动目录站点设置正确。（http://technet.microsoft.com/en-us/library/cc782048(v=ws.10).aspx）另外，看看您是否可以在客户端和服务器上使用 nslookup 查找您的域。这听起来确实像是 DNS 问题。

答案4

假设您的 DNS 和域控制器正在正确复制，并且它们具有域控制器的正确条目，那么这听起来就像当您没有本地 AD 集成 DNS 服务器作为客户端上的第一个 DNS 条目时发生的情况。

相关内容