Jump to content


rdr222

When to place a DP at remote site

Recommended Posts

I have a 2012 R2 SP1 primary site that is servicing the main campus of the University I work at. All the site servers are located in the main campus data center. We also have a remote campus about 15 miles away from the main campus which utilizes the the servers in the main campus data center. For the most part this hasn't caused any issues, however when techs at the remote campus try to PXE boot and image a device, the TFTP portion of the boot process takes 10+ min to download the boot image as opposed to the 30 sec it takes on the main campus. Compounded when imaging multiple machines at once, 10 minutes turns into 20, 30, and so on, and is not feasible for the techs at the remote site.

 

We have worked with our network engineers to verify that there were no problems on the network causing this difference and after A LOT of testing we determined that everything is working correctly as it is currently designed. The time difference comes from how TFTP works with the whole send 1 packet, receive 1 packet process. On the main campus, this isn't much of a problem but the minuscule bit of extra time between packets going back and forth from the main campus to the remote campus adds up to the extra time in the boot process (we actually drew out the math).

 

So now, half of us are of the mind that we need to put a DP at the remote campus wants to start doing registry hacks and messing with DLLs to increase the TFTP window size.

 

Is there any criteria (Physical distance, bandwidth, latency, clients managed, etc) on when it is appropriate to place a DP (or any other roles) at a remote site? Any documentation I can show about the matter would be helpful. Thanks!

Share this post


Link to post
Share on other sites

Yeah, that link works, but it's very broad; it basically says "make decisions based on stuff!"

 

Consider the following to help you determine the appropriate number of distribution points to install at a site:

  • The number of clients that might access the distribution point

  • The configuration of the distribution point, such as PXE and multicast

  • The network bandwidth that is available between clients and distribution points

  • The size of the content that clients retrieve from the distribution point

  • The setting for BranchCache that when it is enabled, lets clients at remote locations obtain content from local clients

DP logic is based solely on bandwidth/client limit. If you have a lot of bandwidth, there's no need for it... unless you see PXE issues. There are hard limits on DP;

 

https://technet.microsoft.com/en-us/library/Gg682077.aspx#BKMK_SiteAndRoleScale

 

But the limit is 4000 clients; so if you only have 1 DP (Primary) serving 4k+ clients, than one "Should" be added if only from the scalability perspective.

 

I assume you have a fast link between main campus and the branch, so the "bandwidth" issue isn't a big deal. If PXE is truly your only pain point, I'd personally:

 

1) Tweak any PXE related settings/TFTP settings, ie, http://windowsitpro.com/configuration-manager/speed-sccm-tftp-performance-pxe-clients

2) Open a support case with MS outlining your issue; they may have more guidance.

 

Assuming those two steps fail, from my perspective, I'd just drop a DP at the site and be done with it. You seem to have already spent a lot of time, both yours and networkings, on troubleshooting it. If you take your hourly rate, plus networkings time, plus time wasted not doing other things, how much has this troubleshooting already cost? 1k? 5k? 20k? Unless your budget is nil or you have a hard and fast "no more server" rule, just set up a DP at the site and be done with it. Some things aren't worth troubleshooting that hard, and this, to me, seems to be one of those.

Share this post


Link to post
Share on other sites

True, but the main thing was in the opening paragraph of that section..."By default, a primary site server is configured as a distribution point. However, assign this role to a remote site system and remove it from the site server if possible."

 

I got the feeling that the OP was looking for a current/best practice outline for DP placement, and their testing has already provided the data they need for considerations in those bullet points.

 

I would be hesitant about the registry hacks, because you already know things are working correctly on the main campus...I would be concerned about the integrity of the data that's being sent across the WAN link, since that can be an issue when you make those registry modifications (though there are safe parameters for that, too).

 

Putting an additional DP would be my first inclination, too...hence the initial question regarding why they hadn't yet.

Share this post


Link to post
Share on other sites

Out of curiosity, what is keeping you from placing a DP at the remote site (aside from differing opinions)? Is it lack of a workstation/server to serve the role?

