VMware Tools on Windows Server Core

原文：VMware Tools on Windows Server Core — theDXT (Daniel Keer)

I’m a fan of using Microsoft Windows Server Core for as many things as possible when it makes sense. In this post, I’ll cover step-by-step how to install VMware Tools on Windows Server Core via the GUI and PowerShell.

Server Core is a smaller attack surface, a smaller patch payload, less rebooting, and a machine that does one job and does it well. The trade-off is that every graphical installer you have ever leaned on becomes an extra step, and VMware Tools is the first one most people hit. The good news is that the installer is a standard Windows Installer package, which means everything it does interactively can also be done silently — and that makes it a perfect fit for Server Core, where PowerShell is the primary interface anyway.

Why Install VMware Tools at All

VMware Tools is not a nicety on a Server Core guest; it is close to mandatory for a production virtual machine. Installing it gives you:

• Storage and network drivers. The paravirtualised SCSI controller (PVSCSI or the LSI Logic SAS emulation) and the vmxnet3 network adapter perform dramatically better than the fallback emulated devices. Without Tools, a Server Core VM on a modern vSphere host is leaving a large amount of I/O performance on the table.
• Quiesced snapshots. Filesystem-consistent snapshots and quiesced backups require the Tools VSS provider. Without it, backups and snapshots are crash-consistent at best, which is a meaningful difference when you are recovering a database server.
• Graceful shutdown and restart from vCenter. Without Tools, a shutdown request from the vSphere client is a hard power-off, which is exactly the situation you do not want on a domain controller or a file server.
• Guest heartbeat and reporting. The host learns that the guest is actually running, which is what allows HA to distinguish a hung VM from a healthy one, and what populates the guest IP address in vCenter.
• Time synchronisation with the host, which matters on any guest that cannot reach a reliable NTP source.
• Guest operations and scripting. Copying files into or out of the guest without network access, and running commands via the API, both depend on the Tools daemon.

In short, if you have a Server Core VM on ESXi, install Tools before you do anything else with it.

Prerequisites

• A Windows Server Core guest — Server 2016 through 2025, on any edition — running on ESXi or managed by vCenter.
• Local administrator rights on the guest.
• The ability to mount the Tools ISO from the host, or a copy of the ISO already on the guest.
• A note of which drive letter the mounted ISO received. This is the single most common trip-up on Server Core, because there is no Explorer to look at.

The GUI Way

• From ESXi or vCenter mount VMware tools to the VM.
• Login to the Windows Server Core VM.
• Change to the D drive (or whichever drive your disk drive is on your install)
• Enter the following command to being the install .\setup64.exe

.\setup64.exe

Sometimes the VMware tools install screen hides behind the command line window.

• Click Next

• Select Typical and click Next.

• Click Install.

• Wait for the installation to finish.

• Click Finish.

• Click Yes to reboot.

That covers how to install VMware Tools via the GUI on Windows Server Core. What if you wanted to take it further and do it with PowerShell only?

Before you leave this section, note where the ISO landed. If the D drive is not the mounted Tools disc, use Get-Volume to see every volume and its label — the Tools ISO is labelled VMware Tools, which makes it easy to identify. On a guest with several attached disks this saves a confused minute or two.

The PowerShell Way

• From ESXi or vCenter mount VMware tools to to the VM.
• Login to the Windows Server Core VM.
• In PowerShell run the following command Start-Process D:\setup64.exe -Wait -ArgumentList "/s", "/v", "/qn", "REBOOT=R" -WindowStyle Hidden

Start-Process D:\setup64.exe -Wait -ArgumentList "/s", "/v", "/qn", "REBOOT=R" -WindowStyle Hidden

The parameters we used are:

• -wait tells PowerShell to wait for the installation to complete before considering the installation to be done. This is a nice trick to slow down PowerShell and force it to wait for installation or uninstall to complete before moving on to the next item.
• /s tells the install to be silent.
• /v tells the install to accept more parameters.
• /qn tells it to be quiet and display no UI.
• REBOOT=R tells it not to reboot.

That’s all it takes.

If you want to read more about the silent parameters here is VMware’s documentation on it.

More info about VMware Tools in general here is the VMware documentation about it.

The silent route is what makes Server Core genuinely pleasant to manage. Because REBOOT=R suppresses the automatic restart, the command returns control to your script immediately after the installer finishes, and you can chain the reboot yourself at a moment of your choosing — after the rest of your configuration steps, at the end of a maintenance window, or as part of a broader build sequence.

Verifying the Installation

Because the silent install produces no output, verification is worth a moment. Three checks give you confidence:

Get-Service VMTools,VGAuthd,VGAuthService | Format-Table Name,Status,StartType

All three services should be running, and set to start automatically. If VMTools is present in the service list at all, the installation reached the point where the core package was registered.

