I guess, you must be using Sysprep, which will reconfigure entire network configuration with default configuration for unspecified items... such as IPv6

Could you please try with Quickprep and check for the same issue ?

hello,

i've used quickprep in this desktop pool for 3 years (view agent 5.x)

since december i've installed the 6.0.2 agent, which does not work properly.

This looks strange. Request to help me with below questions.

1. Have you also upgraded vSphere and/or View Composer along with this? I hope you must be followed View Upgrades - VMware Horizon 6.0 guide to complete the upgrade.
2. Does any VM hardware or tool upgrade happened between these snapshot states ?

Add me as another user seeing the same behavior - my linked-clone master image has IPV6 disabled, but linked clones deployed from that image (either through new pool creation or a recompose operation) are coming up with IPV6 enabled. I'm using Quickprep, and like the original poster we've been running this same config for over two years and not seen this behavior. This is with View 6.0.1 and VMtools 9.4.10 build-2068191.

Looks like a new network adapter is being created during VM spinup which would explain what's going on. Here are my network devices from my master image:

And here's a deployed linked clone:

So I guess something changed in VMtools, the View 6 Agent, or Composer that's causing this to happen?

Geoff

I looked at my setup as we upgraded from 5.3 to 6 recently this year, and my network adapters look fine.

Few things with my setup though:

Network Adapter is E1000 (your screenshot shows the VMXNET3)

We are disabling IPv6 via GPO:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters]

"DisabledComponents"=dword:ffffffff

I'm thinking your problem is related to the VMXNET3 network adapter and a VM Tools update.

And you've done the hack (set devmgr_show_nonpresent_devices=1) to look for hidden devices on your linked clone, right?

If it's a VMTools change that's causing PnP to pick up a new adapter after Quickprep it would be nice to have a way to revert to the previous behavior, otherwise I guess I'll have to do what you're doing and use GPO to turn it off on the new adapter.

Geoff

Yes, I did that, no duplicates here.

I just ran into this problem with a new image I had created, instead of cloning from my previous images.

For me, it was a case of forgetting to apply the Microsoft Hotfix for the VMXNET 3 adapter when using Windows 7.  All of my existing images already had this fix applied.

Your problem might be different, but here is what I found and how I fixed it.

When I took a closer look at the LAN adapters in the composed desktop, the LAN adapter name had a number at the end, indicating it was a new adapter and not a re-use of the base image's NIC.  For example, the adapter name was Local Area Connection #2 or #3 or the active network name was my domain #2 or my domain #3.

To resolve the issue:

1. I removed the NIC from the base image using Edit Settings in the vSphere Web Client
2. I mounted an .ISO I created that includes Microsoft Hotfix from VMware KB 2007319, which will refer you to either Microsoft KB 2344941 for Windows 7 or, as is my case, Microsoft KB 2550978 for Windows 7 with SP1
   This includes the following .msu installation files, depending on my version of Windows 7 with SP1, which I put onto my ISO
   Windows6.1-KB2550978-x64.msu
   Windows6.1-KB2550978-x86.msu
3. I installed the appropriate .msu file, either 64-bit or 32-bit and rebooted the base image from my ISO
4. Then I shutdown the base image VM, Edit the settings again,
   1. Dismount the CD by connecting it back to client device
   2. Add the VMXNET 3 adapter back and set it to the correct network
5. Boot up the base image, edit the network adapter properties to disable IPv6
6. Shutdown the base image again
7. Take a new snapshot
8. Recompose the pool using the updated snapshot

When I logged into the composed desktop, the network adapter no longer has a number appended to it and IPv6 is still disabled.

I learned about this Microsoft Hotfix from VMware KB article 2007319, which is not the same exact issue, but the Hotfix resolves the issue, at least for me it does.