none
XP Clients unable to access Server 2012 clustered file share

    Domanda

  • Hi,

    I have a Server 2012 clustered file server. Clients are able to connect shares on this without problems from Win 7, Win 8 and Server 2008r2. However I am getting an error from XP and 2003r2 clients. I understand that XP and 2003 r2 will be using SMB1.0 whereas the newer Windows will be using SMB 2.0+.

    Trying to shares through DFS I get "\\dfsroot\path\etc is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. The network path was not found."

    Trying to access the share by a direct UNC path (i.e. no DFS) I get "\\fsc is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. Logon Failure: The target account name is incorrect."

    I've read that the second message can be related to DNS and have tried setting HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\DisableStrictNameChecking to 1 but this hasn't helped. I can't see anything obvious in the event viewer at either end.

    Has anybody got any suggestions where I can go from here?

    Thanks,

    Tim

    mercoledì 2 gennaio 2013 17:00

Risposte

  • Well, that's really strange - my problem has just fixed itself. The only significant thing I can think of that has changed is the domain controllers were all updated and rebooted for patch Tuesday. Neither the clients nor the cluster machines had their updates at the point it started working again.

    Chris - you don't say if you are seeing the same Kerberos errors as I was - I think that was the best clue about the cause of my issue. If so, may be worth giving your DCs a reboot.

    Tim

    venerdì 11 gennaio 2013 14:06
  • After a few months of everything running fine after it miraculously fixed itself, the problem re-occurred for me, for no apparent reason.

    I reopened the support case and was advised that there isn't a hotfix at the moment. The workaround as mentioned above is to take the cluster resource offline and repair it. A couple of people have queried what was meant by 'repair' - so to clarify :-

    Open Failover Cluster Manager

    Go to Roles -> Resources Tab -> File Server

    Right Click the File Server role -> Take Offline

    Wait for it to go offline, then Right Click -> More Actions -> Repair

    Wait for it to come back online

    Test your XP clients, they should be fixed. Obviously this process will take your file shares offline for a few seconds.

    Tim

    • Contrassegnato come risposta TimBoothby lunedì 29 aprile 2013 16:42
    lunedì 29 aprile 2013 16:41
  • Dear all,

    A public hotfix is now available. You must uninstall the private fix before install the new hotfix.

    http://support.microsoft.com/kb/2838043

    Laurent

    • Contrassegnato come risposta TimBoothby martedì 18 giugno 2013 14:10
    lunedì 17 giugno 2013 13:43
  • I got it sorted out.  It ended up being the Cluster Network Name of the old cluster we replaced.  I left that account in AD, but used that same name as an Alias on the new cluster.  It didn't like that.

    I removed the old cluster name object in AD and now the Alias and new Cluster Name work fine on my XP and 2003 clients.

    Thanks for all of the advice.  TimBoothby, your comments led me in the right direction.

    venerdì 11 gennaio 2013 16:34

