ESXi 8.0 部署 Windows 11：vTPM 与 UEFI 完整配置指南

1. 项目概述：为什么在 ESXi 上装 Windows 11 不是“点几下就能好”的事？

我在 Dell R730 服务器上部署 ESXi 8.0 已经三年，期间给客户搭过上百台虚拟机，从 Windows Server 2012 到 Ubuntu 24.04，但真正让我在凌晨两点还盯着控制台反复重试的，只有 Windows 11。不是它难装，而是它“太较真”——微软把 Windows 11 的安装门槛从“能跑起来就行”，直接拉到了“必须符合一套完整可信计算链路”的级别。TPM 2.0、Secure Boot、UEFI 启动、vTPM 虚拟化支持、CPU 微码级兼容性……这些词在物理机上可能只是 BIOS 里勾个选项，但在 ESXi 这种企业级裸金属 Hypervisor 上，它们全变成了一条环环相扣的验证流水线，漏掉任何一环，安装程序就会在“准备就绪”界面卡死，或者弹出那句让人血压飙升的报错：“此电脑无法运行 Windows 11”。

你搜到的那些“VMware 虚拟机安装教程”大多默认你用的是 Workstation 或 Fusion——它们对 Windows 11 的兼容性做了大量用户侧妥协，比如自动注入 vTPM、默认启用 UEFI、甚至悄悄绕过部分 TPM 检查。但 ESXi 不是桌面软件，它是数据中心的操作系统，它的设计哲学是“不替你做决定，只给你最干净、最可控的抽象层”。所以当你在 ESXi 上创建一台新虚拟机，它默认给你的是一个纯白板式的硬件环境：没有 TPM、没有 Secure Boot、甚至没有 UEFI 固件——它连 BIOS 都没给你装，更别说 TPM 芯片了。这就是为什么你下载了官方的 Windows 11 ISO，挂载进去，启动后却看到黑屏、蓝屏、或直接跳过安装界面回到引导菜单。问题不在 ISO，不在你的网络，也不在 ESXi 版本（ESXi 7.0U3 起已原生支持 vTPM，8.0 更是全面强化），而在于你没亲手把那套“Windows 11 认可的硬件信任链”一砖一瓦地砌出来。

我见过太多人卡在第一步：以为只要选了“Windows 11 (64-bit)”作为客户机操作系统类型，ESXi 就会自动搞定一切。事实是，这个下拉菜单只是告诉 ESXi “请按 Windows 11 的硬件规范来初始化虚拟硬件”，但它不会主动帮你开启 vTPM，不会强制你切换到 UEFI，也不会检查你的 CPU 是否支持 VMX/VT-d 和 EPT/NPT。它只是站在门口，等你把所有合规的“入场券”——配置参数、固件选项、虚拟设备——一样不少地递上来。这篇文章，就是一张完整的“入场券清单”，它不讲虚的原理，只告诉你每一步该点哪里、填什么、为什么非得这么填。无论你是刚在闲鱼淘到一台二手 R730 想搭家庭实验室，还是运维着几十台 ESXi 主机的企业管理员，只要你需要在虚拟化环境中稳定、合规、可审计地运行 Windows 11，这篇内容就是你跳过所有弯路的实操手册。它不教你“VMware 下载官网”，因为那是公开信息；它也不解释“TPM 是什么”，因为那属于信息安全基础课；它只聚焦一件事：如何让 Windows 11 安装程序在 ESXi 的虚拟机里，心甘情愿地按下“下一步”。

2. 核心设计思路与方案选型：为什么必须用 vTPM，而不是物理 TPM 或绕过检测？

在动手之前，必须先厘清一个根本性问题：为什么我们不直接用宿主机的物理 TPM 芯片？或者，更简单粗暴一点——为什么不能像网上某些教程说的那样，用reg add命令强行绕过 TPM 检查？这两个看似省事的方案，在 ESXi 环境下不仅无效，而且危险，它们背后是完全不同的安全模型和架构逻辑。

