Windows Server 2012 - Prompt on accessing network resource from server hosting resource

Question

Here's an odd one that I've not been able to crack.

For my home lab setup, I've got two near identical physical servers that run Windows Server 2012 R2.

The goal of my home lab setup is to be able to do LAB stuff, without disturbing my wife's requirements to keep streaming content via PLEX, or listening to music via Sonos. So I setup a DNS record called STORE, and this DNS A record points to the server that is the primary file storage, server 1 will sync it's files in the early morning each day, so if I need to bring down server 1 , server 2 can take over as it will have near identical content. All I'd need to do would be change the IP address associated to the DNS A record of "STORE" from server 1 to server 2, and run a script to un-map / re-map the drive mappings on the clients, this part works fine, however, I've run into one snag.

If I logon to the server who's IP is currently set to the DNS A record of "STORE", I'm presented with a prompt for domain credentials when I put in the UNC path of \\STORE into the run box, or via windows explorer, actually inputting my current username/pw over again doesn't clear the prompt , instead, it says 'username/pw is incorrect', screenshot is linked here:

DNS is fine, i can ping the resource, and DNS returns back the correct FQDN/IP name, ipconfig /showdns also shows correct info, i'm not using WINS/host files.

I'm able to open the network resource when I put in the FQDN of the server, as in \\SERVER1\

The reason i want this to work, is because i now want to setup ROAMING profiles, but I want to use the name of \\STORE\USER PROFILES\USER1, etc, instead of \\SERVER1\USER PROFILES\USER1, etc. As the "STORE" network resource doesn't currently connect properly with my current setup, i'm not able to proceed.

-I'm using System Center Endpoint 2013 as my AV / host protection client.

-Windows Firewall is on, with default settings, except that ICMP/RDP are opened.

I'm thinking it has be something simple, right? Any ideas what would cause this? Thanks in advance for anyone's help!

Solution

By default Windows servers will not accept connections that are initiated with an alias. To enable servers to be accessed by a DNS alias name, create and enable the DisableStrictNameChecking option HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters on each server.

If the servers are joined to an Active Directory domain, you can also add the SPN of the alias to the computer that currently owns the name. However, if the SPN is added to a computer, you will need to remove the SPN and add it to the other computer when you change the alias to point to it.

https://support.microsoft.com/en-us/kb/281308

Another setting is the DisableLoopbackCheck. This isn't necessary for clients to access the server by the alias, but if you need to access the alias from the server itself, you will need to set DisableLoopbackCheck to 1.

https://support.microsoft.com/en-us/kb/926642

Comments

[Tony Hinkle]

Do you have an Active Directory domain set up? What version of Windows are the client PCs running?

[Tony Hinkle]

I'm not 100% sure of all the details, but I think enabling DisableStrictNameChecking might work for you: technet.microsoft.com/en-us/library/ff660057(v=ws.10).aspx bonusbits.com/main/…

[Kenny]

Thx so much, Tony !!I I enabled that setting, and this one: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa DWORD: DisableLoopbackCheck=1 And the issue is resolved!! Have a great weekend!

[Tony Hinkle]

Glad I could help--yes, DisableLoopbackCheck allows you to access the server by an alias from the server itself. I will add that to the answer as well.

[Steve365]

@TonyHinkle SMB2 and above don't need DisableStrictNameChecking to be set in order to access file shares using an alias. This is only applicable to SMB1. If the server and all clients are SMB2+ capable (Vista / 2008 and above) then this step isn't necessary. Info on this is hard to find on Google, but the "More Information" section in this KB explains - support.microsoft.com/en-us/kb/281308. This only applies to remote connections, for local loopback connections the DisableLoopBackCheck still applies I believe

[MrCalvin]

Nice! Setting the DisableLoopbackCheck was the trick, and I didn't even had to restart the server or any services.