none
Hyper-V Switch Issues after Windows 10 1709 Update RRS feed

  • Question

  • After allowing my Windows 10 computer to update to 1709 (Fall Creator's Update), I found that my networking wasn't working at all.  I traced it back to Hyper-V, which had taken out my virtual switch and created the Default Switch.  An attempt to create a new virtual switch failed but managed to release my NIC so that the host could access the network again.  But my VMs cannot get network, internal or otherwise, even with Default Switch selected as their adapter.  I still see a vEthernet adapter under Network Connections from my failed attempt but cannot remove it (it's not showing under Virtual Switch Manager).  Anybody have any thoughts?  Thanks!
    Sunday, November 19, 2017 2:03 PM

All replies

  • My system updated this morning, and I had a similar problem.  System couldn't get to the network.  VM's couldn't access the network.  I was finally able to get the vms connected to the internet, by setting their network to the newly created default network, but could not access the host.  

    I also, could not create any virtual switches.  

    This worked for me.  

    https://support.microsoft.com/en-us/help/3101106/you-cannot-create-a-hyper-v-virtual-switch-on-64-bit-versions-of-windo
    • Proposed as answer by MrMalloc Thursday, November 30, 2017 6:38 AM
    Sunday, November 19, 2017 6:43 PM
  • Gave that tool a try with no success.

    Z

    Monday, November 20, 2017 1:09 AM
  • Hi,

    The switch named “Default Switch” or “Layered_ICS”, allows virtual machines to share the host’s network connection.  Without getting too deep into networking (saving that for a different post), this switch has a few unique attributes compared to other Hyper-V switches:

    1. Virtual machines connected to it will have access to the host’s network whether you’re connected to WIFI, a dock, or Ethernet.
    2. It’s available as soon as you enable Hyper-V – you won’t lose internet setting it up.
    3. You can’t delete it.
    4. It has the same name and device ID (GUID c08cb7b8-9b3c-408e-8e30-5e16a3aeb444) on all Windows 10 hosts so virtual machines on recent builds can assume the same switch is present on all Windows 10 Hyper-V host.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, November 21, 2017 3:07 AM
    Owner
  • At this point, please first check the ICS service and restart it.

    Then you needed to un-share the network adapter, and then share it back for ICS to work.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, November 21, 2017 4:53 AM
    Owner
  • Hi,

    The switch named “Default Switch” or “Layered_ICS”, allows virtual machines to share the host’s network connection.  Without getting too deep into networking (saving that for a different post), this switch has a few unique attributes compared to other Hyper-V switches:

    1. Virtual machines connected to it will have access to the host’s network whether you’re connected to WIFI, a dock, or Ethernet.
    2. It’s available as soon as you enable Hyper-V – you won’t lose internet setting it up.
    3. You can’t delete it.
    4. It has the same name and device ID (GUID c08cb7b8-9b3c-408e-8e30-5e16a3aeb444) on all Windows 10 hosts so virtual machines on recent builds can assume the same switch is present on all Windows 10 Hyper-V host.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support

    Hi. Thanks for the reply. I did not delete the Switch, however, it is gone after the update. All the options in Hyper-V with regards to networking are grayed out now, and trying to launch Hyper-V Switch Manager just results in the error in the first post.
    Tuesday, November 21, 2017 4:22 PM
  • The services was running. The adapter was never shared and worked fine. For grins, I tried this suggestion with no better results.
    • Proposed as answer by Royvou Saturday, April 27, 2019 7:18 PM
    • Unproposed as answer by Royvou Saturday, April 27, 2019 7:18 PM
    Tuesday, November 21, 2017 4:23 PM
  • Have you tried to reinstall Hyper-v Feature to check the results? We can reconfigure the network and attach the VHD back. 


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, November 22, 2017 10:27 AM
    Owner
  • As stated in the initial post, Hyper-V was removed using the Add/Remove programs feature and then re=added to the machine. No change in results. Still getting the Generic Failure when launching Hyper-V Virtual Switch Manager.
    Wednesday, November 22, 2017 4:41 PM
  • As stated in the initial post, Hyper-V was removed using the Add/Remove programs feature and then re=added to the machine. No change in results. Still getting the Generic Failure when launching Hyper-V Virtual Switch Manager.
    Me too having same issıue
    Thursday, November 23, 2017 6:07 AM
  • This worked for me. I'd removed the existing virtual switches per VM before running the tool. Recreated a switch and set it per VM again afterwards.

    Thursday, November 23, 2017 2:53 PM
  • Hi, I have a similar Problem:

    After the latest Win fall update 1709 and the latest cumulative update for that (KN4048955) last week, my WinPro64 Machine with one Hyper-V and OpenVPN-Access running on this machine, the OpenVPN shows random packets losts (rates from 5 to 10% on cable Connections which have formerly been loss free) which causes partial VPN disfunction. 

    I found that this is most probably due to a "Rowdy" Hyper V Default Switch. This Switch is not recognized by the hosts (Status "Not identified Network") and therefore is regarded as "public Network" and seems to impair correct packet Routing from time to time.

    As I have set up a external Switch for Hyper V, I do not Need the Default Switch. But as said before, it seems to be undeletable (if I get it deleted, it will be automatically re-created) and it also automatically reactivated after deactivation.

    Is there really no way to get rid of that Default Switch? Alternatively, I have tried to enter useful IP-Settings for this Default Switch (I use static IPs here), but that seems not to be helpful in order to eliminate VPN packet loss.

    Any help would be greatly appreciated.

    Joachim

    Thursday, November 23, 2017 3:13 PM
  • Hi, 

    For further identify this issue, please help to collect following information: 

    1. Click on the link below.

    http://support.microsoft.com/sdp/0B37B04E36363439343939313233CB

    2. Click on the Run button (recommended) to start the diagnostic process.

    3. Follow the onscreen instructions to run the diagnostic on this computer, or on a different computer.

    After the log generate, please upload the results onto OneDrive and share the link here for our research.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, November 24, 2017 9:11 AM
    Owner
  • Same issue here. Ran the diagnostic tool and got Microsoft Service Request (SR) #: 117111717174365.

    Roberto.

    Friday, November 24, 2017 10:45 AM
  • Hi, I had the similar issue after update 1709. By me was also the solution to deinstall, restart, and reinstall the Hype-V Windows feature. Hope you have success!
    Friday, November 24, 2017 2:54 PM
  • Hi Deep network guy,

    and in a future how will be possible safe my host from network attacks with a virtual machine "firewall and vpn gateway" is still connected to the default network, and I don't know to now assign a vlans etc. if somebody want nat it was possible to create before too, this feature is like start button, somebody will be "s..." in your big company, you know how many outages was?

    Monday, November 27, 2017 6:53 AM
  • I had the same issue.  I deleted each External virtual switch (LAN and WLAN), restarted the services, and recreated them with their original names.  Seems to be working for me now.
    Monday, November 27, 2017 3:58 PM
  • similar issue

    all my virtual VMNetworkAdapter were lost after 1709
    also the connected switches are lost!

    for instance:

    Add-VMNetworkAdapter –ManagementOS –SwitchName “ITCamp1”  -Name VirtualOS_NIC1
    Add-VMNetworkAdapter –ManagementOS –SwitchName “ITCamp1”  -Name VirtualOS_NIC2
    Add-VMNetworkAdapter –ManagementOS –SwitchName “ITCamp1”  -Name VirtualOS_NIC2

    NICs and switch were gone.

    I recreated a new external switch and it was only possible to assign one of my three physical nics to this switch.
    The other two nics seems to have a non visible link to the disappeared two switches.

    I am able to see the old VMNetworkAdapters and Switches in registry but I am not sure If deletion is a good choise. Hyper-V Reinstallation is not an option because there are more than 30 vms running.

    Tuesday, November 28, 2017 1:33 PM
  • I made an rollback to 1703 and all vm adapters and switches are visible and functional

    But it is not a good idea to roll back, because 14 of the 30 vm lost her configuration!

    OMG

    All symlinks in

    C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines

    were changed from T: or D: to C: [ironic on] "A really good idea" [ironic off]

    I replaced this files from the os backup. If there is no backup you have to change the symlinks. First you have to search all *.xml and copied to C:

    Wednesday, November 29, 2017 8:03 PM
  • Expired Support Link....

    John

    Thursday, November 30, 2017 1:42 AM
  • Hi, I had the similar issue after update 1709. By me was also the solution to deinstall, restart, and reinstall the Hype-V Windows feature. Hope you have success!

    Did you reinstall the OS or Hyper-V? Thanks. john

    John

    Thursday, November 30, 2017 1:43 AM
  • What? The poster distinctly said the Hyper-V Windows feature. How can that be misunderstood?


    Bill


    • Edited by Bill Grant Thursday, November 30, 2017 5:48 AM Add screenshot
    Thursday, November 30, 2017 5:44 AM
  • My system updated this morning, and I had a similar problem.  System couldn't get to the network.  VM's couldn't access the network.  I was finally able to get the vms connected to the internet, by setting their network to the newly created default network, but could not access the host.  

    I also, could not create any virtual switches.  

    This worked for me.  

    https://support.microsoft.com/en-us/help/3101106/you-cannot-create-a-hyper-v-virtual-switch-on-64-bit-versions-of-windo

    That program MicrosoftEasyFix20159.mini.diagcab appears to drop *ALL* defined network adapters, including VPN adapters, Oracle VirtualBox Adapters, etc. so a bit of a problem here...

    But it did work in getting a valid/working External Virtual Switch in Hyper-V that I could attach to my old VM (Legacy Network Adapter, as it was prior)! So thanks, @sawolsef !

    New set of adapters

    I was actually about to re-install my entire Windows 10 Pro from an .iso just to get this Hyper-V working properly!
    • Edited by MrMalloc Thursday, November 30, 2017 6:45 AM Add image
    Thursday, November 30, 2017 6:38 AM
  • I had a NIC that also had driver problems after 1709 (Killer drivers :( 

    The support tool above helped with get the virtual switch working again, but I also had to update drivers because they performed horribly under 1709 when used by a hyper-v virtual switch. 

    The kicker was, that I was unable to update the drivers UNTIL I dissociated the virtual switch from the physical NIC (made the virtual switch a private network for a bit).  otherwise the driver installer just failed silently.

    Then I successfully updated the drivers and changed the virtual switch back to using the NIC. 

    Finally I have Gigabit network speeds again!  uggh.  several hours wasted on this.

    Friday, December 1, 2017 7:04 AM
  • After applying the new Fall update I was unable to connect to my own LAN. 

    Inspection proved all networking parameters had been changed to a new LAN (172.23.x.x), firewall enabled, new permanent virtual switch (default) which overlapped with the physical adapter my old virtual switch used.  All virtual machines had a 'configuration error' under networking.

    Under 'Network Connections', notice the local adapter is active with several options checked under properties, as is the virtual adapter which differed pre-update.  IP information also exists under the physical adapter and not under the virtual adapter (DHCP) which is a departure from how things were setup previously before the update.

    In my case, I deleted the old virtual switches from 'Hyper-V Manager', then both the network driver and virtual switch drivers from 'Device Manager'.  Rebooting (or scanning for hardware changes) restored the NIC driver.  Applied proper network parameters to restore connectivity to my LAN.  Reboot again and Windows re-added the virtual switch and default switch under Hyper-V.  Then edited all my VM's to point to this new switch and everything appears to be working with the new mshome.net networking information.

    Friday, December 1, 2017 6:24 PM
  • After being force-fed the 1709 Hyper-V enhancements and becoming au fait with the new Default Switch, having replaced my original NAT internal network, I have noticed some strange behaviour for the guest machines.

    The main issue is that an IP is not always given - essentially there is a lack of communication I believe so I don't necessarily think it's the (new) DHCP service not working on the Default Switch.

    Does anybody else experience this issue? I have noticed I sometimes have to go into the Default Switch settings and back out to get it to kick-start something. I don't know what. The other thing is that it seems to be more problematic when I'm on Wifi.

    I already found one issue and fixed it which is to do with SMB access. Simply disabling File & Printer Sharing on the NIC, then enabling it again allowed guests to access the host shares.

    Does anybody else have issues with guests communicating with the host via this new default internal switch?

    Sunday, December 3, 2017 1:56 PM
  • I would not have changed to the new default switch in your case. I would have stuck to your original scheme.

      The new default switch is a version of ICS (which has never been known for its adaptability or reliability). I suspect it was introduced to make Hyper-V on Windows 10 more like the other client virtualization systems (VMWare, VirtualBox etc) which offer a simple NAT connection for the vm. As in those systems, this is aimed at the user who has a standalone host directly connected to the Internet and all they want from the guest is an Internet connection. This is the default setup in VirtualBox because it is the most common scenario.

      If you are on a LAN or if you need communication between vms (or if you know anything about networking), ignore the default switch and set up you own.


    Bill

    Sunday, December 3, 2017 11:03 PM
  • Bill, the default switch hijacked my NAT-enabled internal switch. It effectively tried to replace it but failed at the point of removing assignments. Instead, the assignments were left in a limbo state of not configured or the equivalent. So your advice is basically to add a NAT-enabled switch like I did before 1709.
    Monday, December 4, 2017 2:55 PM
  •   What sort of NAT-enabled switch did you have? None of the standard virtual switches do that apart from the new default switch.

       I never use an internal switch myself because I like to keep my vms isolated from the host. If I want a NAT network for vms I use a private virtual switch and a vm NAT router, with that router having one NIC in the private LAN and one connected to the physical network  through an external virtual switch. Lots of people use the host as a router, I don't.


    Bill

    Tuesday, December 5, 2017 5:55 AM
  • C:> netcfg –u vms_pp

    C:> netcfg –c p –i vms_pp

    that did the job for me ... After i was able to make my virtual switch

    Source : http://blog.armgasys.com/?p=168


    • Edited by AlkaYoda Wednesday, December 13, 2017 8:26 AM
    Wednesday, December 13, 2017 8:23 AM
  • Had the same issue. Ran through all the suggestions in all the forums, ended up reverting back the OS build and it worked. Let's hope Microsoft fixes this soon but am skeptic.
    Wednesday, December 27, 2017 7:29 PM
  • Same issue, I solved this by restoring PC using backup to before the upgrade. removing the network adaptor for all Vms and then deleted all virtual switches from Hyper V. Performed upgrade and recreated the virtual adaptors. Still have 'default' adapter but can start VMs with no issues.

    Hope this helps someone.

     
    Monday, January 8, 2018 8:28 AM
  • Had the same issue.

    Forced to update to 1709 and hyperV switch dissapeared

    Went through various of the proposed solutions to no avail.

    Wasted two days trying to get it to work.

    In the end I gave up, uninstalled HyperV  and went to Virtual Box.

    Half an hour later I was in a happy place.

    Thursday, January 11, 2018 9:16 PM
  • I'm new at this... Just created my first VM and I ran into the same problem.  I had to create one because my development environment went away with Office 2003 with the a recent upgrade on a win10 machine.

    The easy fix worked fine.  The virtual switch is strange to say the least.   I'm kind of in agreement that I would like to choose different connectivity for the VM.  Looks like there is some trial and error exercises going to b needed in this area.  The easy fix is going to come in handy from my experience in the early days of Win98 when the network adapters defined parameters weren't being cleaned up with configuration changes!

    Wednesday, February 7, 2018 4:30 AM
  • I removed this "Default Switch" by:

    Get-HNSNetwork | Remove-HNSNetwork

    Thursday, February 8, 2018 6:51 PM
  • I simply roll back windows after the updates and do all I can to block them that includes at the router level.  
    Tuesday, February 27, 2018 5:35 PM
  • This is what I was looking for.

    Did this; set up a new vSwitch; everything now works.



    Have you visited Lync News lately? All of the latest Lync news, articles, and tips collected in one giant aggregator. http://lyncne.ws

    Saturday, March 3, 2018 4:13 PM
  • Disabling your vEthernet (Default Switch) should immediately show you it is the culprit.  Disable it and then see if you do not immediately resolve your challenges . . . mine was the constant "Resolving Host" delays.
    • Proposed as answer by Mark_ROGs Thursday, March 22, 2018 4:25 PM
    Wednesday, March 7, 2018 4:30 AM
  • FINALLY!!! A solution that worked!

    I am running 17115.rs4_release.180302-1642 and have been plagued by this for the last 2 weeks.  After I removed the Default Switch using 

    Get-HNSNetwork | Remove-HNSNetwork

    I have a stable AnyConnect VPN connection.

    Thank you soooooooo muchj.


    Tuesday, March 13, 2018 2:26 AM
  • I'm having a similar problem -- I have Hyper-V running on Win 10 Pro host, with 2 Linux guest VMs.  Modem is set to bridge mode, so every device pulls a public IP.  Physical NIC is bridged and shared with the VMs.  The guest VMs running in Hyper-V are also able to public IPs, but all of their ports seem to be blocked.  Anything physically plugged into the modem is completely exposed, so the problem appears to be within Windows or Hyper-V.  Any suggestions?
    Friday, March 16, 2018 2:05 PM
  • >Modem is set to bridge mode, so every device pulls a public IP.
     
    Most ISP's don't allow multiple public IP's, even if the modem is in
    bridged mode, you have to be provisioned for multiple IP addresses. 
     
    Are you sure they are getting real public IP addresses? (not starting with
    169. or 192. or 10.)
     
     
    Friday, March 16, 2018 2:45 PM
  • I removed this "Default Switch" by:

    Get-HNSNetwork | Remove-HNSNetwork

    I ran these commands and they deleted the "Default Switch" as expected.

    However after a few minutes the default switch returned as did the loss of inbound traffic to the host (specifically Remote Desktop Connection)

    My only issue with this switch being enabled is I am unable to remote into the host PC when it's enabled, if I disable the switch the issue is resolved.

    So for the 3-4 workstation I have in my environment running a local VM, I've disabled the default Switch, then use an External Switch that I set up to get the guest connected to the network and it all works as it did before 1709.

    I think MS had a good idea however this has caused more headaches then it's worth IMHO, at a minimum we should be able to delete this network switch, and keep it gone!!

    Thursday, March 22, 2018 4:24 PM
  • This is whats happening to me too... what's the new 'default switch' bit about? I've never felt the need for a default switch before. I'm getting dropped packets, slow responses from VMs.. this is not great.

    So - I've just disabled ICS (never a bad idea anyway), disabled the vEthernet (Default Switch) adapter on the host, and not included Default switch in any of my VMs and everything works beautifully again (yes, created my own internal vSwitch).

    Go Microsoft

    Jim

    Friday, March 23, 2018 9:17 PM
  • I still have this issue as of this posting.  I've tried a few options including letting the device manager to update my Dell Precision 7710 wireless device.  I've heard wireless drivers can cause issues.  Seem to work for a while.  But I also run some Linux VMs on my demo laptop, as well as Windows 2012R2 VMs.

    I like the concept of the Default vSwitch.

    Tuesday, October 30, 2018 12:57 AM
  • My system updated this morning, and I had a similar problem.  System couldn't get to the network.  VM's couldn't access the network.  I was finally able to get the vms connected to the internet, by setting their network to the newly created default network, but could not access the host.  

    I also, could not create any virtual switches.  

    This worked for me.  

    https://support.microsoft.com/en-us/help/3101106/you-cannot-create-a-hyper-v-virtual-switch-on-64-bit-versions-of-windo
    Thanks sawolsef worked like a charm!

    NK

    Wednesday, January 23, 2019 3:35 AM
  • I've recently been experimenting with Hyper-V and ran into problems with getting internet access for my Windows 10 VM's.  They were set up as Gen 2 VMs with the standard default VM switch attached.

    For me, the answer was to look at the host OS network settings. I noticed that the Hyper-V switch showed as a network under the Host OS  Network and Sharing Center.  Click on the vEthernet(Default Switch) device to open its status box, and then select the Properties button in that box.

    Under the list of items configured for the switch, the last one was Hyper-V extensible switch which was unchecked. I checked this, and then closed the properties. Voila, the VM's suddenly got NAT based network addresses!

    One oddity I did find was that, whilst checking my steps in order to write this answer, I opened the properties again, and found the Extensible switch was again unchecked! So I checked it again, and received a warning that I was about to disable it!  A bit odd, seems that checking the box simply flip flops the switch status from enabled to disabled and back again.

    In any case, this worked for me, hope it helps others in a similar position.

    Wednesday, January 30, 2019 11:07 AM
  • This Oct 2016 HotFix (here - MicrosoftEasyFix20159) worked like a charm for me after banging my head against the wall for about 2 hours.  My Windows 10 host would not connect to ANYTHING after the 1803 update and a BIOS update on my Dell E7270 unless I deleted *any* Hyper-V vSwitches from the Device Manager in Windows 10.  Didn't matter if I was using Ethernet or WiFi. Major PITA. 

    The link to the hotfix comes from this page:https://support.microsoft.com/en-us/help/3101106/you-cannot-create-a-hyper-v-virtual-switch-on-64-bit-versions-of-windo

    • Proposed as answer by lusocoding Friday, August 23, 2019 10:42 AM
    Monday, February 4, 2019 5:01 PM