Microsoft System Center Configuration Manager Cookbook: Over 60 applicable recipes to administer and manage System Center Configuration Manager Current Branch, Second Edition

This information is based on versions 1511 and 1602. You can find out if the change is made in 1602 or later by looking for the version 1602 or later tag. You can find the latest changes at https://technet.microsoft.com/en-us/library/mt757350.aspx.

There are two features that were removed from CM current branch's initial release in December 2015, and there will be no more support on these features. If your organization uses these features, you need to find alternatives or stay with CM12.

Before we dive into the new CM servicing model, we first need to understand the new Windows 10 servicing model approach called Windows as a Service (WaaS).

Microsoft regularly gets asked for advice on how to keep Windows devices secure, reliable, and compatible. Microsoft has a pretty strong point-of-view on this: Your devices will be more secure, more reliable, and more compatible if you are keeping up with the updates we regularly release.

In a mobile-first, cloud-first world, IT expects to have new value and new capabilities constantly flowing to them. Most users have smart phones and regularly accept the updates to their apps from the various app stores. The iOS and Android ecosystems also release updates to the OS on a regular cadence.

With this in mind, Microsoft is committed to continuously rolling out new capabilities to users around the world, but Windows is unique in that it is used in an incredibly broad set of scenarios, from a simple phone to some of the most complex and mission critical use scenarios in factories and hospitals. It is clear that one model does not fit all of these scenarios.

To strike a balance between the needed updates for such a wide range of device types, there are four servicing options (summarized in Table 1) you will want to completely understand.

Table 1. Windows 10 servicing options (WaaS)

As you read in the previous section, Windows 10 brings with it new options for deployment and servicing models. On the System Center side, it has to provide enterprise customers with the best management for Windows 10 with CM by helping you deploy, manage, and service Windows 10. Windows 10 comes in two basic types: a Current Branch/Current Branch for Business with fast version model, and the LTSB with a more traditional support model.

Therefore, Microsoft has released a new version of CM to provide full support for the deployment, upgrade, and management of Windows 10 in December 2015. The new CM (simply without calendar year) is called Configuration Manager Current Branch (CMCB), and designed to support the much faster pace of updates for Windows 10, by being updated periodically. 

This new version will also simplify the CM upgrade experience itself. One of the core capabilities of this release is a brand new approach for updating the features and functionality of CM. Moving faster with CM will allow you to take advantage of the very latest feature innovations in Windows 10, as well as other operating systems such as Apple iOS and Android when using mobile device management (MDM) and mobile application management (MAM) capabilities.

The new features for CM are in-console Updates-and-Servicing processes that replace the need to learn about, locate, and download updates from external sources. This means no more service packs or cumulative update versions to track. Instead, when you use the CM current branch, you periodically install in-console updates to get a new version. New update versions release periodically and will include product updates and can also introduce new features you may choose to use (or not use) in your deployment.

Because CM will be updated frequently, will be denoted each particular version with a version number, for example 1511 for a version shipped in December 2015. Updates will be released for the current branch about three times a year. The first release of the current branch was 1511 in December 2015, followed by 1602 in March 2016. Each update version is supported for 12 months from its general availability release date.

There will be a release named System Center Configuration Manager LTSB 2016 that aligns with the release of Windows Server 2016 and System Center 2016. With this version, as like previous versions 2007 and 2012, you do not have to update the Configuration Manager Site Servers like the current branch.

Table 2. Configuration Manager Servicing Options:

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:

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:

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 SQL Reporting Services Point role:

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 on your server and that is to create a transnational 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 like 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.

Follow these steps to install the upgrade to the CAS or primary site:

To upgrade a secondary site by the following steps:

Perform the following steps to update clients:

After the preparation of the drives, SQL can be installed using an unattended file, which has the additional benefit of being reused for a reinstall, or being used on similar primary sites. An example of an unattended file is included in this chapter. It includes two sections of note:

PCUSOURCE=\\Server\Share\SQLServicePackX 
CUSOURCE=\\Server\Share\SQLCUX 

The location of any service pack not already slipstreamed should be used for the PCUSOURCE and the location of the latest cumulative update should be used for CUSOURCE. If service packs have already been slipstreamed into the setup files, simply comment them out.

To callout the unattended file, simply use a command similar to the following:

Setup.exe /CONFIGURATIONFILE=cmsqlconfig.ini

Edit the unattended file as needed to match your drive layout. It is currently set to use R, S, T, and X drives so read carefully. The file works only for SQL 2008 R2, but SQL 2008 and SQL 2012 are similar enough that some simple editing can make them work. The key here is that you can read the file to see how to properly lay out the files and options in advance.

SQL will be happy to eat all the memory on a server leaving nothing for the OS, base applications, or CM. So you need to limit it. Simply open SQL Server Management Studio (SMSS) and right-click on your server to view properties, and navigate to Memory. Because CM is all x64, leave AWE alone. But you do want to enter a maximum server memory here. Leave the OS with 2 GB, your base apps could vary, but 1-2 GB should suffice, and leave CM with 4 GB. Add all that and subtract it from the server's total memory and enter that number here. Note that a CAS requires 8 GB minimum to be dedicated to SQL (anyone choosing to use a CAS is likely to use 16 GB or more anyway).

Transaction logs have been known to grow to consume the entire drive and when that happens, everything stops as nothing can be committed to SQL until first written to the transaction log. A fair limit would be 15 percent less than the entire free space of the drive. Refer to the SQL file layout section, (step 5) for where to do this.

With SQL installed, it now has to be configured to make the best use of the processors on the server. Use more than one file for the SQL database. The rule of thumb is to use as many files as there are physical processing cores.

CM has a maintenance task to rebuild indexes, which is disabled by default. Over time, SQL will slow down as the indexes grow stale.

Additionally, if you have no need to keep data around for 3 months, then help keep the database size smaller by shortening the clean-up tasks from 90 days to something you can live with (perhaps 21 days or 30 days).

Lastly, verify that the recovery model for the CM database is from Full to Simple. Because CM runs backup itself, only its point in time backup can be used to recover the database so you will never recover to some point in time with a full backup. This also keeps the transaction log from having to be backed up. This setting can be found in SMSS by right-clicking on the database, navigating to Options and selecting Simple for the Recovery model.

BranchCache is practically free, so be sure to spend some time evaluating it for your needs. If your environment meets the requirements for BranchCache, you should consider enabling it at least at remote sites to reduce bandwidth utilization, possibly reducing the need for CM infrastructure in those remote locations.

BranchCache is supported on the following operating systems:

The configuration for the server component of BranchCache is only supported on Server 2008 R2 (and newer Server OS). CM DPs must reside on a server with the BranchCache feature enabled for clients to leverage BranchCache. Also, CM requires BranchCache to be configured in distributed mode.

Some WAN accelerator configurations may interfere with BranchCache, so be sure to review the BranchCache documentation as well as test in your environment. Follow the instructions referenced in the See also section of this recipe for configuring BranchCache. After configuring the CM DPs, we can use GPO to configure BranchCache on client systems.

Workstation DPs can be a great addition to your CM hierarchy, and significantly reduce the need for server-class hardware in smaller locations. The following table briefly describes the limitations to a workstation DP:

Operating System Deployment (OSD) is probably the most affected as far as limitations on a workstation operating system go, as PXE and multicast are not supported. We can still use bare-metal builds, as well as OS deployment from Software Center, and successfully build systems.

For a full-featured DP, choose to install the DP on a server operating system. All the features described previously in this chapter are fully supported. As mentioned previously, we might find that we can simply install a DP at a remote location, instead of a full secondary site.