Quantcast
Channel: Hyper-V forum
Viewing all articles
Browse latest Browse all 8743

Problem with unidentified network on virtual machine with windows server 2012 R2

$
0
0

I have been searching several blogs for the past 3 days and have found no solution to a Hyper-V issue. This started happening 2 days ago on one server 2012 r2 that hosts 5 virtual servers all are also 2012 r2. Where all the VM's were not connecting to the domain and had registered a "unidentified network". I tried everything I could think of disabling/enabling both the VM virtual NIC and the physical NIC on the host. Instantly went back to "unidentified network". Finally, I just created a new virtual switch and activated another physical NIC and attached the vEthernet switch to the new nic. Assigned to all VM's and they all instantly connected back to my Domain. I thought that it was just glitch when this server re-booted. However, when I came into work today 3 more physical servers all 2012 r2, each hosting at least 3 VM's ranging from Server 2008 Standard to Server 2012 r2 were experiencing the same issue. I did the same solution as stated before and all VM's connected back to the Domain. However, one of my non critical servers I decided to see if this would be a long term resolution so I rebooted the HOST. And instantly all VM's were back to "unidentified network" . And once again the only thing that resolved this is to create a new virtual switch and assign to all VM's.

Please any suggestions would be helpful.

I have already tried all the below steps:

Method 1

Configure the firewall devices not to block communications on UDP/TCP port 389.  For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base: Service overview and network port requirements for the Windows Server system

Method 2

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
  1. Configure one computer in the child domain to connect to the PDC from the root domain.
  2. Restart the computer. The computer should now be able to identify the network. Also, the profile on the firewall will be set to the domain profile.
  3. Export the following registry subkey as a file to a shared location in the domain:
    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache\IntranetForests
  4. Import the registry subkey that you exported in step 3 to the other computers that cannot connect to the PDC from the domain forest.
  5. Restart the computer. The computer should now be able to identify the network and the profile on the firewall will be set to the domain profile.

Method 3

If it is sufficient to identify the network profile based on the child domain name, then mitigating the time taken by NLA during its aggressive retries might be the right approach. 

To deploy a registry setting that changes the retry count used by NLA, follow these steps:
  1. Create a new registry key that matches the forest root domain under the path:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache\Intranet\
  2. In the newly created registry key for the name of the forest root domain, add the  two registry values below:
    • Failures   REG_DWORD with a value of 1
    • Successes REG_DWORD with a value of 0
    This will cause NLA to go to its lowest retry count and should result in identification lasting for just a couple of minutes.



Viewing all articles
Browse latest Browse all 8743

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>