先说物理 TPM。ESXi 是 Type-1 Hypervisor，它直接运行在物理硬件之上，接管了所有底层资源，包括 PCIe 设备。理论上，你可以将宿主机的 TPM 芯片通过 PCI 直通（Passthrough）方式分配给某一台虚拟机。但这条路几乎走不通。首先，绝大多数服务器主板（包括 Dell R730）的 TPM 芯片是 LPC 接口的，而 ESXi 的 PCI 直通功能仅支持 PCIe 设备，LPC 不在支持列表内。其次，即使你有一块 PCIe TPM 卡，直通后，该 TPM 将完全脱离 ESXi 的管理，成为这台虚拟机的独占资源。这意味着，一旦这台 Win11 虚拟机崩溃或被关机，TPM 的状态（如密钥、PCR 值）就永久丢失，下次启动时，BitLocker 加密卷将无法解锁，Windows Hello 的生物识别数据也会失效。更重要的是，ESXi 的核心安全机制——如 Host Client 的证书签名、vCenter 的 TLS 通信——本身也依赖于宿主机的 TPM 来保护其密钥。你把它直通出去，等于拆掉了整个虚拟化平台的信任锚点，这是企业级环境绝对不可接受的风险。

那么，绕过检测呢？网上流传的bcdedit /set {default} testsigning on或修改注册表BypassTPMCheck的方法，本质上是在安装前欺骗 Windows Setup，让它误以为硬件满足要求。这在 Workstation 里或许能糊弄过去，但在 ESXi 上，它会带来更严重的后果。Windows 11 的安全启动链（Secure Boot Chain）是一个深度集成的体系：从 UEFI 固件开始，到 Boot Manager，再到 winload.efi，最后到内核，每一环都由上一环的数字签名进行验证。如果你绕过了 TPM 检查，但没有同时禁用 Secure Boot，那么在系统启动后期，当内核尝试加载受 TPM 保护的驱动（如 BitLocker 的 fvevol.sys）时，它会发现 TPM 并未就位，从而触发内核级的验证失败，导致蓝屏（BSOD）错误代码 0xC0000428。我亲自在 ESXi 8.0 上测试过，这种蓝屏不是安装阶段的报错，而是系统已经写入硬盘、完成首次重启后的致命故障，恢复起来比重装还麻烦。

所以，唯一正解，就是使用 VMware 原生提供的vTPM（Virtual Trusted Platform Module）。vTPM 不是模拟器，也不是软件库，而是一个由 ESXi 内核直接管理的、符合 TPM 2.0 规范的虚拟化设备。它的工作原理是：ESXi 在宿主机内存中为每台启用了 vTPM 的虚拟机分配一块隔离的、加密的内存区域，用于存储 TPM 的状态（如 PCR 寄存器、密钥槽）。所有 TPM 命令（如TPM2_PCRRead,TPM2_CreatePrimary）都由 ESXi 的 vTPM 服务进程在 Ring-0 层直接处理，并将结果返回给虚拟机。这意味着，对 Windows 11 来说，它看到的就是一个真实、可靠、响应迅速的 TPM 2.0 芯片；而对 ESXi 来说，这个芯片的所有状态都被牢牢锁在自己的安全边界内，可以随时备份、迁移、快照，且不会影响宿主机自身的 TPM 功能。vTPM 的优势是碾压性的：它支持完整的 TPM 2.0 命令集，与 Windows 11 的 Device Guard、Credential Guard、BitLocker 完美兼容；它允许你在虚拟机关闭后，依然保留 TPM 状态，实现真正的“关机不丢密钥”；它还能与 vSphere 的加密虚拟机（Encrypted VMs）功能联动，为整个虚拟机磁盘提供双重加密保护。

因此，我们的整个方案设计，就围绕着“如何正确、稳定、可复现地启用并配置 vTPM”这一核心目标展开。它不是一个可选项，而是 Windows 11 在 ESXi 上运行的基石。后续所有的步骤——从虚拟机创建、固件选择、CPU 配置，到安装介质的准备和安装过程中的关键操作——都是为了确保这条信任链能够从虚拟机启动的第一毫秒起，就完整、无中断地建立起来。这不是为了炫技，而是为了让你部署的每一台 Windows 11 虚拟机，都能像物理机一样，通过微软的 Windows Hardware Compatibility Program（WHCP）认证，获得长期、稳定的更新支持，避免未来某次累积更新后突然失联的尴尬。

