DFS Structure help

Discussion in 'File Systems' started by Barkley Bees, Dec 3, 2008.

  1. Barkley Bees

    Barkley Bees Guest

    I am setting up DFS (R2) right now with namespaces and replication. I think
    I may be making a fundamental mistake though with the structure. I will only
    be using it for user folders at this time so I:

    - created my namespace server: Server_A
    - Namespace name and settings: USERS (E:\DFSRoots\USERS\) <- Shared the
    Users folder


    Everything is great up to this point as I can now see "\\domain\users". When
    I go to the Namespaces folder on the DFS Management conosle and drill down
    to \\domain\users I don't see anything in the "Namespace" tab on the right.
    I can of course add folders from but the existing subfolders under "USERS"
    don't appear here.

    Have I made "USERS" the DFS Root in this case? Should I be instead be
    structuring it so that "USERS" is a namespace folder? I'm a little lost
    now..ugh! Thanks.
     
    Barkley Bees, Dec 3, 2008
    #1
    1. Advertisements

  2. Barkley Bees

    Marcin Guest

    Barkley,
    DFS is commonly used to minimize number of drive mappings/providing a single
    point of entry to mulitple network shares. If this is your longer term goal
    (obviously this does not apply at this point), you might want to change your
    approach (and create a generic top level namespace with Users as its
    folder). Otherwise, you will need to create another namespace (which, btw.
    is certainly a possibility) if you decide to add another set of shared
    folders to your DFS hierarchy at some point in the future...

    hth
    Marcin
     
    Marcin, Dec 3, 2008
    #2
    1. Advertisements

  3. Barkley Bees

    DaveMills Guest

    What I have done is
    a) Create a DFS root like you. I called mine Storage so I have \\domain\storage
    b) Added various folders to storage e.g. Users, Public, Confidential
    c) Added links in these above folders the point to the physical data location
    via it \\server\share reference. e.g.
    \\domain\storage\public ---> \\server\public$
    For home folders I added another layer so I can have home folders on the
    department own servers
    \\domain\storage\users\legal ---> \\legalserver\users$
    \\domain\storage\users\engineers ---> \\engineersserver\users$

    No data is ever stored directly in the DFS folder only Links are put there.
     
    DaveMills, Dec 4, 2008
    #3
  4. Barkley Bees

    Barkley Bees Guest

    Thanks for the answers. As mentioned before, mine is setup as
    \\domain\users\ with the user folders in that directory. When I create the
    actual user folders via AD Users & Computers (multiselecting a batch of test
    user accounts - home folder: \\domain\users\%username%) the folders are of
    course created but I notice they do not appear in the DFS Management console
    namespace tab. Of course I can create a folder on the Namespace tab and it
    appears in the users directory but I am left to wonder what the difference
    is between the two ways of creating folders?

    If may ask, why did you create them as hidden shares ($)?

    * that said, I am considering going with the route you suggested David
    (\\domain\dfs\users or similar). Not sure what the 'best practice' would be
    in this case though.
     
    Barkley Bees, Dec 4, 2008
    #4
  5. Barkley Bees

    DaveMills Guest

    I do not know why the folders do not display in the DFS Management console, I
    have never tried to have non DFS managed folders within the DFS root.

    In my opinion this is a poor design because you have no control over the
    replication. All DFS root servers get a replicated copy of the content of the
    DFS root and you cannot change that. This means that many GB of data will be
    moved between the root servers when they synchronize. There is no interface for
    managing the schedule or any other parameters. You may be able to via DFSUTIL or
    registry changes but the system is not designed to be used in this way so I
    would not be surprised to find a future update changing things in a way the will
    break your system. You should change the design to have \\Domain\DFSRoot\Users
    where Users is a link to a \\server\users($) share where the actual %username%
    folders are stored. If you want replication of the Users folders then simply set
    it up when you add a second link to another server share. This will be far more
    flexible. You may have 2 replicated copies of the "Users" folder, no replication
    on the "Public" link or any other combination you desire. The way you have
    things will not allow you to expand the system for future needs, to change
    target servers etc.

    (A side note: Be careful with the NTFS permissions in the physical DFSRoot
    folders, these are not replicated but inherited from the parent folder when the
    root server is set up. I had one copy with Admin=F/C + Everyone=R and the other
    as Everyone=F/C. It took me some time to figure out how people were able to add
    files to the root because when I looked I saw the more restricted permission
    set)


    If you have not yet read "How DFS works" on
    http://technet.microsoft.com/en-us/library/cc782417.aspx
    You may find it very useful. I can't say I remember it all but it sure helped me
    understand why I needed to be careful with the design.

    So users will connect to the DFS paths and not the server UNC path (I know this
    is not enforced). If users connect to the UNC name directly I loose to ability
    to move the share to a new server and simply change the link in the DFS console
    to point to the new location. Instead I have to get all clients to change their
    configuration.
     
    DaveMills, Dec 5, 2008
    #5
  6. Barkley Bees

    Barkley Bees Guest

    1. Thanks for the advice, I have got my Namespace and Replication in place
    as follows:

    Server_A E:\Users$
    Server_B E:\Users$

    Namespace: \\domain\DFS\
    Namespace folder: USERS

    (I will be configuring the users' home path in AD as follows -
    \\domain\dfs\users\%username%)

    We are attempting to have Server_A be the main server with Server_B as a
    "hot stand-by" so to speak. So, I have configured Server_A to be "first
    among all targets" and Server_B to be "last among all targets in Namespaces.
    I have done the same for the Folder "Users" in Namespaces. Does this appear
    to be correct?

    3. I have set up a replication group for these folders to sync. We will be
    replicating ~2TB of data between severs. What would be the recommended quota
    sizes for:

    -Staging folder (4096MB default)
    -Conflict and Deleted folder (660MB default)

    4. To facilitate our "hot stand-by" goal, we would like to implement one-way
    replication but I am beginning to wonder if there is any merit to this. I
    had planned to simply disable (not delete) the replication connection from
    Server_B -> Server_A to prevent it replicating back to the primary. The in
    the event of a failure on the primary server I would enable this connection
    after recovery so Server_B could replicate back to Server_A.

    Can anyone advise on this, should I abandon 1-way replication?

    5. How does VSS work with DFS? Do I simply enable VSS on both servers'
    volumes that host the shared folder in the replication group and restore
    from the active server when required? Or is the VSS restore done from the
    \\domain\dfs\share ?


    6. I have asked this before but didn't get a clear response, does anyone
    know about SiS (single instance storage) and getting it to work correctly in
    a DFS scenario? I am a little bit wary of enabling this service as I don't
    know how it would be have with the Common store folder not being replicated
    (and also how it would function with VSS).

    7. Do most of you using DFS deploy the Client failback patch (kb898900)?

    Appreciate any feedback as always. Thanks.
     
    Barkley Bees, Dec 8, 2008
    #6
  7. Barkley Bees

    DaveMills Guest

    I assume you means E:\Folder shared as Server_X\Users$ in both cases.
    Created using the DFS Management console I assume.
    That is what I did but I often found Server_B was the active target even though
    Server_A was operating normally.
    You cannot configure the target for a folder in the root only a link or the DFS
    root itself, unless I have missed something somewhere.
    Notice that the replication group will be replicating the physical folders not
    via the shares. i.e. E:\Users$ on each server. I think you can even remove the
    shares and DFS namespace and replication will continue (pointlessly)
    Um, you will need to be absolutely certain that the clients cannot connect to
    Server_B and as I noted above they sometimes will. This would mead actually
    disabling the referrals to server B and manually enabling they in a failure.
    This is what I am thinking of doing but not for several months.
    This was answered in another thread as the VSS runs independently on each
    server. I have not looks and as yet do not have the resources to set up the
    replication.
     
    DaveMills, Dec 8, 2008
    #7
  8. Barkley Bees

    Barkley Bees Guest

    Thanks for the advice DaveMills. Btw, I have found a good article on Staging
    folder configuration which I will follow:

    http://blogs.technet.com/filecab/archive/2006/03/20/422544.aspx

    There are several factors that affect the size of staging. Without going
    into theories, here are some rules of thumb:
    1.. It is desirable to set the staging folder to be as large as possible
    (as available space) and comparable to the size of the replicated folder.
    Hence if the size of the replicated folder is 24.5 GB, then ideally a
    staging folder of comparable size is desirable. Note that this amortizes the
    cost of staging and hash calculation over all connections. It is also a best
    practice to locate the staging folder on a different spindle to prevent disk
    contention.
    2.. If staging cannot be set comparable to the size of the replicated
    folder, then reduce the size by 20%. Depending on how well the data
    compresses, staging files will be 30-50% of the original file size.
    3.. Note recommendations (1) and (2) are particularly important if all the
    data is preexisting and DFS Replication must process all content at the same
    time during initial replication. On the other hand, if the replicated folder
    is relatively empty and gradually grows over time, the recommendation is to
    determine the projected size of the replicated folder and size the staging
    appropriately.
    4.. If the size of the staging folder cannot be set proportional to the
    size of the replicated folder, then increase the size of the staging folder
    to be equal to the five largest files in the replicated folder.
    5.. Also monitor for staging clean up events in the DFS Replication event
    log (for example, event 4208 followed by 4206, which means that it was not
    possible to stage a file due to lack of space and no further clean up was
    possible), or frequent clean-up events (4202 followed by 4204). If more than
    a few such event-pair occurs every hour, then increase the size of staging
    by 50%.
     
    Barkley Bees, Dec 12, 2008
    #8
  9. Barkley Bees

    DaveMills Guest

    Thanks, I have sent that to my hint and tip folder.
     
    DaveMills, Dec 12, 2008
    #9
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.