This link is a very interesting read: http://social.technet.microsoft.com/Forums/en-US/winserverPN/thread/58e53691-64cd-44b9-98a2-ff1697e3ea83 logged in 2008 and still unresolved. I was wondering if MS have any plans to fix this issue? The issue occurs with Windows 2008 R2 (and I guess Windows 7). Two NICs, one pointing towards the internal network, one pointing towards the Internet, obviously on different subnets. The one pointing to the Internet has a default gateway, the one pointing inwards doesn't, but there are static routes for routing traffic over the internal WAN. DNS is only configured on the Internal network. Firewall is disabled. The server is in a workgroup but shares the FQDN suffix with the domain. Now, before saying anything else: this configuration works. Traffic is correctly routed in both directions, name resolution works just fine because it's a standard dual-homed setup. Well, it almost works. The problem occurs because the process that detects the internal NIC type (home, work, and so on) spends 5 minutes trying to determine the type, with the little picture of a screen in the task bar and the little circle sits there for 5 minutes. During this time, it is identifying the network and whilst it is doing that, Windows keeps the NIC disconnected. (BTW, the other NIC that points to the Internet is quickly identified as Public and has no issues.) So, for 5 minutes after each boot, the server is unusable which is clearly a pain. (It also causes some apps no end of issues as they fail to start properly because they assume that it would be crazy to assume that it takes 5 minutes to work out the connection type! Anyway, let's not worry about the apps - that's all fixable with some scheduled tasks to restart failed services once Windows has got its own house in order.) It appears to be a well-known issue with Windows since Vista, and there are numerous "fixes" posted, all of which, IMHO, are not acceptable. Examples are: 1. Use local policy to force "unidentified networks" to "private". The problem with this is that the OS still has to mark the connection as unidentified before it cane be marked as "private". 2. Put a default gateway on the internal NIC as well and keep the cost high. Sadly it works! Sadly? Because I don't like servers with multiple default gateways. And neither do Microsoft. 3. Hack the NdisDeviceType. I confess I haven't tried this, but I don't like the sound of such OS hacking for what I consider to be a standard setup. 4. Disable the NLA service. Again, this is a real sledgehammer to crack a nut, and the supportability of such a hack appears questionable. (I tried it and it didn't work for me anyway!) So far, that's all I've found. The fix that MS should introduce is simple: allow the admins to say "Hey, Windows, this is on a private network, so you don't need to waste 5 minutes trying to work it out. Sure, Microsoft knows best, but in this case, I really do know where I'm plugging things into, so you can trust me. No really, you can - I've been working on Unix systems since before Windows even existed." :) Maybe that option already exists, in which case would someone be so kind as to enlighten me? TIA PS. In the meantime, I'll keep on researching.

Hi Mark, Thanks for posting here. Windows will identify and apply the proper firewall profile for a specify interface through series of steps, we can read that form the blog post below: Network Location Awareness (NLA) and how it relates to Windows Firewall Profiles http://blogs.technet.com/b/networking/archive/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles.aspx From your descriptions, I understand that the internal facing interface which has no default gateway entry assigned was been recognized and applied “unidentified” profile. Actually this is expected, system will label the interface as “Unknown” if it has no gateway. we can get the detail explication form the article below : Why is my network detected as “unknown” by Windows Vista or Windows Server 2008? 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 For the hotfixes regarding network location awareness components we can refer to the articles in the link below: http://blogs.technet.com/b/networking/archive/tags/network+location+awareness/ Regards, Tiger Li TechNet Subscriber Support in forum If you have any feedback on our support, please contact tnmff@microsoft.com.Tiger Li TechNet Community Support

Thank you for the background info. Does the hotfix fix the problem? From the description, it appears to fix a different issue.

Hi Mark, Thanks for posting here. This is not a problem but a by design behavior which was been introduced in the articles I just posted . The workaround so far is that we need setting a proper default gateway address for the internal facing interface. Regards, Tiger Li TechNet Subscriber Support in forum If you have any feedback on our support, please contact tnmff@microsoft.com. Tiger Li TechNet Community Support

Hi Tiger, thanks for the reply. Two things I notice here: 1. http://support.microsoft.com/kb/157025 states that "Only one default gateway should be configured on any multihomed computer." So, applying two default gateways breaks MS's own guidelines. If the scenario that I have given in my OP is a supported exception, then I'd be interested to get this confirmed? 2. The second article explains why Microsoft chose to have "unknown" behave like it does. It states that "Since Windows cannot uniquely identify the network, if a persistent network profile were applied, it may be applied on a network that the user did not originally intend to be marked as a private network." OK, for Windows 7, I get that because Windows 7 users don't always do quite what they intend to do. ;) Bit I'm talking about system administrators with decades of experience configuring servers that don't move. Microsoft appear to be applying the same restrictions to such administrators to novice users. Would it not be better to allow administrators to tell the server: "Hey server, this is the connection you are connected - you'll just have to trust me that I know better than you!"?

