The Network Location Awareness service

Posted on by Glenn

Good morning.  I wanted to share an issue I see on a regular basis.  This has to do with the NLA (Network Location Awareness) service.  For those that are not aware of this service it is responsible for determining the type and safety of the network(s) the computer is connected to.  There are 3 network classifications that are used.

  • Public – The NLA determines the computer is directly connected to the Internet or is on an unsafe network.  This is also the default profile assigned to a network adapter until one of the other profiles can be determined.
  • Private – The NLA determines the computer is isolated from the Internet by a NAT (Network Address Translation) device or router.
  • Domain – The NLA determines that the computer is connected to a domain.  It does this by attempting to contact a domain controller.  More specifically it performs a DNS (Domain Name System) query for a SRV (Service) record.  It will then make a connection to the domain controller.  If this is all successful, the domain profile is set.

So what is the purpose of the NLA and setting a network profile?  The primary purpose is for the Windows firewall.  Other applications and services can also access this data though.

Now that the NLA service is sufficiently explained, on to the common issue with it.  The NLA service by default is set to Automatic for its startup type.  Normally this works fine and the NLA properly detects the network.  There are some situations though where the service fails to set the profile correctly on startup.  I typically see this on domain controllers in a domain with just one domain controller.  This means that the network stack and DNS server service have to fully initialize and start before the NLA queries the network.  If they do not then the NLA is not able to contact a domain controller and assumes the computer is connected to a private or public network.

Regardless of the reason why the NLA is failing at startup the solution is fairly simple.  I have seen a 100% fix rate with simply setting the service startup type to Automatic (Delayed Start).  Doing this forces the NLA service to wait until all Automatic services have started, giving DNS enough time to start.  I have seen this little trick work with other services when they are having trouble at startup.

I hope you found this article informative.  If I missed anything or you just want to comment, please feel free to do so below.

Advertisement

SMB 1 in Windows 10

Posted on by Glenn

Today we have a quick tip from Luis, one of my partners in crime.  He had a customer that was experiencing poor file sharing performance with Windows 10 clients.  After replicating the environment Luis discovered the issue was due to the SMB (Server Message Block) version being used.  He was able to increase the performance by forcing a lower version of SMB to be used.  He discovered though that SMB version 1 is no longer supported by default in Windows 10.  He found a way to turn it back on.

I wanted to share that with you as it can be useful in a situation where there is an older file server.  When I say older, think Windows 2003 or Windows XP.  So it is no wonder than Microsoft has decided not to allow SMB 1 by default.  I don’t recommend following this procedure simply to increase performance as the trade-off is less security and fewer features.  Also following the below process will not by itself increase speed, as the highest version of SMB will be negotiated*.  This process will allow a Windows Server 2016 or Windows 10 client to connect to an older Windows system hosting a file share.

To enable SMB 1 do the following on the Windows Server 2016 or Windows 10 client.

  1. Open the registry editor and navigate to the following key:
    HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation
  2. Open the DependOnService key.
    default
  3. Add MRxSmb10 to the list below MRSmb20 entry and click OK.
    new
  4. Close the registry editor and restart the Workstation service.

 

I hope you enjoyed this article and found it informative.  If you have anything to add or just want to comment, please feel to do so below.

 

*If you are dead-set on running SMB 1 to improve performance have a look at this Microsoft article.

How to measure available network bandwidth

Posted on by Glenn

This is an issue I see from time to time.  A server appears to be “slow” on the network.  When you run into this kind of an issue it can be difficult to troubleshoot as there are a considerable number of variables that may be causing the “slowness”.  One of the first tests I like to perform is to test the available network bandwidth.  It is fairly easy to test and will cut the possible culprits in half.

Below is a step-by-step on how to test, accompanied by a diagram.  A note on testing.  In the diagram below the Problem server and Working server have the same network path back to the Client PC.  This allows an apples-to-apples comparison to be made.

iperf bandwidth diagram

  1. Download the Iperf utility.  You can get it from here.  Copy it to the Client PC, Problem server and Working server.
  2. Extract the Iperf zip file on the Client PC, Problem server and Working server.
  3. On the Client PC, open an administrative command prompt and navigate to the folder with the extracted Iperf binaries.  Run the following command*: Iperf3.exe -s
  4. On the Problem server, open an administrative command prompt and navigate to the folder with the extracted Iperf binaries.  Run the following command**: Iperf3.exe -c 192.168.1.9 -w 2m -t 30s -i 1s
  5. Repeat step 4 on the Working server

 

The Working server and Problem server can now be compared directly.  If the speed and amount of data transferred are very close, then the network can be virtually eliminated as a cause of the “slowness”.  Also it is unlikely there is a network card hardware or driver issue.
However if the Problem server transferred significantly less data or the transfer speed was significantly lower, then the network needs a closer look. To rule out the network switch, swap the network switch ports of the two servers, and repeat step 4 and 5 above.  To rule out the network cable, swap the network cables of the two server and repeat step 4 and 5 above.  If problems continue, then update the network card driver and firmware on the problem server.  If at this point the issue remains, it is time to take a closer look at the operating system on the Problem server.

 

*Iperf runs on port 5201 by default.  If a firewall is enabled on the Client PC, the firewall will need to be disabled or an inbound rule created
**Change the IP address to match the system you ran the iperf.exe -s command on.