Announcement

Collapse
No announcement yet.

Problem with DFS in Server 2003 Ent. with XP Clients

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem with DFS in Server 2003 Ent. with XP Clients

    Hello,
    I am having a small domain for learning environment having Server 2003 Enterprise edition as the single domain and rest all pc as clients and all running Windows XP Professional. Also, all of my client pc is joined in the domain of my server 2003.

    Now, recently I created DFS under my domain and shared some folders in my clients and servers. The problem is that, I am not able to access the folders which are being shared in my client pc. Although I am successfully able to access all the folders shared by the server operating system. Whenever I try to access I get the following error:
    Code:
    \\MyDomain\Shares\client1share 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
    Although I am successfully able to access the same folder in my server os. I checked for the security permission as well. For the drive under my client pc in which the folder exists, I have set the following permissions:

    Code:
    Security Permissions:
    Administrators (Client1\Administrators): Full Control
    Domain Users (MyDomain\Domain Users): Read & Execute, List Folder Contents, Read
    SYSTEM: Full Control
    Users (Clien1\Users): Read & Execute, List Folder Contents and Read
    Code:
    For the shared folder, following permissions exist:
    Sharing Permissions:
    Authenticated Users: Full Control
    
    Security Permissions:
    Administrators (Client1\Administrators): Full Control
    Domain Users (MyDomain\Domain Users): Read & Execute, List Folder Contents,  Read
    SYSTEM: Full Control
    Users (Clien1\Users): Read & Execute, List Folder Contents and Read
    I am not able to figure out, what I am doing wrong here. Can anyone please help me out with this problem?

    Thanks,
    Vasu

  • #2
    Re: Problem with DFS in Server 2003 Ent. with XP Clients

    Did you check the DFS share settings?

    http://www.microsoft.com/technet/pro...d6c383967.mspx
    Best Regards,

    Yuval Sinay

    LinkedIn: https://www.linkedin.com/in/yuval14, Blog: http://blogs.microsoft.co.il/blogs/yuval14

    Comment


    • #3
      Re: Problem with DFS in Server 2003 Ent. with XP Clients

      Hello,
      Thanks for the link you sent to me yuval14. Although my problem still stays the same. Regarding the following guidelines, which i copied from the link:

      Use NTFS permissions to secure DFS targets. If you are using FRS to replicate DFS link target information, any permission changes you make on one member of the replica set replicate to other members. If you are not using FRS for automatic replication, you must set the permissions on targets and manually propagate any changes that occur.
      Yes, i am using all NTFS permissions on my all drives and all server and client computers and since i got only one server running in my network it makes no sense of using FRS.

      When setting NTFS permissions, always use the path of the physical folder (\\servername\sharename) instead of navigating through the DFS namespace to set permissions. This is especially important when you have multiple link targets for a given link. Setting permissions on a folder by using its DFS path can cause the folder to inherit permissions from its parent folder in the namespace. In addition, if there are multiple link targets, only one of them gets its permissions updated when you use the DFS path.
      All the permissions for my shared folders are set using the path of their physical folder. And also, i dont have any muliple link targets for any link.

      If you plan to use share permissions, note that FRS does not replicate share permissions; therefore, you must plan to implement identical share permissions for each shared folder in a replica set. If you do not, users might have inconsistent access to shared folders across the network.
      In my case, i share the folders by giving everyone Full Control and then further setting the restrictions by setting the per folder NTFS permissions

      To prevent the spread of viruses in read-only FRS-replicated content, give the appropriate groups the NTFS Read & Execute permission, create a group for administrators who update content, and assign that group the NTFS Modify permission. Do not grant permissions to the Everyone group. For additional recommendations, see "Permissions on a file server" in Help and Support Center for Windows Server 2003.
      In my case the NTFS permissions are set in the similar manner. Only the Domain Admins are set to Read & Execute permission rest all have only Reading and Listing Folder Contents.

      For FRS-replicated content, you must use antivirus programs that are FRS compatible and that do not change the security descriptor of files. For more information about FRS compatible antivirus programs, see article Q815263, "Antivirus, Backup and Disk Optimization Programs That Are Compatible with the File Replication Service." To find this article, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
      I am not using any Antivirus so this point does not apply on me.

      You must have permissions on the DFS configuration object in Active Directory to add and delete roots to a domain-based DFS namespace.
      I am using the server Administrator so by default i have got the full rights to add and delete roots in my domain-based DFS namespace.

      You can create DFS link targets that point to shared folders containing data that is encrypted by using EFS. However, you cannot use FRS to replicate those files among multiple link targets.
      None of my folders are encrypted using EFS and also like i said before, i am not using FRS in my domain.

      Do not enable the RestrictAnonymous registry value on DFS root servers. Doing so restricts anonymous access and causes DFS referral failures. This registry value is also part of the HiSecWeb security template, which is designed to help secure Internet Information Services (IIS) at the operating system level. For more information about the RestrictAnonymous registry value, see article Q246261, "How to Use the RestrictAnonymous Registry Value in Windows 2000." For more information about the HiSecWeb template, see article Q316347, "IIS 5: HiSecWeb Potential Risks and the IIS Lockdown Tool," in the Microsoft Knowledge Base. To find these articles, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
      I did not modify any registry entry for DFS so i guess this point as well wont be applicable for me.

      So, now could you tell me what else i should be looking for correcting the problem.

      Also, i am only using DNS in my server and haven't installed or configure WINS. Is this by any reason cause problem for my DFS not working!!!

      Thanks,
      Vasu

      Comment


      • #4
        Re: Problem with DFS in Server 2003 Ent. with XP Clients

        What DFS structures are stored locally on root servers?

        A. Stand-alone and domain-based DFS root servers store DFS-related information in the registry. All root servers also store a copy of the namespace structure on a local volume on the server in DFS root folders and link folders as follows.

        Root Folders

        When you create a DFS root, you specify a shared folder to use as the root folder. The root folder is accessible on the local server, although we recommend that you keep the root folder as uncluttered as possible. For example, you might place in the root folder a single file such as a readme file, which describes the contents and purpose of the namespace.

        Link Folders

        When you add links to the root, DFS creates special folders under each root folder. These folders, called link folders, are actually reparse points, and they display the following error message if you try to access them on the local server:

        E:\RootName\LinkName is not accessible. The network location cannot be reached.

        Users who access the link folders from across the network are redirected to the appropriate link target.

        If you include subfolders in your link names, such as Groups\Marketing, DFS creates the required subfolders that contain the link folder. For example, when you browse the namespace structure under E:\RootName on the local server, you can open the subfolder E:\RootName\Groups, but you cannot open the link folder E:\RootName\Groups\Marketing.

        http://www.microsoft.com/windowsserv...ew/dfsfaq.mspx
        Best Regards,

        Yuval Sinay

        LinkedIn: https://www.linkedin.com/in/yuval14, Blog: http://blogs.microsoft.co.il/blogs/yuval14

        Comment


        • #5
          Re: Problem with DFS in Server 2003 Ent. with XP Clients

          Found the solution to my problem and incase someone else also faces the same problem then they could go for the following fix which was originally suggested by some techie at MS Newsgroups.

          The fix was to add a DWORD EnableDfsLoopbackTargets new registry entry in my client XP machine with value 1 under HKLM/System/CurrentControlSet/Services/Mup/Parameters.

          The problem is somehow with client pc's which are updated to SP2. For more info, check out the following link:

          http://www.msfn.org/board/index.php?act=ST&f=34&t=26298

          Thanks,
          Vasu

          Comment


          • #6
            Re: Problem with DFS in Server 2003 Ent. with XP Clients

            I think that you meant for:

            http://support.microsoft.com/?kbid=898900
            Best Regards,

            Yuval Sinay

            LinkedIn: https://www.linkedin.com/in/yuval14, Blog: http://blogs.microsoft.co.il/blogs/yuval14

            Comment


            • #7
              Re: Problem with DFS in Server 2003 Ent. with XP Clients

              Yeah.. great.. i was looking for the same. But it seems like they added the article and updates very recently... Will save it in favourites for future reference. Thanks.

              Comment

              Working...
              X