none
DFS - AccessStatus 0xc000003a on site server RRS feed

  • Question

  • Hi Guys,

    I have been trying to sort this problem for the last week or so.  We have recently set-up a DFS share setup on 11 new Server 2008 R2 domain controllers on a new domain around the UK. The DFS share contains installers for proprietary software that gets installed via group policy.  Users have complained that these automated installers can take over an hour which is certainly well above the expected installation time.

    Running dfsutil /pktinfo on our Birmingham Server I get the following results:

       0:[\BIRMAD1\ImgRoot] AccessStatus: 0xc000003a ( TARGETSET )
       1:[\EMEAMGT1\ImgRoot] AccessStatus: 0 ( ACTIVE TARGETSET )
       2:[\NORTAD1\ImgRoot] ( TARGETSET )
       3:[\GLASAD1\ImgRoot] 
       4:[\WATFAD1\ImgRoot] 
       5:[\LIVEAD1\ImgRoot] 
       6:[\IPSWAD1\ImgRoot] 
       7:[\PHOEAD1\ImgRoot] 
       8:[\BRISAD1\ImgRoot] 
       9:[\STOKAD1\ImgRoot] 
      10:[\CROYAD1\ImgRoot] 
      11:[\MANCAD1\ImgRoot]

    If I run the same command on any of the other servers I will get the same error - basically the preferred target (the one at position 0 which is determined correctly by the servers site in AD Sites and Services) always has an AccessStatus: 0xc000003a error.  Likewise the second server in the list \EMEAMGT1\ImgRoot (this is the PDC for the domain) is then always set as the active target no matter what site I try to access the DFS share from.

     

    Interestingly if I delete and re-create a namespace it will work for a couple of days - it will be set as the active target and client PC's can use the DFS share as expected.  Then, without any apparent change to the DFS namespace/replication this will suddenly stop and running dfsutil/ pktinfo will show the results above.

    I ran dfsdiag /TestDfsIntegrity which gave the following result:

    Starting TestDfsIntegrity...
    Validating the DFS metadata integrity of \\OurDomain\ImgRoot...

    Checking for DFS metadata consistency between domain controllers and the PDC emulator in the domain...

    Error: The specified server cannot perform the requested operation.

    Warning: Unable to access the DFS metadata for the following namespace: \\OurDomain\ImgRoot 

    Error: The specified server cannot perform the requested operation.
    Warning: Unable to access the DFS metadata for the following namespace: \\OurDomain\ImgRoot
    Error: The specified server cannot perform the requested operation.
    Warning: Unable to verify DFS metadata consistency on the following domain controller: EXETAD1.OurDomain.local
    Success: DFS metadata is consistent across all accessible domain controllers and the PDC emulator.

    Checking the registry of the namespace servers...

    Success: Registry information on namespace servers is consistent with the metadata in Active Directory Domain Services.
    Validating reparse points of all DFS folders in namespace: \\OurDomain\ImgRoot
    Validating access, access control list (ACL), target state of DFS folders in namespace: \\OurDomain\ImgRoot
    Checking for duplicate and overlapping folders (links) in namespace \\OurDomain\ImgRoot
    Duplicate and overlapping folders (links) test completed.
     

    Finished TestDfsIntegrity.

    Any advise would be most appreciated.  

    Thanks,
    Allan



    • Edited by izomyr Tuesday, December 20, 2011 1:03 PM Updated to include OS type
    Monday, December 19, 2011 12:51 PM

Answers

  • Hi Guys,

    Sorry for the lack of updates, I do think that I have resolved the issue now though the new namespace that I set up had exactly the same problem.  This led us to start thinking that there was something fundamentally wrong with our setup.  I happened to - out of desperation set all of our DFS replicas to read/write as opposed to read-only.   We copied the same hub-spoke topoology as we used in our S2k3 domain.

    All of a sudden - our DFS shares are accessible!  In an attempt to exmplain why this might be the case we found this article http://blogs.technet.com/b/askds/archive/2011/04/19/dfsn-and-dfsr-ro-interoperability-when-good-dfs-roots-go-bad.aspx (which describes a completely different error but the same resolution that we have implemented). 

    It seems the root folder of a DFS namespace can no longer have a read only relationship as it could in Server 2003.

    Hope this helps anybody else in the same situation.

    Thanks, Allan

    • Marked as answer by izomyr Thursday, January 26, 2012 10:40 AM
    Thursday, January 26, 2012 10:40 AM