Tutte le risposte

  • The first thing I would do is run a capture with Network Monitor from Microsoft, to see what exactly is happening at the packet level, how negociation occurs, what is the response, etc. I am not sure about 2012 but from what I read it is supposed to support clients connecting through SMB 1.0 . Make sure you don't have some gpo's or local policy settings misconfigured for digitally signing the SMB traffic.

    Check out this blog for more details about SMB signing issues: http://blogs.technet.com/b/josebda/archive/2010/12/01/the-basics-of-smb-signing-covering-both-smb1-and-smb2.aspx


    ...

    mercoledì 2 gennaio 2013 21:03
  • Thanks for the suggestions Marius - I'll try looking at some captures.

    Some further information to add - connecting using the clusters IP in a UNC path does work.

    I am also seeing occasionally (once so far today) on the client - Event ID 4

    The kerberos client received a KRB_AP_ERR_MODIFIED error from the server fsc2$.  This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named  machine accounts in the target realm, and the client realm.   Please contact your system administrator.

    Tim

    giovedì 3 gennaio 2013 12:00
  • Hi,

    If available please test:

    1. Logon an account which encounter this issue onto a Windows 7 system to see if same issue persists.

    2. Rename one of the computer name of a Windows XP system and re-join domain to see the result.


    TechNet Subscriber Support in forum |If you have any feedback on our support, please contact tnmff@microsoft.com.

    venerdì 4 gennaio 2013 09:06
    Moderatore
  • Hi Shoan,

    I am using the same user account on both the XP and Win 7 clients so I'm fairly sure it's not an account issue. Renaming the machine hasn't helped either. This seems to be a systematic issue - it's all XP clients on all user accounts.

    If I try to access the nodes directly I can't see the cluster shares on either XP or Win 7 - but no error either. I'm new to file server clustering but assume this is expected behavior. If I set up a non-clustered share on one of the nodes this is accessible on any client.

    The packet capture was showing a lot of KRB_AP_ERR_MODIFIED errors, but deciphering this further is beyond my expertise. From what I've read this is can be due to a mismatch between the name requested and the one responding - i.e. request is made to the cluster, but it's a node that responds. I've opened a support case for this and will report back the outcome.

    Tim

    venerdì 4 gennaio 2013 12:13
  • I am having this exact same issue.  We moved our file cluster from 2008 R2 over to 2012.  Our Windows 7, 8 and Server 2012 clients get their drive mapping without a problem. Windows XP and Server 2003 R2 SP2 clients do not.

    I can map a drive using the IP address, but not the DNS name.  When I ping the DNS name it returns the correct IP address.

    I am also getting the following error and warning in the Application log.

    Source: MsGina

    Event ID: 1010

    Description: Failed to set the user's home directory

    Data: 00000574

    ---------------------------

    Source: Group Policy Drive Maps

    Event ID: 4098

    Description: Group Policy object did not apply because it failed with error code '0x80070574 Logon Failure: The target account name is incorrect.' This error was suppressed.


    Chris Brookins

    mercoledì 9 gennaio 2013 15:12
  • Hi,

    Whether there is any child domain exists? If so, check if  the machine account of the affected systems in both the parent and the child domain with the same name.


    TechNet Subscriber Support in forum |If you have any feedback on our support, please contact tnmff@microsoft.com.

    giovedì 10 gennaio 2013 08:20
    Moderatore
  • In my case there is only a single domain.

    Chris Brookins

    giovedì 10 gennaio 2013 13:14
  • One interesting thing I found this morning was that if I log into a problem client as the local admin account everything works fine.  I can map a drive using the DNS name.  Log back into my domain admin account and it stops working.

    As a test I dropped a problem client into an OU that I block GPO inheritance on.  The problem still exists.

    I also logged in as a domain user account.  The problem still exists.

    giovedì 10 gennaio 2013 13:47
  • Well, that's really strange - my problem has just fixed itself. The only significant thing I can think of that has changed is the domain controllers were all updated and rebooted for patch Tuesday. Neither the clients nor the cluster machines had their updates at the point it started working again.

    Chris - you don't say if you are seeing the same Kerberos errors as I was - I think that was the best clue about the cause of my issue. If so, may be worth giving your DCs a reboot.

    Tim

    venerdì 11 gennaio 2013 14:06
  • I am receiving the KRB_AP_ERR_MODIFIED error.

    A reboot of all of the DCs did not change anything.  I am going to bring them up to date to see if that makes a difference.

    Thanks for the update.

    venerdì 11 gennaio 2013 15:55
  • I got it sorted out.  It ended up being the Cluster Network Name of the old cluster we replaced.  I left that account in AD, but used that same name as an Alias on the new cluster.  It didn't like that.

    I removed the old cluster name object in AD and now the Alias and new Cluster Name work fine on my XP and 2003 clients.

    Thanks for all of the advice.  TimBoothby, your comments led me in the right direction.

    venerdì 11 gennaio 2013 16:34
  • I was with the same problem if someone can help me. I has only one domain too;

    XP Messages and erros and wireshark captures:

    -> The Kerberos client received a KRB_AP_ERR_MODIFIED error from server srv-cluster01$. This indicate that the password used to encrypt the kerberos service ticket is different than that on the target server.
    Event ID: 4

    -> Kerberos Tickets that i believe that was with problem:

    Server: krbtgt/DOMINIO.LOCAL@DOMINIO.LOCAL
     KerbTicket Encryption Type: Unknown (18
     End Time: 1/29/2013 21:31:03
     Renew Time: 2/5/2013 11:31:03

    -> In a Kerberos troubleshooting, i can see DNSs querys success, icmp(ping) success and than, start negotiation and I has:

    Negotiate Protocol Request

    Negotiate Protocol Response:
    SMB(Server Message Block Protocol)
    -> Negociate Protocol Response(0x72)
    -> Security Blob: xxxxxxxxxxxx
    -> GSS-API Generic ...
    -> Simple Protected Negotiation
    -> negTokenInit
    -> mechType: 5 items
    MechType: 1.3.6.1.4.1.311.2.2.30 (iso.3.6.1.4.1.311.2.2.30)
    MechType: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
    MechType: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
    MechType: 1.2.840.113554.1.2.2.3 (KRB5 - Kerberos 5 - User to User)
    MechType: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTML SecuritySupport Provider)
    -> mechListMIC: xxxxxxxxxxxxxxx
    principal: not_defined_in_RFC4178@please_ignore

    Tasks really checked and done:

    -> Repadmin, dcdiag(everything is ok) i has only 2 domain controllers on a single domain;

    -> DNS Duplicated, i check every entry;

    -> SPN duplicated, i make setspn -r from all servers and workstations on this process;

    -> netdom /resetpw -> I make reset from servers account to know if it can be a problem too;

    I was with this problem yet, and don´t know how to solve, any ideas are welcome;

    Thanks Fabiano

    giovedì 31 gennaio 2013 11:28
  • Marius, i post messagens that i see, about SMB, XP Clients was negotiating SMB1.
    • Proposto come risposta 5ddunn lunedì 25 febbraio 2013 20:42
    giovedì 31 gennaio 2013 11:32
  • I had the same problem.  I opened a case with Premier support and they found the problem.  The temporary work around is to take the cluster shared resource offline then repair then put it back on line.  That will work until the next time the password is changed for that resource.  The perminated fix is coming in the form of a Hotfix.

    Dwayne Dunn

    Copiah-Lincoln Community College

    lunedì 25 febbraio 2013 20:45
  • Hi dwayne,

    I have the same problem and was wondering if you know the hotfix number Microsoft released to fix this issue.

    I would also ask what you meant by "repairing" the cluster share resource.

    Thanks

    Thierry 

    mercoledì 20 marzo 2013 14:32
  • Dwayne,

    I am having the same issue.  Would you happen to have the HotFix number and could you alaborate how what you mean by "repairing" the cluste resource?

    Thanks

    Paul

    lunedì 25 marzo 2013 13:50
  • My problem still occured ?
    Anyone can help me please :(


    The point is "If i login by "local user account" it can access cluster filesharing.
    But cannot do the same way for "Domain user account".

    I already delete all GPO that linked with domain user account but problem still the same.
    and already followed all step that you guys posted.
    Thank you
    mercoledì 27 marzo 2013 10:13
  • I got it sorted out.  It ended up being the Cluster Network Name of the old cluster we replaced.  I left that account in AD, but used that same name as an Alias on the new cluster.  It didn't like that.

    I removed the old cluster name object in AD and now the Alias and new Cluster Name work fine on my XP and 2003 clients.

    Thanks for all of the advice.  TimBoothby, your comments led me in the right direction.

    Thank so much!!! follow your way is the way out of this problem.
    Just create CNAME in dns and map with cluster DNS Name.

    Thank a lot man.

    giovedì 28 marzo 2013 02:30
  • After a few months of everything running fine after it miraculously fixed itself, the problem re-occurred for me, for no apparent reason.

    I reopened the support case and was advised that there isn't a hotfix at the moment. The workaround as mentioned above is to take the cluster resource offline and repair it. A couple of people have queried what was meant by 'repair' - so to clarify :-

    Open Failover Cluster Manager

    Go to Roles -> Resources Tab -> File Server

    Right Click the File Server role -> Take Offline

    Wait for it to go offline, then Right Click -> More Actions -> Repair

    Wait for it to come back online

    Test your XP clients, they should be fixed. Obviously this process will take your file shares offline for a few seconds.

    Tim

    • Contrassegnato come risposta TimBoothby lunedì 29 aprile 2013 16:42
    lunedì 29 aprile 2013 16:41
  • I had to take the extra step of deleting the Highly Available File Server computer account in the domain.  We do have two clusters being replicated with Double-Take Availability and the configuration requires that the File Server name is identical on both clusters but offline on the target cluster.

    Bill

    giovedì 9 maggio 2013 15:48
  • We have exactly the same problem.

    Following opening a case by our Premier Support, MS gave us a private patch for W2012. This patch was installed for almost 10 days and everything seems to work fine for now.

    If anyone wishes this fix, it can post here and I send it by email.

    Laurent


    venerdì 17 maggio 2013 07:13
  • Please, do share!

    Thanks

    lunedì 20 maggio 2013 15:07
  • You can find it here:

    http://tinyurl.com/2012ClusterXPAccess

    Bests,

    Laurent

    martedì 21 maggio 2013 05:51
  • Thank you!!!  Have you noticed any new issues since installing this patch?
    martedì 21 maggio 2013 11:16
  • No issue since we have installed this patch.

    The only thing I saw is a "cosmetic warning":

    Laurent

    martedì 21 maggio 2013 12:15
  • We have installed the Hotfix, but XP Clients still does not connect to the cluster share, we are prompted for a login. Input is not accepted, even if it is correct. No entries in clients or server event view.

    The Win7 clients connect without problems.

    Already tried:

    - cluster repair as mentioned above

    - updated and rebooted all DCs (all 2008 R2 in a single domain)

    I guess it is a kerberos thing, but don´t know where to look it up?

    Ideas anyone?



    • Modificato Solverino mercoledì 22 maggio 2013 09:20
    mercoledì 22 maggio 2013 08:49
  • http://tinyurl.com/2012ClusterXPAccess

    Thanks a lot! I paste this link in another topic about this problem http://social.technet.microsoft.com/Forums/en-US/winserverClustering/thread/a8fb8a1f-72ab-49bd-bb1d-435cf2168fe6/

    Из ослиного гнезда ... :)

    martedì 28 maggio 2013 04:54
  • You're welcome.

    Knowledge increases only if it is shared ;)

    Laurent

       
    martedì 28 maggio 2013 13:43
  • The hotfix didn't resolve the issue for us either.  Solverino-  Do you have any new developments?
    mercoledì 29 maggio 2013 18:03
  • I had this issue reoccur when the cluster computer account password updated and had to follow the fix again.  I have set the server nodes to disable the computer account password update as explained at http://support.microsoft.com/kb/154501?wa=wsignin1.0.  This should prevent an issue from reoccurring.  Hopefully a long-term fix will be released sooner than later.

    mercoledì 12 giugno 2013 20:28
  • Dear all,

    A public hotfix is now available. You must uninstall the private fix before install the new hotfix.

    http://support.microsoft.com/kb/2838043

    Laurent

    • Contrassegnato come risposta TimBoothby martedì 18 giugno 2013 14:10
    lunedì 17 giugno 2013 13:43
  • Installed this hotfix. Problem still appears to be present. XP clients still cannot connect to the cluster resource share using a domain user account.

    Applied the hotfix to both server nodes, rebooted the servers. Windows 7 clients connect without an issue, Windows XP clients still have the problem.

    How hard can this be for Microsoft to fix? Presuming that I have followed the procedures in the hotfix located in KB2838043 - correctly.

    Install reboot, not that hard to follow. Confirmed that the dll updates match that of the suggested hotfix.

    giovedì 11 luglio 2013 04:57