we have a small VMware cluster that we use to distribute some of the core infrastructure (DNS, DC, DHCP, etc) at the remote campus however it wasn't built with the amount of storage that placing a DP there would require and the differing opinions are from the people that write the checks for that sort of stuff. If we have some documentation or I can show that best practice says SCCM should be a part of that core infrastructure we place at a remote campus it would be helpful.

Share this post


Link to post
Share on other sites

Yeah, that link works, but it's very broad; it basically says "make decisions based on stuff!"

 

Consider the following to help you determine the appropriate number of distribution points to install at a site:

  • The number of clients that might access the distribution point

  • The configuration of the distribution point, such as PXE and multicast

  • The network bandwidth that is available between clients and distribution points

  • The size of the content that clients retrieve from the distribution point

  • The setting for BranchCache that when it is enabled, lets clients at remote locations obtain content from local clients

DP logic is based solely on bandwidth/client limit. If you have a lot of bandwidth, there's no need for it... unless you see PXE issues. There are hard limits on DP;

 

https://technet.microsoft.com/en-us/library/Gg682077.aspx#BKMK_SiteAndRoleScale

 

But the limit is 4000 clients; so if you only have 1 DP (Primary) serving 4k+ clients, than one "Should" be added if only from the scalability perspective.

 

I assume you have a fast link between main campus and the branch, so the "bandwidth" issue isn't a big deal. If PXE is truly your only pain point, I'd personally:

 

1) Tweak any PXE related settings/TFTP settings, ie, http://windowsitpro.com/configuration-manager/speed-sccm-tftp-performance-pxe-clients

2) Open a support case with MS outlining your issue; they may have more guidance.

 

Assuming those two steps fail, from my perspective, I'd just drop a DP at the site and be done with it. You seem to have already spent a lot of time, both yours and networkings, on troubleshooting it. If you take your hourly rate, plus networkings time, plus time wasted not doing other things, how much has this troubleshooting already cost? 1k? 5k? 20k? Unless your budget is nil or you have a hard and fast "no more server" rule, just set up a DP at the site and be done with it. Some things aren't worth troubleshooting that hard, and this, to me, seems to be one of those.

It is a fast link to the remote campus which is why the people in my dept that are against putting a DP there are against it. To them, since it's a fast link, their should be no reason to need a DP out there and there must be something wrong. We tried the reg tweaks and it didn't seem to improve performance much and i'm always hesitant to do those sort of thing because i figure if the tweak was better, it would be that way by default.

 

I'm really trying to make the case that SCCM DP/MP should be a part of the core infrastructure that we place at remote sites like this and am looking for the documentation to back it up.

Share this post


Link to post
Share on other sites

Out side of PXE boot are you seeing any other issues with APP or SU deployment?

 

How many computer are at eh branch office?

Why do you need to PXE boot there at all? Why not ship the computer back to the main campus and fix them there?

Share this post


Link to post
Share on other sites

Like Garth has mentioned this should be based on number of clients at remote site. You have a fast link so software updates may not be throthling the WAN links presently as like software application deployments. PXE initiated OSD of PCs in mass across the WAN links with no local PXE enabled DP will hammer your link, this is expected. If you dont do that much OSD imaging at the remote site then why not go with USB deployment considering you have AD/DNS there etc replicating from Data centre. Get your techs USB built pens with your custom image, software etc.. or get the agent on the machines and stage the OSD Task sequence out to them, either of these options will leave out the slow PXE performance you are experiencing but again all depends on your remote environment i:e number of clients, how much OSD occurs etc... But at the end of the day it is a simpler solution to configure a PXE/DP for the remote site and enable for unknown computer support and F12 your machine as required to pull down a pre deployed OSD task sequence where all the software associated with it resides on a local DP where the system resides so only the local network gets throttled!

Share this post


Link to post
Share on other sites

we have our SCCM environment setup in a distributed model and scoped out for the various colleges/depts own IT teams to use so shipping them back wouldn't work since that campus is where that IT teams does it's work. I believe that having a DP at that location is the obvious way to go, i was just looking for some documentation to back up my claim as well.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.