VMware Workstation Loses Virtual Adapter Settings After Update

[Miriam Mayer]

Hi,

We deploy VMware Workstation via software distribution (SCCM). Since at least VMware Workstation 25H2, we've been experiencing an issue where the settings for the virtual adapters are reset after an update.
Is there a way to prevent this?
The problem is that users do not have admin rights and therefore cannot manually export and re-import the settings.

This issue is also unrelated to the software deployment process itself. The problem occurs even with manual updates.

Thx.

[Allan Solomon Mejia]

Since a manual upgrade also resets the virtual adapter settings, SCCM is unlikely to be the cause. The behavior appears to occur while VMware Workstation updates or recreates its virtual networking components.

 

I'm not aware of a documented installation switch that guarantees custom VMnet settings will be preserved. Because the users don't have administrator rights, the most practical workaround would be to manage the process through SCCM:

 

1. Record or back up the existing VMnet, subnet, DHCP, and NAT configuration before the upgrade.
2. Deploy the Workstation update under the SYSTEM account.
3. Run a post-installation script or administrative task that reapplies the required virtual-network configuration.
4. Restart the VMware NAT and DHCP services, or restart the computer.

 

Before applying this broadly, test the process on one device and compare the virtual-network configuration before and after the upgrade. This should confirm whether all VMnet settings are being reset or only specific values such as the subnet, DHCP range, NAT configuration, or adapter assignment.

 

If the issue consistently started with Workstation 25H2, I'd also recommend opening a Broadcom support case and supplying the installer logs and before-and-after configuration. This may be an upgrade regression, but I couldn't find an official Broadcom article confirming it as a known issue.

[Miriam Mayer]

Thank you very much for the feedback.
I'm quite certain that the settings were preserved in earlier versions. We've likely had this issue since 25H2.

I've already searched all the forums and consulted the AI about this. One suggestion was to export the configuration using "vnetlib.exe -- export "C:\Backup\vmware-network-backup.dat"". Apparently, this used to work, but it no longer does.

The other suggestion was the same as yours. I'm supposed to export the configuration files and the registry and then import them again later:
copy "C:\ProgramData\VMware\vmnetnat.conf" "C:\Backup\VMware-Network\"
copy "C:\ProgramData\VMware\vmnetdhcp.conf" "C:\Backup\VMware-Network\"
reg export "HKLM\SOFTWARE\VMware, Inc.\VMnetLib" "C:\Backup\VMware-Network\VMnetLib.reg"

That might work. But if VMware changes the format, that will cause problems too.
I'll give it a try anyway and hope for the best.

[RaSystemlord]

There is nothing wrong in trying to work with Free of Use tools. However, they have their drawbacks and you may need to work a bit with them to get them as you like, but ...

To my knowledge, ip-address ranges have never stayed in any type of Upgrade or Reinstall of VMware Workstation (Pro) - well, let's say in 29 out of 30 cases (don't know what happened in that one case).

For any large scale deployment - I gather this is the case, since changing VMware Networking ip's for a couple of workstations isn't a big deal - VMware Workstation is not the correct tool. It is cheap, I give you that. For larger or large scale distribution of virtual computers, VMware Horizon is a really good tool. There you can decide what you want users to do (extra applications are not installable if you like) and what access they have. You can also give personal virtual computers to Admin level users, where they can do whatever they want. 3D is also available with good performance and using a slow networking (like bad 4G) isn't a problem at all. If not obvious, Horizon gives you multi-user access to the same data and applications fluently, with one setup of the virtual computer. VMware Horizon might be expensive, I know 3D cards for the system for sure are expensive - I'm not really sure about the price range, but I know that for Engineering purposes it is probably the cheapest and nicest way when counting ALL the costs involved ... I guess this is not the Forum for any deeper level discussion about VMware products.

[gworboys]

I am still on v17.6.4 (after various regressions when Broadcom took over I have been waiting for things to settle down).  My experience has been...

All upgrades up until v15.1.0 reset the virtual network, even a minor "change" to an installation would reset the network.  I had gotten into the habit of recording all settings so I could recreate them - some of our systems use multiple network adapters and I needed things to match up properly.  Then with v15.1.0 my diary records "This time VMware even kept the network configuration!"

I don't recall issues with it since then, so it sounds like (yet another) regression with 25H2.

Thank you for the heads-up, I will know to go back to my old habits when updating.

[Pitphilai Kumar Pandey]

Hi Miriam,

Thanks for reporting this. To help us investigate, could you please share details:

1. Versions: the VMware Workstation you upgraded from and to, plus OS version.
2. Settings: Which particular settings for virtual adapters you are looking into which are getting reset. 
3. Steps: the exact steps to reproduce.
4. Logs.

Thanks,
Pitphilai

[Miriam Mayer]

Hi,

my setting is:

1. In this case I try to upgrade from VMware Workstation 26H1 to 26H1u1. We are all using Windows 11 Enterprise.
2. The config is usually the same on all clients: 
   1. VMNET0: Bridged to internal Ethernet adapter
   2. VMNET1: Bridged to internal Wifi adapter
   3. VMNET8: NAT
3. You can reproduce easily:
   1. Install 26H1
   2. Change virtual network adapters like above
   3. Update to 26H1u1

After the update all virtual adapter settings are reset to default, like when you install VMWare Workstation for the first time.

Many thank!

Miriam

[Pitphilai Kumar Pandey]

Thank you, Miriam, for providing the details.
We have filed an internal bug for this issue and will work on resolving it.

Thanks,
Pitphilai