I'm currently looking into an issue on my client's network, where I am attempting to access a file share on a NAS device from a Win2k8x64 Standard server via an alias. Even if I just map the NAS device name such as "\\NASalias" I get the above error code, but if I map it using the real name eg "\\NASname" it connects without an issue. I'm able to ping both names successfully, with the alias resolving with the NAS' real name FQDN. This started to happen in the middle of the night when no changes were made to the configuration of the system. A batch job running on the Win2k8 server connecting to the NAS via the alias worked perfectly fine , and then 20 minutes later failed and has been ever since along with the above mapping via Windows. I can guarantee that the server was not rebooted or patched in that 20 minute window (it was last patched and rebooted 4 days prior) If anyone has any suggestions I'd appreciate it. Update I've also found that if I connect to the alias using its FQDN the connection works successfully, same with using either short of FQDN of the real name (A Record) of the NAS. The issue only occurs when attempting to connect using the short name of the alias. Ive tested the same connection from another Win2k8R2 server pointed at the same DNS & WINS servers, with the WINS settings set to NetBIOS over TCPIP (on both systems) and it works fine from the other Win2k8R2 server.

Hi, Thanks for posting here. > The issue only occurs when attempting to connect using the short name of the alias. What if perform “net view NASalias” in command prompt ? If it works when access via other name formats I’d suggest you might try to clean DNS cache on this problematic, disable and reenable NIC to see if any improvement Meanwhile, Can you verify the full error event record that regarding this issue form event viewer and post back here ? Please include it’s ID and description. Thanks. Tiger Li Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Can you verify the full error event record that regarding this issue form event viewer and post back here ? Please include it’s ID and description. Tiger, Unfortunately there is no such event log entry on the server when this occurs. All I get if attempting to browse from Windows explorer is the error as described in the discussion subject

Hi WesL, Thanks for update. Could you also try to add the registry keys below on problematic windows host and see if any improvement: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters Value name: DisableStrictNameChecking Data type: REG_DWORD Radix: Decimal Value: 1 HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\BackConnectionHostNames Added the CNAME to this key. NOTE: Please untick the option Do not require Kerberos preauthentication under the user properties under Account. We have ticked this option to eliminate the Kerberos issue. Thanks. Tiger Li Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Tiger, I have done the above reg key entries (which both needed to be created). As a minor clarification for anyone else following this thread, the BackConnectionHostNames is a Multi.String Value (or a Reg_MULTI_SZ). Please also confirm exactly where you mean for the "do not require Kerberos preauthentication" option. Is that a Local Security Policy setting and if so exactly where in the policy is that? Without a reboot I've tested these and they currently dont make any difference, so I therefore suspect a reboot is required? Please confirm if a reboot is required for them to take effect.

Hi WesL, Thanks for update. To clarify the registry key “BackConnectionHostNames” part, please refer to the method 1 in KB 926642 , and yes , restart is requited: Original Method 1 (recommended): Create the Local Security Authority host names that can be referenced in an NTLM authentication request To do this, follow these steps for all the nodes on the client computer: 1. Click Start, click Run, type regedit, and then click OK. 2. Locate and then click the following registry subkey:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 3. Right-click MSV1_0, point to New, and then click Multi-String Value. 4. In the Name column, type BackConnectionHostNames, and then press ENTER. 5. Right-click BackConnectionHostNames, and then click Modify. 6. In the Value data box, type the CNAME or the DNS alias, that is used for the local shares on the computer, and then click OK. Note Type each host name on a separate line. Note If the BackConnectionHostNames registry entry exists as a REG_DWORD type, you have to delete the BackConnectionHostNames registry entry. 7. Exit Registry Editor, and then restart the computer. The option "do not require Kerberos preauthentication" is under “Account” tab of user properties ,account be used for accessing to remote fileserver form problematic host: Thanks. Tiger Li Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi WesL, I want to see if any improvement after rebooting? Please keep us posted on your progress and let us know if you have any additional questions or concerns. Thanks. Tiger Li Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Tiger, As this is a production server in a large corporate environment, I am not able to reboot the server at will as I am restricted by a fairly regimental change management process. The server is already scheduled to be rebooted on the coming weekend due to MS patch deployment, so I will check to see if the above recommendations resolve the issue after the reboot is performed. On a side note, are you possibly able to suggest any reasons as to why this issue would have occurred when no known changes were made to the server that could have impacted it, as the server had been working fine for 4 days since its last reboot, when the problem started to occur on its own at 8:30pm at night. I can confirm form the server's logs that there were no modifications done to the server or the script being used that brought the issue to my attention.