Windows登录性能因素
当查找登录性能问题的原因时，考虑大量因素很重要。一些因素包括：
- 域控制器太接近用户
- 网络连接与可用的带宽
- 数据中心上的硬件资源（x64 vs.x86、内存等）
- 应用于用户和计算机的组策略（GPO，会直接影响带宽）数量
- 用户和计算机所在安全组的数量（也直接影响带宽）
- 需要额外处理时间的GPO包含设置，如：环回处理、WMI过滤器和ACL过滤
- 繁重的载入域控制器由以下因素造成：需要认证的应用、来自用户脚本或应用的无效LDAP查询、宿主其他应用，如Exchange、IIS、SQLServer等的数据中心
- 客户端配置：内存、磁盘、处理器等、网络接口（10个、100或1000个）、到站点的合适子网映射和DNS配置
定义范围
为了定义问题的实际范围，我通常花时间询问简单的问题。这需要一些精力，因为这些问题通常由抱怨问题的用户定义。下面是需要询问的重要问题：
- 这些问题定义为单个站点、安全组、OU、部门、客户端的类型（笔记本还是桌面）还是操作系统？
- 问题在每天某个时刻发生吗？
- 当你在办公室或者跨VPN连接就发生问题吗？
- 描述症状：延迟每次发生在某个点吗？（例如发生在登录屏幕的“NetworkSettings”上）、在登录页面之前还是之后发生？
- 什么时候开始发生的？
工具和数据收集
我使用一些基本的工具收集数据。对于性能问题，我喜欢广撒网，收集所有能收集的信息。如下面例子：
在客户端和他们的验证数据中心运行微软产品支持报道（MPSreports）。这是个常用的工具，收集所有事件日志、MSINFO32、NetDiag、PConfig、驱动与hotfixes等的数据。Hewlett-Packard自身也有叫做HPSReports的版本，在我看来，它比微软的工具更高级，如果运行在数据中心上，可以收集具体的ActiveDirectory数据。它也收集与硬件相关的多余信息，甚至不是HP的硬件也可以收集。
在客户端，使用Microsoft KBarticle221833为Winlogon系统进程设置冗长的登录。这将在%Systemroot%DebugUserModeUserenv.log文件里提供精确的细节。注意，这个日志不包括数据日期，因此你必须：
- 从客户端删除现有的userenv.log
- 启动verbose登录为每KB 221833
- 注销、登录并保存userenv.log到新地点，以在登录期间限制数据收集
注意，userenv.log在下面的GPO和配置文件进程很精确，并且通常你能明显看见哪里发生了登陆延迟。
启用NetLogon登录。Netlogon日志位于%systemroot%debug，如果没有启用登录就是空的。例如，它会显示子网里的哪个客户端没有映射到站点。这会导致客户端在数据中心之外验证，需要的登录时间比预想的长。
运行来自Sysinternals的ProcessMonitor。在启用启动日志上的Help部分查看细节。你能在缓慢启动期间捕获进程信息查看哪个处理器在影响性能。
解决客户端登录缓慢的其他技巧
你还能查看下面的一些事情，看是否由已知的问题导致登录性能。
首先，在客户端上检查GPResult.exe和LOGONSERVER环境变量，MPSreports和HPSReports将为已登录的用户收集GPResult，它们不收集指向验证数据中心的LOGONSERVER变量。这很重要，因为每次用户登录，都会下载GPO到客户端。SYSVOL（包含GPO）是DFS根，不服从客户端站点警告。相反，它以随机命令收集数据中心（宿主SYVOLDFS根），然后可以从列表里的第一个数据中心下载GPO。
我遇到过这样的情况，在主服务站点的客户端将跨过缓慢的WAN连接到数据中心外，以获得GPO，导致了非常缓慢的登录时间。由于这可能在每个登录上发生，所以这个问题是间歇性的。
为下载GPO的数据中心检查GPResult，并查看GPO是否来自数据中心外面。同样，比较LOGONSERVER变量，查看客户端是否在数据中心外验证。使用已知的缓慢或繁忙连接，登录延迟能解释为“通常”行为。
另一个好测试是使用网络启动安全模式，查看是否发生延迟。如果没有，那么进行NetStart并列出所有启动的服务。然后以正常模式启动并运行NetStart，再次列出所有服务。这个不同就能证明是哪个服务有嫌疑，一次消除一个能帮助你识别问题。你也能尝试禁止启动时开始的应用，查看该应用是否是原因所在。交流QQ:3002073997