All replies

  • Hi Allan,

     

    Thanks for posting here.

     

    May I know which OS are running on these domain controller ,especially on BIRMAD1? Meanwhile, since this is a domain controller, have we also verified if any AD replicate warring or error was been recorded on this server form event viewer ?

    Is appears users were unable to connect to the share folder on local BIRMAD1 but to other servers where at remote sites which connected with slow connection.

     

    I’d suggest to first update the latest NIC drive software and DFS patches for this server and try again to remove the namespace and add this server again to the namespaces:

     

    http://blogs.technet.com/b/yongrhee/archive/tags/dfs/

     

    Here are the links for troubleshooting:

     

    http://blogs.technet.com/b/askds/archive/2010/11/01/common-dfsr-configuration-mistakes-and-oversights.aspx

     

    http://blogs.technet.com/b/josebda/archive/2009/07/15/five-ways-to-check-your-dfs-namespaces-dfs-n-configuration-with-the-dfsdiag-exe-tool.aspx

     

    Regards,

     

    Tiger Li

     

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact  tnmff@microsoft.com.


    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.
    Tuesday, December 20, 2011 3:34 AM
  • Hi Tiger Li,

    Thanks for getting back to me, I really should have mentioned that all of these domain controllers are running Server 2008 R2.  Looking at the events on BIRMAD1 I can see only 4 events relating to the ADDS role all of which are info only (event ID 701 and 700 only - 2 of each) so no errors there.

    DFS Replication service on BIRMAD1 does not mention replication of the namespace at all with the exception of the initial setup and replication.  New files are replicated to the server though - just added one to be sure but there is no event in the log that would suggest a replication took place.  I do get plenty of events regarding replicating the Domain System Volume which is working fine.

    I will look into getting some of those DFS patches installed on the server over the weekend.  While I agree that updating the NIC can help all of these affected servers are different models so I doubt that all of them have poor drivers installed for each of their respected NIC cards.  However I will certainly give it a go on this server (assuming that the patches alone do not help).

    Thanks,

    Allan

    Tuesday, December 20, 2011 9:45 AM
  • Hi Allan,

     

    Thanks for update.

     

    OK, if there is any update on this issue, please feel free to let us know.

     

    Regards,

     

    Tiger Li

     

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact  tnmff@microsoft.com.


    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.
    Wednesday, December 21, 2011 10:03 AM
  • Hiya,

    Update: The issue still exists with the "imgroot" namespace, as a test I have created a new namespace "emeaimg".  This new namespace does not have an errors thus far.  As a temporary fix I intend to use the "emeaimg" namespace and once all of the  files/servers are replicated to it try (as suggested by Tiger Li) removing the old "imgroot" namespace and then re-create it.

    I will let you know if re-creating the imgroot namespace works (moving from it will be a slow process since so many scripts etc rely on it being there).

    Thanks, Allan


    • Edited by izomyr Wednesday, December 28, 2011 3:11 PM
    Wednesday, December 28, 2011 3:08 PM
  • Hi,

    The issue appears to be if some targets are configured for caching but others are not. If that is the case then the ones with caching enabled are selected regardless of site.

    1) If all DFS targets are configured for manual caching there is no failover.
    2) If all DFS targets are configured for caching disabled it first tries all targets before using the first target as it should. There is no failover.

    So if the Offline caching settings for the folder targets for that particular link was inconsistent.  The desired target server had Offline Files caching disabled where the rest of the servers hosting that link had caching enabled. It may cause such issue. so please check the offline files setting on each target.


    Best regards, Jason Mei 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.
    Saturday, December 31, 2011 4:17 AM
  • Hi Jason,

    Just checked the caching options on the folders (Folder properties --> Sharing --> Advanced Sharing --> Caching)

    All of the folders appear to have the option "Only the files and programs that users specify are available offline", this appears to be the default as the share is created automatically when setting up the namespace/replication using the DFS management console and I have not made any changes.

    I would assume if anything I would want to disable making this folder available offline across all servers?  The share hosts some very large application installers and I do not want clients dragging them down to their machine for offline use.

    Thanks, Allan


    • Edited by izomyr Tuesday, January 3, 2012 12:24 PM
    Tuesday, January 3, 2012 12:08 PM
  • Hi,

    Thanks for your information.

    Regarding currne situation, I just want to confirm if the caching for new DFS root  emeaimg have same setting as the problematica root imgroot


    Best regards, Jason Mei 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.
    Friday, January 6, 2012 5:37 AM
  • Hi,

    If we want to disable offline files setting for a specified DFS root, we could make the caching setting as "Files or Programs from the shares will not be available offline"


    Best regards, Jason Mei 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.
    Friday, January 6, 2012 6:21 AM
  • Hi,

     

    Is there any update on this issue? thanks for your time and cooperation.


    Best regards, Jason Mei 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.
    Tuesday, January 17, 2012 8:15 AM
  • Hi Guys,

    Sorry for the lack of updates, I do think that I have resolved the issue now though the new namespace that I set up had exactly the same problem.  This led us to start thinking that there was something fundamentally wrong with our setup.  I happened to - out of desperation set all of our DFS replicas to read/write as opposed to read-only.   We copied the same hub-spoke topoology as we used in our S2k3 domain.

    All of a sudden - our DFS shares are accessible!  In an attempt to exmplain why this might be the case we found this article http://blogs.technet.com/b/askds/archive/2011/04/19/dfsn-and-dfsr-ro-interoperability-when-good-dfs-roots-go-bad.aspx (which describes a completely different error but the same resolution that we have implemented). 

    It seems the root folder of a DFS namespace can no longer have a read only relationship as it could in Server 2003.

    Hope this helps anybody else in the same situation.

    Thanks, Allan

    • Marked as answer by izomyr Thursday, January 26, 2012 10:40 AM
    Thursday, January 26, 2012 10:40 AM