Sign in
 
HomeLibraryWikiLearnGalleryDownloadsSupportForumsBlogs
Resources for IT Professionals >
> 
> 
> 
Going to implement DFS-R for branch office deployment servers

Proposed Answer Going to implement DFS-R for branch office deployment servers

  • Friday, March 01, 2013 7:45 PM
     
     
    Sign In to Vote
    0

    Hi fellas,

    Having gotten my head around DFSR, I was going to create a replication group in a hub-and-spoke topology for our 6 deployment servers around the country.  The hub will be the main office image server.

    My main question:  Since there will now be a single customsettings.ini and bootstrap.ini across all 6 servers, what changes do I have to make to ensure that clients at remote sites will PXE boot to the server at their site?  (WDS is in place, incidentally).  As I understand it, I have to make use of a default gateway property, but I have no experience with it.

    I do not use the database, by the way.

     

All Replies

  • Friday, March 01, 2013 8:07 PM
     
     
    Sign In to Vote
    0
    DFS if configured correctly should use the nearby server.  I don't think you have to do anything extra to your cs.ini or bootstrap.ini.

    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. ” How to ask a question that is fixable.

     
  • Friday, March 01, 2013 8:10 PM
     
     
    Sign In to Vote
    0
    I'm pretty sure you do, because the bootstrap.ini specifies the DeployRoot property as \\mainofficeserver\deploymentshare$.
     
  • Friday, March 01, 2013 8:25 PM
     
     
    Sign In to Vote
    0

    I would rather use linked deploymentshares and setup a scheduled task that syncronices the data between them. That way either location will get a customsettings.ini pointing correctly to the deployment share at their location. (and can easier get custom settings for that location if needed)

    Unless you route all your traffic at your main hub, then it will just send everything from the deployment share, up via your main location, back down to your client. Deployment share at location X > route up too main location > back down to client at location X = bad performance. We have this problem where I work, but considering we got physical gigabit+ links to all our diffrent locations around our country, we deploy every location from our main MDT.

     
  • Friday, March 01, 2013 8:59 PM
     
     
    Sign In to Vote
    0
    Well, I'd like to use DFS because we have some slow WAN links at some of our smaller sites, and as I understand it that is more suitable to DFS.
     
  • Friday, March 01, 2013 9:05 PM
     
     
    Sign In to Vote
    0

    Then I guess DFS is better if you have reaaally slow links. Updating linked deployment shares over slow connections can be, lets say you want to spend your time doing something else then waiting.

    I guess you could add something to your customsettings.ini that checks what gateway your clients uses, and then point out that if they are using gateway zzz.xxx.yyy.1 they should use the correct deploymentshare located their site, and not the mainsite.

    I know I have some customsettings.ini saved away with something similar at work, but since I just finished a 12 days-in-a-row stint, I have now love to return tonight to see if I find them =) I am guessing Johan Arwidmark or the 'DeploymentBunny' might have something similar on their blogs.

     
  • Friday, March 01, 2013 10:36 PM
     
     
    Sign In to Vote
    0
    I thought that WinPE didn't support connecting to DFS-R shares
     
  • Friday, March 01, 2013 10:45 PM
     
     
    Sign In to Vote
    0
    Doesn't it?
    • Edited by Atreus21 Friday, March 01, 2013 10:46 PM
    •  
     
  • Saturday, March 02, 2013 12:20 AM
     
     Proposed Answer
    Sign In to Vote
    1

    I am using DFSR across 20 sites without any issues.

    You should specify DeployRoot as \\%wdsserver%\deploymentshare$
    The DFSR target must be the WDS server.

    Ensure the share name is the same on all WDS servers.
    The %wdsserver% variable will be resolved during PXE boot.
    This guarantees that the correct DeploymentShare will be used
    (unless your PXE boot was screwed and you booted from the wrong WDS server)

    Was using Gateway at the beginning, but it is just one of several options.
    Currently using the selected PE Language at the beginning to load different site configurations.

    Not many people running this configuration it seems.

    Please mark as answer :)

    • Proposed As Answer by orioon Saturday, March 02, 2013 12:20 AM
    • Edited by orioon Saturday, March 02, 2013 12:23 AM
    •  
     
  • Wednesday, March 06, 2013 11:32 PM
     
     
    Sign In to Vote
    0

    Unfortunately %WDSSERVER% doesn't work for in-place migrations started within the OS, if that interests you. I used to use a robocopy replication process, and I just excluded customsettings.ini, bootstrap.ini and settings.xml from the copy job, so each server had their own copies.

    Now we use an MDT database with location records. We actually have the sql queries taking place in bootstrap.ini, and populate the ServerA variable per location, so our bootstrap.ini looks like this:

    Deployroot=\\%SERVERA%\Deployment$

     
  • Thursday, March 07, 2013 5:34 PM
     
     
    Sign In to Vote
    0

    I am using DFSR across 20 sites without any issues.

    You should specify DeployRoot as \\%wdsserver%\deploymentshare$
    The DFSR target must be the WDS server.

    Ensure the share name is the same on all WDS servers.
    The %wdsserver% variable will be resolved during PXE boot.
    This guarantees that the correct DeploymentShare will be used
    (unless your PXE boot was screwed and you booted from the wrong WDS server)

    Was using Gateway at the beginning, but it is just one of several options.
    Currently using the selected PE Language at the beginning to load different site configurations.

    Not many people running this configuration it seems.

    Please mark as answer :)

    Interesting configuration.  I'll try that.
     
  • Thursday, March 07, 2013 5:38 PM
     
     
    Sign In to Vote
    0

    Unfortunately %WDSSERVER% doesn't work for in-place migrations started within the OS, if that interests you. I used to use a robocopy replication process, and I just excluded customsettings.ini, bootstrap.ini and settings.xml from the copy job, so each server had their own copies.

    Now we use an MDT database with location records. We actually have the sql queries taking place in bootstrap.ini, and populate the ServerA variable per location, so our bootstrap.ini looks like this:

    Deployroot=\\%SERVERA%\Deployment$

    For the moment we aren't doing in place migrations entirely within MDT.  Good to know, though.
     
  • Thursday, March 07, 2013 9:32 PM
     
     
    Sign In to Vote
    0
    It looks like some people have had success with DFS-N which is what I was referring to earlier: http://social.technet.microsoft.com/Forums/is/mdt/thread/bfada25b-b605-44fd-be11-7029c22d6f3f

    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. ” How to ask a question that is fixable.


    • Edited by Ty Glander Thursday, March 07, 2013 9:42 PM
    •  
     
  • Thursday, March 07, 2013 10:03 PM
     
     
    Sign In to Vote
    1

    I did create custom Shortcuts for all sites, these shortcuts make MDT aware of the current site.
    (each local IT will only need one of these shortcuts for their site)

    There won't be any issues with the %wdsserver% variable entirely, because the Media Boot images will be used instead of the WDS boot media.
    The boot images don't have a Share specified in the bootstrap.ini (which would cause issues otherwise)

    Hope I explained it in an understandable way.

    Running it along with DFS-N as well of course.