3. 核心细节解析与实操要点：vTPM 的启用条件、配置陷阱与硬件兼容性深挖

vTPM 看似只是一个勾选框，但它的背后是一整套精密的硬件与软件协同机制。很多用户在 Web Client 里找不到“添加 vTPM 设备”的按钮，或者勾选后保存失败，根本原因往往不是操作失误，而是忽略了三个硬性前置条件。我把它们称为“vTPM 三把锁”，缺一不可，否则你永远打不开那扇门。

3.1 第一把锁：ESXi 版本与许可的硬性门槛

vTPM 功能并非在所有 ESXi 版本中都可用。它最早在ESXi 7.0 Update 3中作为技术预览（Tech Preview）引入，但此时它仅支持“仅限开发和测试”，且存在诸多限制（如不支持快照、不支持 vMotion）。直到ESXi 8.0，vTPM 才成为正式发布（GA）的功能，并被纳入所有付费许可等级。这里有一个极易被忽略的关键点：免费版 ESXi（ESXi Hypervisor）不支持 vTPM。是的，你没看错。VMware 官方明确将 vTPM 列为“Enterprise Plus”许可级别的专属功能。如果你是从官网下载的免费版 ESXi 8.0 ISO 进行安装，那么无论你如何升级、如何配置，Web Client 的虚拟机设置里都不会出现 vTPM 的选项。这是一个许可层面的硬性封锁，而非技术能力的缺失。

解决方案非常直接：你必须拥有一个有效的vSphere Enterprise Plus许可证，并将其成功应用到你的 ESXi 主机上。获取许可证的途径有二：一是购买正版授权；二是利用 VMware 提供的 60 天全功能试用期（Trial License），它包含了 Enterprise Plus 的所有特性，足以支撑你完成部署和验证。在 vSphere Client 中，进入“主机” -> “配置” -> “许可证”，点击“分配许可证”，然后输入你的试用密钥（通常以XXXXX-XXXXX-XXXXX-XXXXX-XXXXX格式呈现）。分配成功后，你会看到主机的许可状态变为“Enterprise Plus”，此时 vTPM 选项才会在虚拟机设置中“显形”。我建议你在部署任何 Windows 11 虚拟机之前，先确认这一步。曾经有个客户，折腾了三天，最后发现他的 R730 上运行的还是免费版 ESXi 6.7，连升级到 8.0 的资格都没有，因为旧版免费许可不支持跨大版本升级。所以，请务必在开始前，打开你的 vSphere Client，确认许可证状态。这不是多此一举，而是避免后续所有努力付诸东流的最关键一步。

3.2 第二把锁：CPU 级别的微码与虚拟化支持

即使你拥有了 Enterprise Plus 许可，vTPM 依然可能无法启用，原因在于你的 CPU。vTPM 的实现严重依赖于 CPU 的硬件辅助虚拟化技术。具体来说，它需要以下三项 CPU 特性同时被启用：

1. Intel VT-x / AMD-V：这是最基本的 CPU 虚拟化指令集，几乎所有现代服务器 CPU 都支持，但必须在 BIOS/UEFI 中手动开启。对于 Dell R730，你需要进入 BIOS（开机按 F2），找到Processor Settings->Intel Virtualization Technology，将其设为Enabled。AMD 平台同理，查找SVM Mode并启用。
2. Intel EPT / AMD RVI (NPT)：这是扩展页表（Extended Page Tables）技术，用于加速虚拟内存地址转换。它对 vTPM 的性能至关重要。在 BIOS 中，它通常与 VT-x 同处一个菜单，名为Intel EPT或Enhanced Intel VT-x，同样必须设为Enabled。
3. Intel TXT / AMD SVM with SEV：这是最关键的第三项。vTPM 的安全根（Root of Trust）需要一个更高权限的 CPU 模式来保证其执行环境不被恶意 hypervisor 代码篡改。Intel 平台需要Trusted Execution Technology (TXT)，而 AMD 平台则需要Secure Encrypted Virtualization (SEV)。遗憾的是，Dell R730 所搭载的 Intel Xeon E5-26xx v3/v4 系列 CPU，不支持 TXT 技术。这是该型号服务器的一个硬件级限制。这意味着，即使你把 BIOS 里所有能开的选项都打开了，R730 也无法原生支持 vTPM。

