It is likely that most installations of CM consist of a single primary site with all roles loaded locally on the same server. Depending on the hardware used (RAM and disk IO chief among them), this will suffice for many organizations. As companies grow and the workload of CM starts to stress the hardware of a single server, administrators need to offload roles to other servers.
Note
Note that while it was a best practice to offload SQL in CM07, we now advise keeping SQL on box in CM12 as SQL replication has replaced much of the file based replication of CM07. CM12 is native x64 code so there is no performance hit for a WOW64 translation like there was with CM07 on x64 servers. Underpowered VMs, however, might benefit from offloading SQL to more powerful servers.
Admins should move roles off as described in the the following How to do it... section until the primary site starts to perform as expected. We will start with both the Distribution Point (DP) and the Management Point (MP). Unlike CM07, CM12 allows for more than one MP with no default MP to define. Offloading these two roles will do more to alleviate stress than any other steps. For this step, have another server ready where you can move these roles to.
Add the machine account of the primary site to the local admin's group of the server taking on the MP and DP role.
If you need to prevent content from copying to any particular drive on the new server, drop a file on the root of the drive named
no_sms_on_drive.sms.From the CM12 admin console, navigate to Administration | Site Configuration | Servers and Site System Roles. From the Home tab on the ribbon, click on Create a Site System Server.
Enter the name of the new server, select the primary site code, and enter the FQDN of the new server.
Check the boxes for both Distribution Point and Management Point.
Check the box to allow CM to install the IIS role on the new server.
CM12 now gives you the ability to force content on a DP to drive letters of your preference. Choose as needed.
CM12 has moved the PXE service point to the DP. Select this option only if you plan to image devices with an F12 boot. Enable multicast only if needed. The rule of thumb in security is "less is better"; you reduce the surface area of attack and reduce the odds you have something to patch down the road.
CM12 can now verify the content of your packages on a DP, which reduces the chance of clients failing to install an application due to corrupt files. CM12 now allows you to associate DPs to boundary groups. Use this feature only if you're trying to protect the network, otherwise leave this alone as it introduces another possible point of failure in a distribution that you may have to troubleshoot one day.
For the MP settings, use the defaults for now; you can always set up SQL replication to the MP at a later time to reduce additional load.
Complete the wizard, and then read the
sitecomp.loganddistmgrr.logon the primary server andMPSetup.logon the new server to verify a successful installation.Test the new MP by stopping the SMS Agent Host service on the primary, and then verify that clients are contacting the new MP (check the
mpfdm.logon the new MP).Test the new DP by distributing content to it.
With a working MP and DP on another server, those roles can now be removed from the primary site. Follow these steps to remove the roles:
From the CM12 admin console, navigate to Administration | Site Configuration | Servers and Site System Roles and select your primary site in the right-hand pane.
In the bottom pane, select both Management Point and Distribution Point (use Ctrl + click) and then click on Remove Role from the ribbon.
If you see a warning that this is the last management point for the site, click on No and go back to testing the new MP as the site is not aware that it is working.
Once all IIS roles have been offloaded, IIS can be removed from the primary site. This strengthens security of the server and frees up resources for the remaining duties of the site. As you offload roles, the server has less to do as resources are freed up.
Beyond IIS-based roles, there are still several items that can cause stress to the primary site server, which you can offload to other servers.
With the MP and DP offloaded, the bulk of the client traffic to the primary site has been removed. The SUP role should be offloaded next as it's another point where clients can directly hit your primary site. To do this simply follow these steps:
Install the latest version of WSUS on the MP/DP server (that already has IIS installed) and be sure to cancel the configuration wizard when it starts (CM will configure it instead). Also, be sure to select the option Use this server as the active software update point.
From the admin console, navigate to Administration | Site Configuration | Servers and Site System Roles, select the MP/DP server, and add the software update point role. Verify that the setup encountered no errors by checking the
SUPSetup.log, then look out for errors in theWSUSCtrl.logandwcm.log.With the new SUP working, that role can now be removed from the primary site. From the admin console, select the Primary server and remove the Software update role.
Uninstall WSUS from the primary site server, but be sure to leave the WSUS admin console installed as its files are needed to manage the SUP.
If you are using Endpoint Protection in your company, you can move this role next, but note that there will be no change to the server load. To do this simply follow these steps:
Select the MP/DP/SUP server in the admin console and add the Endpoint Protection Point role.
Verify that the setup encountered no errors by checking the
EPSetup.log, then watch for errors in theEPCtlMgr.log. Often, this server will have to be rebooted before it can become functional and that will show in theEPSetup.log.From the admin console, select the primary server and remove the Endpoint Protection Point role.
The SQL Reporting Service Point can cause stress if people are repeatedly running reports that are hard for your primary to query. The smart move there is to simply set such reports to cache for a certain amount of time (an hour, a day, and so on) so that no matter how often the report is run, the cached data is used instead of fresh queries to the primary site's database. Additionally, reporting services for SQL 2008 and above no longer require IIS, so offloading the role doesn't help towards the ability to remove IIS. Should you still wish to offload that role anyway, (perhaps just as a rule you might decide that no other roles be allowed on a primary) select a server with SQL Reporting Services installed (IIS is not necessary). Follow these steps to offload the SQL Reporting Services Point role:
In the admin console, navigate to Administration | Site Configuration | Servers and Site System Roles, and select the Create Site System Server from the Home tab in the ribbon. Enter the FQDN of the server and choose the CAS if you have one or the primary server.
Select the Reporting services point as the role, verify the settings by clicking on the Verify button, and enter a domain account that you have granted the
smsschm_usersrole in SSMS (generally, the same account used when SRS was created on the primary site).Complete the wizard and verify that the new site is working by running a report from the Monitoring | Reporting node in the console and choosing the new server (not the primary site).
In the admin console, navigate to Administration | Site Configuration | Servers and Site System Roles, choose your primary site and remove the Reporting services point role.
Log on to the primary site, click on the Start button, type
SQL Server Installation Center (64-bit), and hit Enter. Run the installation wizard and remove the reporting services role by unchecking it thereby completing the wizard.
The remaining roles should cause no discernible stress to the primary. But there is one additional step you can take to reduce the impact of the MP role to your server and that is to create a transactional replica between the primary site and the MP. With such a replica, the MP can answer all client requests without querying the primary site. This also allows clients to remain functional if the primary site is down for maintenance or patching (assuming you've offloaded other roles needed, such as DP, SUP, and so on).
By creating this replica, there is a benefit in that if other roles are offloaded from the primary site, the primary site could go down for patching or maintenance while software distribution and patching could continue.
How to set up publication of this replica is already documented quite well by Microsoft at http://technet.microsoft.com/en-us/library/hh846234.aspx