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

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.

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

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.

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 s

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.

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