这个结论可能会让很多 R730 用户感到沮丧，但请别急着放弃。VMware 为这类老平台提供了一个“降级兼容”方案：vTPM 1.2。从 ESXi 8.0 开始，vTPM 支持两种模式：默认的 vTPM 2.0（需要 TXT/SEV）和向后兼容的 vTPM 1.2（仅需 VT-x/EPT）。vTPM 1.2 的功能集略少于 2.0（例如不支持某些高级密钥派生算法），但它完全满足 Windows 11 的最低安装要求，能完美支持 Secure Boot、BitLocker 和 Windows Hello。要启用它，你必须在创建虚拟机时，通过VMX 配置文件进行手动干预。稍后我会在实操环节详细说明这个“隐藏开关”的设置方法。现在，你只需要记住：R730 不是不行，而是需要多走一步，用 vTPM 1.2 这个“老将”来扛起大旗。

3.3 第三把锁：虚拟机固件与硬件版本的精确匹配

这是最容易被忽视，却最常导致安装失败的陷阱。vTPM 不是一个独立的设备，它与虚拟机的固件（Firmware）深度耦合。ESXi 提供两种固件选项：Legacy BIOS 和 UEFI。而 vTPM只能与 UEFI 固件配合工作。如果你在创建虚拟机时，错误地选择了“BIOS”作为固件类型，那么即使你后续在设置中成功添加了 vTPM 设备，Windows 11 的安装程序在启动时，也会因为无法在 BIOS 环境下初始化 TPM 而直接报错退出。

此外，虚拟机的硬件版本（Hardware Version）也必须足够新。vTPM 是在硬件版本 15（对应 ESXi 6.7U3）中首次引入的，但为了获得最佳兼容性和稳定性，强烈推荐使用硬件版本 20（ESXi 8.0）或更高。硬件版本决定了虚拟机所能使用的虚拟硬件集合。低版本的硬件（如 v13）可能缺少对某些 UEFI 安全启动策略的支持，导致 Windows 11 在加载winload.efi时因签名验证失败而蓝屏。

因此，在创建虚拟机时，你必须严格遵循以下顺序：

1. 先选择固件：在“虚拟机选项” -> “固件”中，必须选择UEFI。不要选“自动”，也不要选“BIOS”。
2. 再选择硬件版本：在“虚拟机选项” -> “硬件版本”中，选择Version 20 (ESXi 8.0 and later)。如果你的 ESXi 是 7.0U3，那就选 v19。
3. 最后添加 vTPM：在“虚拟机选项” -> “添加新设备” -> “vTPM”，此时按钮才应是可用的。

提示：如果你已经创建了一个 BIOS 固件的虚拟机，不要试图去修改它的固件类型。ESXi 不允许在已存在的虚拟机上更改固件。唯一的办法是删除该虚拟机（注意：只删虚拟机，不删磁盘文件），然后严格按照上述顺序重新创建。这是一个设计上的硬性限制，没有变通办法。

这三个“锁”，构成了 vTPM 启用的黄金三角。它们不是孤立的，而是相互依赖的。缺少任何一个，你的 Windows 11 安装之旅都会在起点就宣告终结。理解它们，不是为了增加复杂度，而是为了让你在遇到问题时，能精准地定位到是哪一把锁没打开，从而节省数小时的盲目排查时间。

4. 实操过程与核心环节实现：从零开始，手把手搭建一台合规的 Windows 11 虚拟机

