“The device cannot start. (Code 10)” for Microsoft ISATAP and Microsoft Teredo Tunneling adapters

I was checking the system settings for one of the Windows 2008 R2 virtual machines that had been provisioned from the template recently when ran over this issue.

Both Microsoft ISATAP Adapter and Microsoft Teredo Tunneling Adapter had warning icons in the Device Manager.



Even if it is a minor obstacle, I prefer to resolve any problems with the operating system before installing and configuring applications.

After searching on Microsoft web-site, I came to the following forum thread where the user named Dork Man pointed at the DisabledComponents registry value in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters registry hive.

In my case, it has been set to a value of 0xfffffff for some reason.



I found the Microsoft KB # 929852 that explained this parameter. In this article Microsoft states the following:

…system startup will be delayed for 5 seconds if IPv6 is disabled by incorrectly, setting the DisabledComponents registry setting to a value of 0xfffffff.

Microsoft supports only the following values to configure the IPv6 protocol:

  • 0 – re-enables all IPv6 components (Windows default setting)
  • 0xff – disables all IPv6 components except the IPv6 loopback interface
  • 0x20 – makes IPv4 preferable over IPv6 by changing entries in the prefix policy table
  • 0x10 – disables IPv6 on all non-tunnel interfaces (both LAN and PPP)
  • 0x01 – disables IPv6 on all tunnel interfaces
  • 0x11 – disables all IPv6 interfaces except for the IPv6 loopback interface.

I haven’t had any specific requirements for the setting. So changing the DisabledComponents registry value to 0 and rebooting the server resolved the problem completely.

vCenter Server 6.0: vmware-dataservice-sca and vsphere-client status change from green to yellow


Some of you might be aware of the behaviour in vCenter Server 6.0 when the vmware-dataservice-sca and vsphere-client status change from green to yellow continually, and VMware KB # 2144950 provided as a workaround for this one.

However, two questions should be explained in the knowledge base above but seem to be missing.

The first question is current memory usage by the vsphere-client service. Knowing this data will help to choose the correct value for the vSphere Web Client’s maximum heap size when setting it manually. Fortunately, William Lam has a great article that explains a dynamic memory reconfiguration process when vCenter Server is booting up. One of the suggestions that William had was to use a CLI utility cloudvm-ram-size to monitor the memory usage.

cloudvm-ram-size -S | grep -e Service-* -e Linux* -e OS -e vsphere-client -e TOTAL

In the picture below, an output of the command shows memory usage in MB for the vCenter Server with external PSC in a small environment.


As a rule of thumb, to determine the maximum heap size for the vsphere-client service, I usually round the MaxMB value to the nearest gigabytes and add extra 512 MB as a reserve. In this example, AllocatedMB is 2,048 Mb + 512 MB = 2,560 MB.

Then, I set this parameter manually and restarted the vSphere Web Client service using the commands below.

cloudvm-ram-size -C 2560 vsphere-client | service vsphere-client restart

The dynamic memory algorithm adjusts the value of this setting automatically. After few minutes the service reinitialises, and memory allocation looks much better.


On rare occasions, you might notice that vAPI Endpoint service generate error messages after restarting vsphere-client. Restarting this service helps to resolve the problem.

service vmware-vapi-endpoint restart

Now we come to the second question: does this setting change survive the vCenter Server reboots? The answer is yes! And this is great news.

08/12/2016 – Update 1: You should reapply this setting after VCSA has been updated.

19/07/2017 – Update 2: VMware released a KB 2150757 to guide through the process of manually changing the heap memory on vCenter Server components in vCenter 6.x.