If you would like to read the other parts of this article series please go to:
Introduction
System Center Configuration Manager 2012 is Microsoft’s latest version of the company’s desktop and server management tool and brings a number of new and enhanced capabilities. However, getting SCCM 2012 fully operational takes a lot of time and effort and requires planning. The most foundational part of an SCCM implementation is the client and getting that right is critical to successful long-term satisfaction with the implementation.
In parts one and two of this series, you learned about discovery methods, boundaries, and boundary groups. In this part, you will learn about the various methods by which the SCCM 2012 client can be deployed to the various machines in your organization.
A hotfix: Applies to SCCM 2012 SP1 only
I’m including this here before anything else because it’s important, especially if you are planning to upgrade to SCCM 2012 SP1. When you attempt to install the SCCM 2012 SP1 client to an endpoint, you may receive the following error message in the ccmsetup.log file:
Couldn’t verify ‘C:\WINDOWS\ccmsetup\MicrosoftPolicyPlatformSetup.msi’ authenticode signature. Return code 0x800b0101
In order to correct this problem, you need to download and apply a hotfix that Microsoft makes available specifically to correct this issue.
Client prerequisites
The SCCM 2012 client has a number of prerequisites that must be considered. Perhaps the most vexing one is the need to have the Background Intelligent Transfer Service (BITS) installed on the client before the SCCM client can be installed. In older versions of SCCM, the client installation would also install or enable BITS on the endpoint. Now, however, that doesn’t happen when the client is installed to Windows Server 2003 systems. As such, administrators need to take steps to get BITS installed to these older systems and enable it on newer ones.
I’m assuming for this article series that you have extended Active Directory and gone through all of the steps necessary to create the appropriate Active Directory objects and permissions that are necessary for clients to be able to automatically discover site settings.
There are a number of additional requirements that need to be installed along with the client, but these are taken care of automatically during the client installation and don’t require any proactive effort on the part of the administrator.
If you’re deploying the SCCM client to a Linux or UNIX endpoint, there are some additional prerequisites that need to be met. However, we won’t be discussing Linux and UNIX client deployment in this article, but it will be discussed in a later part of this series.
Some of the individual installation methods also carry their own requirements. We’ll take a look at two of the available installation methods on this article and continue with the remainder in the next part in this series.
Push
In the right circumstances, the push installation method would be the preferred option as it’s the most straightforward. However, a lot of things need to align in order for this installation method to work in a fully reliable manner. When it’s possible to use this method, it has a number of benefits:
- Can be configured to automatically install the client on all newly discovered domain-joined computers in the site.
- Can be deployed to computers on a collection-by-collection basis.
- Among the easiest of the installation methods.
Unfortunately, the push installation methods suffers from some major drawbacks:
- The push installation method can’t be used with workgroup-joined computers.
- The system must have already been discovered via one of SCCM’s discovery methods.
- The account used for client push must have administrative rights on the computer to which the client is going to be installed; this can create a security issue. If you haven’t specified an account to be used for this purpose, the computer account for the SCCM system will be used, but in this case, that computer account still needs administrative rights to the target system.
- If a host-based firewall is being used, it can interfere with the installation of the client unless the administrator takes proactive steps to allow SCCM traffic through.
To change client push configuration settings in SCCM, go to the Administration area and expand Site Configuration and choose Sites. Right-click your site and choose Client Installation Settings > Client Push Installation. You can see how to get here in the figure below.
Figure 1: Change the settings for the client push installation method
Once you open the properties page for the client push installation, you’ll note that there are three tabs with configuration options. The General tab has the bulk of these options:
- Enable automatic site-wide client push installation. When this option is selected, the SCCM client is automatically deployed to clients as they are discovered. This can streamline the effort that an administrator has to put into maintaining the SCCM environment.
- In the System Types box, choose the kinds of systems to which the SCCM client should be automatically deployed.
From this tab, you also have the option to automatically install the Configuration Manager client to domain controllers. In some organizations, domain controllers are managed completely separately from the rest of the desktop and server environment. If you choose the “Always install…” option, the client will always be installed on domain controllers. When you choose the “Never install…” option, the client will not be installed unless you specifically include domain controllers in the Client Push Installation Wizard.
Figure 2: Client push installation properties – General tab
On the Accounts tab, specify the account or accounts you plan to use for client push installation. To add an account to this page, click the yellow star button.
Figure 3: Client push installation properties – Accounts tab
The installation properties page outlines the properties that will be passed to a client through the installation process. Installation properties will also be provided by Active Directory when your configuration is correctly configured.
Figure 4: Client push installation properties – Installation Properties tab
Software update point
Many organizations already have an existing environment they use to deploy software updates. Most often this takes the form of a Windows Server Update Services (WSUS) environment, which is a service that Microsoft has made freely available for quite some time.
There are some obvious advantages to using this deployment method. First, it leverages an already existing part of your environment. Second, if the SCCM client software is accidentally removed from an endpoint, your WSUS environment will automatically reinstall it without further administrator intervention.
This client deployment method does not require that endpoints first be discovered. As such, it can make the process of bringing clients into the SCCM fold a bit easier.
However, on the down side, if you don’t have a WSUS environment or alternative software update infrastructure, you can’t use this method. Second, if you don’t extend the Active Directory schema, you need to take further steps with Group Policy to fully configure this deployment method.
When you choose to use this deployment method, you have one screen of information to configure and it’s shown in the figure below.
Figure 5: Software Update Based client installation properties
Summary
Getting the client installed can be a challenge if you don’t do it right. Make sure you’re considering all of the various deployment options and the pros and cons of each one..
If you would like to read the other parts of this article series please go to:
