EC2 Windows 域控升级 PV、ENA 与 NVMe 驱动的安全流程

旧 Windows Server 域控制器从早期 EC2 虚拟化栈迁移到 Nitro 平台时，通常要处理 PV、ENA 和 NVMe 驱动。普通成员服务器驱动失败可以换卷救援，但域控制器还涉及 AD DS、SYSVOL、FSMO、DSRM 和 System State，不能只把它当成一次设备驱动安装。

下面是一套面向双域控的变更流程。命令中的主机名、卷和区域均为示例，执行前必须结合 Windows 版本、实例代际和 AWS 当前驱动包验证。

变更原则

• 一次只操作一台 DC，另一台必须保持健康。
• 先把 FSMO 转移到不参与本轮变更的 DC。
• 先验证 AD、DNS、SYSVOL 和复制，再处理驱动。
• 先安装目标平台需要的 ENA/NVMe 驱动，再切换实例类型。
• 保留 AMI/EBS 快照和 System State，但不要把快照当成唯一 AD 恢复方案。
• 明确 DSRM 密码和 EC2 Serial Console/卷离线修复路径。

变更前健康检查

在两台域控上分别运行：

dcdiag /e /c /v /f:C:\Temp\dcdiag-before.txt
repadmin /replsummary
repadmin /showrepl * /csv > C:\Temp\repl-before.csv
net share

确认 SYSVOL、NETLOGON 共享存在，事件日志没有未处理的 AD DS、DNS、DFSR 或磁盘错误。

记录实例和驱动：

Get-CimInstance Win32_ComputerSystem | Select-Object Manufacturer,Model
Get-CimInstance Win32_PnPSignedDriver |
  Where-Object {$_.DeviceName -match 'Amazon|ENA|NVMe|Xen'} |
  Select-Object DeviceName,DriverVersion,DriverDate

转移 FSMO 并确认 DSRM

把角色转移到健康的另一台 DC：

Move-ADDirectoryServerOperationMasterRole `
  -Identity 'DC2' `
  -OperationMasterRole 0,1,2,3,4
netdom query fsmo

确认或重置本机 DSRM 密码：

ntdsutil
set dsrm password
reset password on server null
quit
quit

DSRM 使用本地恢复账户，不等于域管理员密码。凭据应进入安全的密码管理流程，不能记录在脚本或变更单明文中。

备份

至少准备三层：

1. EC2 AMI 或所有相关 EBS 卷快照；
2. Windows Server Backup 的 System State；
3. 已验证健康的另一台可写域控。

System State 示例：

wbadmin start systemstatebackup `
  -backuptarget:E: -quiet
wbadmin get versions -backuptarget:E:

备份盘不要与系统盘使用同一故障域作为唯一副本。快照恢复域控时还要考虑 VM-Generation ID 和 AD 支持边界，不能简单克隆后同时上线。

准备驱动

驱动包应来自 AWS 官方分发位置，并校验数字签名和哈希。先在与生产系统相同的克隆实例上验证安装、重启和卸载路径。

ENA 与 NVMe 可以先预安装，让 Windows 在迁移到 Nitro 后能够识别网络和系统卷。安装后检查驱动仓库和设备状态：

pnputil /enum-drivers | Select-String -Pattern 'Amazon|ENA|NVMe' -Context 0,5
Get-PnpDevice -PresentOnly | Where-Object Status -ne 'OK'

旧 PV 驱动的升级或卸载可能需要 DSRM，尤其是域控上存在过滤驱动、旧 Xen 组件或安装器明确要求时。不要在不知道恢复入口的情况下强行卸载当前存储驱动。

推荐变更顺序

第一台域控

1. 确认 FSMO 已转移；
2. 确认复制、DNS、SYSVOL 正常；
3. 完成 System State、AMI/EBS 备份；
4. 预安装目标 ENA/NVMe 驱动；
5. 按 AWS 对该 Windows 版本的说明升级 PV 组件；
6. 关机并调整实例类型或迁移平台；
7. 启动后验证磁盘、网络、时间同步和 AD；
8. 观察一段时间后才处理第二台 DC。

第二台域控

第一台完全恢复并通过复制测试后，再重复相同步骤。不要同时把两台 DC 置于 DSRM、关机或驱动未验证状态。

启动后验证

操作系统层：

Get-Disk
Get-NetAdapter
Get-NetIPConfiguration
Get-PnpDevice -PresentOnly | Where-Object Status -ne 'OK'

AWS 驱动层：

Get-CimInstance Win32_PnPSignedDriver |
  Where-Object {$_.DeviceName -match 'Amazon Elastic Network|AWS NVMe'} |
  Select-Object DeviceName,DriverVersion,DriverDate

AD 层：

dcdiag /test:dns /v
repadmin /replsummary
repadmin /syncall /AdeP
nltest /dsregdns
net share

还应确认 CloudWatch/SSM、Windows 时间源、业务端口、事件日志和重启后的持续稳定性。驱动显示“安装成功”并不代表域控变更验收完成。

故障恢复

Windows 能进入 DSRM

• 回滚最近安装的驱动或组件；
• 查看 SetupAPI、System 和 Directory Service 日志；
• 确认启动类型、存储设备和网卡驱动；
• 修复后先以正常模式启动单台 DC，再验证复制。

Windows 完全无法启动

• 停止实例，避免反复启动扩大问题；
• 把根卷挂载到同可用区的救援实例；
• 保留故障卷副本后再离线修复驱动和注册表；
• 必要时从变更前 AMI/快照恢复；
• 恢复域控时遵守 AD DS 支持的虚拟化恢复流程。

网络驱动失败

如果系统启动但 ENA 不工作，可以通过 Serial Console 或离线卷修复，确认驱动已进入 Driver Store，并检查 ENA 支持、设备状态和实例属性。不要因为 RDP 不通就立即判定 AD 数据损坏。

总结

域控制器驱动升级的核心不是安装命令，而是缩小故障域：FSMO 先转移、两台 DC 分批、目标驱动先预装、三层备份、逐层验证。把 PV、ENA、NVMe 变更纳入 AD 的恢复设计后，即使驱动或实例平台切换失败，也仍有明确且可演练的返回路径。