Squarespace’s all-in-one platform gives you everything you need to express yourself creatively online, whether it is with a domain, website, or online store. Get started with your free trial today, and when ready, take 10% off your first purchase with offer code 'EXPERTS'.
Windows 10 issue with mapped drive
Been running some test PCs with Windows 10 installed and noticed this issue.
We currently have logon scripts which map a user to their needed network drives.
In this case, the mapped drive references an old server name which is actually a CNAME to the current server.
In Windows 7, this is working fine and the drives are mapped.
In Windows 10, when a user logs in, there is no drive mapped or error displayed.
It is when I try mapping it manually that I get the error "The target account name is incorrect."
Doing a ping test, the server name resolves fine and I can ping the server.
If I map it using the current server name, it works.
Is there a setting in Windows 10 I need to change?
We currently have logon scripts which map a user to their needed network drives.
In this case, the mapped drive references an old server name which is actually a CNAME to the current server.
In Windows 7, this is working fine and the drives are mapped.
In Windows 10, when a user logs in, there is no drive mapped or error displayed.
It is when I try mapping it manually that I get the error "The target account name is incorrect."
Doing a ping test, the server name resolves fine and I can ping the server.
If I map it using the current server name, it works.
Is there a setting in Windows 10 I need to change?
Asked:
-
4
1 Solution
LVL 14
Can you map it in Windows 7 using the new name. If you can - change you login script to use the new name. If not then modify the login script to change it based on the OS
Yes, it can and I had thought of changing the script but wanted to see if there is a way to fix it on Windows 10 without touching that.
I don't know the reason for the CNAME existing and would have to check if there are any applications relying on this naming before making a change.
I don't know the reason for the CNAME existing and would have to check if there are any applications relying on this naming before making a change.
Found this in Event Viewer logs on the PC when it tried connecting to the share the first time.
Doing it a second or third time does not log an error although the same pop up error message appears.
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server server2$. The target name used was cifs/server1. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMAIN) is different from the client domain (DOMAIN), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.
Doing it a second or third time does not log an error although the same pop up error message appears.
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server server2$. The target name used was cifs/server1. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMAIN) is different from the client domain (DOMAIN), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.
This registry key mentioned here: https://support.microsoft.com/en-us/kb/926642
is meant for Windows Server 2003 but it still applies in Windows 10.
Went to HKEY_LOCAL_MACHINE\SYSTEM\
Added Multi-String value BackConnectionHostNames and typed in the CNAME as the value.
Rebooted and it is now working!
Tried many, many other registry fixes and suggestions before landing on this one.
Went back to the PCs and undid all the other fixes just to confirm this was the only one needed.
Don't know why this is such an obscure fix, I would imagine there are many environments which have CNAMES set up on file servers for DR purposes.
Just glad this got it working even on the recently released 1607 build.
is meant for Windows Server 2003 but it still applies in Windows 10.
Went to HKEY_LOCAL_MACHINE\SYSTEM\
Added Multi-String value BackConnectionHostNames and typed in the CNAME as the value.
Rebooted and it is now working!
Tried many, many other registry fixes and suggestions before landing on this one.
Went back to the PCs and undid all the other fixes just to confirm this was the only one needed.
Don't know why this is such an obscure fix, I would imagine there are many environments which have CNAMES set up on file servers for DR purposes.
Just glad this got it working even on the recently released 1607 build.
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
Join & Write a Comment Already a member? Login.
Featured Post
Tackle projects and never again get stuck behind a technical roadblock.
Join Now