Windows Server 2025

创建时间 2026-11-14 最后修改 2026-11-14

诊断服务器故障时，应把用户症状和发生时间，与相关事件及服务状态对应起来。单个事件 ID 或一份已停止服务清单，不能证明故障原因。修改设置前，应先与正常运行情况比较。

记录症状、时间与近期变更

共享不可访问时，记录客户端、账户、准确路径、错误消息与时间。检查是所有用户还是单个身份受影响，以及同一计算机的其他服务是否也异常。记录近期更新和配置变更，但不要直接认定它们就是原因。在被检查的服务器（例如 FS1）上运行以下 Windows PowerShell 查询，不要误在管理工作站执行：

hostname
Get-Date
Get-TimeZone
Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime

hostname 标识当前控制台所在计算机；Get-Date、Get-TimeZone 帮助解释时钟和时区，LastBootUpTime 表示操作系统最近启动时间。比较多个计算机时，应对齐用户报告与事件的时间，不要先改系统时钟。也要核对每个远程控制台当前选中的计算机。启动时的一次警告，不等于事故时段持续发生的故障。

缩小事件查看器的时间范围

打开 eventvwr.msc，核对树中选定的计算机。根据症状检查“Windows 日志”→“系统”和“应用程序”。
选择日志，筛选事故前后的一段时间。选择相关级别，但不要永久排除信息级事件所提供的上下文。
同时读取提供程序、事件 ID、时间与消息。不同提供程序使用相同编号，含义可能不同；还应打开“详细信息”查看具体数据。
按受影响角色检查“应用程序和服务日志”→“Microsoft”→“Windows”中的相关通道。域名系统（DNS）、组策略 GroupPolicy 和文件共享 SMBServer 是示例，准确通道取决于安装的组件。
比较故障前后的事件，通过操作窗格将相关记录保存为 EVTX，即 Windows 事件日志格式，并保留计算机、提供程序与时间范围。裁剪截图不能替代原始记录。

错误数量本身不能衡量服务影响。信息级事件可能解释启动与变更顺序，即使最初只筛选警告和错误，也应保留其上下文。不要为了让旧提示消失就清除日志，否则会丢失证据而未解决原因。文件访问被拒绝时，可结合SMB 签名与加密故障排查区分权限和安全协商；SMB 是 Server Message Block（服务器消息块）文件共享协议。

使用有明确边界的 PowerShell 查询

以下示例在服务器管理员 Windows PowerShell 中，以设置筛选器时刻向前推一小时为起点，从 System 日志读取最新的最多 50 条严重、错误或警告事件。Get-WinEvent 筛选文档说明了 FilterHashtable。应在查询时限定条件，而不是先读取整台计算机的全部日志：

$eventFilter = @{
    LogName = 'System'
    StartTime = (Get-Date).AddHours(-1)
    Level = 1,2,3
}
Get-WinEvent -FilterHashtable $eventFilter -MaxEvents 50 |
    Select-Object TimeCreated,ProviderName,Id,LevelDisplayName,Message

结果包含时间、提供程序、ID、级别与消息。Level=1,2,3 不含信息级事件；一小时内记录很多时，MaxEvents=50 可能遗漏故障开始阶段。应按事故时间调整筛选表中的 StartTime，需要结束边界时设置 EndTime。“没有匹配事件”不能证明事件服务故障，应与访问被拒绝、日志名称错误区分。保留原始 EVTX 文件；导出文本时保留消息编码和换行，不要仅保存控制台表格截短的内容。

区分服务状态、启动与依赖关系

运行 services.msc，找到具体服务。在属性中检查当前状态、启动类型、登录账户及恢复选项，并记录原值。不要启动所有已停止服务：有些按需或由触发器启动，有些仅在安装特定角色后存在。使用内部服务名称，它可能不同于显示名称。此处 W32Time（Windows 时间服务）仅作为查询示例：

Get-Service -Name W32Time
Get-Service -Name W32Time -RequiredServices
Get-Service -Name W32Time -DependentServices
Get-CimInstance Win32_Service -Filter "Name='W32Time'" | Select-Object Name,State,StartMode,StartName

Win32_Service 类区分 State（当前状态）、StartMode（启动模式）和 StartName（运行服务的账户）。StartName 不是计算机名称，也不显示密码。此处选择的列并未列出延迟启动、触发器及恢复动作的全部设置。判断已停止服务是否应始终运行前，应检查这些细节。W32Time 查询成功，也不能单独证明域的全部时间同步正常。

这些命令只读取 W32Time，不启动或修改服务。RequiredServices 返回 W32Time 所需的服务，DependentServices 返回依赖 W32Time 的服务，方向不同，详见 Get-Service 参考文档。空列表可能是有效结果。比较 Status 与配置查询中的 State；Running 表示服务正在运行，不代表用户实际操作必然成功。

修改启动类型与一次性启动、重启服务不同。服务立即停止时，应将时间与账户、配置、权限和依赖错误对应，不能毫无诊断地反复重启。“恢复”选项卡中的动作可能自动重试，影响观察到的顺序。共用服务账户的密码可能也被其他计算机或任务使用，未经调查就重置可能扩大故障。不要在域环境停止 W32Time，只为演示这些概念。

在针对性变更前保留证据

保存相关日志与服务原配置，包括启动、身份和恢复选项。对外分享前检查内部名称、路径、账户和消息数据；保护原件，另做隐去敏感信息的副本。
说明启动或重启将验证什么假设、影响哪些用户与依赖服务，以及何时可操作。不清楚影响范围或没有恢复途径时，应继续调查再决定是否变更。
只对相关服务执行有依据的变更，并比较同一时段的状态与事件。不要同时修改启动、凭据、依赖关系和访问规则。
从相同客户端、以相同账户重复原操作，例如读取同一个共享文件。仅显示 Running，不能证明该访问已成功。
假设未获证实时，只恢复自己修改并记录的值，再检查回退效果。依据新证据缩小下一步范围，不要把全部选项重置为猜测的默认值。

修改 Windows Remote Management（WinRM，Windows 远程管理）或其他访问服务，可能断开自己的会话。操作前应准备控制台访问和恢复原值的方法。不要从清日志、重启全部服务或重启服务器开始。结束排查的依据是使用同一客户端、账户和路径重复原操作，得到预期结果，并检查相关错误是否继续出现；控制台看起来没有错误并不足够。

Windows Server 2025