none
SCCM 1906 Managing Low Bandwidth sites in remote locations RRS feed

  • Question

  • By remote, I mean geographically remote. I am designing an SCCM implementation for a mining company high in the mountains of a third world country. There is a small office in the nation's captial and in the port office across the harbour. Most of the infrastructure will be in a small datacentre in the local mining town. What I am proposing is a CAS to manage the site from above, 3 primary site servers (one in the city office, one in the DC in town and another in the office at the actual mine site. There are fibre links betweeen the mine and the town. There are 3 other sites a fair distance from the town so I was thinking about a DP at each of these sites with a management point in the datacentre. There are redundant microwave links as well but they are low bandwidth, around 8-10Mbps.

    Would a secondary site server be a better option than the DP's? Has anyone else had experience with a similar environment?

    Tuesday, September 17, 2019 1:26 AM

Answers

  • I was considering a CAS for the bandwidth control.

    A CAS does not provide bandwidth control as that's not the purpose of a CAS. A CAS is for scale-out in terms of client count. Bandwidth control is a mechanism of of other facilities in ConfigMgr and Windows.

    As for connectivity, ConfigMgr is not critical for any business operations so a temporary loss of connectivity is more or less meaningless. Additionally, the clients are autonomous in that they carry out the actions provided to them in their policy without any explicit need for communication. Unless the comms outages were consistent *and* extended, this is not something I would worry about.

    As for physical distances, that really doesn't matter. The only thing that matters is connectivity.

    For reference, many oil and gas companies use ConfigMgr to manage systems on ships at sea connected using VSAT connections. Many, including those as large as 125,000 managed systems, use a single primary site.

    That doesn't mean you don't need to work around the outages on occasion, but it does mean that designing around them is most likely not the best path.


    Jason | https://home.configmgrftw.com | @jasonsandys

    • Marked as answer by Bea5tOfBourb0n Friday, September 20, 2019 12:40 AM
    Thursday, September 19, 2019 4:07 PM

All replies

  • Hello,
     
    Thanks for posting in TechNet.
     
    How many devices would be managed? It's suggested not to use CAS unless there are over 150,000 devices need to be managed. We could expand a primary to CAS if needed in the future.
     
    If we only need to manage the transfer of deployment content across low-bandwidth networks, I prefer to use remote DPs instead of Secondary Sites. You could refer to the following link to help determine whether you need a Secondary site. 
     
    Determine when to use a secondary site
     
    Hope my answer could help you and look forward to your feedback.
     
    Best Regards,
    Ray

    Please remembers to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, September 17, 2019 2:09 AM
  • +1 to no CAS. A CAS and multiple primary sites are not designed for handling geographically separate locations. While technically, it could work, it also adds a lot of additional overhead and latency that simply isn't required unless you have 150,000+ managed systems.

    As Ray noted though, without more details on each location including client count, actual bandwidth, and network topology information, there's no way to offer any specific guidance. 


    Jason | https://home.configmgrftw.com | @jasonsandys

    Tuesday, September 17, 2019 2:14 AM
  • There's only going to be around 1000 devices including physical & virtual servers, and workstations/desktops etc. I was considering a CAS for the bandwidth control. If this can be done better another way without a CAS then that would be preferred. The other problem with the network is they can lose communication between the different areas of the site. The mine is a couple of kms up the hill from the town (the main ICT office is located in town) and if comms is lost between the two sites, the mine pit office needs to continue running, hence why I was thinking of more primary site servers than what I would normally put in for an environment of this size.

    The city is about 800km away and there are two offices there, one in the CBD and one at the port across the harbour. Primary in the city office. Primary at the ICT office and another at the mine itself. Some of the locations are a few kms apart between a giant hole at the top of the mountain, their own power station a few kms down river, another smaller open cut mine and the ore processing mill are also kms apart. I want the city office to have full PXE, update and deployment capabilties as if it were a stand-alone site.  One or two other sites at the mine or town as well but the majority of machines can be taken into the ICT office for rebuilding if required.

    When I have more info about the actual bandwidth I'll post that up.
    Thursday, September 19, 2019 5:29 AM
  • I was considering a CAS for the bandwidth control.

    A CAS does not provide bandwidth control as that's not the purpose of a CAS. A CAS is for scale-out in terms of client count. Bandwidth control is a mechanism of of other facilities in ConfigMgr and Windows.

    As for connectivity, ConfigMgr is not critical for any business operations so a temporary loss of connectivity is more or less meaningless. Additionally, the clients are autonomous in that they carry out the actions provided to them in their policy without any explicit need for communication. Unless the comms outages were consistent *and* extended, this is not something I would worry about.

    As for physical distances, that really doesn't matter. The only thing that matters is connectivity.

    For reference, many oil and gas companies use ConfigMgr to manage systems on ships at sea connected using VSAT connections. Many, including those as large as 125,000 managed systems, use a single primary site.

    That doesn't mean you don't need to work around the outages on occasion, but it does mean that designing around them is most likely not the best path.


    Jason | https://home.configmgrftw.com | @jasonsandys

    • Marked as answer by Bea5tOfBourb0n Friday, September 20, 2019 12:40 AM
    Thursday, September 19, 2019 4:07 PM
  • >A CAS does not provide bandwidth control as that's not the purpose of a CAS. A CAS is for scale-out in terms of client count. Bandwidth control is a mechanism of of other facilities in ConfigMgr and Windows.

    This is where I started on that train of thought: https://docs.microsoft.com/en-us/sccm/core/plan-design/hierarchy/design-a-hierarchy-of-sites#BKMK_ChooseCAS

    It mentions bandwidth control there for the transfer data between sites. I've probably go the wrong idea about that by the sounds of it. I've scrapped the idea of a CAS and now thinking of a single primary at the top, a secondary in the city office abd either DPs or another secondary for the power station, mine, mill etc

    Friday, September 20, 2019 12:04 AM
  • The official documentation is somewhat misleading on this topic and also doesn't convey the main negative ramifications of choosing a CAS.

    As for the secondary sites, be careful there as they have issues high latency, low bandwidth links. The oil and gas examples from above found this out quickly on their VSAT connections.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, September 20, 2019 1:10 AM
  • Thank you very much. I've got a lot of information to consider. I'll comment how it goes later, it could be a 2 year project.
    Friday, September 20, 2019 1:25 AM