Have you ever come into the office to find that your critical line-of-business app fails to connect to your SQL server? After further investigation, you may find that your domain-joined is no longer on a “domain network” but is now on a public network.
This will cause problems as a public network profile will also lead to a public firewall profile. Public firewall profiles are specifically designed to err on the side of caution and block most traffic including the SQL connections that your line-of-business app uses.
How does Windows determine what kind of network you’re connected to?
Beginning with Windows Vista, Microsoft has included a service in Windows that will dynamically adapt the firewall rules and security based on the network connection that you are on. The service is called Network Location Awareness service or NLA for short. When you plug your laptop into an office port that is connected to the domain, you get a domain profile. Now, go to a hotel and connect to their WiFi; you get a public profile. You can read full details on what the NLA service is and how it affects your connection on TechNet.
Confirming NLA is the culprit:
Once you have confirmed that you are indeed connected to a domain network and the server is able to contact the domain controllers, you can check the NLA and confirm that this is the root cause of the sudden change in policies. To do this, open the services on the affected server and locate the NLA service.
Restart the service and check your network again. Are you on a domain profile now?
If the answer is “yes” then we have successfully found the cause of the sudden change in network profiles.
Why did this happen?
The most likely cause of this issue is a slow connection most commonly found in networks that span different geographies. Maybe you have 2 offices and your SQL server is not in the same location as your domain controller. Or maybe your company has embraced the cloud and you are in a hybrid setup with domain controllers in the office and your SQL server in Microsoft Azure.
Unlike domain authentication, the NLA service will only run at different times: 1) at startup or 2) when a network connection changes. On a server, your network connection typically won’t (and for good reason) change therefore the NLA will set the network location at startup and not query again until the next restart of the service (typically on the next reboot). If the NLA service starts before the domain has authenticated with a domain controller, it assumes that it’s on a public network.
Now for the fix:
Simply change the startup type from the default setting of Automatic and now set it to Automatic (Delayed Start).
This will still allow the service to run at startup but allow a little more time for the domain to authenticate before the service checks for the network location.
Want a better solution?
Reach out to New Signature to find out how we can help your company most efficiently leverage the power of Windows 10 coupled with the cloud to avoid these types of problems in your environment.
