locked
SCCM 2012 R2 Single Server Implementation - Migration to Multiple Servers for Fault Tolerance and Performance RRS feed

  • Question

  • Hello all. Hoping to get some answers to a few questions about role migrations and best practices. We currently have SCCM 2012 R2 implemented on a single server, for the most part. Here's how our current setup looks:

    • VM1 (at datacenter) - Primary Site Server, Asset Intelligence synchronization point, Fallback status point, Endpoint Protection point, Application Catalog website point, Application Catalog web service point, Distribution point, Site database server, Management Point
    • VM2 (at datacenter) - Distribution Point
    • VM3 (onsite) - Distribution Point (PXE), State Migration Point

    Now that SCCM is working how we want it to at our main site, we'd also like to get SUP going here, as well as at our remote locations. Here's my thoughts on splitting up the roles to introduce a bit of load balancing and fault tolerance:

    At Datacenter

    • VM1 - Primary Site Server, Distribution Point, Endpoint Protection, Site database
    • VM2 - Distribution point
    • VM3 - Application Catalog web service point, Application Catalog website point
    • VM4 - Asset intelligence synchronization point, Reporting services point
    • VM5 - Software update point

    Main site

    • VM6 - Distribution point (PXE; fallback), State migration point, Management point with SQL replica

    Remote sites

    • VM7 - VM14 (eight separate sites, one VM at each site) - Distribution point (PXE), Management point with SQL replica

    We plan on continuing to do OSD at our main site, introduce OSD to our remote sites, and introduce SUP to our main and remote sites. Just wondering if this implementation seems like a good way to introduce some load balancing and fault tolerance. Obviously, this is in general, as everyone won't really know much about the capability of our network. 

    Besides that, I had planned on migrating our primary site server to a new VM running Server 2012 R2 (it's currently in a VM running 2008 R2). From what I've read, it seems the easiest method here is to bring up another VM with the same name and partitions as the primary site server, and just restore the primary site and database to this new server. However, I wanted to go ahead and migrate anything off the primary site beforehand. 

    Reporting services seems easy, looks like I can just install it on a new server, and import any custom reports. However, I'm not seeing any information on how I would go about migrating an Assset intelligence synchronization point, or the Application catalog components. Any thoughts/information on how I would go about migrating that off our primary site server?

    I realize this is a lot to ask, but I'm hoping to get at least some information. I really appreciate any help and/or advice anyone has to give me. Thanks. 




    • Edited by Yabos Friday, February 20, 2015 5:59 PM Formatting
    Friday, February 20, 2015 5:54 PM

All replies

  • One question, how many clients?
    Friday, February 20, 2015 6:17 PM
  • VMs 3-5 in you above proposal will be idle most of the time. Those roles are the least of your worries as far as perf goes and thus moving them off is a complete waste of time.

    The best thing you can do is to move your client facing roles -- MP, DP, SUP -- onto a separate site system to separate them load wise from the site server. Then to add HA at the client communication layer, you simply add additional site systems with these client facing roles also.

    For your remote locations, placing an MP is also worthless because clients do *not* use MPs based upon location so they would/would all be traversing the WAN to access a DP. (As of CU3 you can hardcode which MPs a client may use, but this is more trouble than it's worth to configure and manage). Generally, the only thing you need at the remote locations is a DP and SMP.

    Thus, leave your AI sync point and Reporting Services point on your primary site server -- you will be much better served by this. The app catalog components are completely stateless (as is the AI sync point) so moving them is trivial but there generally is no need to do so. I would leave those on the primary site server also.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Friday, February 20, 2015 9:31 PM
  • VMs 3-5 in you above proposal will be idle most of the time. Those roles are the least of your worries as far as perf goes and thus moving them off is a complete waste of time.

    The best thing you can do is to move your client facing roles -- MP, DP, SUP -- onto a separate site system to separate them load wise from the site server. Then to add HA at the client communication layer, you simply add additional site systems with these client facing roles also.

    For your remote locations, placing an MP is also worthless because clients do *not* use MPs based upon location so they would/would all be traversing the WAN to access a DP. (As of CU3 you can hardcode which MPs a client may use, but this is more trouble than it's worth to configure and manage). Generally, the only thing you need at the remote locations is a DP and SMP.

    Thus, leave your AI sync point and Reporting Services point on your primary site server -- you will be much better served by this. The app catalog components are completely stateless (as is the AI sync point) so moving them is trivial but there generally is no need to do so. I would leave those on the primary site server also.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Thanks for the great advice. I did neglect to mention that we've separated out the remote locations by using boundary groups, with a boundary group for each remote location (i.e. boundary group main, boundary group remote 1, boundary group remote 2, etc). So, that's why I wanted to put a single VM with DP and MP roles (with the MP using SQL replica) at each location. Then, have one of the DP at the main site perform as a fallback point. Would your advice still stand with that new information?

    I also noticed that you can remove the DP role from the primary site server. Do you recommend removing it to increase primary site performance, considering I was going to keep a separate DP at our datacenter, and another DP on our main site (for OSD with PXE)? Again, appreciate the help and advice. 

    Monday, February 23, 2015 1:34 PM
  • Yes. As mentioned, clients do not choose MPs based on location. Clients do not use boundaries or boundary groups to locate MPs or any other criteria for that matter -- MP location by clients within a domain is completely random. Multiple MPs, by design, are for high availability and not remote locations. Client to MP traffic is generally negligible though so unless you have severely constrained bandwidth or lots of clients across a WAN link, this traffic should not be of any concern.

    As mentioned, I move the client facing roles to separate systems to isolate client communication from the site server while also placing the three roles which can easily be made highly available on a separate site system. Duplicating this site system (not in technical terms but in functionality) thus provides HA at the client access layer while also separating the load of these site roles from the site server.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Monday, February 23, 2015 2:51 PM
  • Yes. As mentioned, clients do not choose MPs based on location. Clients do not use boundaries or boundary groups to locate MPs or any other criteria for that matter -- MP location by clients within a domain is completely random. Multiple MPs, by design, are for high availability and not remote locations. Client to MP traffic is generally negligible though so unless you have severely constrained bandwidth or lots of clients across a WAN link, this traffic should not be of any concern.

    As mentioned, I move the client facing roles to separate systems to isolate client communication from the site server while also placing the three roles which can easily be made highly available on a separate site system. Duplicating this site system (not in technical terms but in functionality) thus provides HA at the client access layer while also separating the load of these site roles from the site server.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Sorry for the late reply, just got around to being able to deal with this again. You do mention that client to MP traffic is usually negligible, but one consideration is our 8 remote sites only have a 10Mbit connection back to our main site. We're hoping to upgrade it in the near-future, but who knows. The clients at each remote site can vary from about 30-100. However, the amount of clients active at each site are very sporadic. Since they are remote campuses, they are usually only busy when the students are on-site (once to twice a week), and the remainder of the time there can be anywhere between 20-40 faculty/staff machines active. On the flip side, the students are only getting Windows updates when they're on campus (currently with just WSUS, but we are planning to use SUP). 

    My main concern when trying to decide whether we should place MP with SQL replica at each remote site was in trying to figure out what the client would do if the main site MP went down while they were on campus. But, since it appears that we wouldn't really be making each client communicate with their respective MP, would you suggest putting up at least a couple remote MP for fault tolerance? That way, if the main site MP does go down, or the link to the main site goes down, the remote sites can still communicate with an MP?

    Just for clarification, you said the only thing you generally need at a remote location is a DP and SMP. By SMP you mean State Migration Point, correct? Also, do you believe removing the DP role from the Primary site server generally increases performance? 

    Again, I appreciate all the help and advice. Thanks. 

    Tuesday, March 3, 2015 2:46 PM
  • 10Mb is actually quite a bit. Policies are usually around 10-20KB per client every hour. Even with 100 clients, that's still at most 1-2MB every hour.

    For fault tolerance, yes I usually recommend placing at least two MPs. -- not remote though. That would mean if your main MP goes down, all clients will traverse the smaller remote WAN link and depending upon your WAN topology that's not a direct route.. Fault tolerance in roles should be provided at the same location. If the main site goes down, you've got bigger issues.

    Correct on the SMP.

    For the DP and perf, I wouldn't necessarily say increases perf, but it does remove that load from the site server and all of the traffic and memory overhead associated with it. Just like the MP and SUP, adding HA for the DP is simply a matter of adding multiple instances of the role and these roles are all client facing roles. Thus, it makes sense to put them all on the same site system and duplicate that site system (configuration wise) to both isolate all client traffic and provide HA.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Tuesday, March 3, 2015 3:24 PM

  • We choose to split our central SCCM infrastructure on four servers. 

    one is siteserver

    one is MP

    the third is SUP/WSUS and AIS

    the fourth is software catatalog and FSP

    None has the DP role. 

    Instead we have a rule that says that if a location has seven users or more they get a DP server. It will then have DP (with PXE) and SMP roles

    We also have one central DP server configured as a fallback server for the locations that are too small to get their own DP

    Tuesday, April 7, 2015 1:44 PM