Once you have the Configuration Manager sites and site servers installed and configured, the next logical step is to plan the client deployment. The client deployment success rate very much depends on your knowledge of the internal network infrastructure combined with the ability to understand the components involved in the process. Once you fully understand the process, installing a large number of clients over a short period of time may be no problem. On the other hand, if you do not truly understand the process, installing a single client can be a very time-consuming experience.
No one solution for deploying the Configuration Manager client fits all organizations. Most likely you will find yourself using a mix of the different installation techniques described in this chapter.
This chapter covers the prerequisites for installing clients, a walk-through of the different client installation methods, and information needed for troubleshooting the installation process.
In this chapter, you will learn to
In order to manage a device with Configuration Manager, you must first have the client software installed. Regardless of the device and operating system on that device, we always use the term client when we refer to the software on the managed computer that interacts with the Configuration Manager site servers. A client consists of different agents that you can enable or disable. During the installation, the full Configuration Manager client is installed, and you use the Client Settings section of the Administration workspace to control the agent settings and configuration. In Configuration Manager 2012, client settings are global data and thus are no longer separately controlled by each primary site. Furthermore, you can create multiple custom client settings and assign them to individual collections. As a best practice, you should typically configure custom client settings only as exceptions to the default client settings. There may be several reasons why you would need to configure multiple client settings, for example:
A set of default client settings is always configured when you install Configuration Manager. In Figure 6.1 you can see an example of where two custom client settings have been created and assigned to two different collections. Notice the number in the Deployments column; it indicates the number of collections that are affected by the custom client settings. Figure 6.2 shows the new client settings interface. You can assign your own custom client settings to any user or device collection. The same settings can be assigned to multiple collections, and one collection can have multiple assignments. In the event of a conflict, the custom setting with the lowest Order number will be assigned.
CONFIGURE DIFFERENT CUSTOM CLIENT SETTINGS FOR ALL SERVERS
As the Configuration Manager administrator, you have been requested to ensure that only members of the global group Server Administrators can use Remote Tools on servers. Follow these steps to do so:
Notice the number shown under Permitted Viewers.
The individual client agent settings will be discussed in detail in later chapters. Figure 6.2 shows a client settings group that includes several of the available client actions. You can view the list of all possible settings by selecting the Default Client Settings and selecting Properties in the Ribbon. Here is a short description of each of the agent settings:
Background Intelligent Transfer This setting allows you to control the BITS protocol. BITS is the protocol being used by the client when it is downloading and uploading information to the management point and also when it is downloading packages from the distribution points.
Cloud Services This setting determines whether client computers are allowed to access cloud distribution points.
Client Policy The Client Policy settings control how often the client agent will contact the management point for a policy refresh:
Compliance Settings This option is used to enable the settings-management feature formerly known as Desired Configuration Management in Configuration Manager 2007.
Computer Agent Here you define most of the basic Configuration Manager client settings:
Computer Restart This setting allows you to control when restart notifications are shown.
Endpoint Protection Here you enable or disable the System Center Endpoint Protection agent. The settings are configurable only when you have enabled the Endpoint Protection Site System role:
Hardware Inventory This option is used to scan for and report hardware installed on the computer. You can specify custom agent settings for different collections but only define hardware to collect in the default client settings. Unlike Configuration Manager 2007, there is no unique sms_def.mof file per site; instead you use the Custom Client Settings interface to specify the inventory data classes.
Metered Internet Connections This setting can be used to control costs if client computers are utilizing an Internet service provider that charges based on the amount of data that is used.
Enrollment This setting provides configuration options for enrolling mobile devices and Mac computers. It can be used to define the polling interval for mobile device legacy clients as well as defining whether or not end users are allowed to enroll mobile devices and Mac computers.
Network Access Protection (NAP) Use this option to enable Network Access Protection compliance on systems as well as to schedule when scans will occur. Notice that NAP requires that you have installed and configured Network Policy and Access Services in Windows Server 2008 (or higher).
Power Management This setting enables power management for all clients in the hierarchy and allows you to control whether end users can exclude their own devices from being part of a power management configuration. You configure each of the Power Management settings by collection.
Remote Tools This is used to control the Remote Tools and Remote Assistance settings for Windows XP and later systems.
Software Deployment Use this option to configure whether notifications should be shown when deployments are about to run. Schedule Re-evaluation For Deployments determines how often the Configuration Manager client will trigger the re-evaluation process. The process will automatically install required software that is not already installed and remove software that is supposed to be uninstalled.
Software Inventory This option is used to discover what software is installed on the computer. You can control which file types the agent will scan for and where. Furthermore, you can use the settings to collect software files. Collected files are not stored in the database but will be stored on the site server. Even though it might be tempting to collect files, you should think twice before enabling this feature because it can easily lead to network congestion.
Software Metering This option enables software metering and controls how often clients will upload the software-metering data from WMI to the management point.
Software Updates This setting enables software updates, controls how often clients will perform a scan for software updates, and determines whether or not all required updates should be installed upon the deployment deadline.
State Messaging This setting controls how often state messages are forwarded from the client to the management point.
User And Device Affinity This setting controls the calculations that are being used to determine when a user(s) is being considered a primary user(s) for a device.
The following are the more common operating systems that are supported for the Configuration Manager client. The complete list of supported operating systems is available at http://technet.microsoft.com/en-us/library/gg682077.aspx. (Mobile devices will be discussed in detail in Chapter 16, “Mobile Device Management.”)
Windows:
The following are the prerequisites for Windows-based clients:
The following are the prerequisites for Windows-based clients downloaded during the client installation:
Configuration Manager 2012 SP1 and R2 also provide client support for Linux/Unix computers as well as Macintosh computers. The following are the supported operating system versions for these platforms:
Linux/Unix:
Macintosh:
Discovery is the process by which Configuration Manager finds objects in the computer infrastructure and keeps them up to date in the Configuration Manager database. Objects can be users, groups, and computers. All discovery processes will generate one data discovery record (DDR) for each discovered object. For an administrator it is nice to know how many computers you have (and where they are) before you start deploying clients. To find out, you must understand the different discovery methods and when they should be used. Discovery also plays an important part in creating the collections that will support features like application deployment, updates deployment, and operating system deployment.
The only discovery method enabled by default is Heartbeat Discovery, described in a later section. Before configuring any other discovery method, you must ask yourself a few basic questions:
This is essential knowledge before configuring any of the methods. If you do not understand what's being discovered, chances are that you will discover the wrong information.
If you can't answer this question, most likely you do not need to configure the discovery method.
Configuration Manager 2012 natively supports delta discovery, which eliminates the reason for running frequent full discovery processes.
Not knowing the duration of each discovery method has often resulted in backlogs and incorrect discovery schedules. Having knowledge about the log files generated by each discovery process can give you precise data and help you configure the correct schedules.
The discovery methods use different techniques to gather a data discovery record (DDR). Active Directory methods will query the nearest domain controller, whereas Network Discovery uses protocols like RIP and OSPF to get the information.
To configure discovery methods, perform the following steps:
Each of the Active Directory discovery methods requires a target and a schedule. The target can be a single object, an organizational unit (OU), a security/distribution group, or an entire domain. While it might not make much sense to search for a single object, specifying individual OUs or groups versus the entire domain is often considered a best practice. Especially in the pilot phase, it is an easy way to limit the number of objects you are working with. A new feature in Configuration Manager 2012 allows you to specify the account being used to run the discovery process. If none is specified, the process will run under the security context of the site server. In order to run a successful discovery, the account you specify must have Read permission on the object.
Figure 6.3 shows the Active Directory Container field that you use to define the locations where you want to search. When you click Browse, you will see the dialog shown in Figure 6.4. This dialog allows you to select the criteria for the LDAP query. You can select any container or OU within the tree view. Unlike with previous versions of Configuration Manager, you can now browse to other domains and forests.
DISCOVERY PATHS AND ACTIVE DIRECTORY ORGANIZATIONAL UNITS
It is important to know that Configuration Manager will query all objects in the specified paths every time. If you delete an old computer object from the Configuration Manager database but not from Active Directory, the same computer object will be added to the Configuration Manager database after the next discovery process unless you have configured the option to exclude computer objects that have not recently logged on or changed their password. Failure to exclude computers can have an effect on the automatic client push installation attempts because Configuration Manager will initiate a client push attempt on computers that do not have the client installed. These might be the most important reasons why you should plan the discovery processes carefully; make sure that you have an OU structure in Active Directory where you can store objects that are no longer active and exclude those OUs from the specified LDAP path. Failure to do so might lead to errors related to failed client push installation attempts and discovery of unwanted objects.
Once you choose the start location for the query, the default behavior of the query is to search all of the child objects beneath the starting point. If you do not want to search through the child OUs, you can clear the check box labeled Recursively Search Active Directory Child Containers. This is a good way to limit the data returned from the query.
The option Discover Objects Within Active Directory Groups is especially useful in scenarios where you want the Active Directory System Group Discovery method to find computer objects within Active Directory groups. Many organizations have a unique OU where they store computer groups.
Figure 6.5 shows all discovery methods available in a primary site. Let's look at each of these methods in detail.
This discovery method is new to Configuration Manager 2012 and can be very helpful in environments where the Configuration Manager administrator is not always informed about IP infrastructure changes. The method returns information about domains, IP ranges, and Active Directory sites. Furthermore, as shown in Figure 6.6, you can configure the method to automatically create boundaries for the objects being discovered (IP ranges or Active Directory sites only), thus saving yourself hours of work.
By default the discovery process runs once a week and will only discover those forests that are created as Active Directory Forest objects in the Administration workspace. The local forest is automatically created as part of the site installation process. Figure 6.7 shows how you can specify a new forest using an account from the target forest.
You can monitor this discovery process by reading the ADForestDisc.log on the site server.
This is the key discovery method for finding devices. In essence you configure one or more LDAP paths to Active Directory and query a domain controller for all objects in those paths. The device attributes returned by the domain controller depend on what you have configured. By default these attributes will be returned:
In Figure 6.8 you see an example where custom attributes have been specified. Attributes can be specified for AD System Discovery and AD User Discovery. The information you specify will be added to the discovery data and used in queries and reports like any other discovery information. You can monitor this discovery process by reading the ADSysDis.log on the site server.
This discovery method is not used at all in the client deployment process but plays an important part of the user-centric application model. With the method enabled you will get a list of users to whom you can target different deployments such as applications. By default these attributes will be returned:
You can monitor this discovery process by reading the ADusrdis.log on the site server.
This discovery method will discover any local groups, global groups, and universal security groups. You can search for objects within a specific group or perform the search for all groups in a specific location. The information is not really used in a client installation scenario. But once you have the client deployed, you will find the Active Directory security group very useful, especially in user target deployments. You can limit the number of objects returned in the discovery process by configuring the values on the Option tab, as shown in Figure 6.9. Notice that discovering only computers that have logged on to a domain within a specified number of days requires that the domain function level be at least Windows 2003.
You can monitor this discovery process by reading the ADsgdis.log on the site server.
This discovery method is enabled by default and differs from the other methods. It is the responsibility of the client to initiate the discovery process. Failure to do so can result in unwanted client installation attempts and cause the client to be marked as inactive in the Configuration Manager console. The discovery process will not discover any new objects; instead it rediscovers existing objects. You can look at this method as a way to send a keep-alive package from the client to the management point. The heartbeat record is used for the following purposes:
How often should you run the discovery method? By default clients will send an updated DDR to the management point every seven days, and you can change this to occur more frequently, perhaps daily, if needed to meet your requirements. As with any Configuration Manager changes, monitor the environment for any performance or file backlog issues if you make changes to the default settings. These are some of the attributes that will be returned:
You can monitor this discovery process by reading the InventoryAgent.log on the client.
HEARTBEAT DISCOVERY AND MODIFYING COMPUTER NAMES
The Heartbeat Discovery process is responsible for updating changes in the computer name to the database. If you are starting a process where you need to rename a large number of computers, consider modifying the default schedule from seven days to a more frequent interval.
Let me start by saying this: Run the Network Discovery method only when no other discovery method can find the needed resources. It is considered to be the “noisiest” method and will use protocols like RIP or OSPF to discover objects. Most often you'll need to use this method only if you have a number of workgroup clients in your environment. Network Discovery is used to discover many different types of objects. Not only can you find computers that are on the network, but you can discover any device that has an IP address as well.
You can monitor the Network Discovery process by reading the Netdisc.log on the server.
Each method also has a way of scheduling when the discovery will run. For the Active Directory discovery methods, the Polling Schedule tab resembles Figure 6.10 (in this case Active Directory System Group Discovery). The schedule determines when the site server will initiate a full discovery. You can also configure delta discovery. Delta discovery runs by default every 5 minutes and will only discover any changes made to the objects. Unlike in Configuration Manager 2007 R3, the process will discover when you modify existing objects, such as adding an existing computer account to an existing group. Using delta discovery along with the collection property Use Incremental Updates For This Collection, all changes will be reflected in the collection within 10 minutes: 5 minutes for the delta discovery and 5 more minutes for the incremental collection update.
If you need to modify the schedule, click the Schedule button to display the Custom Schedule window.
The Heartbeat Discovery method schedule is found on the General tab, as shown in Figure 6.11. Notice that you can set only a simple schedule for the Heartbeat; your options are much more limited than with the Active Directory methods.
You can create multiple schedules for the Network Discovery method, as shown in Figure 6.12. Configuring the options in the Custom Schedule dialog shown in Figure 6.13 gives you a lot of control over scheduling the Network Discovery agent. Because of the time required for the network searches, you may want to configure a maximum runtime.
After a client has been installed, it must be assigned to a Configuration Manager 2012 R2 site before it can be managed. Once assigned, the client will start receiving the default client policies, using the local resources of the site such as management points, distribution points, and software update points. During the installation, you can configure command-line properties to automatically assign the client a fixed site code or let an auto-assignment process begin. Note that clients will never be assigned to secondary sites, only primary sites.
Configuring boundaries has long been the way you assigned a client to a Configuration Manager/SMS client site. This has changed in Configuration Manager 2012, where a new feature has been introduced to control the assignments: boundary groups. In essence you still use boundaries, but they have no real value until they have been added to a boundary group. A boundary group is basically a collection of individual boundaries grouped together for one or two purposes:
Site Assignment Used to control which sites clients are assigned to
Content Lookup Used to control which distribution points will be used by the client
Figure 6.14 and Figure 6.15 show a site boundary added to a boundary group that is configured for site assignment.
Boundaries are basically address ranges; the following range types are supported:
Even though all four boundary types are supported, there will be scenarios where one or more of the types will not work correctly. There are known issues with IP subnets and network IDs that might cause clients not to be assigned even if they fall within the boundary defined. Furthermore, AD site boundaries are not supported in IP supernetting environments. If you experience problems, you can always configure IP ranges.
CONFIGURING A BOUNDARY AND A BOUNDARY GROUP
As the Configuration Manager administrator, you have been requested to create an AD boundary and ensure it is used to assign clients to the primary site. Follow these steps:
As an important part of your client deployment planning, you need to ask yourself a few questions:
Basically you can choose between a manual installation and an automatic installation. The automatic installation method comes in different flavors.
You need to know which environments need a client. Many organizations plan only for client support in the local domain just to realize later in the process that they also need to support workgroup clients, clients in DMZ, and clients in other forests.
You need to decide whether you want to deploy all clients at once or in a controlled manner.
You have several different deployment methods to choose from; most organizations find themselves using a mix of different methods. It is important to know that there is no right or wrong method, but methods used in different scenarios have different requirements. Regardless of the installation method, you need to know the different command-line properties and when to use them. Gaining knowledge about the command-line properties will ensure that you can install clients in different environments such as workgroups, other forests, and DMZs.
Several command-line properties are used to control the installation. Before you start the deployment, you will need to know two things:
The installation process will always run ccmsetup.exe and client.msi; both of these processes can be controlled using command lines. Any needed prerequisites will be installed and controlled by ccmsetup.exe. When you specify command-line properties, you should do so like this:
CCMSetup.exe [CCMsetup properties] [client.msi setup properties]
For an updated list of command-line properties, you should look at the TechNet article at this URL:
http://technet.microsoft.com/en-us/library/gg699356.aspx
The following are ccmsetup.exe command-line properties:
/source The /source switch is used to identify the location of the client.msi installer file. You can specify the switch multiple times to provide additional source file locations to provide for redundancy. Usage: ccmsetup.exe /source:folderpath.
/MP The /MP switch is used to specify the management point that will be used as a source location. As with the /source switch, you can specify multiple management points by including the switch multiple times. The setting is not used to control the management point that will be used during the site assignment process. Usage: ccmsetup.exe /MP:Server.
/retry:<minutes> The /retry switch is used to retry values used to determine how often a client will try to download the installation files. The client will attempt to download the files until it reaches the values specified in downloadtimeout. Usage: ccmsetup.exe /retry:30.
/downloadtimeout:<minutes> The /downloadtimeout switch controls the number of minutes the ccmsetup process attempts to download the needed client installation files. By default the ccmsetup process will try downloading files for one day. Usage: ccmsetup / download timeout:120.
/noservice The /noservice switch is used to specify that the logged-in user's account is the service account for the installation of the client. For this switch to work, the user account will need to have rights to install software; otherwise the installation will fail. Usage: ccmsetup / noservice.
/Service The /Service switch is used to install the client software using the security context of the local system account. For this to work, Active Directory has to be in use within your network, and the computer's Active Directory account must have access to the installation directory where the client installation files are stored. Usage: ccmsetup /Service.
/Logon The /Logon switch is used to determine if a Configuration Manager client exists on the system. If a Configuration Manager 2012 client is already installed, the installation process will stop. Usage: ccmsetup.exe /Logon.
/forcereboot The /forcereboot switch is used to determine if the ccmsetup process needs to perform a restart of the computer in order to finish the installation. Usage: ccmsetup.exe /forcereboot.
/BITSPriority:<Priority> The /BITSPriority switch controls the bits download priority when downloading the client installation files. You can specify these values:
Usage: ccmsetup.exe /BITSPriority:Foreground.
/Uninstall The /Uninstall switch is used to silently uninstall the Configuration Manager client. Usage: ccmsetup.exe /Uninstall.
/UsePKICert The /UsePKICert switch is used to specify that the client will use a PKI certificate that uses client authentication for communication. If no certificate can be found, the client will use a self-signed certificate and communicate using HTTP. Usage: ccmsetup.exe /UsePKICert.
/NoCRLCheck The /NoCRLCheck switch is used to specify that the client will not check the certificate revocation list before establishing HTTPS communication. This example will enable HTTPS communication and not check for any revocation lists. Usage: ccmsetup.exe /UsePKICert /NoCRLcheck.
/config:<configuration file> The /config switch is used to specify the name of a userdefined configuration file. The configuration file replaces the default mobileclient.tcf file. It is a very good idea to modify an existing mobileclient.tcf file whenever you want to create a custom configuration file. That way you ensure that the syntax used in the file is correct. Usage: ccmsetup.exe /config:C:Windowsccmsetupmysettings.txt.
The following are Client.msi command-line properties:
Patch This property allows you to apply client patches during the installation. At the time of writing, there are no Configuration Manager 2012 client patches. Usage: patch=\ServerShareclientpatch.msp.
CCMALWAYSINF This property with a value of 1 allows you to determine that the client will always be Internet-based, thus never connecting to the intranet. Usage: CCMALWAYSINF=1.
CCMCERTISSUERS This property specifies the list of certificate issuers trusted by the Configuration Manager site. Notice that the list is case-sensitive. Usage: CCMCERTISSUERS= =“CN=CM Root CA; OU=SRV; O=CM, Inc; C=US”.
CCMCERTSEL This property allows you to control the certificate selection criteria used when the client has more than one certificate to choose from. When specifying the criteria you can search for the exact subject name (type subject: prior to the SN) or a partial match in the subject name (type subjectstr: prior to part of the subject name, object identifier, or distinguished name). Usage: CCMCERTSEL=“subject:Server1.CM2012.COM”.
CCMCERTSTORE This property allows you to specify an alternative certificate store. You should use the command line only if the certificate is not found in the default store. Usage: CCMCERTSTORE=“CM2012CERT”.
CCMFIRSTCERT With this property configured to 1 the client will automatically select the certificate with longest validity period. Usage: CCMFIRSTCERT=1.
CCMHOSTNAME This property is used to specify the management point for Internet-based managed clients. Usage: CCMHOSTNAME=“MPServer.CM2012.COM”.
SMSPUBLICROOTKEY This property allows you to specify the trusted root key if, for some reason, it cannot be retrieved from Active Directory. You can open the mobileclient.tcf file and copy the trusted root key. Usage: SMSPUBLICROOTKEY= 02000000A40000525341310 0080000010001008186332BF592B793C8B7F7C01FB32CB811465DEB71095C4442DE45661CE-25031FE2B6F8D9C1C71C6C0BB335C3B5747035E028C43C35E4F8DF1E0CB8B42289A8B-9F9A3143964817DCC50F0D5DB9A879705AD0F4063F4F30242472A933FE8B452BEE608147D9E-CED79CA9422D5441894D152C54B0ABB920741BA0B5582482EA131FAB0BD67AAAB-82DEC50BDCE7D91FCCFB2C3F6C03C8C67C31B5F083A98860389E8D2FD93C4C5BAE-6124A4977EA76B5A89AE2917687782783E003C5F215C767782C0F79A1C1E1F4D14E8B693-25C8CC33C574BE774CEA9579AD765A864DB0FBBBBB854D4390473E72014111EFD-FC11DDDF46EF7B1F03EF1D60A3ABDAA52E8868A0.
SMSROOTKEYPATH This property allows you to reinstall the trusted root key from a file. Usage: SMSROOTKEYPATH=“D:NewRootKeyRootkey.txt”.
RESETKEYINFORMATION This property allows you to remove the old trusted root key. This is often used when you move clients from one Configuration Manager site hierarchy to another. Usage: RESETKEYINFORMATION=TRUE.
CCMAdmins This property allows you to configure which admin accounts are for the client. If there is more than one account, separate the accounts with a semicolon. Usage: CCMAdmins= account1;account2;….
CCMAllowSilentReboot After the installation is complete, if a reboot is required, this property will cause the machine to reboot without saving any user changes. It needs to be specified only if the silent reboot is to be used. A value of 1 forces the reboot if required. Usage: CCMAllowSilentReboot.
CCMDebugLogging This property enables or disables debug logging. A value of 1 enables logging; a value of 0 disables logging. Usage: CCMDebugLogging=0 | 1.
CCMEnableLogging This property turns logging on or off. If this property is not included, then logging is disabled. Usage: CCMEnableLogging=True.
CCMInstallDir This is the directory where the client software will be installed. Usage: CCMInstallDir=C:ConfigMgr.
CCMLogLevel This property is used to control the amount of logging activity. A value of 0 is verbose logging. A level of 1 logs all information, warning, and error conditions. A level of 2 logs warning and error conditions. A value of 3 logs error conditions only. When included, you must also use CCMEnableLogging. Usage: CCMLogLevel=0 | 1 | 2 | 3.
CCMLogMaxHistory This property controls the total number of previous log files within the Logs directory. When included, you must also use CCMEnableLogging. Usage: CCMLogMax History=NumberOfLogFilesToKeep.
CCMLogMaxSize This property controls the maximum log file size. When included, you must also use CCMEnableLogging. Usage: CCMLogMaxSize=LogSizeBytes.
DisableCacheOpt When this property is included in the text box, it disables the Cache configuration setting within the Systems Management properties in Control Panel. Users will not be able to manipulate the settings—only administrators will be allowed to. Usage: DisableCacheOpt=True.
DisableSiteOpt When this property is included in the text box, it disables the Site Code configuration setting within the Systems Management properties in Control Panel. Users will not be able to manipulate the settings—only administrators will be allowed to. Usage: DisableSiteOpt=True.
SMSCacheDir This property controls the directory where the cache is created. Usage: SMSCacheDir=directorypath.
SMSCacheFlags This property can be used to control how much space the cache can occupy and the location where the cache will be stored. When used in conjunction with the SMSCacheDir property, you have control over where the cache is stored. The flags are as follows:
SMSCacheFlags=PercentDiskSpace Used to control the size of the cache by allocating the total cache size as a percentage of the disk size. Cannot be used with PercentFreeDiskSpace.
SMSCacheFlags=PercentFreeDiskSpace Used to control the size of the cache file by allocating the total cache size as a percentage of the free space on the disk. Cannot be used with PercentDiskSpace.
SMSCacheFlags=MaxDrive Used to place the cache on the largest drive in the system. Cannot be used with MaxDriveSpace.
SMSCacheFlags=MaxDriveSpace Used to place the cache on the drive with the most free space. Cannot be used with MaxDrive.
SMSCacheFlags=NTFSOnly Used to control the placement of the cache drive on volumes formatted with NTFS.
SMSCacheFlags=Compress Used to compress the files within the cache.
SMSCacheFlags=FailIfNoSpace Used to stop installation of the client if there is not enough space on the drive for the cache.
SMSCacheSize This property controls the amount of space in megabytes that the cache will consume or in percentage if used in combination with PERCENTDISKPACE or PERCENTFREE DISKSPACE. Usage: SMSCacheSize=CacheSizeInMB.
SMSConfigSource This property controls where the configuration source files are stored. Usage: SMSConfigSource=R | P | M | U.
SMSDIRECTORYLOOKUP This property controls whether WINS lookup is allowed when the client is trying to locate the management point and the site code. Usage: SMSDIRECTORYLOOKUP=NOWINS.
CCMHTTPPort This is the HTTP port used by the client to communicate with the site systems. Usage: CCMHTTPPort=80.
CCMHTTPSPort This is the HTTPS port used by the client to communicate with the site systems. Usage: CCMHTTPSPort=443.
SMSMP This property is used to configure the initial management point that the client communicates with. Usage: SMSMP=Server1.CM2012.COM.
FSP This property specifies that a fallback status point is used. Usage: FSP=Server1.CM2012.COM.
DNSSUFIX This property specifies the DNS domain of the management point. With this option clients will search DNS for the .srv record that includes the DNS suffix of the management point. Usage: DNSSUFFIX=CM2012.COM.
SMSSiteCode This property controls the site code that is assigned to the client. Usage: SMSSiteCode=Auto | SiteCode.
CCMEVALINTERVAL This property controls how often in minutes the client evaluation process runs. By default the process is configured to run once a day. Usage: CCMEVALINTERVAL=1440.
CCMEVALHOUR This property controls when the client evaluation process runs (by the hour). By default the process is configured to run at midnight. Usage: CCMEVALHOUR=14.
For example, suppose you wanted to push the client to systems, using the following options:
Your entry within the Property text box would look like this:
SMSSITECODE=AUTO SMSCACHEDIR=CACHE SMSCACHEFLAGS=MAXDRIVE SMSENABLELOGGING=TRUE CCMLOGLEVEL=0 CCMLOGMAXHISTORY =5
You can provision command lines in three different ways:
If the AD schema is extended, you can type the command lines in the Installation Properties for the client push installation method. All properties you enter here will be published to Active Directory and used by any client that can access Active Directory during the installation. Notice that this applies only if you start the installation using ccmsetup.exe with no other command lines.
For those scenarios where clients cannot access the information in Active Directory, you can provision the command lines using a Group Policy with the ConfigMgrInstallation .adm template. The template is found on the Configuration Manager 2012 installation media in .SMSSetupTOOLSConfigMgrADMTemplates.
This installation method might sound like a very time-consuming method; however, you will find yourself installing clients manually for several reasons. You can manually install the client by running CCMSetup.exe from the site server or from any management point. The file is located in the Program FilesMicrosoft Configuration ManagerClient folder.
To manually install a client in an environment where the AD schema has been extended, do the following: From Start Run, type \ConfigMgr ServerSMS_<sitecode>Clientccmsetup.exe.
To manually install a client on a workgroup computer, follow these steps:
This will install the Configuration Manager client from the local source C:CM2012Client and assign it to primary site PS1 using SCCM4 as the management point and fallback status point. The client must be able to resolve the site system names; otherwise the installation will fail. You can use the Hosts and LMHOSTS files to provide the needed naming resolution support.
To support a DMZ installation where the client is not able to resolve the needed hostnames, you configure these settings in the LMHOSTS and Hosts files (in the example the site server is named SCCM4.SCCMLAB.LOCAL with 192.168.1.2 as the IP address). You can find the files in %windir%System32driversetc. There must be exactly 15 characters between the first “ and the in the LMHOSTS file.
Add these entries to the LMHOSTS file:
192.168.1.2 SCCM4 #PRE 192.168.1.2 “SMS_MP x1A” #PRE
Add this entry to the Hosts file:
192.168.1.2 SCCM4.SCCMLAB.local
Client push is one of the most used installation methods because it requires very little work. All you need to do is to specify one or more client push installation accounts along with some client push installation settings. Before you use client push, you need to understand the preinstallation phase:
Note: The client push installation feature of Configuration Manager 2012 does not support client installation on Linux/Unix or Mac computers. The client for these platforms must be installed manually or via a remote scripting solution.
All this information from the preinstallation phase is recorded in the CCM.log file on the site server. It is not uncommon to see errors in the log file for reasons like these:
If the client Configuration Manager component fails to start the installation on the client, it will retry the installation once an hour for seven days. All retry attempts are stored in Program FilesMicrosoft Configuration Managerinboxesccrretry.box.
To configure the client firewall correctly you need to enable
To configure the client push installation account correctly you need to assign it local administrative permissions on the client.
When you create the account, make sure you add it to the group within your Active Directory structure that has the proper security rights on each machine within the site. Once the account(s) are created, you can configure them as client push installation accounts in the Configuration Manager console. If none of the specified client push accounts are able to connect to the client, the site server will attempt to connect using the site server computer account. With that in mind, you can also assign the correct permissions to the site server computer account, thus eliminating the need for multiple client push accounts.
Once the discovery methods have been configured, you will need to configure the client push settings. In the Configuration Manager Administrator console, follow these steps:
Selecting the check box Enable Automatic Site-Wide Client Push Installation means that whenever a computer is discovered within a defined site boundary group, the client will be automatically installed.
Figure 6.16 shows the Client Push Installation Properties, and this is where you can enable and configure automatic client push installation. It is important to know that client push can be performed in several ways. Use the General tab to configure the options for the fully automated client push feature of Configuration Manager. For a collection-based or client-based client push, you only need to configure settings on the Accounts and Installation Properties tabs.
The Accounts tab, shown in Figure 6.17, allows you to specify the accounts to use to install the Configuration Manager client. Configuration Manager will try the accounts in order until it finds an account with administrative rights on the destination computer. It will always try using the site server's computer account last if one or more accounts are listed and try the site server's computer account only if no accounts are listed. In the figure you will notice that two different accounts, a domain account and a local account, have been specified. A maximum of 10 user accounts can be specified here.
In the Installation Properties tab of Client Push Installation Properties, shown in Figure 6.18, you control how the client is installed by entering installation properties within the text box. The properties that you enter here will be published as command lines in Active Directory. You can enter all available client.msi command lines.
In order to manually push the client install out from within the Configuration Manager administrative console, the target client system(s) needs to be discovered and visible in the Assets and Compliance workspace. Once a system is available, you can push the client to the individual system, or you can push the client to all of the systems within the collection. The simplest way to do this is with the Install Configuration Manager Client Wizard. To initiate the wizard, select a discovered system or collection and choose Install Client from the ribbon. This will open the Install Configuration Manager Client Wizard.
Although the properties and the installation account cannot be modified from the wizard, as Figure 6.19 shows, you can change some of the client push installation options on an individual basis. Especially notice that you can select which site you want to use to install the client. The site choice also affects from which server the client will download the needed software.
From this page you can also choose to always install the client software. This will force the installation of the client, even if another client is already installed.
You can use the canned reports in the Client Push category to monitor the client push attempts. The reports will provide you with information about all client push attempts divided into days and installation status.
You can use a software installation GPO to install the client. For GPO installations you must use the ccmsetup.msi file. This file can be found in the folder .Program FilesMicrosoft Configuration Managerini386 on the site server. You cannot specify any command-line properties when publishing the client; instead the command lines that are published to Active Directory will be used. If you are installing the client in another forest, you can use a Group Policy based on the ConfigMgrInstallation.adm template to provision the command lines locally on the client in the registry before installing the client.
This installation method requires that you have an existing WSUS server in the environment and that it is also configured as the software update point. (A Windows client can only be configured with a single WSUS server. For that reason you need to make sure that the WSUS server specified in the GPO is the same as the one being used as the software update point.) Once you enable this method, the Configuration Manager client will be published to WSUS as a required infrastructure update. You cannot specify any command-line properties when publishing the client; instead the command lines that are published to Active Directory will be used. If you are installing the client in another forest, you can use a Group Policy based on the ConfigMgrInstallation.adm template to provision the command lines in the registry before installing the client. You can monitor publishing between the site server and WSUS server by reading the wcm.log file on the site server.
Note that if you ever need to uninstall Configuration Manager for any reason, make sure you have disabled this client installation method. Failure to do so will leave the Configuration Manager client in WSUS as a required infrastructure update.
You can deploy the client using the Software Deployment feature. This method is often used when upgrading the client to a new service pack. You will notice that a new installation of Configuration Manager ships with a Configuration Manager client package and a Configuration Manager client Upgrade package. If you want to create your own Configuration Manager client software package, follow these steps:
If you do not see the definition, verify that you have selected Microsoft as the publisher.
You have now created a software package containing the client software that you can deploy using the deployment methods described in later chapters.
Logon scripts have been used by companies for many years to apply settings to users and their systems. The parameters that you can use are the same as those described earlier in this chapter. When installing the client using this method, remember to add the /Logon command line to ccmsetup.exe; otherwise, the client installation will begin every time the user logs on to a system.
If you are using the Operating System Deployment feature of Configuration Manager, there is a step in the task sequence that will install the Configuration Manager client. The task sequence step Set Up Windows And ConfigMgr is required and will install the Configuration Manager client correctly in both the reference image and the real image. If you are using another imaging solution and need the Configuration Manager client installed in the reference image, follow these steps:
Beginning with Configuration Manager 2012 SP1, Configuration Manager supports Linux and Unix computers as Configuration Manager clients. The Linux/Unix Configuration Manager client supports hardware and software inventory as well as software distribution. The client push feature of Configuration Manager 2012 cannot be used to install the client, and these computers are treated as workgroup-based devices. As a result, you must manually install the Configuration Manager client on Linux/Unix devices, or you can use a shell script that installs the client remotely.
The client installation process leverages a script named Install, which is included in the downloaded media for the Linux/Unix client. This installation media is available at www.microsoft.com/en-us/download/details.aspx?id=39360.
The Install script supports command-line properties, some of which are required and others are optional. For example, you must specify the management point for the site that the Linux/Unix client will utilize. Once the client is installed, you can use the Client Settings feature in the Configuration Manager 2012 console to configure the client agent as you would for Windows-based clients.
You must use the correct client installation package for the Linux/Unix computer that the Configuration Manager 2012 client will be installed on. Several versions of Linux/Unix can utilize the Universal Agent, while other versions will utilize a client installation package that is specific to each operating system version and platform. Use the TechNet article “Supported Distributions of Linux and UNIX” to determine which installation package to use:
http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_ SupConfigLnUClientReq
You can utilize the same installation process and command-line properties, regardless of which installation package is used. Also, the client installation package contains all of the files required to completely install the Configuration Manager 2012 client, and the computer will not download additional files from the management point or another source location during the install process.
As shown in Figure 6.20, the client installation command line will reference the Install script that is included with the client installation package and will also specify the management point, the assigned site, any optional installation configurations, and the client installation package file.
To install the client on a Linux/Unix computer, follow these steps:
./install -mp <management point> -sitecode <sitecode> <property #1> <property #2> <client installation package>
If optional command-line properties are needed during the install, they must be specified in the command before the statement that identifies the client installation package file that will be used. Also, the client installation package file must be specified last in the command line. Table 6.1 describes the available command-line options. You can utilize the property -h to display this list of properties that are available.
Configuration Manager 2012 also supports the management of Apple Mac computers as clients. The client for the Mac operating system allows you to discover, retrieve inventory, manage settings, and also deploy applications and security updates via Configuration Manager.
The management of Mac computers in Configuration Manager 2012 requires the use of public key infrastructure (PKI) certificates. Configuration Manager can utilize Microsoft Certificate Services with an enterprise certification authority (CA), or you can request and install computer certificates outside of Configuration Manager as long as the certificate meets the requirements of Configuration Manager. It is worth noting that Mac-based Configuration Manager clients always perform certificate revocation checking and cannot be disabled. If Mac clients cannot confirm the certificate revocation status via the certificate revocation list (CRL), they will not be able to connect to the Configuration Manager site servers. Mac devices will also require that the Configuration Manager enrollment point and enrollment proxy point site system roles are installed and configured.
Mac computers are automatically assigned to the Configuration Manager site that will manage them and are installed as Internet-only clients, even if the Mac computer will communicate only on an internal or intranet network. Thus, you will need to ensure that the site systems in the assigned Configuration Manager site are configured to allow client connections from the Internet.
The following is the process for installing the Configuration Manager client on a Mac computer:
Here are the steps for the CMEnroll process:
Here are the steps for the Mac Computer Enrollment Wizard process:
Once the client installation is complete, you can verify that the Mac computer registered properly by viewing the Devices node in the Assets and Compliance workspace in the Configuration Manager 2012 console.
While the installation is in progress, you can view the installation program running within Task Manager or monitor the installation by reading the log files. In Task Manager you will see ccmsetup.exe running. As it completes, you will see ccmsetup.exe replaced by the agent host program ccmexec.exe.
You can also verify that the client has obtained the correct site code and is communicating with the management point, as follows:
Within the Actions tab of the Configuration Manager Properties screen, you should also find several actions listed by default; other actions will appear in this list as the client agents are enabled. The default actions are Application Deployment Evaluation Cycle, Discovery Data Collection Cycle, Hardware Inventory Cycle, Machine Policy Retrieval & Evaluation Cycle, User Policy Retrieval & Evaluation Cycle, and Windows Installer Source List Update Cycle. Each of these actions will be covered when we discuss the related components.
Now, unless you have a very small environment, you will not be able to manually verify the installation of each client. Instead you will use the following reports in the Site - Client Information category:
The reports require that you have specified a fallback status point in the command line for the client installation.
To troubleshoot a client installation you will need to understand the three phases in the process. You can troubleshoot each of the phases in real time by reading the correct log files with CMtrace.exe.
The Preinstallation Phase This phase is described in the “Client Push” section of this chapter. A useful log file in this phase is ccm.log on the site server.
The Installation Phase This phase begins when ccmsetup.exe reads the mobileclient.tcf file and starts downloading the required files needed to complete the installation. Useful log files in this phase are ccmsetup.log and client.msi.log, both found in the %windir% ccmsetup folder on the client.
The Post-installation Phase This phase is also known as the assignment phase, where the client is being added as a managed client to a primary site. Useful log files in this phase are clientidstartupmanager.log, clientlocation.log, and locationservices.log, all found in the %windir%ccmlogs folder on the client.
Once you have identified where the problem is, you will be able to select the correct log file for further troubleshooting.
Client status and automatic client remediation are some of the new features in Configuration Manager 2012. In previous versions of Configuration Manager/Systems Management Server, organizations were forced to spend numerous hours creating custom client health solutions, and even more organizations did not even implement a client health process. In Configuration Manager an automatic remediation process runs daily on every client, and reports and alerts tell you if the number of active clients is dropping to a number below the defined service-level agreements for the company.
During the client installation a schedule remediation task is created in Windows. Figure 6.23 shows the scheduled task in Task Scheduler. The process ccmeval will run daily and perform all the checks that are specified in the ccmeval.xml file found in the %windir%ccm folder. There are more than 20 different checks. If the evaluation process fails, the client will automatically be repaired. All ccmeval status messages will be forwarded to the management point. You can monitor the process by reading the ccmeval.log and CcmEvalTask.log files found in %windir%ccmlogs and the ccmsetup-ccmeval.log file found in %windir%ccmsetup.
You can monitor the client remediation process in the Configuration Manager console. Navigate to the Monitoring workspace and select Client Status Client Check.
To determine the overall client health Configuration Manager uses multiple objects such as these:
As the administrator, you will define when a client goes from being considered active to inactive. To configure the client activity settings, follow these steps:
There are no correct or incorrect settings; it all depends on the client behavior in your network. Do you have only workstations that are supposed to be started daily, or do you have a large number of laptops that are infrequently connected to the network? Don't be too aggressive when configuring the settings. If you configure the wrong values, you might find yourself chasing ghosts and trying to troubleshoot clients that for obvious reasons are not connected to the network.
The client status data is displayed in the Monitoring workspace. When you click the Client Status node, you will see both the client activity and the client check data. If you click any of the different states, you will be taken to the Assets and Compliance workspace, where you will see all the devices that are in the selected state.
You can also use the canned reports in the Client Status category. They will provide you with valuable information about the overall health status and the client agility.
Client Status Summary Can be used as the main client health report. It will give an overview of the client health and client activity data.
Inactive Client Details Will list all inactive clients along with information about the last health check.
Client Status History Will provide a very good historic view for the last 30–90 days.
Client Time To Request Policy Will display how many clients have requested policies during the last 30 days.
Having a mixed environment with laptops, desktops, and servers often means that you have different activity requirements. You can configure individual thresholds per collection and that way have different settings for the unique computer roles in your environment. Figure 6.25 shows the alerts settings that are configured for a collection containing all servers. Because you can use Configuration Manager to keep the servers compliant with software updates, it is unacceptable to have a server running without a healthy client.
CONFIGURING CLIENT HEALTH ALERTS FOR THE ALL SERVERS COLLECTION
As the Configuration Manager administrator, you have been requested to ensure that alerts are generated if any servers become unhealthy. To do so, follow these steps:
To monitor the alerts, do the following:
You will now see a list of all client remediation, client health, and client activity alerts.
Configuration Manager 2012 provides the ability to automatically upgrade the Configuration Manager client software on Windows-based devices to the latest version when the site determines that the Configuration Manager client version that is being used is lower than the version that is being used in the hierarchy. The configuration options are shown in Figure 6.26.
Configuration Manager 2012 automatically creates a client upgrade package and deploys the content to all of the distribution points in the hierarchy (except for cloud-based distribution points). As changes are made to the client package, for example, adding a client language pack, Configuration Manager 2012 will automatically update the package and update the distribution points. If automatic client upgrade is enabled, all clients will install the new client language pack automatically. The automatic upgrade feature was originally intended for upgrading relatively small numbers of Configuration Manager 2012 clients, but with the performance improvements in SP1 and R2 it is possible that the automatic client upgrade feature is the primary method you will use for upgrading clients. As always, you should test heavily in your environment and verify that this feature will not cause unexpected performance or network issues.
The following is the process to configure the automatic client upgrade feature:
Configure boundaries and boundary groups. Before starting any client installation, verify that you have configured a boundary group for site assignment.
Master It Let Configuration Manager Forest Discovery automatically create the boundaries and add them to the correct boundary groups.
Select the relevant discovery methods. You configure discovery methods in the Configuration Manager console. The Active Directory discovery methods all require a schedule and an LDAP path. There are schedules for delta and full discovery. In Configuration Manager 2012, delta discovery will also find changes to existing objects; this eliminates the need to run a full discovery more than once a week.
Master It Always know what you want to discover and where. Based on that knowledge, configure the needed discovery methods.
Employ the correct client installation methods. When configuring the client installation methods, make sure you know the pros and cons for each method. Some require firewall settings; others require local administrative permissions. You need to make sure that all the required settings are in place. Do not start any installation until you have the needed site systems, boundary groups, and command lines specified.
Master It Configure the correct command-line properties and ensure they will work for all environments (local forest, workgroup, and DMZ). Create multiple client push installation accounts, and ensure that you have a good understanding of the three phases (pre-installation, installation, and post-installation).
Manage Unix/Linux and Mac devices. Configuration Manager 2012 provides support for managing Unix/Linux and Mac computers as devices. You are now able to manage your entire computer infrastructure from a single management console.
Master It Understand the installation methods available for deploying the Configuration Manager client to the Unix/Linux computers and Mac computers. Remember that client push cannot be used for these devices.
Ensure client health. Client status might not be the first task you think about when implementing a system like Configuration Manager. But it is crucial to the daily administration that you can trust the numbers you see in the reports and in the console. One way to ensure that is by making certain that all clients are healthy and are providing the server with up-to-date status messages and discovery information.
Master It Discuss the different environments that exist in your organization, and use that information when configuring client health alerts. Make sure that you know the client activity during a normal period and that you have a set of defined SLAs for each of the environments (laptops, road warriors, servers, call center, and so on).