现在，我们进入最核心的实操环节。下面的每一步，都是我在 R730 + ESXi 8.0 环境下，经过数十次反复验证后提炼出的“最小可行路径”。它不包含任何花哨的优化，只保留了让 Windows 11 成功安装并稳定运行所必需的、最精简的配置。请务必严格按照顺序执行。

4.1 创建虚拟机：避开所有默认陷阱的“黄金配置”

登录 vSphere Client，进入你的 ESXi 主机，点击“创建新的虚拟机”。

1. 选择创建类型：选择“创建新虚拟机”，不要选“从模板部署”或“克隆”。
2. 命名与位置：为虚拟机起一个有意义的名字，例如WIN11-PROD-01。选择一个合适的存储位置（Datastore）。
3. 兼容性：在“兼容性”下拉菜单中，选择ESXi 8.0 and later。这是确保你能使用最新硬件版本的前提。
4. 客户机操作系统：在“客户机操作系统”中，选择Microsoft Windows->Windows 11 (64-bit)。这一步很重要，它会自动为你预设一些合理的默认值，比如内存大小和 SCSI 控制器类型。
5. CPU 和内存：Windows 11 的最低要求是 2 核 CPU 和 4GB 内存。但为了获得流畅体验，我建议：
   • CPU：2个插槽（Sockets），2个内核（Cores per socket），总计4个逻辑处理器。不要勾选“启用 CPU 热添加”，这在 Windows 11 上可能导致不稳定。
   • 内存：8192MB（8GB）。这是兼顾性能与资源效率的甜点值。
6. 网络：选择一个已配置好的标准交换机（vSwitch）或分布式交换机（vDS）端口组。确保该网络能访问你的 ISO 存储。
7. SCSI 控制器：选择LSI Logic SAS。这是 Windows 11 官方支持的首选控制器，兼容性最好。避免使用PVSCSI，虽然它性能更高，但在安装阶段有时会引发驱动加载问题。
8. 磁盘：创建一个新虚拟磁盘，大小建议120GB。格式选择Thin Provision（精简置备），这样可以节省初始存储空间。重要：在此步骤，不要点击“完成”！

此时，你来到了最关键的“虚拟机选项”页面。这是所有默认配置的“分水岭”。

• 固件：在左侧导航栏，点击“虚拟机选项” -> “固件”。将“固件”下拉菜单从默认的Automatic改为UEFI。这是第一道生死线。
• 硬件版本：在同一页面，找到“硬件版本”，选择Version 20 (ESXi 8.0 and later)。
• 添加 vTPM：点击“虚拟机选项” -> “添加新设备” -> “vTPM”。此时，如果前面的步骤都正确，你应该能看到一个清晰的“vTPM”设备被添加进来。它的状态会显示为“已启用”。

注意：如果你在这里看不到“vTPM”选项，或者点击后提示“此主机不支持 vTPM”，请立即停止，回头检查“核心细节解析”章节中的“三把锁”。90% 的失败都发生在这里。

完成以上所有配置后，点击右下角的“完成”。虚拟机创建完毕，但此时它还处于“已注册”状态，尚未开机。

4.2 关键的 VMX 文件手工编辑：为 R730 注入 vTPM 1.2 支持

对于 Dell R730 这类不支持 TXT 的老平台，仅仅在 UI 里添加 vTPM 是不够的。你必须手动编辑虚拟机的.vmx配置文件，强制指定使用 vTPM 1.2。这是一个必须执行的步骤，否则 Windows 11 安装程序会因找不到兼容的 TPM 而拒绝继续。

1. 在 vSphere Client 中，右键点击你刚刚创建的虚拟机，选择“打开控制台”。

2. 在控制台窗口的顶部菜单栏，点击“文件” -> “下载” -> “下载虚拟机配置文件 (.vmx)”。

3. 将下载的.vmx文件用 Notepad++（或其他纯文本编辑器）打开。

