企业官网建设流程全解析

简介：这份资源面向在 Win10 系统下使用 VMware 运行 Ubuntu 等虚拟机的用户，尤其是关闭 Hyper-V 后仍被 Device/Credential Guard 兼容性提示拦住、无法启动虚拟机的场景。它基于 Windows Defender Device Guard 与 Credential Guard 硬件就绪检测工具，提供一键禁用 Credential Guard 的脚本方案，适合具备基本命令行操作能力、希望快速排除虚拟化冲突的开发者与运维人员。压缩包共 6 个文件，约 32KB，以 ps1 脚本为核心执行入口，辅以 p7b 策略文件、xml 配置模板和 txt 说明文档，分别承担策略定义、配置参考与使用指引，体积轻量、结构清晰。目前已有 3195 人学习下载，说明该问题在 Win10 与 VMware 组合中较为普遍。读者可借助脚本的 -Disable -AutoReboot 参数完成禁用并自动重启，省去手动逐项排查的麻烦，同时通过随附的说明与策略文件理解 Credential Guard 的启用逻辑，为后续恢复或同类虚拟化兼容问题提供可复用的排错思路。

1. 从一台 Win10 虚拟机里的 Credential Guard 报错说起

上周帮同事在一台 Win10 虚拟机上排查一个环境检测脚本跑不起来的问题，脚本一启动就卡在Credential Guard检测环节，日志里反复刷LsaSrv相关告警。折腾半天才发现，问题不在脚本本身，而是这台虚拟机从模板克隆出来时，Credential Guard 的注册表状态和虚拟化平台的安全特性没对齐——宿主机开了基于虚拟化的安全，客户机里却残留着半套配置。这类“环境看着正常、检测就是不过”的坑，在 Win10 + VMware 的组合里特别常见，尤其是做安全基线核查、合规检测、镜像封装的同学，几乎都会撞上一次。

dgreadiness_v3.6.zip就是冲着这个场景来的：它是一套用于检测和调整 Windows 设备 Credential Guard 就绪状态的脚本工具集，解压后直接跑，不需要额外装运行时。装不好会怎样？轻则检测结果误报、脚本中途退出，重则把客户机的 LSA 配置改乱，开机进不了系统。这篇笔记按“先列环境、再解压、再配参数、最后验证”的顺序走一遍，适合刚接手 Win10 虚拟机基线核查的新手，也适合想搞清楚每个开关到底改了什么的熟手。

2. 装前把环境列清：Win10 版本、VMware 与 PowerShell 三件套

2.1 Win10 版本与 Credential Guard 的对应关系

Credential Guard 不是所有 Win10 版本都能开。企业版和教育版从 1607 起支持，专业版要到 1903 之后才有部分能力，家庭版基本别想。我一般先让同事在客户机里跑一条命令确认版本，而不是凭印象：

# 查看当前系统版本与 SKU，确认是否具备 Credential Guard 能力 Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, OsHardwareAbstractionLayer

WindowsProductName里出现 Enterprise 或 Education 才算稳；OsBuildNumber低于 14393 的直接放弃，脚本里的很多注册表路径对不上。OsHardwareAbstractionLayer这一项容易被忽略，它反映的是虚拟化层版本，VMware 客户机里如果这一项异常，后面检测会误判为“硬件不支持”。

2.2 VMware 侧的三个开关

在 VMware Workstation 或 ESXi 里跑 Win10，Credential Guard 依赖虚拟化平台暴露的几项能力。常见做法是进虚拟机设置，确认这几项：

这里有个血泪经验：从模板克隆的虚拟机，安全启动状态经常是“继承但未生效”，界面上显示已启用，客户机里Confirm-SecureBootUEFI却返回 False。遇到这种情况别急着重装，先把虚拟机完全关机（不是重启），再改设置，改完再开机，否则改动不落地。

2.3 PowerShell 执行策略与管理员权限

dgreadiness_v3.6.zip里的脚本是 PowerShell 写的，默认执行策略是 Restricted 的机器上直接双击会被拦。我一般用管理员身份开 PowerShell，先看一眼当前策略：

# 查看当前会话与机器级执行策略 Get-ExecutionPolicy -List

如果LocalMachine是 Restricted，临时放开当前进程即可，不要图省事改成 Unrestricted 全局放开：

# 仅对当前 PowerShell 进程放开，关闭窗口即失效 Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force

