We have two new servers running Server 2008 R2 and we first noticed a problem connecting to them with RDP after a reboot. The problem was the firewall would not permit access because the NLA service could not identify that it was on the local domain network. After updating the firmware on the system (HP DL380) and the NIC (Broadcom NC series) and installing the latest NIC driver, we are still experiencing the problem of being able to connect after a reboot. While I can disable the firewall, that is not preferred. It also seems to have occurred after installing Hyper-V. If I remove Hyper-V the problem seems to go away. Using a single NIC, no teaming, etc. Other unused NICs are disabled. Any help would be greatly appreciated. Thanks.
- Moved by Tiger LiMicrosoft employee Tuesday, February 07, 2012 10:20 AM (From:General)
Enable the below option using secpol.msc, check also you have assign proper default gateway on the NIC.
Check this blog article.
For Hyper-V queries, post here.
That didn't work. The gateways on both servers are correct and verified by access to the internet. Additional info: NICs can be disabled/enabled after reboot and then correctly identify the domain network. Is there perhaps an order of services that may need started in a delayed fashion to be sure the Network Location Awareness (NLA) service is working correctly?
I've also enabled:
- DNS Client
- Function Discovery Resource Publication
- SSDP Discovery
- UPnP Device Host
With no luck...
Thanks for posting here.
The NLA service is used to determine the network profile. When a machine boots up or comes out of hibernation the NLA service that runs using the Network Service account will send an LDAP bind request to a domain controller in its site via port 389. The Network Service Account uses the client’s domain machine account when performing this bind. If the client can successfully bind to a DC in its domain, the network connection category will be set to “Domain”. If an LDAP bind is unsuccessful the network category is always public unless specified as private by the user.
Network Location Awareness Service Provider (NLA)
According to the your description, the domain profile is not detected properly. In this case, let’s check the following:
1. Verify the Network Location Awareness service is Started and the Startup type is “Automatic”. Restart the NLA service.
2. Disable and re-enable the NIC which connects to the domain network. Meanwhile, please disable the all unused NICs.
3. The Network Location Awareness (NLA) service expects to be able to enumerate the domain’s forest name to choose the right network profile for the connection. The service does this by calling DsGetDcName on the forest root name and issuing an LDAP query on UDP port 389 to a root Domain Controller. The service expects to be able to connect to the PDC in the forest domain. If something hinders the DNS name resolution or the connection attempt to the DC, NLA is not able to set the appropriate network profile on the connection. Please ensure that the problematic clients can contact root DC properly.
For more information please refer to the blog post below:
Why is my network detected as “unknown” by Windows Vista or Windows Server 2008?
TechNet Community Support
I understand, and have verified all the above configuration items. The problem still exists ONLY when I install the Hyper-V role so I know it's not a configuration issue. Is there something to check when Hyper-V creates the virtual network connection? I know there is a seperate forum for Hyper-V, but I wasn't sure if this is a networking problem, or something related to the Hyper-V role. If I remove Hyper-V, the server correctly identifies the domain network. Is there anything else to check?
Thanks for update.
So have we also installed loopback interface or maybe have assigned multiple addresses for the physic NIC before we install Hyper-V role on it ? could you please post the results of commands “ipconfig /all” and “route print” here ?
Meanwhile, some workarounds for this scenario that posted by Bill in the old thread below may help:
TechNet Community Support
I finally found a solution to this issue with DC that didn`t recognizes thw own domain.
I my case it was caused because AD replication fails, consequently DNS and Network recognition.
Add/modify the following key:
Value name: Repl Perform Initial Synchronizations
Value type: REG_DWORD
Value data: 0
It is a workaround because Microsoft don`t fix it yet.
- Proposed as answer by rafaeldasilva Thursday, October 04, 2012 6:33 AM