Hi, Thanks for posting here. I totally understand you concern however for security reason Windows will apply the public profile to the interface that be recognized as “unidentified” networks. Generally this is because there is not default gateway or it is not a domain joined machine. To workaround this behaviors so far , we can force system to set unidentified networks to get the Private profile instead Public byassigning the location type for the unidentified network properties in group policy : Regards, Tiger Li TechNet Subscriber Support in forum If you have any feedback on our support, please contact tnmff@microsoft.com.Tiger Li TechNet Community Support

Hi Tiger, thanks for the reply. Unfortunately the solution proposed doesn't work: please refer to my OP, point 1. It basically says that the OS still spends 5 minutes trying to work out that it is unidentified before setting it to private. This is true of both the Unidentified and the Identifying settings. So, the original problem still exists. I doubt very much that it is by design that Microsoft chose to have the server stay disconnected from the network for 5 minutes after every boot. Any thoughts on the fact that the only solution breaks MS recommendations? Also, I presume that the solution is to set the second default gateway and then make it a high metric? Finally, re the "it's for security reasons" amy be true, but that's not a consistent application of security principles. If MS did everything in their power to prevent admins overriding what the OS thinks is the best security even if the admin knows better, they'd prevent the firewall being disabled. But they don't. I suspect more realistically, it's just been coded that way. :)

Hi, Based on my experience, there is registry key which could control the NLA retry count during it detects the network of the NIC. Please try to open regedit and locate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache\ Then you can see the intranet and intranetAuth, please expand the two folders, there should be some subfolders under the two folders. Then click all the subfolders and set the following two registry key in them. Failures REG_DWORD with a value of 1 Successes REG_DWORD with a value of 0 This may cause NLA to go to its lowest retry count and reduce the idle time. Please try it and see if it works for you. Best Regards Scott Xie

Hi Mark, Please also take look the script in the link below and see if will help to specify the firewall profile we want to apply to 'Unidentified network’: http://gallery.technet.microsoft.com/ScriptCenter/2b6c59c3-5404-44ff-b8ac-eb73f9eee559/ Regards, Tiger Li TechNet Subscriber Support in forum If you have any feedback on our support, please contact tnmff@microsoft.com. Tiger Li TechNet Community Support

@Scott, thanks for the ideas: this sounds more promising. However, under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache I only have Intranet, no IntranetAuth. In HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache\Intranet, I only have values: there are no subkeys. I tried the Failures and Successes values in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache\Intranet anyway, but it didn't make any difference. @Tiger: the problem is not the firewall: it's the amount of time the OS spends working out which network it is on. I'll try it anyway and let you know.

@Tiger: The script appears simply to do the same as the local policy setting we discussed earlier. But, the network still takes 5 minutes to work itself out. :(

Hi, Thanks for the response. I think the related registry subkeys doesn't exist because it is a workgroup machine. The subkeys should exist if it joins the domain. Is it possible to join the server to the domain? Anyway, I'll try to do more research to see if there is any good workaround for the issue. Best Regards Scott Xie

Hi Scott, unfortunately not, it can't be added to a domain (it will be a Lync Edge server). FYI, I did add a second default gateway with a high metric (999) and although the server immediately asked me whether I was on a public, home or work network, when I rebooted, it still took a long time to do the discovery during the next reboot. That surprised me and I am investigating further.

Hi Mark, I guess there is any performance issue with the second NIC. Based on my experience, even though there is no default gateway configured on that, it should not take such a long time to do the discovery. Have you updated the NIC driver to the latest version? Best Regards Scott Xie

Hi Scott, yes that was exactly my thought. The driver is the latest, but I am going to try a separate network card in case it's the card itself. It just take a bit of planning to swap the card out - I'll let you know what happens.

Hi Mark, Have you tried to switch the network card? Best Regards Scott Xie

Unfortunately, not yet. I have to do it over a weekend to get downtime on the system, so I should know by Monday. Cheers Mark

Hi Mark, Have you done that? Best Regards Scott Xie

Update: new network cards make no difference. It still takes around 7 to 8 minutes (difficult to be exact) for network location to sort itself out. Looking like a bug in 2008 R2? Just need to find a workaround now. :(