Exchange Services Not Starting on Windows Server 2012 Due to Network Location Profile

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 in this case. 

Autodiscover #Fail 101 - Server Totally Unreachable

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. 

Checking Network Profile On Windows 2012 - Note Public Is Selected

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.  

Network Profile On Exchange - Domain Not Detected.  Neither Public or Private Allow the Required Traffic

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. 

Checking Network Profile On PDC - Note Public Is Selected.  Oh Crap.

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. 

Checking Network Profile On PDC - Domain Profile Is Now 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. 

Checking Network Profile On Exchange Server - Domain Profile Is Now Applied

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:







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:


Checking Currnet Network Connection Profile Using PowerShell

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

Attempting To Set DomainAuthenticated Network Category Using PowerShell

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

Setting Private Network Category Using PowerShell

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:

Checking Currnet Network Connection Profile Using PowerShell

Rhoderick Milne [MSFT]

Leave a Reply

Your email address will not be published. Required fields are marked *