none
Roaming Profiles using DFS? - is it possible?

    Question

  • Hi,

    Has anyone ever used DFS replication for roaming profiles?  Is it possible to specify a namespace for a roaming profle path?

    The dilema I have is that several users work between 2 sites at the moment.  Sites are connected via VPN, but only a standard ADSL line is used due to the size of the Organisaton and costs etc.

    I've already set profile size restrictions, but there can still be a lengthy delay pulling the profile and caching between sites.  I've already managed to replicate the company filestore, so data access should be significantly improved.

    The problem now is logon etc.  I did think about redirection, but clients are still XP so less group policy options. 

    Using Server 2008 Std R2 at each site with XP client.

    Really just looking for other engineers experiences / ideas for this kind of problem.  What have other people created in this situation?  I'm thinking more towards the re-direction of profile data and possible replicating that?

    Any help is greatly appreciated.

    Many Thanks.
    Thursday, November 05, 2009 3:31 PM

Answers

  • Hello Hozzie,

     

    ·         Generally speaking, using DFSR to replicate user roaming profiles isn't a good idea. This will cause some potential inconsistent issue.

     

    Let's assume that we have two servers FileSrv1 and FileSrv2 that will host profiles. You setup DFSR to replicate profiles between the two machines.

     

    Now let's imagine the following scenario:

     

    1) A user logs into their desktop, which downloads its profile from FileSrv1.

    2) The user makes changes to their profile and logs out.

    3) The changes are written back to FileSrv1

    4) DFSR sees the changes and begins replicating them to FileSrv2

    5) The user logs into their laptop, which downloads its profile from FileSrv2

    6) Since DFSR hasn't finished replicating the changes on FileSrv1 to FileSrv2, the user just receives a partially modified profile on their laptop

     

    Even more will be confusing to the client user would be the following scenario:

     

    1) A user logs into their desktop, which downloads its profile from FileSrv1

    2) The user makes some changes to their profile on the desktop

    3) The user logs into their laptop, which downloads its profile from FileSrv2

    4) The user makes some changes to their profile on the laptop

    5) The user logs out of both machines. Changes are written back to both FileSrv1 and FileSrv2.

    6) DFSR begins replicating and detects conflicts. Its conflict resolution algorithm applies the last-writer wins policy

    7) The profile that ends up on FileSrv1 and FileSrv2 is combination of the changes made from both machines, but may be internally inconsistent if configuration settings are stored across multiple files.

     

    Therefore, we don’t recommend you use DFSR to replicate Roaming profile in the case.

     

    Hope this can be helpful for you.

     

    Best Regards,

    David Shen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by David Shen Thursday, November 12, 2009 3:07 AM
    Friday, November 06, 2009 4:48 AM

All replies

  • Hi,

    Has anyone ever used DFS replication for roaming profiles?  Is it possible to specify a namespace for a roaming profle path?

    The dilema I have is that several users work between 2 sites at the moment.  Sites are connected via VPN, but only a standard ADSL line is used due to the size of the Organisaton and costs etc.

    I've already set profile size restrictions, but there can still be a lengthy delay pulling the profile and caching between sites.  I've already managed to replicate the company filestore, so data access should be significantly improved.

    The problem now is logon etc.  I did think about redirection, but clients are still XP so less group policy options. 

    Using Server 2008 Std R2 at each site with XP client.

    Really just looking for other engineers experiences / ideas for this kind of problem.  What have other people created in this situation?  I'm thinking more towards the re-direction of profile data and possible replicating that?

    Any help is greatly appreciated.

    Many Thanks.
    I did find this on DFS FAQ so will do some testing- but any advice would be appreciated.

    Is DFS Replication suitable for replicating roaming profiles?

    If the profile is accessed from only one location (such as the branch server), and the files are not locked for exclusive use by the user or an application, then DFS Replication can replicate the profiles back to a hub site without conflict.

    However, if a single file is updated in two locations in a short timeframe, a conflict will occur and only the file that was most recently updated will be replicated. Therefore, use DFS Replication for roaming profiles only if the user allows enough time for replication between accessing the profile from multiple locations.

    Thursday, November 05, 2009 3:34 PM
  • Hello Hozzie,

     

    ·         Generally speaking, using DFSR to replicate user roaming profiles isn't a good idea. This will cause some potential inconsistent issue.

     

    Let's assume that we have two servers FileSrv1 and FileSrv2 that will host profiles. You setup DFSR to replicate profiles between the two machines.

     

    Now let's imagine the following scenario:

     

    1) A user logs into their desktop, which downloads its profile from FileSrv1.

    2) The user makes changes to their profile and logs out.

    3) The changes are written back to FileSrv1

    4) DFSR sees the changes and begins replicating them to FileSrv2

    5) The user logs into their laptop, which downloads its profile from FileSrv2

    6) Since DFSR hasn't finished replicating the changes on FileSrv1 to FileSrv2, the user just receives a partially modified profile on their laptop

     

    Even more will be confusing to the client user would be the following scenario:

     

    1) A user logs into their desktop, which downloads its profile from FileSrv1

    2) The user makes some changes to their profile on the desktop

    3) The user logs into their laptop, which downloads its profile from FileSrv2

    4) The user makes some changes to their profile on the laptop

    5) The user logs out of both machines. Changes are written back to both FileSrv1 and FileSrv2.

    6) DFSR begins replicating and detects conflicts. Its conflict resolution algorithm applies the last-writer wins policy

    7) The profile that ends up on FileSrv1 and FileSrv2 is combination of the changes made from both machines, but may be internally inconsistent if configuration settings are stored across multiple files.

     

    Therefore, we don’t recommend you use DFSR to replicate Roaming profile in the case.

     

    Hope this can be helpful for you.

     

    Best Regards,

    David Shen


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by David Shen Thursday, November 12, 2009 3:07 AM
    Friday, November 06, 2009 4:48 AM
  • Hi Hozzie,

    I want to see if the information provided was helpful. Please keep us posted on your progress and let us know if you have any additional questions or concerns.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, November 11, 2009 4:15 AM
  • Hi David,

    Many thanks for your response.

    When I initially set the roaming profile path to a DFS share I encountered problems, so I decided to go down the standard roaming profile route with limits set.

    The main issue is the logon time between sites.  I've got it to around 3/4 minutes, which isn't bad.

    Moving ahead, would you say that re-direction is the best method for managing profiles?  Clients are still XP at the moment, but we'd be looking to move to Windows 7 in the near future.

    Thanks Again!

    Ian
    Tuesday, November 17, 2009 9:20 AM