& "C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe" -v

This returns the installed driver and Tools version. Compare it to the version of the Tools ISO you mounted — if you are several releases behind, plan an upgrade, because the storage and network drivers are part of the value here and they improve release over release.

Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object DisplayName -like "VMware Tools" | Select-Object DisplayName,DisplayVersion

Using the standard Windows Installer uninstall registry view confirms the product registered properly, which matters if you ever need to script an upgrade or a removal. It also gives you a reliable version string to record in your build documentation.

Finally, check on the host side. In vCenter, the guest should now report a Tools status of “Running” with a current version, and the IP address field in the VM summary should populate within a minute or two. That last one is the quickest end-to-end confirmation that the vmxnet3 driver is actually in use.

Upgrading and Uninstalling Silently

The same technique covers the rest of the lifecycle. To upgrade an existing installation, mount the newer ISO and run the same command — the installer detects the installed version and performs an in-place upgrade. To remove Tools entirely, add the uninstall switch:

Start-Process "C:\Program Files\VMware\VMware Tools\VMware Tools.msi" -Wait -ArgumentList "/x", "/qn", "REBOOT=R" -WindowStyle Hidden

When scheduling upgrades across a fleet, remember that the reboot is not optional in the general case — the network and storage drivers are kernel components, and the guest will not pick up a new vmxnet3 driver until it restarts. Plan for one reboot per host per upgrade cycle and do them in batches so that a bad ISO never takes out the whole estate at once.

Automating Across Many Server Core Guests

The real payoff comes when you have twenty Server Core guests to service rather than one. The pattern that works well over PowerShell remoting is:

Invoke-Command -ComputerName $servers -ScriptBlock {
    if (Test-Path 'D:\setup64.exe') {
        Start-Process 'D:\setup64.exe' -Wait -ArgumentList '/s','/v','/qn','REBOOT=R' -WindowStyle Hidden
        Restart-Computer -Force
    }
}

Two notes on running this in production. First, mount the Tools ISO on each VM before you start — either through the vSphere API in a loop or from the vSphere client. Second, use a reboot-aware pattern: because Restart-Computer tears down the remoting session, wrap the actual restart so that you can collect the installer’s exit code first, and check it. A non-zero exit code is the only reliable signal that something went wrong, since the silent install will not tell you anything else.

Troubleshooting the Common Failures

The installer window is invisible. On the interactive path this is usually just the setup window hiding behind the command prompt, as noted above. Alt+Tab brings it forward. On Server Core there is no full shell, so if you need to interact with the installer at all it is worth doing so over a console session rather than RDP.

“The system cannot find the file specified.” The ISO is not mounted, or it landed on a different drive letter than the one you assumed. Run Get-Volume and look for the volume labelled VMware Tools.

The install finishes but Tools shows as “not running” on the host. The guest almost always needs the reboot that was suppressed with REBOOT=R. Restart the VM and check again before you start troubleshooting the drivers.

Repeated upgrade prompts or a failed upgrade. An interrupted earlier install is the usual cause. Run the MSI repair or the uninstall, reboot, and install cleanly rather than running the upgrade installer on top of a broken state.

Snapshots still are not quiesced. This is a different problem from a Tools installation problem. Confirm the VSS shadow copy providers are healthy inside the guest and that the application actually supports VSS. Tools provides the mechanism, not the application’s cooperation.

Frequently Asked Questions

Do I really need the GUI path at all? Only if something goes wrong and you want the installer’s log in front of you. For day-to-day work, the silent command is faster, scriptable and easier to repeat across a fleet.

Should I let Tools reboot the guest? On a freshly built machine, letting it reboot is fine. On anything in production, suppress the reboot with REBOOT=R and do it under your own change control.

Can I install Tools on a Server Core guest without mounting an ISO? Yes — copy the installer into the guest, or push it with a configuration management tool, and run the same command. Mounting is a convenience, not a requirement.

Does this apply to a converted or cloned VM? Yes, and it is more important there. A converted VM often carries emulated drivers from its previous platform, and swapping them for the paravirtualised ones is one of the largest single performance wins available.

Final Thoughts

Windows Server Core and VMware Tools are an easy pairing once you accept that the installer is just an MSI with a friendly face on it. Mount the ISO, run one command with the right switches, verify the three services and the version, and reboot when it suits you. Do it as part of your standard build rather than as an afterthought, and you get the full benefit of the virtual hardware your guest is running on.

If you are building Server Core guests at any scale, it is worth getting the vSphere side right at the same time — the guide to ESXi vSwitch port groups, VLAN IDs and teaming covers the network design that sits underneath these virtual machines, and regenerating the ESX self-signed certificate is useful housekeeping for a lab that has been running for a while. If you are building a desktop estate on the same platform, the notes on VMware Horizon GPO templates are a good companion read.