-Scope Process是关键，它只影响当前窗口，不会在机器上留后门。很多教程让你直接Set-ExecutionPolicy Unrestricted，在合规环境里这是要被审计挑出来的。

3. 解压与目录结构：dgreadiness_v3.6 里到底有什么

3.1 解压位置的选择

压缩包不要解压到C:\Program Files或带空格的路径下，脚本里有几处相对路径拼接对空格处理不干净，路径带空格时会出现“找不到模块”的报错。我一般固定放C:\Tools\dgreadiness_v3.6，短路径、无空格、无中文。解压后先列一下目录：

# 列出解压后的文件结构，确认脚本与模块齐全 Get-ChildItem -Path C:\Tools\dgreadiness_v3.6 -Recurse | Select-Object FullName, Length

正常应该能看到主检测脚本、一个Modules或类似名字的子目录，以及若干.ps1、.psd1、.psm1文件。如果解压后只有孤零零一个脚本、没有模块目录，多半是解压工具把嵌套目录拍平了，换 7-Zip 重新解压，别用系统自带解压。

3.2 先读脚本头部的参数声明

动手跑之前，我习惯先看主脚本开头的param块，搞清楚它接受哪些开关，比盲跑再猜参数高效得多：

# 查看主脚本的参数声明部分，了解可用开关 Get-Content C:\Tools\dgreadiness_v3.6\*.ps1 -TotalCount 60 | Select-String -Pattern "param|\[Parameter|\[switch|\[string"

这一步能直接看出脚本支持的是“只检测”还是“检测并修复”，有没有-Force、-WhatIf这类开关。有-WhatIf的一定先用它跑一遍，看清楚它打算改哪些注册表键，再决定要不要真改。没有-WhatIf的，就先在快照上跑，这是虚拟机环境最大的后悔药。

3.3 模块加载失败的预处理

如果脚本依赖自定义模块，直接跑可能报Import-Module : 未能加载文件或程序集。常见原因是模块目录没在PSModulePath里。临时把工具目录加进去：

# 将工具目录临时加入模块搜索路径，仅当前会话有效 $env:PSModulePath = "C:\Tools\dgreadiness_v3.6;" + $env:PSModulePath # 验证模块能否被识别 Get-Module -ListAvailable | Where-Object { $_.Path -like "*dgreadiness*" }

$env:PSModulePath的拼接顺序有讲究，工具目录要放最前面，否则同名模块可能被系统里的旧版本抢先加载。这一步做完再跑主脚本，模块加载类报错基本能消掉大半。

4. 配置与运行：检测模式、修复模式与参数取舍

4.1 先跑只读检测，拿到基线

任何会改注册表的工具，第一步永远是只读跑一遍。假设主脚本叫DGReadiness_Tool.ps1（以实际解压出的文件名为准），检测模式一般不带修复开关：

# 以只读方式运行检测，输出当前 Credential Guard 就绪状态 .\DGReadiness_Tool.ps1 -ReadOnly

如果脚本没有-ReadOnly这个开关，就看param块里默认行为是不是只检测。跑完重点看三类输出：VBS（基于虚拟化的安全）是否运行、Credential Guard 是否配置、LSA 保护是否启用。这三项任意一项为否，后面的修复才有意义；三项全绿还报错，问题多半在检测逻辑和系统版本的匹配上，不在配置本身。

4.2 修复模式的参数怎么选

修复模式通常会动注册表和启动配置，参数取舍直接决定改完能不能开机。我一般按这个顺序来：

# 启用 Credential Guard 相关配置，具体开关以脚本 param 声明为准 .\DGReadiness_Tool.ps1 -Enable -Force

-Enable是方向，-Force是跳过交互确认。这里要注意：如果脚本同时提供“仅配置不重启”和“配置并重启”两个开关，虚拟机里优先选不自动重启的那个，改完自己手动重启，方便在重启前打个快照。自动重启的开关在批量环境里省事，在单机排错时反而是坑——重启失败你连改之前的现场都没了。

4.3 注册表改动的核对方法

脚本跑完，别急着信它的“成功”提示，自己核一遍关键键值：

# 核对 Credential Guard 与 LSA 保护相关注册表项 $paths = @( "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa", "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" ) foreach ($p in $paths) { Get-ItemProperty -Path $p -ErrorAction SilentlyContinue | Select-Object PSPath, LsaCfgFlags, EnableVirtualizationBasedSecurity, RequirePlatformSecurityFeatures }

