Hi everyone – I just have one new networking-related article to share with you:
2018583 Windows 7 or Windows Server 2008 R2 domain join displays error "Changing the Primary Domain DNS name of this computer to "" failed...."
- Mike Platts
Hello, I am Robert Paige from the Windows Server Partner Ecosystem Team. I wanted to resurface a continuing support issue with deployments that I first commented on back in December of 2009, and again in a March post. After a very encouraging decrease in support incidents traced to this issue, we’ve seen an upward trend again for the same issue – perhaps a reminder will reverse the trend!
If you are running certain older versions of Symantec Endpoint Protection or Symantec Antivirus, you can get the solution from Symantec. Symantec confirms that this is a known issue and there are updates to resolve the problem. For more information, please see the Symantec Knowledge Base article about this issue. For information about Symantec support for Endpoint Protection 11, visit the Symantec Support site.
Please note: If you are unable to upgrade promptly or remove the software, Symantec urges you to contact their technical support to determine if there are any workarounds available to you.
While the error messages are not specific to this issue, and can often have other unrelated causes, versions of Symantec Endpoint Protection prior to version 11.0.4202 or Symantec Antivirus 10.2 on a Windows Server can cause these connectivity problems. The real frustration can be the difficulty in determining that the root cause may be due to these third-party products; the intermittent loss of productivity and reliability of client connections to the server often results in costly and time-consuming investigations. To make the matter even more frustrating, it does not happen immediately after installation of the security software, the interoperability issue can sometimes happen weeks after deployment.
Here are the most common symptoms you may experience that may help you diagnose this issue. Note that if you have this software installed, the easiest troubleshooting step to determine if this is the cause of connectivity issues is to simply remove the software and reboot the server.
KB 961293 Unable to access Shares "The specified network name is no longer available" when Symantec Endpoint Protection prior to 11.0.4202 (MR4-MP2) or Symantec Antivirus 10.2 are installed on a Windows 2003, 2008 or 2008 R2 Server
KB 961654 A file sharing connection to a Windows Server 2008-based server drops unexpectedly if the server has Symantec Endpoint Protection prior to 11.0.4202 (MR4-MP2) or Symantec Antivirus 10.2 installed
KB 948732 Network shares become unresponsive after some time on a Windows Server 2003 or 2008 or 2008 R2-based-based computer running Symantec Endpoint Protection prior to 11.0.4202 (MR4-MP2) or Symantec Antivirus 10.2, and you receive an error message
KB 923360 You may experience various problems when you work with files over the network on a Windows Server 2003-based or Windows 2000 Server-based computer
All of the articles also refer to the Symantec Knowledge Base article about the issue, including information about how you can obtain the fix.
Hi all – this week I have 5 new networking-related articles to share with you:
2366024 Primary DNS suffix for a Windows server 2008, Windows server 2008 R2, Windows 7, Windows Vista, deployment using an Answer file may not be set.
2282988 DNS Model for MBCA 2.0 for Windows Server 2008 - download location + rule documentation
2121546 MS10-069: Vulnerability in Windows client/server runtime subsystem could allow elevation of privilege
982802 MS10-066: Vulnerability in remote procedure call could allow remote code execution
Hi everyone – below are the most recently published networking-related articles:
2253198 Remote Desktop Gateway Installation And Public Configuration
2253032 DirectAccess Installation and Configuration
2253119 NLB migration questions and answers
2161341 Active Route removed on Windows Server Failover Cluster
Hi all – here are the most recently published networking-related articles:
2286940 802.1Q VLAN Tagging on NLB enabled adapters
2388131 FTP uploads using Windows Explorer and Internet Explorer are slower than FTP uploads using command prompt
I am writing this blog post because we get a lot of questions regarding how NLA determines a network profile and how it relates to Firewall Profiles as the two are often confused.
First let’s start with what NLA does. For each network interface the PC is connected to, NLA aggregates the network information available to the PC and generates a globally unique identifier (GUID) to identify each network. In other words, it creates a Network Profile for any network it connects to. The Windows Firewall then uses that information to apply rules from the appropriate Windows Firewall Profile. This allows you to apply a different set of Firewall rules depending on which network you are connected to. For example, a Public network could get a very restrictive set of rules, a Home network could get a less restrictive set of rules, and a Managed network could get a set of rules determined by an administrator. NLA can be used for more but I want to focus on how it interacts with the Windows Firewall.
So how does NLA determine which network it is connected to? It depends on which Windows version you are using.
In Windows XP and Windows Server 2003, detection is pretty basic and there are only 2 network profiles: Domain and Standard. If the Connection Specific DNS Name matches the “HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName” registry value, you get the Domain Profile. Otherwise, you get the Standard Profile. You can find more detail about Windows XP in the following Cable Guy article: http://technet.microsoft.com/en-us/library/bb878049.aspx
Since the Firewall in Windows XP only supported two firewall profiles, this system worked pretty well. The problem was that people don’t connect to just two kinds of networks and found they wanted a restricted set of firewall rules when connected to a public hotspot and a less restrictive set when they were at home, in addition to the firewall rules required by their admin. In Windows Vista, Microsoft introduced a new set of firewall profiles: Domain, Public, and Private. The idea is that any new\unidentified network will get the Public (most restrictive) profile to start with. If you are then found to be on the domain network, you will get the Domain (managed) profile provided by your administrator. That leaves the Private profile for users to configure in their own (semi – trusted) environment. To support the Private profile, network detection had to be enhanced. This was accomplished by gathering various characteristics about the network and using that information to create a network profile and assign a unique GUID that could be used to identify that network. Network identification still starts the same way that Windows XP did by determining if you are on the domain and if that fails it will try to match to a Network profile. The important thing to remember about Windows Vista is that you now have 3 profile choices but you can only have a single active Firewall Profile. So if the machine is multi-homed with a VPN connection, for example, you only get one Profile for all interfaces.
The big change in Windows 7 from Windows Vista is that now you can have multiple active profiles. The same network identification process takes place, but it is done for each interface. So now, for example, a VPN interface can have the domain profile assigned while the physical interface can get the public profile and be protected.
Note: Not all VPN clients work this way. The Microsoft VPN client registers as a network interface and will get an associated Firewall Profile, but third-party VPN clients may not register and thus would not get an associated Profile. The VPN connection will still work but the system will not be protected by the Microsoft Firewall on that VPN interface.
In all cases, detection starts the same way that it does in Windows XP. If the Connection Specific DNS Name matches the “HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName” registry key then the machine will attempt to contact a Domain Controller via LDAP. If both these steps succeed, you will get the Domain profile. It is important to note that if the steps succeed, processing stops here. This allows you to roam across multiple access points in the same domain without having to stop and identify each of them individually.
If the above steps are complete and a match to the domain was not found, NLA will evaluate the network characteristics to see if it can identify a match. If there is a profile created for that network (not to be confused with the Firewall Profile) the interface will get the Firewall profile associated with that network either Private or Public. If the network is not identified by one of the above methods it will remain with the Public profile.
Note: By default all new/unidentified interfaces get the Public Profile.
So how does it know which profile to associate with a network? Good question. The user is prompted when a new network is identified. They have a choice of Home, Work, or Public.
Home and Work will both give you the Private profile while Public will of course give you the Public profile. I am often asked if this can later be changed; the answer is yes. In the Network and Sharing Center, there is a link to “Customize” the network settings.
Note: Customization does not apply to the Domain profile as it is determined by your administrator.
Generally, the next question I am asked is about the characteristics that are used to identify a network. Based on pieces of information I have collected myself and from this MSDN article that provides information on what NLA can tell you about the network, I have put together the following table that I think covers what is used to identify a network.
This table shows the list of network characteristics NLA provides and indicates how applications may use them:
Managed
Indicates when the computer is managed by a domain controller.
Typically, computers that are part of a corporate network are members of a domain that is managed by one or more domain controllers. Therefore, the presence of such a domain controller usually indicates that the network is a corporate network. Applications may use this indication to attempt to discover and connect to corporate resources. Applications may also use this indication to apply policy or settings that are specific to the corporate network.
Bandwidth
Indicates the bandwidth of a TCP connection.
Applications may adjust their behavior based on the bandwidth of a TCP connection. For example, if the bandwidth to a mail server is low, then a mail client application may choose to download only the headers of messages, rather than entire messages.
Internet Connectivity
Indicates connection to the Internet.
Applications can use this as an indication that they can discover and connect to servers on the Internet or establish a virtual private network (VPN) connection to the corporate network via the Internet.
Primary DNS Suffix
The name of the domain for which the computer is a member or the DNS suffix of the computer's full computer name.
Domain names are closely related to the infrastructures of networks and as a consequence remain relatively static. When a computer moves around or returns to a given network, their Internet Protocol (IP) address may change, but their domain name suffix is likely to be the same. Applications can use this as a hint that the computer is connected the same network and apply policy or settings accordingly. However, the DNS suffix can be spoofed. Therefore, for applications where accurate network determination is needed, the DNS suffix should not be used as the only network identifier.
DC Authenticated
Indicates that the domain controller (DC) of the domain for which the computer is a member has authenticated the computer.
When the DC has authenticated the computer, applications may have a degree of confidence that the computer is on the corporate network and use this indication to apply policy or settings that are specific to the corporate network.
Host IP address
The IP address of the computer.
If the IP address of the computer is a public IP address, then remote applications can use it to establish a connection to the computer. For example, a help and support application could relay the computer's IP address to the corporation's help and support center, along with a description of the issues it might be experiencing so that a technician may connect to the computer to assist.
Subnet Mask
The subnet mask of the subnet to which the computer is connected.
The subnet mask is used along with the host IP address to obtain the network ID of the subnet.
Subnet IP address
The network ID of the subnet to which the computer is connected.
Applications may require a more granular network definition than a domain wide network. The network ID allows applications to identify the specific subnet to which the computer is connected. Group policy may be applied per subnet. As a result, it may also be useful for help and support applications to note the subnet to which the user is connected in order for a technician to resolve any issues. The subnet network ID is the host IP address logically ANDed with the subnet mask.
Default Gateway IP address
The IP address of the default gateway.
Like domain controllers, gateways (routers) on a subnet are also relatively static. Although the user may roam within a network and connect at different places, when they are configured with the same default gateway, it is likely that they are on the same subnet. Thus, applications may use the default gateway IP address as an indication that the user is on a particular subnet. Applications that require a more granular network definition than a domain wide network may also use the default gateway IP address. This is particularly useful on home networks because home users typically do not have their own domain.
WINS
Indicates whether the computer is connected to a network on which a Windows Internet Name Service (WINS) server is present.
In some enterprises, WINS may be used to resolve Network Basic Input/Output System (NetBIOS) names into IP addresses. In such enterprises, the presence of a WINS server may be used as an indication that the network is a corporate network.
SSID
When connected to a Wireless Network
Default Gateway MAC address
The MAC address is more unique than an IP address and therefore makes a better characteristic
802.1x Auth
Whether the PC is 802.1x authenticated to the given network
The “unknown” status has been covered by one of my colleagues in a different blog so I won’t go into detail here but I’ll provide a link if you would like to read more about it.
http://blogs.technet.com/b/networking/archive/2009/02/20/why-is-my-network-detected-as-unknown-by-windows-vista-or-windows-server-2008.aspx
It simply means that Windows cannot uniquely identify the network and will apply the public profile. Generally this is because there is not default gateway and it is not a domain joined machine.
You can use Group Policy to force certain settings. For example you can set unidentified networks to get the Private Profile by default.
There are four policies available beneath Computer Configuration->Windows Settings->Security Settings->Network List Manager Policies:
NLA attempts to identify the network you are connecting to so that you can apply an appropriate set of Firewall rules based on the connection type. It attempts to match the Connection Specific DNS suffix to the domain you are joined to, and if they match you get the Domain firewall profile. Windows Vista adds the additional requirement of successfully connecting to a DC. If that does not succeed, other networks are identified using various infrastructure characteristics and then a unique GUID is assigned to form a Network Profile.
Lastly, I want to share additional technical information about how and where NLA stores information in Windows Vista and later.
Another question I am often asked is about what calls are made when determining if the domain is accessible. This article has the most thorough description I know of:
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
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 to populate the following registry subkey:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache\IntranetForests
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.
Most info regarding NLA will be stored under the following three places:
Historical data can be found under the Cache key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache
Profiles are stored under the profiles key. Notice the GUID:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\{985EE69C-23B4-4D38-AC66-5F0D6AD8A128}
And managed Networks are stored under the Signatures\Managed key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Managed\010103000F0000F0A00000000F0000F077ABED71E35E1237A502490669F3BF81C3215FEB0A05CB1B6D53F11EB0B0D47C
While unmanaged networks are stored under Signatures\Unmanged:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Unmanaged
I think that about sums it up for now; I hope you find this information useful.
- David Pracht
Hey everyone – here are the most recently published networking-related articles:
2276930 Windows Vista Client releases its DHCP Lease during reboot unexpectedly
2029072 "Windows Easy Transfer can't connect to your other computer" error message when you try to transfer data to a Windows 7-based computer that has a Winsock LSP installed
2264080 An update rollup package for the Hyper-V role in Windows Server 2008 R2: August 24, 2010
2271812 You can't turn on the Windows Firewall in the Security Center
2288085 You get a security warning telling you that the Windows Firewall is turned off
2292301 You can't access shared files or printers in Windows