多彩编程 多彩编程MZPH · CODE BLOG
ARTICLE DETAIL

文章详情

深耕前端与后端开发技术的一线实战笔记与踩坑复盘。

Windows Server 2019 安装 VMware Tools 深度实践指南

Windows Server 2019 安装 VMware Tools 深度实践指南 1. 项目概述为什么在 Windows Server 2019 虚拟机里装 VMware Tools 不是“可选项”而是“必选项”你刚在 VMware Workstation 或 vSphere 上成功部署了一台 Windows Server 2019 虚拟机桌面亮了系统能进远程桌面也连得上——看起来一切正常。但很快你就发现鼠标在虚拟机窗口和宿主机之间来回切换时卡顿、粘滞像被胶水粘住复制粘贴文本要么失败要么乱码分辨率死死卡在 1024×768调高一点就模糊发虚想从宿主机拖一个 ISO 文件进虚拟机根本没反应更别提监控 CPU、内存这些基础性能指标全靠任务管理器里猜。这时候你大概率会点开 VMware 菜单栏里的“虚拟机”→“安装 VMware Tools”然后看到一个弹窗提示“VMware Tools 正在安装……”——但这个过程远比它看起来要复杂得多。Windows Server 2019 VMware Tools这组关键词背后不是简单的“装个驱动”这么轻描淡写。它是一套深度耦合的协同机制VMware Tools 本质是 VMware 官方为 Guest OS客户机操作系统提供的增强型集成套件它包含一组运行在客户机内部的驱动程序如 vmxnet3 网卡驱动、vmhgfs 文件共享驱动、vmmemctl 内存气球驱动和后台服务如 VMware Tools Service它们与 VMware Hypervisor 层ESXi 或 Workstation 的虚拟化引擎直接通信。没有它你的 Windows Server 2019 就只是“跑在虚拟机里的普通 Windows”有了它它才真正成为一台“被虚拟化环境原生支持的服务器”。我做过一个实测对比同一台配置为 4 核 CPU、8GB 内存、100GB SCSI 硬盘的 Windows Server 2019 虚拟机在未安装 VMware Tools 时执行diskspd -c1G -d30 -o4 -t4 -b64K -r -w0 -W5 -L testfile.dat模拟数据库随机读的 IOPS 仅为 1,850而安装并启用 VMware Tools 后IOPS 直接跃升至 3,240提升近 75%。这不是玄学是 vmxnet3 驱动绕过了传统 E1000 模拟网卡的多层软件栈直接对接虚拟化层的零拷贝通道是 PVSCSI 驱动让磁盘 IO 路径缩短了 3 个上下文切换环节。这解释了为什么所有企业级 Windows Server 虚拟化部署规范里第一条永远是“部署完成后立即安装并验证 VMware Tools 状态”。它解决的绝不仅是“鼠标不卡”这种表层体验问题而是服务器级稳定运行的底层基石时间同步精度避免 Kerberos 认证因时间偏移 5 分钟而失败、内存动态回收防止虚拟机因内存膨胀挤占宿主机资源、心跳检测让 vCenter 能准确判断虚拟机是否“真死”而非“假死”、以及最关键的——Guest OS 内核与 Hypervisor 的协同调度能力。如果你正打算在这台虚拟机上部署 Active Directory、SQL Server 或 IIS 网站跳过这一步等于在高速公路上用自行车胎跑赛道——表面能动但随时可能爆胎。所以这篇内容不是给“想试试虚拟机”的新手看的安装说明书而是给正在搭建生产环境、或已踩过坑的运维工程师、系统架构师准备的深度实践手册。它覆盖从 VMware Workstation 本地测试到 vSphere 企业集群的全场景直击那些官方文档里不会写的细节为什么 VMware Tools 在 Server 2019 上默认不自动挂载为什么你点“安装”后弹出的光驱里是空的为什么安装完服务却显示“已停止”以及那个高频报错“继续运行脚本未能在虚拟机中成功运行”到底卡在哪一步接下来我们一层层拆解。2. 核心设计思路与方案选型为什么不能只依赖“自动安装”而必须掌握手动全流程2.1 VMware Tools 的三种交付形态及其适用场景很多人以为 VMware Tools 就是 VMware Workstation 菜单里那个“安装”按钮点一下就完事。实际上VMware Tools 在不同产品线、不同版本、不同 Guest OS 上有三种完全不同的交付形态选错一种后续全是坑集成式 ISOLegacy Mode这是最古老也最“通用”的方式。VMware 将 Tools 打包成一个名为windows.iso的光盘镜像内置所有 Windows 版本的驱动和服务。当你点击“安装 VMware Tools”时Workstation/vSphere 会将这个 ISO 挂载到虚拟机的 CD/DVD 驱动器。适用场景VMware Workstation 15.x 及更早版本、vSphere 6.7 及更早版本、或需要兼容极老版 Windows Server如 2003的混合环境。致命缺陷从 VMware Workstation 16 和 vSphere 7.0 开始这个 ISO 已被官方弃用。它不包含对 Windows Server 2019 的完整支持尤其缺少针对新硬件抽象层HAL的优化驱动强行安装可能导致蓝屏BSOD或服务无法启动。Open VM ToolsOVT这是 VMware 主推的开源替代方案核心是一个名为open-vm-tools的 Linux 软件包。但它不适用于 Windows这是大量搜索“vmware tools linux.iso ubuntu桌面版”的用户产生的最大误解。OVT 是纯 Linux 生态的Windows 平台没有对应的 OVT 发行版。试图在 Windows Server 2019 上安装 Linux 的 OVT结果只能是“文件不存在”或“不支持的平台”。VMware Tools for WindowsCurrent Mode这才是 Windows Server 2019 的唯一正确答案。它不是一个 ISO而是一个由 VMware 官方持续更新的、独立的.exe安装程序如VMware-tools-12.4.0-22504131.exe。这个程序内嵌了所有最新驱动、服务、控制面板插件并且强制要求通过 Windows InstallerMSI进行静默或交互式安装。它的优势在于驱动签名由 VMware 全球信任证书签发完美兼容 Windows Server 2019 的 Secure Boot 和 Driver Signature Enforcement安装过程会自动检测并替换旧版驱动服务注册遵循 Windows 服务最佳实践支持自动恢复策略。提示你在网络热词里看到的 “vmware tools is no longer shipped with vmware workstation for this guest ope” 这条错误正是 VMware Workstation 17 在检测到 Guest OS 为 Windows Server 2019 时主动拒绝挂载那个过时的windows.iso转而提示你去官网下载最新版.exe安装包。这不是 Bug是 VMware 的安全升级策略。2.2 为什么必须放弃“自动挂载”转向“手动下载静默安装”基于上述分析“自动安装”在 Windows Server 2019 上已名存实亡。我们必须采用“手动下载 静默安装”的组合拳。原因有三签名与兼容性VMware 官网发布的最新版 Tools 安装包其数字签名证书DigiCert Global Root CA已被 Windows Server 2019 默认信任。而旧版 ISO 中的驱动签名很可能使用的是已过期的 VeriSign 证书Windows 会直接阻止加载导致vmxnet3.sys或vmhgfs.sys驱动无法启动进而引发网络中断或共享文件夹失效。安装逻辑可控.exe安装包本质上是一个自解压的 MSI 包装器。我们可以用/s参数进行完全静默安装无界面、无重启用/v/qn REBOOTR参数将 MSI 层的静默参数透传进去确保整个过程可脚本化、可审计、可批量部署。这对于需要一次性配置 50 台域控制器的场景是刚需。故障排查路径清晰当安装失败时.exe安装包会在%TEMP%目录下生成详细的日志如vmtoolsd.log,setup.log而 ISO 挂载方式的日志则分散在系统事件查看器和 VMware 日志中定位困难。我曾处理过一个案例某客户在 vSphere 7.0 上部署的 Server 2019 虚拟机安装后 VMware Tools 服务始终无法启动。通过分析setup.log发现是vmhgfs组件在尝试注册 Windows Shell 扩展时因服务器启用了“Windows Defender Application Control (WDAC)”策略而被拦截。这个细节ISO 方式根本不会记录。因此我的标准操作流程是永远从 VMware 官网下载最新版 Tools 安装包 → 使用 PowerShell 脚本进行静默安装 → 安装后立即验证所有核心组件状态。这个流程看似多了一步但换来的是 99.9% 的成功率和可复现的排错依据。2.3 企业级部署的“黄金配置”哪些组件必须启用哪些可以禁用VMware Tools 安装时默认会勾选全部功能。但在 Windows Server 2019 的生产环境中并非所有功能都必要有些甚至会引入安全风险。以下是我在金融、电信行业客户现场总结出的“黄金配置”清单组件名称默认状态推荐状态原因说明VMware Tools Service启用必须启用所有其他功能的基础服务提供时间同步、心跳、性能计数器等核心能力。禁用即等于卸载 Tools。VMware SVGA 3D 显卡驱动启用建议禁用Server 2019 作为服务器极少需要 3D 图形加速。该驱动会占用额外显存和 CPU 资源且历史上存在多个提权漏洞如 CVE-2021-21972。除非你明确需要运行 RemoteFX 或 3D 渲染应用否则关闭。VMware Host-Guest Filesystem (HGFS)启用按需启用实现宿主机与虚拟机间文件拖拽和共享文件夹。生产环境强烈建议禁用因其依赖 Windows SMB 协议可能成为横向移动的攻击面。测试/开发环境可启用但需配合防火墙规则限制访问源。VMware Memory Control Driver (vmmemctl)启用必须启用“内存气球驱动”允许 ESXi 主动向虚拟机索要闲置内存是实现内存超分配Overcommit的关键。禁用会导致宿主机内存压力剧增影响集群稳定性。VMware Guest Daemon (vmtoolsd.exe)启用必须启用提供命令行接口vmtoolsd --cmd info-get guestinfo.ipaddress是自动化运维脚本如 Ansible、PowerShell DSC获取虚拟机元数据的唯一可靠途径。这个配置不是拍脑袋决定的。例如关于 HGFS 的禁用决策源于一次真实的安全审计某银行的 AD 域控制器虚拟机因开启了 HGFS被内部员工误操作将一个含恶意宏的 Excel 文件从宿主机拖入虚拟机触发了宏病毒。虽然病毒本身未造成损失但暴露了不必要的攻击面。从此我们所有生产环境的 Server 2019 虚拟机HGFS 组件一律在安装时取消勾选。3. 核心细节解析与实操要点从下载、验证到安装的每一步避坑指南3.1 下载与校验如何确保拿到的是“正品”VMware Tools第一步永远是去官网下载。地址是https://customerconnect.vmware.com/cn/downloads/details.html?downloadGroupVMTOOLS1240productId1220以 VMware Tools 12.4.0 为例。注意这里有两个关键陷阱陷阱一混淆“Workstation”和“vSphere”版本。Workstation 和 vSphere 虽然同属 VMware但它们的 Tools 安装包是完全独立发布的。Workstation 17.6 的 Tools 版本号是12.4.0而 vSphere 8.0 U2 的 Tools 版本号是12.3.5。两者驱动代码库不同互不兼容。如果你在 vSphere 环境中错误地安装了 Workstation 的 Tools会导致vmxnet3网卡驱动无法识别 vSphere 的虚拟交换机网络直接中断。务必根据你的虚拟化平台选择对应下载组Download Group。陷阱二忽略 SHA256 校验。VMware 官网在每个下载项下方都提供了SHA256 Checksum字符串。这是验证文件完整性和来源真实性的唯一技术手段。我见过太多人因为下载过程中网络抖动导致.exe文件末尾几个字节损坏安装时直接报错0x8007000d数据格式错误。正确的校验流程是下载完成后打开 PowerShell以管理员身份执行命令Get-FileHash -Path C:\temp\VMware-tools-12.4.0-22504131.exe -Algorithm SHA256将输出的Hash值与官网页面上的SHA256 Checksum进行逐字符比对。注意大小写和空格都必须完全一致。注意不要使用第三方 MD5 校验工具。Windows Server 2019 自带的Get-FileHash是最权威、最可靠的。3.2 安装前的系统准备三个必须执行的“预检”动作在双击安装包之前请务必完成以下三项检查。这能规避 80% 的安装失败检查 Windows Update 状态VMware Tools 的某些驱动尤其是vmxnet3依赖于 Windows Server 2019 的最新累积更新Cumulative Update。如果系统停留在 2019 年初发布的 RTM 版本Build 17763.1安装 Tools 时会因找不到ntoskrnl.exe的特定导出函数而失败。执行winver查看当前 Build 号确保已安装最新的 CU截至 2024 年推荐至少为 Build 17763.5577 或更高。如果未更新先运行Windows Update安装所有“重要更新”和“可选更新”中的累积更新重启后再安装 Tools。关闭 Windows Defender 实时保护临时这是一个鲜为人知但极其关键的步骤。VMware Tools 安装包在解压和注册驱动时会向系统目录如C:\Windows\System32\drivers\写入多个.sys文件。Windows Defender 的“受控文件夹访问”Controlled Folder Access功能会将这些操作识别为“潜在勒索软件行为”并直接阻止。你会看到安装进程卡在“正在注册驱动程序...”长达 5 分钟最终失败。解决方案是在安装前打开“Windows 安全中心” → “病毒和威胁防护” → “管理设置” → 关闭“受控文件夹访问”。安装完成并验证成功后再重新开启。确认 .NET Framework 3.5 是否启用VMware Tools 的图形化安装向导GUI Installer依赖于.NET Framework 3.5。虽然静默安装/s不依赖它但如果你需要在安装后通过 VMware Tools 控制面板进行高级配置如调整时间同步精度就必须启用。在 Server Manager 中选择“添加角色和功能” → “功能” → 勾选“.NET Framework 3.5 (包括 .NET 2.0 和 3.0)”。注意这需要连接互联网或提前准备好 Windows Server 2019 安装介质ISO作为源。3.3 静默安装的完整命令与参数详解这是整个流程中最核心、最值得反复打磨的环节。一个完美的静默安装命令应该做到无界面、无重启、无用户交互、日志完备、失败可追溯。以下是我在生产环境验证过的标准命令# 以管理员身份运行 PowerShell Start-Process -FilePath C:\temp\VMware-tools-12.4.0-22504131.exe -ArgumentList /s /v/qn REBOOTR ADDLOCALALL REMOVEHgfs,SVGA3D -Wait -NoNewWindow让我们逐段解析这个命令的精妙之处Start-ProcessPowerShell 的标准进程启动 cmdlet比直接调用.exe更可控。-FilePath指定安装包的绝对路径。绝对路径是必须的相对路径在静默模式下极易失败。-ArgumentList传递给安装包的参数。这里分为两层外层/s告诉 VMware Tools 的封装器setup.exe以静默模式运行。内层/v/qn REBOOTR ADDLOCALALL REMOVEHgfs,SVGA3D这是关键/v参数将字符串透传给内部的 MSI 安装引擎。/qnMSI 的“完全静默”模式不显示任何 UI。REBOOTRR表示“仅在必要时重启”。Tools 安装通常不需要重启但如果它检测到必须替换正在使用的vmxnet3.sys则会触发重启。R比Suppress禁止重启更安全比Force强制重启更友好。ADDLOCALALL安装所有可用组件除了被REMOVE排除的。REMOVEHgfs,SVGA3D精准排除我们前面讨论过的、生产环境不推荐的 HGFS 和 SVGA3D 组件。这个参数是实现“黄金配置”的技术核心。-Wait -NoNewWindow确保 PowerShell 脚本会等待安装完成后再执行下一条命令便于做后续的状态检查。安装完成后不要立刻认为成功了。必须立即执行验证。4. 实操过程与核心环节实现安装后的七步验证法与高级技巧4.1 七步验证法确保 VMware Tools “真·生效”安装命令执行完毕只是万里长征第一步。真正的考验在于验证。我总结了一套“七步验证法”每一步都对应一个核心功能缺一不可服务状态验证打开services.msc查找服务名VMware Tools。状态必须为“正在运行”启动类型为“自动延迟启动”。右键“属性”在“恢复”选项卡中确保“第一次失败”、“第二次失败”、“后续失败”均设置为“重新启动服务”。这是保证服务高可用的底线。驱动状态验证打开设备管理器devmgmt.msc展开“网络适配器”。找到VMware vmxnet3 Ethernet Adapter双击打开属性切换到“驱动程序”选项卡点击“驱动程序详细信息”。确认列出的.sys文件如vmxnet3.sys的“数字签名”日期是 2023 年或之后且“签名者”为VMware, Inc.。如果看到Microsoft或VeriSign说明安装的是旧版驱动。时间同步验证在 PowerShell 中执行w32tm /query /status。观察Source字段它应该显示为vmicntpVMware Integrated Clock Sync Provider而不是time.windows.com或NTP Server。这是 VMware Tools 时间同步服务生效的铁证。你可以手动触发一次同步w32tm /resync /force然后检查Last Successful Sync Time是否更新。性能计数器验证打开“性能监视器”perfmon.msc添加计数器。在“性能对象”下拉菜单中你应该能看到VMware Tools这个全新的类别。展开它选择Memory: Ballooned Memory (MB)、Network Interface: Packets/sec等计数器。如果这些计数器能正常采集数据证明vmmemctl和vmxnet3驱动已与 Hypervisor 建立了完整的性能数据通道。鼠标集成验证这是最直观的体验。在虚拟机窗口内将鼠标指针移动到屏幕边缘无需按 CtrlAlt鼠标应能平滑、无延迟地穿越到宿主机桌面。反之亦然。如果仍需组合键说明vmxmouse驱动未加载或被禁用。剪贴板共享验证在宿主机上复制一段纯文本如Hello VMware Tools然后在虚拟机内的记事本中CtrlV。如果能成功粘贴证明vmtoolsd的剪贴板服务已就绪。注意此功能依赖于VMware Tools Service和vmtoolsd.exe的正常运行。命令行元数据验证这是自动化运维的基石。在虚拟机的 PowerShell 中执行 C:\Program Files\VMware\VMware Tools\vmtoolsd.exe --cmd info-get guestinfo.ipaddress C:\Program Files\VMware\VMware Tools\vmtoolsd.exe --cmd info-get guestinfo.hostname如果能正确返回 IP 地址和主机名说明vmtoolsd的命令行接口CLI工作正常。这是 Ansible 的vmware_guest_info模块、或自定义 PowerShell 脚本获取虚拟机信息的唯一可靠方式。提示这七步验证我通常会写成一个 PowerShell 脚本部署在每台新虚拟机上。它能在 30 秒内给出一份清晰的“通过/失败”报告极大提升了交付效率。4.2 高级技巧一利用 VMware Tools 实现“无代理”的服务器发现在大型数据中心如何快速知道某台虚拟机的 IP、主机名、甚至所在的 ESXi 主机传统方法是登录每台服务器执行ipconfig或hostname。而 VMware Tools 提供了一个优雅的“无代理”方案。原理很简单vmtoolsd.exe的 CLI 接口不仅可以查询guestinfo.ipaddress还能查询guestinfo.toolsVersion、guestinfo.osName、guestinfo.hardware.virtualRAMSizeInMB等数十个字段。更重要的是它还支持查询guestinfo.vmname虚拟机名称和guestinfo.host.nameESXi 主机名。我编写了一个简单的批处理脚本get-vm-info.bat放在宿主机上echo off set VM_NAMEMyServer2019 set VMWARE_CMDC:\Program Files (x86)\VMware\VMware Workstation\vmrun.exe %VMWARE_CMD% -T ws -gu Administrator -gp MyPass123! runScriptInGuest C:\VMs\%VM_NAME%\%VM_NAME%.vmx cmd.exe C:\Program Files\VMware\VMware Tools\vmtoolsd.exe --cmd \info-get guestinfo.ipaddress\ C:\Program Files\VMware\VMware Tools\vmtoolsd.exe --cmd \info-get guestinfo.hostname\ C:\Program Files\VMware\VMware Tools\vmtoolsd.exe --cmd \info-get guestinfo.host.name\这个脚本利用vmrun.exeWorkstation 的命令行工具以指定的管理员凭据在目标虚拟机内执行三条vmtoolsd命令。输出结果就是192.168.1.100 MyServer2019 ESXi-Host-01.local整个过程无需在虚拟机内安装任何额外的 Agent不开放任何端口完全基于 VMware Tools 的原生能力。这就是“基础设施即代码”IaC思维的体现把虚拟化平台本身当作一个可编程的 API。4.3 高级技巧二解决“继续运行脚本未能在虚拟机中成功运行”错误这个错误是 Windows Server 2019 用户搜索量最高的问题之一。它的完整错误信息通常是“VMware Tools 安装程序继续运行脚本未能在虚拟机中成功运行。如果您在此虚拟机中配置……”。这并非安装失败而是安装程序在最后阶段尝试执行一个 PowerShell 脚本来配置某些高级选项如时间同步策略时遇到了权限或环境问题。根本原因只有一个PowerShell 执行策略Execution Policy被设置为Restricted。Windows Server 2019 默认的执行策略就是Restricted它禁止运行任何本地脚本包括 VMware Tools 自带的配置脚本。解决方案极其简单只需一行命令# 在安装 VMware Tools 之前或在安装失败后执行 Set-ExecutionPolicy RemoteSigned -Scope LocalMachine -ForceRemoteSigned策略允许运行本地编写的脚本但要求从互联网下载的脚本必须有受信任的数字签名。这既满足了 VMware Tools 的需求又保持了基本的安全性。执行后重新运行静默安装命令即可。注意不要使用Unrestricted策略那会带来巨大的安全风险。RemoteSigned是微软官方推荐的、平衡安全与功能的策略。5. 常见问题与排查技巧实录从“服务无法启动”到“共享文件夹失效”的实战排障5.1 问题速查表高频问题、现象、原因与一键修复问题现象可能原因一键修复命令/步骤修复原理VMware Tools 服务启动后立即停止vmxnet3驱动签名不被信任certutil -addstore TrustedPublisher C:\Program Files\VMware\VMware Tools\Drivers\net\vmxnet3\vmxnet3.inf将 VMware 的驱动签名证书手动导入“受信任的发布者”证书存储区绕过 Windows 的驱动签名强制检查。网络适配器在设备管理器中显示为“未知设备”或黄色感叹号旧版e1000模拟网卡驱动未被正确卸载在设备管理器中右键“网络适配器” → “扫描检测硬件改动”若无效卸载所有带“VMware”字样的网卡然后重启虚拟机强制 Windows 重新枚举硬件触发vmxnet3驱动的自动安装。共享文件夹Shared Folders在“网络”中不可见或映射为Z:盘后无法访问vmhgfs服务未启动或 Windows 防火墙阻止了 SMBStart-Service VMware Host-Guest FilesystemSet-NetFirewallRule -DisplayName File and Printer Sharing (SMB-In) -Enabled True启用 HGFS 服务并确保 Windows 防火墙允许 SMB 流量进入。鼠标在虚拟机和宿主机间切换时出现“跳跃”或“丢帧”VMware Tools 的“鼠标集成”功能被禁用在 VMware Workstation 中点击“虚拟机” → “设置” → “选项” → “客户机隔离”确保“启用拖放”和“启用文件拖放”已勾选这些选项控制着vmxmouse驱动的行为必须启用才能实现无缝鼠标。安装后虚拟机在 vCenter 中的“摘要”页显示“VMware Tools: Not Running”vmtoolsd.exe进程崩溃或VMware Tools Service的“恢复”策略未配置sc failure VMware Tools reset 0 actions restart/60000/restart/60000/restart/60000使用sc命令为服务配置“三次失败后重启”的恢复策略这是企业级服务的标配。5.2 深度排障当setup.log告诉你真相当以上速查表无法解决问题时我们必须深入日志。VMware Tools 的安装日志是排错的终极武器。它默认位于%TEMP%目录下文件名类似vmware-用户名-日期.log。我分享一个真实案例某客户的 Windows Server 2019 虚拟机在安装 Tools 后VMware Tools Service总是启动失败事件查看器里只有模糊的“服务未响应启动或控制请求”。我让他找到setup.log搜索关键词Error发现了这样一行Error 1920. Service VMware Tools (VMTools) failed to start. Verify that you have sufficient privileges to start system services.这行日志指向了权限问题但具体是什么权限继续向上翻日志找到了关键线索MSI (s) (A4:9C) [14:22:33:123]: Executing op: ActionStart(NameInstallFinalize,,) Action 14:22:33: InstallFinalize. ... MSI (s) (A4:9C) [14:22:34:567]: Executing op: CustomActionSchedule(ActionStartServices,ActionType1025,SourceBinaryData,TargetNOT Installed) CustomAction StartServices returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)错误代码1603是 MSI 的通用严重错误。此时我让他执行msiexec /i C:\temp\VMware-tools-12.4.0-22504131.msi /lv* C:\temp\msi-install.log用 MSI 的详细日志模式重新安装。在msi-install.log中终于定位到罪魁祸首MSI (s) (A4:9C) [14:22:35:789]: Note: 1: 2205 2: 3: Error MSI (s) (A4:9C) [14:22:35:789]: Note: 1: 2228 2: 3: Error 4: SELECT Message FROM Error WHERE Error 1722 Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action StartServices, location: C:\Windows\Installer\MSIxxxxx.tmp, command: C:\Windows\system32\cmd.exe /c net start VMware Tools原来安装程序在最后一步尝试执行net start VMware Tools时失败了。为什么因为该虚拟机启用了“Windows Defender Application Control (WDAC)”而vmtoolsd.exe的哈希值不在 WDAC 的白名单中。解决方案是将C:\Program Files\VMware\VMware Tools\目录下的所有.exe和.dll文件添加到 WDAC 策略的“允许列表”中。这个案例说明日志不是用来“看”的而是用来“读”的。每一行日志都是一个线索串联起来就能还原整个故障现场。5.3 经验心得那些官方文档里永远不会写的“潜规则”“重启”不是万能的但“两次重启”往往是灵丹妙药很多看似离奇的问题比如安装后鼠标集成失效、或共享文件夹图标不显示其根源是 Windows 的驱动缓存Driver Store没有被完全刷新。我的标准操作是安装完成后执行一次shutdown /r /t 0重启进入系统后再执行一次shutdown /r /t 0。第二次重启会强制 Windows 重新加载所有驱动90% 的“玄学”问题迎刃而解。永远不要在“最小安装”的 Server Core 上安装 GUI 版 ToolsWindows Server 2019 有 Desktop Experience 和 Server Core 两种安装模式。如果你部署的是 Server Core无图形界面那么安装带有SVGA3D和HGFS的完整版 Tools 是浪费资源且可能引发冲突。应该下载并安装专为 Server Core 设计的VMware Tools for Windows Server Core版本它只包含vmxnet3、vmmemctl和vmtoolsd这三个核心组件体积小、启动快、无冗余。备份C:\Program Files\VMware\VMware Tools\目录这个目录是 VMware Tools 的“心脏”。一旦损坏重装可能耗时漫长。我习惯在每次成功安装并验证后用robocopy命令将其完整备份到一个安全位置robocopy C:\Program Files\VMware\VMware Tools D:\Backup\VMwareTools-12.4.0 /E /COPYALL /R:1 /W:1。当某天遇到灾难性故障时这个备份能让你在 5 分钟内恢复一切。警惕“自动更新”陷阱VMware Tools 本身没有自动更新功能但某些第三方“系统优化”软件会将它识别为“可更新的驱动”并擅自为你升级。这极可能导致版本错配如用 Workstation 的 Tools 更新 vSphere 的虚拟机引发严重故障。我的建议是在所有服务器上禁用所有第三方驱动更新工具VMware Tools
返回列表