LsaCfgFlags为 1 表示启用但不开 UEFI 锁，为 2 表示启用并加锁，0 是关闭。EnableVirtualizationBasedSecurity为 1 才说明 VBS 真的开了。这两个值对不上，说明脚本只改了一半，常见于权限不足或组策略覆盖。组策略优先级高于注册表，如果机器加入了域，先确认没有域策略把这些键锁死，否则改完重启又被刷回去。

4.4 快照与回滚的节奏

虚拟机环境最大的优势就是快照，我一般按“改前一个、改后一个”的节奏打：

# 以命令行方式为当前虚拟机打快照（VMware 环境示例，名称按实际替换） vmrun snapshot "C:\VMs\Win10-Base\Win10-Base.vmx" "before-dgreadiness"

vmrun的路径和虚拟机名按实际替换，快照名用英文、无空格。改完配置、验证通过后再打一个after-dgreadiness，以后环境再出问题，能快速回到“已知可用”的状态。没有vmrun的用图形界面打也一样，关键是养成习惯，别在裸机上直接改。

5. 避坑与排查：五条踩过的坑

5.1 现象：脚本报“访问被拒绝”，明明已是管理员

原因多半是 PowerShell 窗口不是“以管理员身份运行”开的，而是普通窗口里runas提权不彻底，或者 UAC 虚拟化把写操作重定向了。解决：关掉当前窗口，右键 PowerShell 选“以管理员身份运行”，再确认whoami /groups里有 High 完整性级别。别在普通窗口里反复重试，浪费时间。

5.2 现象：检测全绿，但重启后 Credential Guard 又变回未启用

原因是组策略或镜像里的默认配置在开机时覆盖了注册表。解决：先跑gpresult /h report.html看有没有相关策略下发，有域策略的找策略管理员确认；没有域的检查本地安全策略里“基于虚拟化的安全”相关项。注册表改完不重启就验证，看到的往往是假象。

5.3 现象：虚拟机克隆后脚本报“硬件不支持 VBS”

原因是克隆时虚拟化引擎开关没跟着走，或者宿主机不支持嵌套虚拟化。解决：完全关机后检查虚拟机设置的虚拟化引擎选项，宿主机 BIOS 里 VT-x/AMD-V 要开。嵌套虚拟化场景下，这一项在部分平台上默认关闭，需要手动勾选。

5.4 现象：模块加载报“无法识别术语”

原因是PSModulePath没包含工具目录，或者模块文件被杀软隔离。解决：按 3.3 的方法临时加路径，再Get-Module -ListAvailable确认模块可见；被杀软隔离的，把工具目录加进白名单后重新解压，别从隔离区直接恢复，文件可能已损坏。

5.5 现象：修复后开机蓝屏或登录异常

原因是 LSA 保护配置与系统版本不匹配，或安全启动链路被破坏。解决：进安全模式或挂载虚拟磁盘回滚注册表，最省事的是直接回滚到改前快照。这也是为什么 4.4 的快照节奏不能省——蓝屏之后再想“早知道”，就只剩重装一条路。

6. 装完怎么验证：三条命令确认真的跑通

验证不是看脚本最后打印的“完成”，而是自己独立确认三层状态。第一层，系统层面 VBS 是否运行：

# 确认基于虚拟化的安全是否处于运行状态 Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object VirtualizationBasedSecurityStatus, SecurityServicesRunning

VirtualizationBasedSecurityStatus为 2 表示运行中，SecurityServicesRunning里出现 1 表示 Credential Guard 在跑。第二层，注册表层面配置是否落地，用 4.3 那段脚本再核一遍LsaCfgFlags和EnableVirtualizationBasedSecurity。第三层，实际行为验证：注销再登录一次，看事件查看器里LsaSrv和DeviceGuard相关日志有没有新的错误，登录过程是否正常。

三层都对上，才算真跑通。我一般还会把这三条命令的输出存一份到工具目录下，命名带日期，方便下次对比：

# 将验证结果落盘，便于版本间对比 $out = "C:\Tools\dgreadiness_v3.6\verify-$(Get-Date -Format yyyyMMdd-HHmm).txt" Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Out-File -FilePath $out

从那以后我每次在虚拟机里跑这类会改 LSA 配置的工具，都强制走一遍“快照 → 只读检测 → 修复 → 三层验证”的流程，哪怕只是帮同事看一眼，也不跳过。环境这东西，省下的每一步后面都会以另一种方式还回来。希望帮到你。

本文还有配套的精品资源，点击获取