Microsoft System Center Configuration Manager Cookbook

Chapter 1. Designing a System Center Configuration Manager Infrastructure

In this chapter, we will cover the following recipes:

What's changed from System Center 2012 Configuration Manager?
System Center Configuration Manager's new servicing models
Keeping your CM deployment up-to date
Infrastructure sizing considerations
Dividing up site system roles
Upgrading in-place from Configuration Manager 2012
Installing SQL the right way
Managing Internet-facing clients
Using remote and workstation distribution points and BranchCache

What's changed from System Center 2012 Configuration Manager?

We will go through the new features, changes, and removed features in CM since CM 2012.

Getting ready

The following are the new features in CM since CM12:

In-console updates for Configuration Manager:CM uses an in-console service method called Updates and Servicing that makes it easy to locate and install updates for CM.
Service Connection Point: The Microsoft Intune connector is replaced by a new site system role named Service Connection Point. The service connection point is used as a point of contact for devices you manage with, upload usage and diagnostic data to the Microsoft cloud service, and makes updates that apply within the CM console.
Windows 10 Servicing: You can view the dashboard which tracks all Windows 10 PCs in your environment, create servicing plans to ensure Windows 10 PCs are kept up to date, and also view alerts when Windows 10 clients are near to the end of a CB/CBB support cycle.

How to do it...

Whats new in CM Capabilities

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.

Endpoint Protection anti-malware:
- Real-time protection: This blocks potentially unwanted applications at download and prior to installation
- Scan settings: This scans mapped network drives when running a full scan
- Auto sample file submission settings: This is used to manage the behavior
- Exclusion settings: This section of the policy is improved to allow device exclusions
Software updates:
- CM can differentiate a Windows 10 computer that connects to Windows Update for Business (WUfB) versus the computers connected to SUP
- You can schedule, or run manually, the WSUS clean up task from the CM console
- CM has the ability to manage Office 365 client updates by using the SUP (version 1602 or later)
Application management:
- This supports Universal Windows Platform (UWP) apps
- The user-available apps now appear in Software Center
- When you create an in-house iOS app you only need to specify the installer (.ipa) file
- You can still enter the link directly, but you can now browse the store for the app directly from the CM console
- CM now supports apps you purchase in volume from the Apple Volume-Purchase Program (VPP) (version 1602 or later)
- Use CM app configuration policies to supply settings that might be required when the user runs an iOS app (version 1602 or later)
Operating system deployment:
- A new task sequence (TS) type is available to upgrade computers from Windows 7/8/8.1 to Windows 10
- Windows PE Peer Cache is now available that runs a TS using Windows PE Peer Cache to obtain content from a local peer, instead of running it from a DP
- You can now view the state, deploy the servicing plans, and get alerts of WaaS in your environment, to keep the Windows 10 current branch updated
Client deployment:
- You can test new versions of the CM client before upgrading the rest of the site with the new software
Site infrastructure:
- CM sites support the in-place upgrade of the site server's OS from Windows Server 2008 R2 to Windows Server 2012 R2 (version 1602 or later)
- SQL Server AlwaysOn is supported for CM (version 1602 or later)
- CM supports Microsoft Passport for Work which is an alternative sign-in method to replace a password, smart card, or virtual smart card
Compliance settings:
- When you create a configuration item, only the settings relevant to the selected platform are available
- It is now easier to choose the configuration item type in the create configuration item wizard and has a number of new settings
- It provides support for managing settings on Mac OS X computers
- You can now specify kiosk mode settings for Samsung KNOX devices. (version 1602 or later)
Conditional access:
- Conditional access to Exchange Online and SharePoint Online is supported for PCs managed by CM (version 1602 or later)
- You can now restrict access to e-mail and 0365 services based on the report of the Health Attestation Service (version 1602 or later)
- New compliance policy rules like automatic updates and passwords to unlock devices, have been added to support better security requirements (version 1602 or later)
- Enrolled and compliant devices always have access to Exchange On-Premises (version 1602 or later)
Client management:
- You can now see whether a computer is online or not via its status (version 1602 or later)
- A new option, Sync Policy has been added by navigating to the Software Center | Options | Computer Maintenance which refreshes its machine and user policy (version 1602 or later)
- You can view the status of Windows 10 Device Health Attestation in the CM console (version 1602 or later)
Mobile device management with Microsoft Intune:
- Improved the number of devices a user can enroll
- Specify terms and conditions users of the company portal must accept before they can enroll or use the app
- Added a device enrollment manager role to help manage large numbers of devices
- CM can help you manage iOS Activation Lock, a feature of the Find My iPhone app for iOS 7.1 and later devices (version 1602 or later)
- You can monitor terms and conditions deployments in the CM console (version 1602 or later)
On-premises Mobile Device Management:
- You can now manage mobile devices using on-premises CM infrastructure via a management interface that is built into the device OS