4. 在文件末尾，添加以下三行：

   vtpm.present = "TRUE" vtpm.version = "1.2" firmware = "efi"

   解释：vtpm.present = "TRUE"是显式声明启用 vTPM；vtpm.version = "1.2"是核心指令，它覆盖了 UI 默认的 2.0 版本；firmware = "efi"是双重保险，再次确认固件类型，防止 UI 设置被意外覆盖。

5. 保存文件。

6. 回到 vSphere Client，右键虚拟机，选择“从清单中移除”。注意：这只是从清单中移除，不是删除磁盘！

7. 点击“主机” -> “存储” -> 你的 Datastore，找到该虚拟机的文件夹（通常以虚拟机名命名）。

8. 找到并删除该文件夹下的*.vmx文件（就是你刚刚编辑的那个）。

9. 将你本地编辑并保存好的.vmx文件，拖拽上传到这个文件夹中。

10. 右键该.vmx文件，选择“添加到清单”。虚拟机将重新出现在清单中。

这一步操作看起来繁琐，但它赋予了 R730 运行 Windows 11 的能力。我把它称为“老将的逆袭”。完成之后，你的虚拟机就已经具备了所有硬件层面的合规性。

4.3 准备与挂载 Windows 11 安装介质

现在，我们需要一个“干净”的 Windows 11 ISO。网上流传的所谓“破解版”或“精简版”ISO，往往移除了 TPM 和 Secure Boot 的检查模块，这会导致两个严重后果：一是它无法通过微软的 WHCP 认证，未来更新可能失败；二是它破坏了 Windows 11 的安全根基，使 BitLocker 等功能形同虚设。因此，必须使用微软官方发布的、未经修改的 ISO。

获取方式很简单：

1. 访问微软官方的 Windows 11 下载页面 。
2. 下载“Windows 11 Installation Assistant”工具。
3. 运行该工具，它会自动检测你的环境，并提供一个“创建安装媒体”的选项。选择“USB 闪存驱动器”或“ISO 文件”。强烈推荐选择“ISO 文件”，因为你可以直接将这个 ISO 上传到 ESXi 的 Datastore 中，供虚拟机挂载。

将下载好的Win11_23H2_English_x64.iso（或你选择的版本）上传到 ESXi 的 Datastore。上传完成后，在 vSphere Client 中，右键你的虚拟机，选择“编辑设置”。

• 在“硬件”选项卡下，找到“CD/DVD 驱动器 1”。
• 将“连接”设为已连接和启动时连接。
• 将“设备类型”设为数据存储 ISO 文件。
• 点击“浏览”，找到你刚刚上传的 Windows 11 ISO 文件，并选中它。

4.4 启动安装与关键操作：如何在安装过程中“说服”Windows 11

点击“开机”，虚拟机启动。你会看到熟悉的 UEFI 启动画面，然后进入 Windows 11 安装程序。

1. 语言与区域设置：选择你的偏好，点击“下一步”。
2. 安装类型：点击“现在安装”。
3. 产品密钥：此处可以直接点击“我没有产品密钥”。Windows 11 允许在安装完成后，再通过设置 -> 更新和安全 -> 激活来输入密钥。跳过这一步，可以避免因密钥格式错误导致的安装中断。
4. 选择版本：选择Windows 11 Pro（或你所需的版本），点击“下一步”。
5. 许可条款：勾选“我接受许可条款”，点击“下一步”。

此时，安装程序会进行初步的硬件扫描。如果一切配置正确，你将看到一个绿色的对勾，旁边写着“此电脑可以运行 Windows 11”。这是第一个胜利信号。

6. 安装类型：选择“自定义：仅安装 Windows（高级）”。

7. 分区选择：在磁盘列表中，你会看到一个名为Disk 0的磁盘。不要直接点击“下一步”！这是最关键的一步。Windows 11 的 UEFI 安装要求磁盘必须是 GPT 分区格式，并且需要一个 EFI 系统分区（ESP）。如果直接安装，它会尝试在 MBR 分区上操作，导致失败。

   • 点击Disk 0，然后点击“驱动器选项（高级）”。
   • 你会看到一个未分配的空间。点击“新建”，输入大小（例如500MB），点击“应用”。这会创建一个 EFI 系统分区。
   • 再次点击“新建”，这次输入剩余的全部空间（例如119500），点击“应用”。这会创建主分区（C:）。
   • 此时，你应该看到两个分区：一个是System Reserved（EFI），另一个是Primary Partition（C:）。
   • 选中Primary Partition（即 C: 盘），然后点击“下一步”。

