A vendor KB tells you to change one advanced settings value on every ESXi host in a vSphere cluster. There might be twenty of them. Clicking through Configure → Advanced System Settings twenty times is how mistakes get made, and PowerCLI does the whole cluster in one line.
Change advanced settings on every host in the cluster
Everything below assumes an open PowerCLI session — Connect-VIServer vcenter.example.com.
$clusterName = 'My VMware Cluster'
Get-Cluster -Name $clusterName | Get-VMHost | Get-AdvancedSetting -Name VMFS3.UseATSForHBOnVMFS5 | Set-AdvancedSetting -Value 0 -Confirm:$false
Scoping through Get-Cluster rather than a bare Get-VMHost is deliberate: bare Get-VMHost returns every host in the connected vCenter, and an advanced setting applied to the wrong cluster is not something you notice the same day.
The example value is not a recommendation. VMFS3.UseATSForHBOnVMFS5 controls whether ESXi uses the ATS primitive for VMFS heartbeats, and its default is 1. Setting it to 0 is the workaround VMware published in KB 2113956, "ESXi host loses connectivity to a VMFS datastore", for arrays where heartbeat ATS traffic caused hosts to drop datastores. VMware is explicit that you should not disable it unless vmkernel.log actually shows ATS Miscompare detected between test and set HB images at offset XXX on vol YYY — and on ESXi 6.5 and later, which retries false miscompares, it should normally stay at 1.
Copy the shape of the command, not the setting — take the name and the value from whatever KB or vendor note sent you here.
Read before you write
Get-Cluster -Name $clusterName | Get-VMHost |
Get-AdvancedSetting -Name VMFS3.UseATSForHBOnVMFS5 |
Select-Object @{n="Host";e={$_.Entity.Name}}, Name, Value
Two reasons this is not optional. First, it is your record of what the value was, which is the only rollback you will have. Second — and this is the one that costs people an afternoon:
A typo in an advanced settings name fails silently
Get-AdvancedSetting -Name with a name that does not exist returns nothing. -Name is a wildcard pattern, not a lookup — so a misspelling is not an unknown setting, it is a pattern that matches nothing. Nothing then flows into Set-AdvancedSetting, which obligingly does nothing, and the pipeline finishes without an error, without a warning and without any output. It looks exactly like a run that worked.
Advanced settings names are long, dotted and easy to mistype — VMFS3.UseATSForHBOnVMFS5 has two capital-letter clusters and a digit in the middle. So count what you got back:
(Get-Cluster -Name $clusterName | Get-VMHost | Get-AdvancedSetting -Name VMFS3.UseATSForHBOnVMFS5).Count
If that number does not equal the number of hosts in the cluster, stop. Either the name is wrong or some hosts are on a version that does not have the setting, and both are worth knowing before you change anything.
If the setting genuinely is not there, PowerCLI cannot add it — New-AdvancedSetting against a host fails, because the API it uses only reads and updates options that already exist. Creating one means esxcfg-advcfg on the host itself, which is a different job from this one.
Wildcards help when you are hunting for the exact spelling:
Get-VMHost esxi-01.domain.local | Get-AdvancedSetting -Name "VMFS3.*" | Select-Object Name, Value
On a single host the same change is esxcli system settings advanced set -i 0 -o /VMFS3/UseATSForHBOnVMFS5. Note the separator: KBs write the path as /VMFS3/... while PowerCLI wants VMFS3...., which is itself a thing people get stuck on.
Verify, and know whether it needs a reboot
Get-Cluster -Name $clusterName | Get-VMHost |
Get-AdvancedSetting -Name VMFS3.UseATSForHBOnVMFS5 |
Select-Object @{n="Host";e={$_.Entity}}, Value | Sort-Object Host
Every host should show the new value. Whether it is in effect is a separate question that depends on the setting: many take effect immediately, some only apply to newly mounted datastores or newly started processes, and a few need a host reboot. The KB that gave you the setting says which — and if it does not mention it, assume the change is only fully live after the next maintenance-mode cycle rather than assuming it is not. For the ATS heartbeat setting above, VMware says it takes effect immediately.
Rolling back
Get-Cluster -Name $clusterName | Get-VMHost |
Get-AdvancedSetting -Name VMFS3.UseATSForHBOnVMFS5 |
Set-AdvancedSetting -Value 1 -Confirm:$false
This is where the "read before you write" output earns its place — you are putting back a value you recorded, not one you remember. If different hosts had different values to begin with, restore them per host rather than sweeping the cluster with one number.
The same Get-Cluster | Get-VMHost pipeline drives other fleet-wide changes, like enabling SSH on every host in a cluster and checking disk latency for every VM.