Removed features

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.

Out of Band Management: With Configuration Manager, native support for AMT-based computers from within the CM console has been removed.
Network Access Protection:CM has removed support for Network Access Protection. The feature has been deprecated in Windows Server 2012 R2 and is removed from Windows 10.

System Center Configuration Manager's new servicing models

The new concept servicing model is one of the biggest changes in CM. We will learn what the servicing model is and how to do it in this chapter.

Getting Ready

Windows 10's new servicing models

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)

Servicing Models	Key Benefits	Support Lifetime	Editions	Target Scenario
Windows Insider Program	Enables testing new features before release	N/A	Home, Pro, Enterprise, Education	IT Pros, Developers
Current Branch (CB)	Makes new features available to users immediately	Approximately 4 months	Home, Pro, Enterprise, Education	Consumers, limited number of Enterprise users
Current Branch for Business (CBB)	Provides additional testing time through Current Branch	Approximately 8 months	Pro, Enterprise, Education	Enterprise users
Long-Term Servicing Branch (LTSB)	Enables long-term low changing deployments like previous Windows versions	10 Years	Enterprise LTSB	ATM, Line machines, Factory control

How to do it...

How will CM support Windows 10?

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.

Why is there another version called Configuration Manager LTSB 2016?

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:

Servicing Options	Benefits	Support Lifetime	Intended Target Clients
CM CB	Fully supports any type of Windows 10	Approximately 12 months	Windows 10 CB/CBB, Windows 10
Configuration Manager LTSB 2016	You do not need to update frequently	10 Years	Windows 10 LTSB

Keeping your CM deployment up-to date

CM synchronizes with the Microsoft cloud service to get updates. You can then install from within the CM console. Only updates that apply to your infrastructure and version are downloaded and made available. This synchronization can be automatic, or manual depending on how you configure the service connection point for your hierarchy.You can choose either of the following methods for upgrading your CM Infrastructure.

You can choose either of the following methods for upgrading your CM Infrastructure:

In online mode, the service connection point automatically connects to the Microsoft cloud service and downloads applicable updates
In offline mode, you must manually use the Service Connection Tool to download and then import available updates into the service connection point

By default, CM checks for new updates every 24 hours. Beginning with version 1602 or later, you can also check for updates immediately by:

Navigating to Administration | Cloud Services | Updates and Servicing.
Clicking on Check for Updates.
Note
To view updates in the console, a user must be assigned a security role that includes the Read permission in the permission group Site, and the security scope All.

To configure the service connection point role:

Navigate to Administration | Site Configuration | Servers and Site System Roles.
Add Service connection point role by doing the following:
- New site system server: On the Home tab in the Create group, click on Create Site System Server to start the Create Site System Server wizard.
- Existing site system server: Click on the server on which you want to install the service connection point role. Then, on the Hom e tab, in the Server group, click on Add Site System Roles to start the Add Site system Roles wizard.
On the System Role Selection page, select Service connection point, and click on Next.
Complete the wizard.
Note
The service connection point site system role may only be installed on a central administration site or standalone primary site. The service connection point must have Internet access.

Getting ready

Before applying a CM update, there are three recommended actions you can execute in order to safely update CM:

Refer to the checklist made available by Microsoft:
Refer to the checklist available at https://technet.microsoft.com/en-us/library/mt691556.aspx for updating from System Center Configuration Manager version 1511 to 1602.
Test the database upgrade:
1. Obtain a set of source files from the CD.Latest folder of a site that runs the version you plan to update to from the lab environment. For example, if your site runs version 1501 and you want to update to 1602, you must get a CD.Latest folder from a site that has already updated to version 1602.
2. Create a backup of the site database, and then restore it to an instance of a test SQL Server.
3. Run Setup.exe from CD.Latest, for example, SMSSETUP\BIN\X64\Setup.exe /TESTDBUPGRADE DBtest\CM_ABC.
4. Monitor ConfigMgrSetup.log in the root of the system drive.
5. If the test upgrade fails, resolve any issues related to the site database upgrade failure.
Run the prerequisite checker:
1. Navigate to Administration | Cloud Services | Updates and Servicing.
2. Right-click on the update package you want to run the prerequisite check for.
3. Choose Run prerequisite check. When you run the prerequisite check, content for the update replicates on child sites.
4. To view the results, navigate to Monitoring | Site Servicing Status and look for the prerequisite status. You can also view the details from ConfigMgrPrereq.log.

How to do it...

Before installing a new CM update, be sure to have done the prerequisite checks described in the Getting ready section.

Tip

Child primary sites start the update automatically after the central administration site completes installation of the update. You can use Service Windows for site servers to control when a site installs updates.

When it comes to updating CM to a new version, you will have to consider updating the CM hierarchy in the following order:

The top-tier site (primary site or CAS if you have one). Follow these steps to apply the update to the top-tier site:
1. From the top-tier site server, navigate to Administration | Cloud Services | Updates and Servicing.
2. Select an available update and then click on Install Update Pack.
Update installation at secondary sites. After the parent primary site is updated, update the secondary site using the following steps:
1. Navigate to Administration | Site Configuration | Sites.
2. Select the site you want to update, and then on the Home tab, in the Site group, click on Upgrade.
3. Click on Yes .
To monitor the status, select the secondary site server, and then on the Home tab, in the Site group, click on Show Install Status.
Note
You have to manually update secondary sites from the CM console after the primary parent site update is completed. Automatic update of secondary site servers is not supported. When you open the CM console after the site update, you are prompted to update the console.
Start update of CM clients. Perform the following steps to update clients:
1. Navigate to Administration | Site Configuration | Sites.
2. On the Home tab, in the Sites group, click on Hierarchy Settings.
3. In the Client Upgrade tab, review the version and date of the production client.
4. Click on Upgrade all clients in the hierarchy using the production client and click on OK in the confirmation dialog box.
5. If you don't want client upgrades to apply to servers, click on Do not upgrade servers.
6. Specify the number of days in which computers must upgrade the client after they receive the client policy.
7. If you want the client installation package to be copied to prestaged distribution points, click on the Automatically distribute client installation package to distribution points.
8. Click on OK to save the settings and close the Hierarchy Settings Properties dialog box.

How it works...

As part of the update installation, CM re-installs any affected components such as site system roles or the console, manages updates to clients based on the selections you made for client piloting, and basically there is no need to reboot site system servers as part of the update.

Tip

When updates are installed, Configuration Manager also updates the CD.Latest folder which is used during a site recovery.

There's more...

From the CM console, it is also possible to verify any update installation status as well as monitor the update in progress.

To verify the status of updated packages, navigate to Administration | Cloud Services | Updates and Servicing. This node shows the installation status for all updated packages.

To monitor the CM update while it's applied, follow these steps:

Navigate to Monitoring | Overview | Site Servicing Status. You will find there the installation status of the CM update currently in progress.
You can view the CMUpdate.log file in <ConfigMgr_Installation_Directory>\Logs\.

After a CAS or primary site updates, each CM console that connects to that site must also update.

To start updating CM consoles:

Open the console, you are prompted to update a console, click on OK.
To verify the version, go to About System Center Configuration Manager at the top-left corner of the console where the new site and console versions are displayed.

Infrastructure sizing considerations

In this section, we provide a quick reference on supported size and scale information and recommended hardware information. Basically, it depends on the scale of CM, make sure your planning hierarchy and hardware is good enough for CM requirements.

Supportable size and scale

You can verify the maximum supported size and scale information from the following tables:

Table 1. Sites

Site Type	Maximum Scale and Size
CAS	Up to 25 child primary sites 700k clients (50k clients for SQL Standard)
Primary	Up to 250 child secondary sites 150k clients
Secondary	Does not support child sites 15k clients

Table 2. Site Roles

Site Role Type	Maximum Scale and Size
Distribution Point	A Primary/Secondary site supports up to 250 DPs A Primary/Secondary site supports up to 2k pull-DPs A Primary site hierarchy supports up to 5k DPs Up to 10k packages and applications 4k clients
Management point	Primary site supports up to 15 MPs Only single MP can be in secondary site 25k clients
Software update point	25k clients (150k for Remote SUP)

Hardware recommendation

Microsoft has published detailed guidance on recommended hardware configurations, you can find it here: https://technet.microsoft.com/en-us/library/mt589500.aspx.

Table 3. Site Servers

Site Server Type	CPU Cores	Memory (GB)/for SQL (%)	Disk (GB)
Stand-alone primary with SQL	16	96/80	OS-32 (WS2012R2) CM-25~200 DB-100 per 25k clients TempDB - As needed Content- As needed
Stand-alone primary with remote SQL	8	16/-	-
Remote SQL for stand-alone primary	16	64/90	-
CAS with SQL	16	96/80	-
CAS with remote SQL	8	16/-	-
Remote SQL for CAS	16	96/90	-
Child primary with SQL	16	96/80	-
Child primary with remote SQL	8	16/-	-
Remote SQL for child primary	16	64/90	-
Secondary	8	16/-	-

Table 4. Remote site system servers

Site System Role	CPU cores	Memory (GB)	Disk (GB)
Management point	4	8	50
Distribution point	2	8	As needed
Application Catalog	4	16	50
Software update point	8	16	As needed
All other site system roles	4	8	50

Dividing up site system roles

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

While it was a best practice to offload SQL in CM07, we now advise keeping SQL on box in CM as SQL replication has replaced much of the file-based replication of CM07. CM 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.

Getting ready

Admins should move roles off as described in the following How to do it... section until the primary site starts to perform as expected. We will start with both Distribution Point (DP) and Management Point (MP). Unlike CM07, CM 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.

How to do it...

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.
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.
CM now gives the ability to force content on a DP to drive letters of your preference. Choose as needed.
CM 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.
CM 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. CM 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 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 sitecomp.log and distmgrr.log on the primary server and MPSetup.log on the new server to verify a successful installation.
Test the new MP by stopping the SMSAgentHost service on the primary, and then verify that clients are contacting the new MP (check mpfdm.log on the new MP).
Test the new DP by distributing content to it.

With a working MP and DP on another server, these roles can now be removed from the primary site. Follow these steps to remove the roles:

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.

How it works...

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.

There's more...

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.

Offloading the SUP

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.
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 SUPSetup.log, then look out for errors in WSUSCtrl.log and wcm.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.

Offloading Endpoint Protection

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 EPSetup.log, then watch for errors in EPCtlMgr.log. Often, this server will have to be rebooted before it can become functional and that will show in EPSetup.log.
From the admin console, select the primary server and remove the Endpoint Protection Point role.

Offloading SQL Reporting Services

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:

Navigate to Administration | Site Configuration | Servers and Site System Roles, 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 choose 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_users role 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).
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 and 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 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.

Upgrading in-place from Configuration Manager 2012

You can perform an in-place upgrade to CM from a CM12 hierarchy. Before starting the upgrade, you must prepare sites, which requires you to remove specific configurations, and then follow the upgrade sequence from top to bottom level.

Getting ready

Microsoft has published a checklist for upgrade preparation. You can refer the information from here https://technet.microsoft.com/en-us/library/mt627853.aspx.

The following are some of important items to note:

Ensure that the site system environment meets the supported configurations that are required for upgrading to CM
Review the server OS versions
Review the required prerequisites for the site system server (especially, ADK Windows 10)
Install all critical updates for OS
Run Setup Prerequisite Checker
Create a backup of the site database at the CAS and primary sites

How to do it...

Before you start the CM hierarchy upgrade, read the Getting ready section.

To upgrade the CM hierarchy, you upgrade the top-tier site of the hierarchy (CAS or standalone primary site). After the upgrade of the top-tier site is completed, you can upgrade child primary sites in any order that you want. After you upgrade all primary sites, you can upgrade a child secondary site.

Starting the upgrade installation at the CAS or primary site

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

Make sure the user has the following security rights:
- Local Administrator rights on the site server computer.
- Local Administrator rights on the remote site database server for the site, if it is remote.
Open Explorer and browse to <ConfigMgSourceMedia>\SMSSETUP\BIN\X64.
Double-click on Setup.exe. The Configuration Manager Setup wizard opens.
On the Before You Begin page, click on Next.
On the Getting Started page, select Upgrade this Configuration Manager site, and then click on Next.
On the Product Key page, click on Next.
On the Microsoft Software License Terms page, read and accept the license terms, then click on Next.
On the Prerequisite Licenses page, read and accept the license terms, then click on Next.
On the Prerequisite Downloads page, specify download the latest files or use previously downloaded files, and then click on Next.
On the Server Language Selection page, check required languages, then click on Next.
On the Client Language Selection page, check required languages, then click on Next.
On the Settings Summary page, click on Next to start Prerequisite Checker.
On the Prerequisite Installation Check page, make sure there are no problems listed, then click on Next.
On the Upgrade page, you can see the progress status. When setup completes the installation, close the wizard.

Starting the upgrade installation at a secondary site

To upgrade a secondary site by the following steps:

Make sure the user has the following security rights:
- Local Administrator rights on the secondary site computer
- Infrastructure Administrator or a Full Administrator security role on the parent primary site
- System administrator (SA) rights on the site database of the secondary site
Navigate to Administration | Site Configuration | Sites.
Select the secondary site; on the Home tab in the Site group, click on Upgrade.
Click on Yes to confirm the decision.
The secondary site upgrade progresses in the background.

Starting the upgrade installation of clients

Perform the following steps to update clients:

Navigate to Administration |Site Configuration | Sites.
On the Home tab, in the Sites group, click on Hierarchy Settings.
In the Client Upgrade tab, review the version and date of the production client.
Click on Upgrade all clients in the hierarchy using the production client and click on OK in the confirmation dialog box.
If you don't want client upgrades to apply to servers, click on Do not upgrade servers.
Specify the number of days in which computers must upgrade the client after they receive the client policy.
If you want the client installation package to be copied to prestaged distribution points, click on Automatically distribute client installation package to distribute points.
Click on OK to save the settings and close the Hierarchy Settings Properties dialog box.

How it works...

When you upgrade to CM, the site performs a site reset, which includes a re-installation of all site system roles, and if the site is the top-tier site, it updates the client installation package on each DP in the hierarchy. The site also updates the default boot images to use the new Windows PE version which is included with the Windows Assessment and Deployment Kit 10. If the site is a primary site, it updates the client upgrade package for that site.

There's more...

From the CM console, it is possible to verify the upgrade status of any secondary site.

To verify the upgrade status:

In the CM console, select the secondary site server.
On the Home tab in the Site group, click on Show Install Status.

You must manually upgrade each standalone consoles, after CM upgrade. To start updating CM consoles:

Open the console, you are prompted to update a console, click on OK.
To verify the version, go to About System Center Configuration Manager at the top-left corner of the console where the new site and console versions are displayed.

Installing SQL the right way

How well SQL is installed before CM can have a dramatic effect on how people perceive CM to be as a product. Common complaints heard are CM is slow, The console is slow, and It can't keep up with these many clients. A well thought out installation will go unnoticed where the reverse can cause downright agony for admins.

Getting ready

Get the latest supported version of SQL, the latest supported service pack, and the latest version of the cumulative update files. An already slipstreamed set of files from Microsoft will make things easier if available. The enterprise version has many benefits such as online re-indexing of tables, support for more than 50,000 clients and more, but the decision of which edition to use usually comes down to cost, as the enterprise edition is far more expensive than the standard version.

The more memory SQL has access to, the better it will run. The more disks and controllers it can use, the better it will run. SQL doesn't perform well in a virtual machine on virtual disks. This can be done in a lab or even on a laptop as a lab, but for production, memory and disks will define the CM experience.

How to do it...

Consider the following disk layout optimized for an enterprise-class primary site or CAS:

Disk	Controller	Number of Drives	Drive letter	Partitions
0	0	4	C	OS
1	1	4	T	TempDB
2	1	4	X	TxLogs
3	1	6	R	SQLDB1
4	2	6	S	SQLDB2
5	2	8	D	Data\Backup

External controllers 1 and 2 get as much RAM as you can afford (1 GB optimally). Each gets one hot, spare drive. All controllers are formatted with RAID 10. SQL activity is split across two controllers. RAID cache settings should be set to Write Back, no Read Ahead .

From the previous table, you can peel away the number of drives as costs constrain your budget in the following order:

The OS could be on a simple mirror.
TempDB and TxLogs could be on a single drive.
The SQL files could be on the same drive.
The SQL files could be mixed with TempDB.
The SQL files Data\Backup and TempDB could be on the same drive.
Move TxLogs to C: and all other data on the second drive.
Everything sits on one drive (small lab scenario).

How it works...

With the best layout of disks you can afford and the most memory you can afford, SQL will be able to stand under the stress CM puts on it. If using SAN, multiple dedicated LUNs are best, if available. Notice TxLogs were the last to be compromised as nothing can be committed to SQL until first written to TxLogs. Even with plenty of RAM, data must still be written to disk, which makes TxLogs an important point in any design.

There's more...

Drive layout is the key to smooth SQL operations. But that's just the start. A few more easy steps will keep your installation bug free and optimized for CM use.

Installing SQL with an unattended file

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.

Setting some limits

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.

SQL file layout

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.

From the Microsoft SQL Server Management Studio (SMSS) right-click on your CM database and choose Properties. Go to Files and then click on the Add button.
If you had eight cores and two drives for the SQL database (R and S), you would add four files to R and three more to S (assuming you initially installed SQL to S).
Set the initial size of each file to one-eighth the size of what you expect your entire database size to be.
Set Autogrowth to 1000 MB.
Set Autogrowth of the transaction log to 1000 MB. Additionally, restrict the growth of the file to a size that is smaller than the free space on the drive on which it resides.
Click on OK to commit the changes; no need for reboot.

Helping SQL

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

From the CM admin console, navigate to Administration | Site Configuration | Sites and click on Site Maintenance in the ribbon.
Change the properties of the Rebuild Indexes task to be enabled to Weekly.
Choose a time of day where CM isn't busy. The default of 1 a.m. on Sunday is probably a good choice.
Repeat for all primary sites (and the CAS if you have one).

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.

Managing Internet-facing clients

Depending on the environment, you may have clients that:

Regularly move between the Internet and the intranet
Are home computers and never connect to the intranet

Managing clients that are not always connected to the internal network can be a challenge. If remote computers use Virtual Private Networking (VPN) to connect to the corporate network on a regular basis, Internet-facing support may not be required. But if we know that clients may use some type of remote desktop to connect to the corporate network, or maybe they don't have to connect to the corporate network at all to do their job, then Internet-facing support should be considered to ensure proper patch and asset management.

CM has two client communication methods: HTTPS only and HTTPS or HTTP. One CM site can support both HTTPS and HTTP communication if required.

Getting ready

Public Key Infrastructure (PKI) certificates are required for Internet-based client communication. Engage with the team that owns PKI in your infrastructure. If a PKI infrastructure doesn't currently exist, follow Microsoft's step-by-step example of deploying PKI https://technet.microsoft.com/en-us/library/mt627852.aspx. Once you have all valid certificates, proceed to the next section.

How to do it...

To enable Internet-facing clients, perform the following steps:

Navigate to Administration | Site Configuration | Sites, and select the desired site to support Internet-based clients. Right-click on the site and select Properties.
From the Client Computer Communication tab, select either HTTPS only if you only want to support HTTPS, or HTTPS or HTTP as required.
Enable the checkbox to Use PKI client certificate, and then click on the Modify button to select the client certification selection criteria, as well as the store name, and then click on OK.
Click on the Set button to specify the Trusted Root Certification Authorities, and then select the starburst to browse to a new certificate file.
Select OK to save changes to Site Properties.
From the Servers and Site System Roles node, select the desired site in the top pane. Select the desired roles from the bottom pane (Management Point, Distribution Point, Software Update Point, as well as Application catalog Point, if required).
Specify HTTPS for client communication types.
As long as the new site systems are accessible from the Internet at this point, the infrastructure configuration is complete. Follow the client installation instructions given at https://technet.microsoft.com/en-us/library/mt489016.aspx; to install the CM client properly.

How it works...

CM allows clients assigned to the same primary site to use either HTTP or HTTPS communication. If a client has the PKI cert, it can be set to use HTTP for the intranet and HTTPS for the Internet.

Using remote and workstation distribution points and BranchCache

When CM administrators ask us, What are the most resource-intensive components of CM?, we usually start with the obligatory It depends, and then quickly follow up with distribution points. Distribution points are the file shares and websites that clients use for installing software, security patches, operating system deployments, and more. So depending on the content we plan to deploy, we may need more distribution points than any other server.

Similar to CM12, it supports a single instance store, adding consistency checks with the distribution point role, and adding a sender for throttling. Troubleshooting and deploying a distribution point to a workstation is very similar to troubleshooting and deploying a distribution point to a server.

From CM12, it also has integrated BranchCache, which allows us to reduce the amount of traffic that occurs between each network client and the distribution point for downloading content. For example, when a supported system needs to download content, it will first check to see if any system on its local network already has the content (based on file hash), and if so, it will download from a peer. If not, it will download from the distribution point, and then store the content so that it can be shared among other peers on the same network in the future.

Getting ready

We described the process of installing a distribution point in the Dividing up site system roles recipe, so we will use this section to help you determine how to choose which type of distribution point(s) you need.

How to do it...

To determine the best distribution point for your needs, ask the following questions:

How many clients will use the distribution point?
Will Preboot Execution Environment (PXE), also known as network-based boot, be required?
Must the distribution point support BranchCache?
Is the distribution point connected to the site server over a slow or fast network link?
Do you plan to use any third-party add-on tools or WAN accelerators for remote locations?
Do you require redundancy, in the event that a distribution point is offline or a DP fails?

Review the following table to help determine the proper DPs for your environment:

CM Feature	Workstation DP	Server DP
Supports PXE	No	Yes
Supports multicast	No	Yes
Supports BranchCache	No	Yes
Maximum concurrent connections	20	Unlimited
Supports bandwidth throttling	Yes	Yes
Supports single instance store	Yes	Yes
Supports content validation	Yes	Yes
Supports boundary groups	Yes	Yes
Supports additional site roles (MP, Web Svc Pt, and so on )	No	Yes

How it works...

You cannot distribute software or software updates to clients without DPs. The decision on how many to place, where to place them, whether or not to throttle them and if so, how much, are all considerations that affect the ability of clients to get software in an efficient manner. Don't just throttle a DP because you can now. Do so only because you need to alleviate a possible network bottleneck.

There's more...

As we can see from the previous table, bandwidth throttling is available on DPs either on a workstation or a server. This new feature alone may allow you to reduce the need for secondary sites in remote locations. Refer to the following sections for more discussion about maximizing content efficiency with CM.

When to choose BranchCache

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:

Windows 10 Enterprise and Education Editions (or newer)
Windows 8.1 Enterprise Edition (or newer)
Windows 7 Enterprise and Ultimate Editions (or newer)
Windows Vista Enterprise with at least service pack 2 and BITS 4.0

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.

When to choose a workstation distribution point

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:

CM Feature	Limitations
Supports PXE	Workstation operating system does not support this WDS server feature
Supports multicast	Workstation operating system does not support this WDS server feature
Supports BranchCache	Workstation operating system does not support the server feature required for BranchCache configuration on a DP.
Max concurrent connections	Workstation has a maximum of 20 concurrent connections. This may put larger locations of clients into a waiting for content situation, until enough connections become available.
Supports additional site roles (MP, Web Svc Pt, and so on)	Workstation operating system does not support additional roles for a CM site.

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.

When to choose a server-class distribution point

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.