安装程序开始复制文件。这个过程会持续几分钟。期间，虚拟机会自动重启数次。每次重启后，你都需要在 vSphere Client 的控制台中，快速按下ESC键，进入 UEFI 固件设置界面。这是为了确保它始终从 CD/DVD 驱动器启动，而不是从硬盘启动。如果不按 ESC，它可能会跳过安装，直接进入一个空白的 Windows 安装环境。

8. OOBE（开箱即用体验）：当安装完成，进入 OOBE 界面时，你会被要求登录 Microsoft 账户。此时，强烈建议你选择“离线账户”。点击左下角的“我没有 Internet 连接”，然后连续按Shift + F10（或Fn + Shift + F10，取决于你的键盘），打开命令提示符。

   在命令提示符中，依次输入以下命令：

   reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v "DisableWindowsUpdateAccess" /t REG_DWORD /d 0 /f reg add "HKLM\SYSTEM\Setup\Status\ChildCompletion" /v "setup.exe" /t REG_DWORD /d 2 /f exit

   然后，关闭命令提示符，点击“继续使用有限设置”。这会跳过联网和账户绑定，直接进入桌面。这样做是为了避免在首次启动时，系统因网络策略或账户同步问题而卡死。

至此，Windows 11 的安装已经完成。你拥有一台在 ESXi 上原生、合规、可信赖运行的 Windows 11 虚拟机。接下来，就是安装 VMware Tools 和进行最终的优化了。

5. 常见问题与排查技巧实录：那些让我熬夜到凌晨的真实踩坑记录

在无数次部署 Windows 11 的过程中，我总结了一套“问题-现象-根源-解决”的速查表。这些问题，每一个都曾让我在深夜对着控制台抓耳挠腮。我把它们毫无保留地分享出来，希望能帮你避开这些深坑。

除了以上表格中的问题，我还想分享一个独家的、关于性能的避坑技巧。很多人在 R730 上安装完 Windows 11 后，会感觉系统“卡顿”，尤其是在打开设置或运行图形应用时。这并非 CPU 或内存不足，而是显卡驱动的问题。ESXi 默认为虚拟机提供的是VMware SVGA 3D显卡，它是一个通用的、软件渲染为主的虚拟显卡。对于 Windows 11 的现代化 UI（尤其是 Fluent Design 和 Acrylic 效果），它的性能捉襟见肘。

我的解决方案是：在安装完 VMware Tools 后，手动禁用VMware SVGA 3D，并启用Microsoft Basic Display Adapter。听起来很反直觉，对吧？但事实是，Windows 11 自带的“基本显示适配器”驱动，对虚拟化环境的优化反而更好。它放弃了复杂的 3D 渲染，转而专注于高效的 2D 图形合成，这使得整个 UI 流畅度大幅提升。操作方法很简单：在“设备管理器”中，找到“显示适配器”，右键VMware SVGA 3D，选择“禁用设备”。系统会自动回退到基本显示适配器。你可能会看到屏幕闪烁一下，但之后的体验会截然不同。这个技巧，是我从一位在 VMware Labs 工作的朋友那里得到的，它没有写在任何官方文档里，却是提升 R730 上 Windows 11 体验最立竿见影的方法。

最后，我想说的是，部署 Windows 11 到 ESXi，本质上是一场与微软安全策略和 VMware 虚拟化架构的深度对话。它考验的不是你的记忆力，而是你对底层原理的理解和对细节的敬畏。每一次成功的部署，都是对这套复杂系统的一次致敬。当你看到那台运行在 R730 上的 Windows 11 虚拟机，稳定地执行着自动化