Hello everyone, my name is John Clyburn and I am a Sr. consultant in MCS. I recently ran into a problem connecting to a share on a Hyper-V server configured using the SDNExpress PowerShell scripts. I’ve been working with Software Defined Networking (SDNv2). I’ve been primarily working with Windows Server 2019 and VMM 2019, deploying the solution using VMM SDN Express from the GitHub site. To learn more about this solution see the following link: SDNExpress.
I would like to share this with everyone in hopes it will save you some time if you ever run into it while troubleshooting.
PROBLEM: I used the SDNExpress scripts to configure Network Controller on some Hyper-V servers. A few days later, when attempting to connect to a share on one of the Windows 2019 Hyper-V servers, it fails with the following error message:
Windows cannot access \\<servername>\<sharename> Error code: 0x80070035 The network path was not found.
NOTE by no means am I saying the SDNExpress scripts cause this problem. I’m only sharing my experience. This could very well fall into the realm of a hiccup. One of the things that the SDNExpress PowerShell script does is automatically applies a logical switch to the NICs on the Hyper-V servers you’re configuring. For some reason, this is when the issue was introduced.
Additional Information on my configuration There were two ethernet adapter’s/NICs on the Hyper-V host configured via logical switch using SCVMM 2019. The first NIC (MGMT) is used for management and the IP address is set statically and is registered in DNS. Therefore, it is used to resolve the server name. The second NIC (VMs) is used for VM traffic and is set via DHCP and is not registered in DNS.
When attempting to connect to the server share using the NetBIOS, FQDN (DNS registered) or IP number of the MGMT NIC, the connection fails.
When attempting to connect to the server share using the VMs ethernet/NIC IP number the connection works. (This was a clue)
SOLUTION: On the management NIC (MGMT) in the Network Connections, the following items was NOT set in properties: • Client for Microsoft Networks • File and Printer Sharing for Microsoft Network
Setting these two items solved my problem. Somehow during the creation of the virtual adapters, these options got unselected.
And that’s it. The steps above were successful for me to resolve the Windows cannot access… error message. I hope this post saves you time if you ever encounter these errors.