Some of my lab servers run in Microsoft Azure with no redundancy. This is because they are only a lab, and I want to minimise the monthly billing costs for these environments. When the servers are restarted due to patching or maintenance activities, there can be a little fallout.
In the case below, some Exchange services were not running on the Exchange 2010 CAS server in the lab, and Autodiscover was not working at all. Simply pinging the Autodiscover endpoint from a test client failed. Note that DNS resolution is working, as the name has been correctly mapped to the underlying IP, which is 10.0.0.6 in this case.
For reference these IPs are static and were set using Azure PowerShell many moons ago,
Why can we not even ping the Autodiscover endpoint? Experience tells me that something is blocking the IMCP traffic, and this is most likely the Windows Firewall due to the current network profile that is applied. This is something that was an issue with Windows 2008 R2 and required a hotfix to correct. The details are in this previous Windows Server 2008 R2 post, and the hotfix is also listed in my recommend Exchange 2010 tweaks post.
If we look at the network status on the Exchange 2010 CAS server, sure enough the network profile says public. Windows firewall will block the incoming HTTP and ICMP requests.
One way to troubleshoot is to restart the server. That’s not how we like to roll. Can we fix this without rebooting the server? Challenge accepted…
Changing Windows Network Location
To re-assess the network connections, we can restart the Network Location Awareness service (NlaSvc), and its dependant service – the Network List service.
However restarting the services did not change the profile location, it remained on Private.
Manually setting the network to Private, using the steps listed in the appendix at the end of this post, made no difference.
What exactly are we missing here? We cannot set the profile to domain authenticated manually, Windows needs to detect that it is a member of the domain and is currently connected to the domain. This is discussed in KB 980873 - A computer cannot identify the network when the computer is running Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2, and is a member of a child domain.
That KB provides a clue – the reference to the PDC emulator. Can we get to the PDC emulator from the Exchange server in question? Let’s look at the network profile selected on the PDC emulator.
Well that’s just great, the PDC also detected the network as Private which explains why the other servers were not able to query it properly. Windows firewall on the PDC emulator is also blocking inbound traffic.
Note the network is Ethernet16, the Exchange server listed above was Ethernet 20.
Let’s restart the Network Location Awareness service on the PDC.
In the below screenshot the PDC has now detected that the domain profile is to be applied.
Now that we can contact the PDC, let’s restart the Network Location Awareness service on the Exchange server. The change is highlighted below. The domain network is now using the domain profile.
We can now start the Exchange services, and clients can connect to the Autodiscover endpoint and other services successfully. Yay!
To review the history of network transitions, the following Event log can be consulted:
Microsoft-Windows-NetworkProfile/Operational
Cheers,
Rhoderick
Appendix – Manually Setting Server 2012 Network Profile
Since we are not able to manually set the Network Location using the GUI on a domain joined Windows Server 2012 machine, different approaches are needed. While it is possible to configure a local policy, this is not the most efficient and will be overlooked when troubleshooting in the future. Manually setting the network profile in PowerShell is likely to be a better option.
To review the current network connection, we can use:
If we want to change the profile, the Set-NetConnectionProfile cmdlet is used.
The NetworkCategory parameter will accept Public, Private and DomainAuthenticated, but DomainAuthenticated will result in an error:
Set-NetConnectionProfile -InterfaceIndex 33 -NetworkCategory DomainAuthenticated
The server automatically sets the value of DomainAuthenticated when the network is authenticated to a domain controller. The acceptable values for this parameter are:
-
Public
-
Private
Trying this again, let’s set the NetworkCategory to Private:
Set-NetConnectionProfile -InterfaceIndex 33 -NetworkCategory Private
Note that the InterfaceIndex parameter is used to ensure that the changes are applied to the correct interface.
And we can use Get-NetConnectionProfile to check the change was applied:
