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
In this chapter, we will learn the new servicing model, and walk through the various setup scenarios and configurations for System Center Configuration Manager Current Branch (SCCM CB). Designing and keeping a System Center Configuration Manager (SCCM) infrastructure current by using best practices such as keeping SQL server on the site, offloading some roles as needed, and in-place upgrades from CM12.
We will go through the new features, changes, and removed features in CM since CM 2012.
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.
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) fileYou 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
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.
Refer to the TechNet documentation on CM changes at https://technet.microsoft.com/en-us/library/mt622084.aspx
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.
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 |
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:
|
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 |
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.
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.
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:
Obtain a set of source files from the
CD.Latestfolder 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 aCD.Latestfolder from a site that has already updated to version 1602.Create a backup of the site database, and then restore it to an instance of a test SQL Server.
Run Setup.exe from
CD.Latest, for example,SMSSETUP\BIN\X64\Setup.exe /TESTDBUPGRADE DBtest\CM_ABC.Monitor
ConfigMgrSetup.login the root of the system drive.If the test upgrade fails, resolve any issues related to the site database upgrade failure.
Run the prerequisite checker:
Navigate to Administration | Cloud Services | Updates and Servicing.
Right-click on the update package you want to run the prerequisite check for.
Choose Run prerequisite check. When you run the prerequisite check, content for the update replicates on child sites.
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.
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:
From the top-tier site server, navigate to Administration | Cloud Services | Updates and Servicing.
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:
Navigate to Administration | Site Configuration | Sites.
Select the site you want to update, and then on the Home tab, in the Site group, click on Upgrade.
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.
Start update of CM 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 the Automatically distribute client installation package to distribution points.
Click on OK to save the settings and close the Hierarchy Settings Properties dialog box.
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.
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.logfile 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.
Refer to the TechNet documentation on CM updates at https://technet.microsoft.com/en-us/library/mt607046.aspx
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.
You can verify the maximum supported size and scale information from the following tables:
Table 1. Sites
|
Site Type |
Maximum Scale and Size |
|
CAS |
|
|
Primary |
|
|
Secondary |
|
Table 2. Site Roles
|
Site Role Type |
Maximum Scale and Size |
|
Distribution Point |
|
|
Management point |
|
|
Software update point |
|
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 |
Refer to the TechNet documentation on CM supported configurations at https://technet.microsoft.com/en-us/library/mt589499.aspx
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.
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.
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
FQDNof 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.loganddistmgrr.logon the primary server andMPSetup.logon 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.logon 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.
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.
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 inWSUSCtrl.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
EPSetup.log, then watch for errors inEPCtlMgr.log. Often, this server will have to be rebooted before it can become functional and that will show inEPSetup.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 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
FQDNof 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_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).
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.
How to set up a publication of this replica is already documented quite well by Microsoft at https://technet.microsoft.com/en-us/library/mt608546.aspx
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.
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
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.
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.
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.
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.
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.
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.
Refer to the information at https://technet.microsoft.com/en-us/library/mt627853.aspx for Upgrading System Center Configuration Manager
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.
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.
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.
TempDBandTxLogscould 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\BackupandTempDBcould be on the same drive.Move
TxLogstoC:and all other data on the second drive.Everything sits on one drive (small lab scenario).
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.
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.
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.
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.
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.
Install SQL Server 2012 Using a Configuration File at https://technet.microsoft.com/en-us/library/dd239405(v=sql.110).aspx
Install SQL Server 2016 Using a Configuration File at https://msdn.microsoft.com/en-us/library/dd239405.aspx
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.
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.
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.
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.
Refer to the document PKI certificate requirements for System Center Configuration Manager at https://technet.microsoft.com/en-us/library/mt613191.aspx
Refer to the Plan for managing Internet-based clients in System Center Configuration Manager document at https://technet.microsoft.com/en-us/library/mt629422.aspx
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.
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.
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 |
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.
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.
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.
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.
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.
Refer to BranchCache at https://technet.microsoft.com/en-us/library/mt613461.aspx
Refer to the document Manage content and content infrastructure for System Center Configuration Manager at https://technet.microsoft.com/en-us/library/mt607024.aspx
