CHAPTER 9
Client Management

With a working System Center Configuration Manager (ConfigMgr) environment, you can begin managing remote devices in a process referred to as client management. A client is the end device managed by ConfigMgr; this can be any system with agent software installed and configured or managed through its built-in management capabilities (based on the Open Mobile Alliance Device Management [OMA DM] standard). Clients can be mobile devices, workstations, server operating systems, or cash registers using Windows Embedded systems. While they are not required to be ConfigMgr clients, site servers typically have the client agent software installed. By using mobile device management (MDM) to manage clients, ConfigMgr leverages its hybrid Intune or on-premise MDM functionality. This chapter discusses clients that have the client agent software installed.

This chapter describes ConfigMgr client requirements and installation, discovery, updating and configuration, client settings, inventory, client management, client health, and Wake on LAN (WOL). Configuring clients managed through ConfigMgr’s MDM capabilities is covered in Chapter 16, “Integrating Intune Hybrid into Your Configuration Manager Environment,” and Chapter 17, “Managing Mobile Devices.”

Configuration Manager has the ability to execute tasks on clients, which requires agent software, running the agent as a background service. Once installed and configured, the ConfigMgr client, which communicates with the ConfigMgr back-end infrastructure, can execute commands for tasks such as running hardware inventory or installing software.

When ConfigMgr is implemented in environments that have devices already in place, its discovery functionality can find potential clients in the network.

The authors recommend inventorying your systems to help plan client agent deployment. A free tool to assist with this task is the Microsoft Assessment and Planning (MAP) Toolkit. This solution accelerator provides extensive hardware and software information, utilizing an inventory, assessment, and reporting tool designed for technology migration projects such as Windows 10 migrations or migrations toward Microsoft Azure. The MAP Toolkit is available at http://www.microsoft.com/download/details.aspx?id=7826.

For frequently asked questions on MAP, see http://social.technet.microsoft.com/wiki/contents/articles/1643.aspx.

Windows 7 and higher versions

Windows Server 2008 and higher versions

Windows Embedded and Windows CE

Mac OS X 10.9 and higher

AIX, CentOS, Debian, HP-UX, Oracle Linux, Red Hat Enterprise Linux (RHEL), Solaris, SUSE Linux Enterprise Server (SLES), and Ubuntu UNIX and Linux distributions

Supported OS versions may change with each new build; check https://docs.microsoft.com/sccm/core/plan-design/configs/supported-operating-systems-for-site-system-servers#bkmk_ClientOS for current information.

The Microsoft Task Scheduler service is enabled.

Microsoft Background Intelligent Transfer Service (BITS) version 2.5 or higher is installed.

The Windows Installer version is at least 3.1.4000.2435.

The ConfigMgr client agent installation process automatically installs necessary prerequisites, although you may want to preinstall if a reboot is required. Find the prerequisite software at https://docs.microsoft.com/sccm/core/clients/deploy/prerequisites-for-deploying-clients-to-windows-computers.

You can install the ConfigMgr mobile device legacy client on supported mobile devices such as Windows Mobile and Windows CE. Available features depend on the platform and client type (discussed in Chapter 17).

The next sections discuss the different ways to install the ConfigMgr client agent. Chapter 17 discusses installing the mobile client and enrolling your mobile device for MDM.

CCMSetup.exe and Client.msi support command-line options and properties to change installation behavior. Specify CCMSetup.exe command-line properties and then Client.msi MSI properties, using the format CCMSetup.exe </CCMSetup properties> <Client.msi properties>. CCMSetup properties always start with /.

See https://docs.microsoft.com/sccm/core/clients/deploy/about-client-installation-properties for a complete overview of installation properties, options, and usage examples.

Following is sample syntax to install a ConfigMgr client agent manually in a site that has its properties published to Active Directory (AD):

Click here to view code image

CCMSetup.exe /MP:APOLLO SMSSITECODE=AUTO FSP=APOLLO

This example installs the ConfigMgr client agent using the MP installed on the Apollo system. The PR1 site code is determined by querying AD. The fallback status point (FSP), also installed on the Apollo system, is used to send state messages until the client successfully joins the PR1 site. /MP:APOLLO is a CCMSetup property, and SMSSITECODE and FSP are Client.msi properties.

Chapter 6, “Installing and Updating System Center Configuration Manager,” discusses installing and configuring ConfigMgr to support agent installation and configuration. The “Understanding Client Settings” section of this chapter describes how to configure the default client settings for enrollment and how to configure the enrollment profile.

You can manually install a certificate if the certificate meets ConfigMgr requirements. Mac clients always check for certificate revocation, requiring certificate revocation list (CRL) functionality.

Creating and issuing a Mac client certificate template on a certificate authority (CA) is described at https://docs.microsoft.com/sccm/core/plan-design/network/example-deployment-of-pki-certificates. You must also configure default client settings related to enrollment, including the following:

Setting Allow users to enroll mobile devices and Mac computers to Yes

Configuring an enrollment profile

Before installing the agent, download the program installation files and make them available on the Mac system. Obtain these files by installing the ConfigMgrMacClients.msi file on a Windows system. Download the .msi from https://www.microsoft.com/download/details.aspx?id=47719.

Run the ConfigMgrMacClient.msi file on a Windows system and then extract the Macclient.dmg file to the folder %ProgramFiles%MicrosoftSystem Center Configuration Manager for Mac Client. A DMG file is a Mac OS X Disk Image File, comparable to an ISO file, which contains program installation files for Apple applications. Run Macclient.dmg locally to extract its contents and then perform the following steps to install the agent on Mac OS X:

1. Navigate to the folder where the installation files were extracted.

2. Enter the following command:

sudo ./ccmsetup

Wait for the Completed Installation message to appear. Ignore the message asking to restart and continue with the next step to install the certificate.

3. Run the following command line from the tools subfolder to install the certificate:

Click here to view code image

sudo ./CMEnroll -s <name of the enrollment proxy server>
-ignorecertchainvalidation -u <user name>

sudo allows you to run installation programs using security privileges of another user (superuser by default).

For the name of the enrollment proxy server, use the computer name in the fully qualified domain name (FQDN) format: <domain><username> or <username>@<domain name> notation. For this example, use the following command line:

Click here to view code image

sudo ./CMEnroll -s Athena.Odyssey.com -ignorecertchainvalidation
-u odysseyksurksum

The message Successfully enrolled indicates a successful installation.

4. Use the Mac Computer Enrollment Wizard to enroll the client. This opens when you finish installing the client or click Enroll in the Configuration Manager preference page. The wizard asks for the username, password, and server name of the enrollment proxy point server, as provided at the command line when running CMEnroll.

Restart the Mac system to complete the installation.

Verify a successful installation by finding the client in the All Systems collection or by opening the Configuration Manager item in the System Preferences on the Mac. If there are any issues, use CMDiagnostics to determine the cause. This program creates a .zip file saved to the computer’s desktop.

Install the ConfigMgr client agent on UNIX/Linux computers by using the install script, which is included in the client installation files. The agent uses root credentials to collect hardware inventory and deploy software. After downloading the client installation files and extracting them on a Windows system, copy the install script and .tar file to the UNIX/Linux system. Before running the install script, modify its rights with the following command:

chmod +x install

Start the install script by using the following syntax:

Click here to view code image

./install -mp <MP name> -sitecode <site code> <command line properties>  <client installation package filename>

The following is an example:

Click here to view code image

./install -mp athena.odyssey.com -sitecode PR1 ccm-Universalx64.tar

Specify command-line properties for the install script after the -sitecode option. These properties are described at https://docs.microsoft.com/sccm/core/clients/deploy/deploy-clients-to-unix-and-linux-servers.

Review the scxcm.log file at /var/opt/microsoft to determine whether the client installed successfully. The client should also become visible under Assets and Compliance -> Devices in the console.

Following is sample syntax to install the client agent from a logon script:

Click here to view code image

CCMSetup.exe /logon /MP:APOLLO SMSSITECODE=PR1

When you assign the ConfigMgr client, the software is installed the first time the computer starts.

When you publish the client, it appears in the Control Panel Programs and Features applet, from where it can be installed.

As group policy software installation supports only .msi files, you can only specify the CCMSetup.msi file, found in the <ConfigMgrInstallPath>ini386 folder on the site server, without providing additional parameters. Following is how to provide those parameters:

When the AD schema is extended for ConfigMgr and ConfigMgr publishes site information to AD, the client can query AD for installation properties; these are pushed to AD based on the settings specified in the Client Push Installation Properties.

If the schema is not extended, use group policy to populate the ConfigMgr client properties in the Registry by using a group policy object (GPO). These properties are used during ConfigMgr client installation. Use the ConfigMgrInstallation.adm template located in <ConfigMgrInstallPath>Tools to make the necessary properties available in the GPO management console.

1. In the ConfigMgr console, navigate to Administration -> Overview -> Site Configuration -> Sites.

2. In the navigation tree, select <site code> - <site name> in the Details pane, select Client Installation Settings from the ribbon bar and select Software Update-Based Client Installation to enable ConfigMgr to publish the ConfigMgr client to the SUP.

This method precludes directly providing any installation properties. Have ConfigMgr push the settings to AD or use a GPO to populate the properties in the Registry, as in a ConfigMgr client deployment using group policy.

Use the SUP to update ConfigMgr clients after they are installed; this occurs using the software updates functionality in ConfigMgr. For additional information, see Chapter 15, “Managing Software Updates.”

Before you can install the ConfigMgr agent on an Azure AD-joined Windows 10 device, you must do the following:

Set up Configuration Manager cloud services

Set up the CMG

Chapter 6 discusses installing Configuration Manager cloud services and the CMG.

Once cloud services and the CMG are set up, you must configure the cloud services client settings to allow the use of a cloud distribution point (DP) to automatically register new Windows 10 domain-joined devices with Azure AD and to enable the use of a CMG in case you want to enroll clients when Windows 10 clients are residing on the Internet.

To enroll clients while within the network boundaries of ConfigMgr, at least one MP must be configured with HTTPS.

To install the ConfigMgr client agent on a Windows 10 device meeting this scenario, use the following command-line options for CCMSetup.exe or CCMSetup.msi with the CCMSETUPCMD parameter:

/MP: The download source, which can be set to the CMG if bootstrapping from the Internet.

CCMHOSTNAME: The name of your Internet MP. You can find this by running gwmi -namespace rootccmlocationservices -class SMS_ActiveMPCandidate from a command prompt on a managed client.

SMSSiteCode: The site code of your Configuration Manager site.

SMSMP: The name of your lookup MP; this can be on your intranet.

AADTENANTID, AADTENANTNAME: The ID and name of the Azure AD tenant you linked to ConfigMgr. You can find this by running dsregcmd.exe /status from a command prompt on an Azure AD-joined device.

AADCLIENTAPPID: The Azure AD client app ID.

AADResourceUri: The URI of the onboarded Azure AD server app.

Following is an example of how a CCMSetup command line could look:

Click here to view code image

ccmsetup.exe /mp: https://UNLEASHED.CLOUDAPP.NET/CCM_Proxy_MutualAuth/72057594037928100
CCMHOSTNAME=UNLEASHED.CLOUDAPP.NET/CCM_
Proxy_MutualAuth/72057594037928100 SMSSiteCode=PR1
SMSMP=https://Athena.Odyssey.com
AADTENANTID=72F988BF-86F1-41AF-91AB-2D7CD011DB47 AADTENANTNAME=unleashed
AADCLIENTAPPID=bef323b3-042f-41a6-907a-f9faf0d17026
AADRESOURCEURI=https://unleashedserver

When deploying the agent using Intune, the command line should be built as follows:

Click here to view code image

ccmsetup.msi CCMSETUPCMD="/mp:<URL of cloud management gateway mutual auth endpoint>
CCMHOSTNAME=<URL of cloud management gateway mutual auth endpoint>
SMSSiteCode=<site code> SMSMP=https://<FQDN of MP> AADTENANTID=<AAD tenant ID>
AADTENANTNAME=<Tenant name> AADCLIENTAPPID=<Server AppID for AAD Integration>
AADRESOURCEURI=https://<Resource ID>"

To configure the client approval settings, perform the following steps:

1. In the ConfigMgr console, navigate to Administration -> Overview -> Site Configuration -> Sites.

2. Click Hierarchy Settings from the ribbon bar to open the Hierarchy Settings Properties page.

3. On the Client Approval and Conflicting Records tab of this page, displayed in Figure 9.1, specify the approval method for the site.

Following is what you need to know about client approval:

Clients communicating using HTTP and self-signed certificates must be approved before they can participate in the ConfigMgr hierarchy.

AD clients from local and trusted forests are approved automatically.

Client approval is not necessary when configuring clients to always use HTTPS to communicate with your site or if the clients use a PKI certificate to communicate to site systems, as they are already trusted by means of the installed certificate.

To approve a client, navigate to Assets and Compliance and select the client from the Devices node or from a device collection. Then click Approve on the ribbon bar.

One of the specified client push installation accounts must be a member of the local administrators group.

The remote computer must have the ADMIN$ share enabled.

The computer must be found by the site server and vice versa, using Domain Name System (DNS) name resolution.

The computer must be discovered.

The computer must be reachable by the site server.

The computer must be able to contact an MP to download supporting files.

With client push, the ConfigMgr site server connects to the client computer and verifies its OS information, based on the information stored in the entry for the client in the ClientPushMachine_G table in the site database, which contains the computer name and other information. The site server then connects to the ADMIN$ share on the client and its Registry via Windows Management Instrumentation (WMI) to gather information about the client. It copies CCMSetup.exe and MobileClient.tcf from <ConfigMgrInstallPath>ini386 to %windir%/ccmsetup on the client. CCMSetup.exe uses this file to locate the installation files on the site server and initiates a local installation of the client. Listing 9.1 shows a sample file, with all options configured for the client to install to the Odyssey PR1 site.

LISTING 9.1 Sample MobileClient.tcf File

Click here to view code image

---

[WINNT CLIENT FILES]
   bin\%cli_cpu%MobileClient.tcf=MobileClient.tcf
   bin\%cli_cpu%ccmsetup.exe=ccmsetup.exe

[SERVER PATHS]
   Server1=\ATHENA.ODYSSEY.COMSMSClient
   MP1=Athena.Odyssey.com
   ServerRemoteName1=\Athena.Odyssey.comSMSClient

[Site]
   Last TCF Update=09/26/2016 00:20:09
   SMSMPLIST=Athena.Odyssey.com
   IISSSLState=224
   IISPreferedPort=80
   IISSSLPreferedPort=443
   IISPortsList=80
   IISSSLPortsList=443

SMSPublicRootKey=0602000000A40000525341310008000001000100C1D526FA058D04BED2FCE230B6CB435
8C14E2CEB3342AC1C9D8349074D18B9C3B10271A6263347FD8B845328B5726A79A9017F088F3722D903AB29A
8B35419A3EB0620493B0D99B555D7180E52403FC4FF5E013A1CD3D0E4282C140C258F0157049F9408F2D6127
98AFCF52A4CAD4694109E5EA2EBFF4771874D58BD34DCAF320AB9AFCAA5DF868E1899EC249E6A38F81F2F2FD
4972FA48701D34D1EE0126B03BB4A1AC59B23A712626CA8D4D791DA952C170916B482519A2724841107698FB
2AED05E7AF394C2AAC6A6AC294D761AD3824F7211986BBE4E20C9CF449B68F5CFD3E0E255C3C0B3C2B22F965
B29EB86575619DE2026E7FCB7AFB90584818FF8AC
   SelectFirstCertificate=1

[Client Install]
   Install=INSTALL=ALL SMSSITECODE=PR1

[IDENT]
   TYPE=Target Configuration File

---

When ConfigMgr determines that the CCMSetup.exe service started successfully and the agent is running, the ClientPushMachine_G table entry is updated for verification. The entry is deleted after a second verification. If something goes wrong, ConfigMgr retries the installation every 60 minutes for 7 days and then discards the installation.

1. In the ConfigMgr console, navigate to Administration -> Overview -> Site Configuration -> Sites.

2. In the navigation tree, select <site code> - <site name> in the Details pane, click Client Installation Settings from the ribbon bar, and then select Client Push Installation Properties.

3. Select Enable automatic site-wide client push installation on the General tab, as displayed in Figure 9.2.

4. Specify parameters for client push, selecting server, workstations, and ConfigMgr site system servers. Stipulate whether to install the client software on domain controllers (DCs) or prevent that unless specified in the wizard.

Following is information on the other tabs of the Client Push Installation Properties dialog:

Accounts: Specify one or more accounts for ConfigMgr to use to initiate installation; these should be local administrators. ConfigMgr tries each account until it finds a local administrator.

Select an account specified previously in ConfigMgr or provide a new account to use by keying it in or clicking Browse. Click Verify to confirm that the account and password are correct.

Provide the location of a network share; click Test connection to verify that the account is valid by using it to connect to the network share.

Installation Properties: Specify the installation properties used by the Client.msi Windows Installer file when installing the ConfigMgr client software. By default, SMSSITECODE=<site code> is already available.

To prevent individual systems from receiving the client with site-wide client push enabled, add the computer names of these systems to a Registry key on the primary site server. You may want to do so for temporary systems you do not want to manage or systems where you may not install any additional client software for legal reasons. See https://technet.microsoft.com/library/bb693996.aspx for additional information.

1. In the ConfigMgr console, navigate to Assets and Compliance -> Devices and select a device in the Details pane. Alternatively, navigate to Device Collections and select one of the collections.

2. Click Install Client from the ribbon bar or from the right-click context menu to start the Install Configuration Manager Client Wizard, which provides three installation options you can select individually before continuing the installation:

Whether to install the client software when the computer is a DC.

Whether to always install the client software, even if it is already installed.

Whether a site server other than the site server in the assigned site for the resource can perform the installation. When this is enabled, you can choose a site server from a dropdown list.

3. Click Next on the Installation Options page.

4. Review the Summary page and click Next to install the ConfigMgr client on the target system.

5. On the Completion page that displays when installation completes, click Close to close the wizard.

An empty .ccr file matching the MachineID value in the database entry is created in the <ConfigMgrInstallPath>inboxesccr.boxinproc folder and triggers the client installation. If the installation fails, the .ccr record is moved to the <ConfigMgrInstallPath>inboxesccrretry.box folder, where ConfigMgr retries the installation every 60 minutes for 7 days.

1. In the ConfigMgr console, navigate to Administration -> Overview -> Site Configuration -> Sites.

2. On the ribbon bar, select Hierarchy Settings to open the Hierarchy Settings Properties dialog.

3. On the Client Upgrade tab, shown in Figure 9.3, specify whether you want to enable automatic upgrading of clients when new updates are available.

You can automatically upgrade the client on Windows operating systems by using a two-phased approach:

Upgrade clients in a pre-production collection (enabled by default). ConfigMgr client agents belonging to the Test Client Coll collection automatically update to the latest version of the ConfigMgr client agent. To promote the pre-production client to production status, browse to Monitoring -> Client Status, right-click Pre-Production Client Deployment, and select Promote Pre-production client.

After verifying functionality for the client agent deployed to the pre-production collection, enable automatic client upgrading for all other client agents by promoting that client and enabling the check box Upgrade all clients in the hierarchy using the production client. Exclude servers by selecting the Do not upgrade servers option.

If necessary, specify an exclude collection. All clients belonging to that collection will be excluded from automatic client upgrade and therefore must be updated manually.

Configure when to begin upgrading; the default is 7 days by default, and 31 days is the maximum. You can specify whether to automatically distribute the ConfigMgr client installation package with its updates to DPs that are enabled for prestaged content.

When updating ConfigMgr using the Updates and Servicing functionality discussed in Chapter 6, the ConfigMgr administrator can also update the ConfigMgr client software; choose to upgrade without validating, causing the client package to be overwritten with the new version used by every new client installation or client upgrade; or validate the new ConfigMgr client package first in a pre-production collection. The pre-production package can then be promoted to production.

1. In the ConfigMgr console, navigate to Monitoring -> Overview -> Client Status.

2. Select Pre-Production Client Deployment to review the client deployment status to the defined pre-production collection.

3. Select Production Client Deployment to review the client deployment status as configured in the Hierarchy settings. Click Browse and select a production collection to see the status.

Selecting a slice in the pie chart of the client deployment status page creates a temporary device collection containing the clients that are compliant, in progress, not started, failed, or of unknown status.

When using client push, ensure that all prerequisites are met, ensure that the site server can connect to the client machines, and ensure that one of the configured Client Push Installation accounts can reach the machine on its ADMIN$ share. Test by performing a net use to a client using the Client Push Installation account credentials. Following are some issues that can prevent the ConfigMgr infrastructure from connecting to the client:

The firewall is incorrectly configured.

The ADMIN$ share is unavailable.

The installation account does not have the required administrative rights.

The Client Push Installation account is locked out or has an expired password.

A pending reboot initiated by another software installation is preventing installation of the client software.

There is a nonworking or corrupted DCOM or WMI configuration.

If the site server can connect to the client, ConfigMgr copies necessary files to %windir%ccmsetup, and the installation begins from there. CCMSetup.log provides installation progress, showing information about each step and what went wrong if the client does not install successfully.

Problems could be caused by incorrectly configured site boundaries and boundary groups, or the CCMSetup bootstrapper may be unable to find the necessary files to install the software prerequisites from an MP. ConfigMgr provides reports to assist with failing client installations. Follow these steps to access the reports:

1. In the ConfigMgr console, navigate to Monitoring -> Overview -> Reporting -> Reports -> Client Push. You now see several reports available regarding client push installation:

Client Push Installation Status Details

Client Push Installation Status Details For a Specified Site

Client Push Installation Status Summary

Client Push Installation Status Summary For a Specified Site

The reports provide guidance on where client push installation is failing and where to investigate the issue. For example, if a prerequisite software installation is failing, you could start by examining what occurs when manually installing that software on a failing machine. Use verbose logging to check the log file to determine the root cause.

2. Select a report and click Run from the ribbon bar to open a page where you can provide criteria before running the report.

For additional information regarding ConfigMgr reporting, see Chapter 21, “Configuration Manager Reporting.”

Problems may also occur with client push installation or client assignment after installing the client, leaving the client in an unmanaged state.

On Mac OS X computers, use the CMUnistall program in the DMG file extracted to the Mac OS X client. Start a command line in the program location and type sudo ./CMUninstall -c.

On UNIX and Linux computers, use the uninstall utility installed during ConfigMgr client agent installation. Uninstall the ConfigMgr client agent by typing /opt/microsoft/configmgr/bin/uninstall at the command line.

System Center Configuration Manager currently offers six discovery types:

Active Directory Forest Discovery

Active Directory Group Discovery

Active Directory User Discovery

Active Directory System Discovery

Heartbeat Discovery

Network Discovery

This discovery method is disabled by default, and it runs weekly by default when enabled. It can be configured for the central administration site (CAS) and primary sites. Follow these steps:

1. In the ConfigMgr console, navigate to Administration -> Overview -> Hierarchy Configuration -> Discovery Methods. Select Active Directory Forest Discovery and choose Properties.

2. On the General tab, shown in Figure 9.4, check the box Enable Active Directory Forest Discovery. Also specify whether to create site boundaries from AD and whether you want to create IP address range boundaries for IP subnets.

You can modify the default discovery schedule from 1 week to between 1 hour and 4 weeks. A weekly schedule is usually sufficient. For some scenarios—for example, in the midst of a huge migration that affects AD—you may want to use a different value.

Follow these steps to configure publishing to an AD forest:

1. Navigate to Administration -> Overview -> Hierarchy Configuration -> Active Directory Forests. Select a forest and choose Properties.

2. On the General tab, select whether to discover sites and subnets in that forest. You can also specify the discovery account (which is, by default, the computer account of the site server).

3. On the Publishing tab, select the sites to publish to the remote forest. By default, information is published to the root of that forest; to override the default, specify a particular domain or server.

To configure a new forest in the Active Directory forests configuration, perform the following steps:

1. Navigate to Administration -> Overview -> Hierarchy Configuration -> Active Directory Forests. Click Add Forest in the upper-left corner of the ribbon bar.

2. Provide the domain suffix of the forest you want to add. You can also make all the changes described in the previous procedure in this section for configuring an already added forest.

3. Click OK to save the newly added forest configuration.

You can specify a location in AD to search for groups in a specific container, or you can specify a specific group. These are security groups by default.

Perform these steps to configure Active Directory Group Discovery:

1. Navigate to Administration -> Overview -> Hierarchy Configuration -> Discovery Methods.

2. Select Active Directory Group Discovery and choose Properties.

3. On the General page, shown in Figure 9.5, check the box Enable Active Directory Group Discovery, which is disabled by default.

4. To add a location or group, click Add and select one of the following:

Groups: Select Groups to open the Add Groups dialog. Specify the group to add or click Browse to select one. The site server’s computer account is used for searching; specify another account if necessary (such as to specify a group in another AD domain). You can also select a specific DC to search to lessen the burden on other DCs serving users and devices; the default domain and forest is used by default.

Location: Select Location to open the Add Active Directory Location dialog. Specify a name to reflect the location you want to add and click Browse to search for an AD container. The search is recursive by default, meaning child objects of the selected container are included. The site server’s computer account is used by default to search AD.

5. On the Polling Schedule tab, specify the full discovery polling schedule, which is set as every 7 days. Specify whether to use delta discovery, which is enabled by default with a 5-minute interval and can be set from 5 to 60 minutes.

6. Use the Options tab to exclude certain computers from discovery. These could be computers that have not logged on to a domain for a certain amount of time (90 days by default) or computers for which the computer account was not updated for a certain amount of time (also 90 days by default). You can also enable discovery of members of distribution groups. For this option to work for systems that have not logged on to a domain for a certain amount of time, your AD domain functional level must be Windows Server 2003 or later.

1. In the ConfigMgr console, navigate to Administration -> Overview -> Hierarchy Configuration -> Discovery Methods.

2. Select Active Directory User Discovery and choose Properties.

3. On the General tab, shown in Figure 9.6, check the box Enable Active Directory User Discovery. Click the starburst icon and specify an AD container to search by providing the Lightweight Directory Access Protocol (LDAP) path manually or by clicking Browse and searching for a container. This search is recursive by default. Specify if you want to discover users that reside within groups. By default, the site server’s computer account is used to search AD; specify another account as needed.

4. On the Polling Schedule tab, specify the full discovery polling schedule, which is set to every 7 days. Specify whether you want to use delta discovery, which is enabled by default.

5. On the Active Directory Attributes tab, add specific attributes belonging to the user object to include with the discovery. Select an attribute and click Add. For other attributes, select Custom and type the attribute name.

1. In the ConfigMgr console, navigate to Administration -> Overview -> Hierarchy Configuration -> Discovery Methods.

2. In the navigation tree, select Active Directory System Discovery and choose Properties from the ribbon bar.

The following are the different tabs for Active Directory System Discovery:

General: The General tab, shown in Figure 9.7, allows you to enable System Discovery for the site. Specify AD containers to include in the discovery by clicking the starburst icon or modify an already provided container by clicking the edit icon to its right. Delete a container by selecting it and clicking the red X.

Click the starburst icon to open the Active Directory Container page. Specify a container to search during discovery. Provide an LDAP query or click Browse and select a container from a hierarchy list. You can also specify a global catalog (GC) query to find an AD container within multiple domains. Next, specify the search options, which include recursively searching AD child containers and discovering AD group objects. Recursively searching child containers searches any child container within the specified path. Discovering objects within AD groups also discovers objects within groups in the search path.

Specify a service account to use for the discovery process. By default this is the site server’s computer account, which should at least have read permissions for the specified location. Alternatively, specify a specific domain account with the same user rights.

Click OK after configuring the Active Directory container properties to return to the Active Directory System Discovery Properties dialog.

Polling Schedule: Use this tab to modify how often ConfigMgr polls AD to find computer data. By default, full discovery polling occurs every 7 days starting Thursday 1/1/1998, and delta discovery runs every 5 minutes. These settings are modifiable.

Active Directory Attributes: Specify the AD properties of discovered objects to discover. Attributes discovered by default include name, sAMAccountName, and primaryGroupID. Specify additional attributes, such as adminCount, department, and division, by selecting them from the available attributes list and clicking Add.

Options: Use this tab to exclude computers from discovery—for example, to discover only computers that have logged on or updated their computer account password with the domain within a given period (90 days by default). This lets you keep the ConfigMgr environment clean even if Active Directory is not. These settings are disabled by default.

When enabling options to exclude computers from discovery, the default values are set to 90 days and are modifiable. These settings could depend on the value you configured for clients to update their computer password (30 days by default) and on the number of days within which a client must contact the key management server (KMS) if KMS is the activation mechanism.

Once you enable Active Directory System Discovery or discover clients using Active Directory Group Discovery, clients begin to appear in the Devices node of the Assets and Compliance workspace; these clients do not yet have the ConfigMgr client installed. It is easy to determine whether a client is not installed as the Client column in the Devices view is set to No.

The ConfigMgr client sends a DDR for Heartbeat Discovery every 7 days by default. Using Heartbeat Discovery with the Delete Aged Discovery Data setting in the Site Maintenance task lets you configure when to delete an inactive client from the site database. (Site maintenance tasks are discussed in Chapter 24, “Backup, Recovery, and Maintenance.”) The ConfigMgr client logs Heartbeat Discovery actions in the InventoryAgent.log file, found in the %windir%CCMLogs folder.

To configure Heartbeat Discovery, follow these steps:

1. In the ConfigMgr console, navigate to Administration -> Overview -> Hierarchy Configuration -> Discovery Methods.

2. In the navigation tree, select Heartbeat Discovery for the site code for which you want to enable Heartbeat Discovery and then select Properties.

3. On the General tab, specify whether to disable Heartbeat Discovery and the schedule to use.

With site-wide client push installation, discussed in the “Pushing the Client” section, configure the heartbeat schedule to run less frequently than the client rediscovery period for the Clear Install Flag site maintenance task, discussed in Chapter 24. If the Clear Install Flag task is set to a lower value than the client rediscovery value, ConfigMgr reinstalls the client even if it is running as expected.

The MP of mobile devices managed by an agent generates a DDR for those devices. Disabling Heartbeat Discovery does not disable generating the DDR.

1. In the ConfigMgr console, navigate to Administration -> Overview -> Hierarchy Configuration -> Discovery Methods.

2. In the navigation tree, select Network Discovery under the site code for which you want to enable Network Discovery and then choose Properties from the ribbon bar. Following is information on each tab:

General: You can select a check box to enable network discovery. You can specify one of the following discovery types:

Topology: Topology (which is the default) finds the topology of your network by discovering IP subnets and routers using SNMP, although it does not discover potential clients. The number of subnets and routers discovered is dependent on the specified router hops on the SNMP tab.

Topology and client: Selecting this option also allows you to discover potential client devices.

Topology, client, and client operating system: Selecting this option causes operating systems and versions to be discovered.

Specifying that you have a slow network speed causes ConfigMgr to make automatic adjustments such as doubling the SNMP time-out value and reducing the number of SNMP sessions.

Subnets: You can specify the subnets to search. By default only the subnet of the server running discovery is searched; you can disable this by deselecting the check box Search local subnets. Click the starburst icon to specify a new subnet and provide its subnet address and subnet mask. Modify subnet settings or disable a subnet by clicking the edit icon (which is next to the starburst). You can also delete subnets or switch the order of appearance.

Domains: Use this tab to specify domains to search. Only the local domain is searched by default; disable this by deselecting the Search local domain check box. Add additional domains by clicking the starburst icon to specify a domain name. Click the edit icon to modify the domain properties or (temporarily) disable this option by deselecting Enable domain search. You can also delete domains from being searched or switch the order in which they are searched.

SNMP: This tab specifies SNMP community names and the maximum number of router hops for the discovery process. The public community name is included by default. To specify additional SNMP community names, click the starburst icon and specify a name. You can modify the search order for the SNMP communities and delete previously provided community names. Specify maximum hops to indicate the number of hops used to search for discovered objects. Hops lets you specify how many routers the process will pass through.

SNMP Devices: Specify specific SNMP devices to discover. If you know the IP address or device name to be discovered, click the starburst icon to provide that information.

DHCP: Specify one or more Microsoft DHCP servers to use to discover clients receiving their IP address from a Microsoft DHCP server. You can also specify using the DHCP server that gave the site server its IP address by clicking the check box Include the DHCP server that the site server is configured to use.

Schedule: Identify one or more schedules by specifying when Network Discovery will run. Click the starburst icon to create a schedule by identifying a start time and duration and a recurrence schedule, which can be none, monthly, weekly, or a custom interval.

1. Navigate in the console to Assets and Compliance -> Devices.

2. Select Import Computer Information on the ribbon bar to open the Import Computer Information Wizard.

3. Select to import a single computer or to import computers using a file.

If you select Import Single Computer, provide at least the computer name and either the media access control (MAC) address or SMBIOS GUID of the machine (see Figure 9.8). You can also specify whether to provide a reference computer for use in operating system deployment when migrating settings from an old computer to this new computer.

If you select Import computers using a file, browse for a comma-separated values (CSV) file you can create with Microsoft Excel. The minimum information to supply in this file is the computer name and SMBIOS GUID or MAC address of the machine. You can provide additional information, such as specific variables. If using column headings in the CSV file, check This file has column headings to ignore the first line of the file.

Map the values in the CSV file to the corresponding ConfigMgr fields. If you supplied the CSV fields in the order Name, SMBIOS GUID, MAC Address, Source Computer, Variable1, Variable 2, the most important information is mapped automatically; all you should do is map the provided variables to a ConfigMgr variable. If you don’t make this mapping, these values are ignored.

After supplying the computer information using a CSV file or the wizard, a data preview page indicates the expected result of the import. Click Next to supply the collection to which you want to add the computer resources (All Systems by default).

4. On the Summary page, which shows what will be imported and where, click Next to begin the import. When the import is complete, close the wizard to see the new computers displayed in the specified collection.

Azure AD User Discovery is available in the console as one of the properties of Azure cloud management services. Find the cloud management properties by navigating to Administration -> Overview -> Cloud Services -> Azure Services. From the Azure AD User Discovery tab of the Cloud Management Properties dialog box, you can initiate a full discovery, configure delta discovery, and set the schedule on which the discovery should run.

Manually, Based on Provided Parameters: You can manually assign a client by using the SMSSITECODE property during client installation or by providing the site code in the Configuration Manager Control Panel applet. Manual assignment is necessary when a client is already assigned, when it resides on the Internet, when DNS publishing is used to find the MP, or when the client’s network location does not fall within a boundary group configured for site assignment and a fallback site is not configured. When a client is installed using a task sequence, the SMSSITECODE property is also provided as a client installation property.

Automatically, Based on Information the Client Finds in AD: This occurs by default when you install the client manually and provide SMSSITECODE=AUTO during installation. It requires the MP to be either discoverable or provided as an option.

You can also initiate automatic client assignment by clicking Discover in the Configuration Manager Control Panel applet. The client uses its AD site and IP address to look up its site boundary configured in ConfigMgr and published to AD (or from an MP, if the necessary schema changes to AD for ConfigMgr have not occurred). If the IP falls within a boundary group specified for site assignment on the ConfigMgr site, the client assigns itself to that site. If the client does not fall within a ConfigMgr site boundary group and a fallback site is specified in the hierarchy, the client is assigned to the fallback site. Chapter 6 discusses configuring fallback site assignment.

After an intranet-based ConfigMgr client completes site assignment, it performs a site compatibility check to verify that it is assigned to a ConfigMgr site and has a supported OS and version. Assignment fails if the site is ConfigMgr 2007 or 2012 or if the OS or version is not supported. The compatibility check verifies that the client can access an MP when applicable and can access the site information in AD when published. The check does not occur if the client is configured for Internet-based client management. Assignment succeeds if an older ConfigMgr client agent is assigned to a newer site. The client can then be upgraded via automatic client upgrade.

The configmgrassignment.adm Group Policy template file is also available to configure client assignment. This file is located on the site server in the <ConfigMgrInstallPath>Tools folder and can be used to set these settings using GPO:

Assigned Site by Specifying a Site Code

Site Assignment Retry Interval in Minutes

Site Assignment Retry Duration in Hours

After it is assigned to a site, the client uses the site’s initial MP and composes a list of available MPs (the MP list), stored locally in WMI. This list contains MPs specified during setup and MPs matching the client’s site code, available in AD. The client sorts the list; HTTPS-capable MPs are first if configured with a PKI certificate based on random order or by boundary group configuration if the option Clients prefer to use management points specified in boundary groups is enabled in the hierarchy settings. The list is extended with HTTP-capable MPs in random order or MPs specified by boundary group settings, if enabled. If it has a PKI certificate, the client tries all HTTPS-capable MPs first.

The client updates the MP list every 25 hours, when CCMExec is restarted, and when it receives a new IP address that resets the order of MPs to use. If the client cannot contact an MP from the MP list, it uses an alternative method to search for an MP, in the following order:

Active Directory: The ConfigMgr site server publishes MP information to the Active Directory domain to which the client belongs.

DNS: DNS information is published by the ConfigMgr site automatically if allowed or to DNS manually if automatic publishing is not allowed. For clients to use DNS as a location mechanism for finding the MP, the DNS domain suffix must be provided during client installation with the DNSSUFFIX parameter.

WINS: When the site server is configured to use WINS, it uses this information to publish the MP information.

DNS and WINS are used when an MP was not specified during client setup and the AD schema is not extended for ConfigMgr. The ConfigMgr client consults DNS or WINS and adds the MPs published in DNS or WINS to its MP list.

You can also configure clients such that MPs assigned to a boundary group are preferred over other available MPs. This requires enabling the option Clients prefer to use management points specified in boundary groups on the General tab of the Hierarchy Settings Properties dialog box and adding MPs as a site system server in the References tab of the Boundary Groups dialog box.

When a client may only communicate with a specific MP or specific MPs, you can define these MPs in the client’s Registry. This scenario could be useful for clients in a demilitarized zone (DMZ) environment that are allowed to communicate only with MPs in that same DMZ. Define the MPs for a client to use by specifying the FQDN of the MP(s) as a Reg_Multi_SZ value for the AllowedMPs key in the HKLMSOFTWAREMicrosoftCCM Registry path. You can specify multiple MPs, one per line.

Each client agent runs the Configuration Manager Health Evaluation scheduled task, scheduled at the primary site level. If the client is powered off or in sleep mode, the task runs when the computer is booted or comes out of sleep mode. This scheduled task calls ccmeval.exe, evaluates client health status, and sends results to the site server by using state messages. If it cannot deliver a message, it uses an FSP if one is deployed. ccmeval.exe loads the ccmeval.xml evaluation file, found in the %windir%CCM folder, which contains the client health evaluation rules. Open this file to see the checks and actions that occur. Microsoft does not support modifying ccmeval.xml to include custom checks. For information about the health checks performed, see https://docs.microsoft.com/sccm/core/clients/manage/monitor-clients#BKMK_ClientHealth.

The Configuration Manager Health Evaluation scheduled task also provides remediation by checking important WMI namespaces, classes, and instances, and it reinstalls the ConfigMgr client if missing. It tests whether it can read and write to WMI; if not, it rebuilds the repository and reinstalls the ConfigMgr client.

You can configure the client health mechanism to only perform checks rather than attempt to remediate. To configure health-only scanning, open the Registry and navigate to HKLM/Software/Microsoft/CCM/CCMEval to change the NotifyOnly value from FALSE to TRUE.

Results are displayed in the console under Monitoring -> Client Status -> Client Check. From there you can configure client status settings, which specify evaluation periods for client activity and retention of client status history from 0 to 90 days. You can also schedule client status updates to recur between 1 (default) and 31 days.

You can modify the evaluation periods between 1 and 30 days for the following settings:

Client policy request (by default set to 4 days)

Heartbeat discovery (by default set to 7 days)

Hardware inventory (by default set to 7 days)

Software inventory (by default set to 7 days)

Status messages (by default set to 7 days)

For example, when the software inventory evaluation period is set to 7 days and the site server has not received software inventory data from a client in that time, it considers that client inactive for software inventory. The ConfigMgr client is considered inactive when it is inactive for all listed activities.

Each primary site runs the CH_UpdateAll stored procedure, which summarizes client health and client activity information and provides the schedule for when clients run the Configuration Manager Health Evaluation scheduled task; this is every day by default but is configurable. Follow these steps to change the schedule:

1. In the ConfigMgr console, navigate to Monitoring -> Client Status.

2. Select Schedule Client Status Update on the ribbon bar.

3. Configure the recurrence schedule that by default is set to every 1 day, but can be set to a value between 1 hour and 31 days.

You can also update client status by selecting Refresh Client Status on the ribbon bar; this triggers the stored procedure and refreshes the charts with the latest information, as shown in Figure 9.9.

Look at the Results panes of the Client Status, Client Activity, and Client Check nodes for an overview of statistics and recent alerts. Clicking the corresponding regions in the chart or hyperlinks in the Results pane creates a temporary collection that contains the computer objects belonging to that selection. The Statistics node uses the All Desktop and Server Clients collection by default; change this to any other device collection by clicking Browse and selecting another collection.

ConfigMgr lets you specify client settings at the collection level, meaning you can define different settings as necessary. Note that this can lead to conflicts if a client belongs to multiple collections with client settings. You can set priorities to help manage these settings; the lowest number wins. Design these priorities carefully to maintain consistent client behavior, as you would when designing group policy in AD.

Client settings also assist with VDI scenarios. Each client randomizes scheduled times for hardware inventory, software inventory, software update scans, software update deployment evaluations, compliance settings evaluations, application deployment evaluations, and endpoint protection scans on VMs sharing the same host.

Each ConfigMgr installation has default settings, which are configured at the hierarchy level and applicable to every user and device that does not have custom settings. You can apply other (custom) settings to override the defaults. Default client settings have a priority of 10,000, which means you could theoretically define 9,999 custom client device and user settings. Custom device settings are deployed to device collections; custom user settings are deployed to user collections. When creating custom settings, keep them at a minimum and provide meaningful names so you know what each one does.

Configure default settings by selecting Administration -> Client Settings -> Default Client Settings and then double-click or choose Properties from the right-click context menu or the ribbon bar to open the Default Settings dialog box. Some settings cannot be set through custom device or user settings (for example, the Enrollment profile in the Enrollment section or hardware inventory classes in the Hardware section).

Some settings can use a simple or custom schedule, as shown in Figure 9.10. Following is information about each:

Simple Schedule: A simple schedule allows you to specify an action that runs regularly each specified number of days, hours, minutes, and so on. The client determines when to run this action based on its installation date and coded randomization that distributes the load on ConfigMgr. This option is preferred with VDI clients, as it minimizes the load on the host hosting the VMs—because not all VMs run the same client action at exactly the same time.

Custom Schedule: Use a custom schedule to specify exactly the time to launch the action. This means each client receiving the schedule initiates that action at exactly the same time, which could put a high load on ConfigMgr. Consider using a custom schedule when other processes running at specified intervals require current information.

Use custom client settings to provide specific settings to apply to members of one or more specific collections. For example, you can define another hardware inventory schedule for specific servers managed with ConfigMgr. The first custom client setting defined receives priority 1, the second priority 2, and so on. You can make adjustments to this schedule by increasing or decreasing the priority, by using the right-click context menu or ribbon bar to select Priority.

You can deploy custom settings to one or more collections. Select a setting and choose Deploy from the ribbon bar and specify the collection to which to apply the settings.

To view the result of client settings applied to a device or user, use the resultant client settings capability provided in the Assets and Compliance workspace. Right-click a device, user, or group and select Client Settings -> Resultant Client Settings to open the Resultant Client Settings panes, which display the effective client settings for that device, user, or group.

Specify the time frame for enabling BITS bandwidth throttling by specifying a start and end time window.

If throttling should always be enabled, set the start and stop times for throttling to the same value.

Specify the maximum transfer rate during the throttling window (in kilobytes per second).

Select Yes for the Allow BITS downloads outside the throttling window option to specify whether to use bandwidth throttling outside the specified throttling window. You can specify the maximum transfer rate (in kilobytes per second) when BITS downloads are allowed outside the window.

ConfigMgr clients can leverage BranchCache, a Windows feature that enables clients in remote locations to obtain content from local clients caching that content. Enable BranchCache by setting the option Allow clients to share content with other clients on the same subnet; this is available for packages, application deployment types, and software updates. Chapter 5 discusses setting up BranchCache. The device settings allow you to specify whether to configure BranchCache on clients. When enabling the Configure BranchCache option, specify whether to enable BranchCache and the percentage of disk space to use for the cache.

Peer Cache is similar in functionality but does not require a BranchCache infrastructure. In contrast to BranchCache (which is enabled for any file transfer), Peer Cache only caches ConfigMgr-related file transfers; see Chapter 5 for additional information. Enable Peer Cache by setting the Enable Configuration Manager client in full OS to share content setting to Yes and specifying whether to use HTTP or HTTPS to communicate between client peers. You can also specify the port for initial network broadcast (port 8004 by default) and the port for content download from peer (8003 by default).

Each ConfigMgr client agent also has a cache folder where software distribution-related files are downloaded before executing. This folder is normally in %windir%ccmcache and defaults to 5120MB. If the cache size is too small, the client cannot download the files necessary for a certain task, which then fails. Configure client cache size in the Configuration Manager Control Panel applet on individual clients or by setting the Configure client cache size setting in the Client Cache Settings device settings to Yes. You then can specify the maximum size (in megabytes) or a percentage of disk space to use for the client cache.

When the Enable user policy polling on clients setting is set to No, users do not receive required applications or any other operations contained in user policies, they do not receive revisions and updates for applications published in the application catalog, and they do not see notifications about application approval requests.

User policy requests from Internet clients work only when the Enable user policy setting is set to True and the Internet-based MP can successfully authenticate the user using Windows authentication.

The capability to report and alert on compliance helps monitor and manage configuration drift. You can apply Compliance Settings device settings to desktops, servers, mobile devices, and users; you can also use these settings to remediate WMI, Registry, and script settings that are not natively compliant in ConfigMgr. Automated remediation can drastically reduce the amount of time a noncompliant configuration stays out of compliance.

You can also enable the use of User Data and Profiles management, which is disabled by default. Prior to using this functionality, which is described in Chapter 10, enable it using a client device setting.

Deployment Deadline: Specify the notification intervals before a deployment deadline is reached. By default, users are notified 48 hours in advance when the deployment deadline is greater than 24 hours; you can set this value between 1 and 999 hours.

If the deployment deadline is less than 24 hours but over 1 hour, users are reminded every 4 hours; this is modifiable from 1 to 24 hours.

If the deployment deadline is less than 1 hour, users are notified every 15 minutes; this can be changed to between 5 and 25 minutes.

Application Catalog: Following are settings related to the default Application Catalog website point:

Specify the Server That Hosts the Application Catalog Website by Clicking Set Website: Configuring this setting requires that the application catalog website point be installed. The authors recommend using a NetBIOS name to prevent clients from receiving a credentials prompt when connecting to the website. You must specify the NetBIOS name on the website point properties and have a name resolution mechanism in place that supports short names; this could be specifying the necessary DNS domain suffix search list on the client or using the DNS GlobalNames Zone (GNZ) feature.

Using Automatic Detection, Allowing Clients to Receive the Closest Application Catalog: Automatic detection makes a service location request to a MP every 25 hours, returning an application catalog website based on the client’s location and pointing clients automatically to the application catalog website from their own sites. You can specify different catalogs for clients residing on the intranet and those on the Internet; those configured for HTTPS take precedence over HTTP. You may decide not to use automatic detection if you want to manually specify which clients connect to what server or do not want to wait 25 hours when the application catalog website point changes.

Specifying the URL to a Customized Application Catalog, Allowing You to Specify a URL to a Custom Website Hosting Application Catalog Functionality: If the application catalog website is not added to the trusted sites zone in Internet Explorer (IE) on the client, IE Protected Mode may not allow you to install applications from the catalog. In this case, add the application catalog website to the trusted sites zone in IE by using a GPO. When you use the Add default Application Catalog website to Internet Explorer trusted sites zone setting, ConfigMgr ensures that only the current application catalog is added to the zone. If using other mechanisms to populate the trusted sites zones or other security zones for IE, verify that they do not conflict with ConfigMgr settings.

Allow Silverlight Applications to Run in Elevated Trust Mode: Version 1511 included a new Software Center combining the functionality of the old Software Center and the Application Catalog. The Application Catalog website point and Application Catalog web service point site system roles are still required for user-available applications to appear in the new Software Center.

Microsoft Silverlight is required for the old Software Center. For more information about the old and new versions of Software Center, see the “Use New Software Center” bullet in this list.

Organization Name Displayed in Software Center: This name appears in the Software Center, which can help users identify whether it is from a trusted source.

Use New Software Center: The new Software Center does not require Microsoft Silverlight. Enable use by setting this to Yes. For more on using the new software catalog, see Chapter 14, “Distributing and Deploying Applications and Packages.”

Enable Communication with Health Attestation Service: You can specify whether the client on which the ConfigMgr client agent is running should use the Health Attestation service.

The Health Attestation feature was introduced with Windows 10. It ensures that client computers have a trustworthy BIOS, TPM, and boot software configuration by turning on and using the following options:

Secure Boot

BitLocker

Code Integrity

Early-Launch Antimalware (ELAM)

The client can report its health attestation status to ConfigMgr; information is shown in the console. The status could be used to define rules for conditional access in compliance policies for devices.

You can find health attestation information by navigating to Monitoring -> Security -> Health Attestation. In the Health Attestation results pane, the following information is available:

Health Attestation Status

Devices Reporting Health Attestation

Noncompliant Devices by Client Type

Top Missing Health Attestation Settings

More information about Windows 10 health attestation is available at https://docs.microsoft.com/windows/device-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.

Install Permissions: Specify which users can initiate software installation, software updates, and task sequences; it is set to All Users by default. If it is set to No Users, required deployments are always installed at the deadline, and users cannot initiate software installation from the Software Center or Application Catalog. You can also enable this for administrators and primary users only, or for administrators only.

Suspend BitLocker PIN Entry on Restart: Enable suspension of the BitLocker PIN during restart if BitLocker with PIN is enabled on the client by setting the Suspend BitLocker PIN entry on restart to Always.

Additional Software Manages the Deployment of Applications and Software Updates: Set Agent extensions manage the deployment of applications and software updates to True when using a third-party solution or the ConfigMgr software development kit (SDK). You can also use this option on a collection of VDI clients sharing the same master VM, where you want regular ConfigMgr options to work but don’t want those clients to download and apply any updates as those updates are typically applied to the master VM only.

PowerShell Execution Policy: If your clients run PowerShell 2.0 or higher, you can specify the PowerShell execution policy to apply during ConfigMgr actions. This is set to Restricted by default, meaning the current PowerShell restriction settings on the client are used. Setting it to Bypass allows ConfigMgr to use unsigned scripts during ConfigMgr actions.

Show Notifications for New Deployments: Enable notifications for new deployments by setting this to Yes.

Disable Deadline Randomization: If this setting is enabled, the agent delays installing required software for up to two hours when the deadline is reached. This setting is especially useful in VDI environments where you don’t want all VDI clients to start a certain action at the same time, possibly causing a drop in performance for the entire VDI environment.

Display Countdown Interval Before Log Off and Restart: This is set to 90 minutes by default and can be between 1 minute and 24 hours (1440 minutes).

Display Countdown Interval Before Final Log Off and Restart in Minutes: This is set to 15 minutes by default and can be set between 1 minute and 24 hours.

Ensure that the intervals specified are shorter in duration than the shortest maintenance window so the computer will restart during the window.

Allow Users to Enroll Mobile Devices and Mac Computers: This setting, which is No by default, allows you to specify whether users can enroll older-style mobile devices, such as Windows Mobile and Windows CE and Mac computers. If this is set to Yes, set the Enrollment profile by clicking Set Profile to open the Enrollment Profile dialog.

Allow Users to Enroll Modern Devices: Specify if users are allowed to enroll modern devices using on-premise MDM. The default is No. If it is set to Yes, you can set the Enrollment profile by clicking Set Profile to open the Enrollment Profile dialog.

Chapter 17 discusses setting up enrollment for modern devices. It also covers configuring corresponding user settings.

Client settings can define other Hardware Inventory settings for laptops versus for traditional desktop systems. Configure the items you want to inventory by modifying hardware inventory settings at the Default Client Agent settings level. Perform the following steps:

1. Navigate to Administration -> Overview -> Client Settings.

2. Select Default Client Settings and choose Properties from the ribbon bar.

3. Select Hardware Inventory settings and then Set Classes to open a new dialog box, where you can enable or disable those inventory classes (see Figure 9.11). If a class is checked with a black checkmark in this window, the class and all its properties are inventoried.

If a class has a gray box, the class and some of its properties are inventoried; it is not inventoried if it is not checked. Modify this list by defining custom client devices settings, which enable you to specify different selections for specific collections.

There are several ways to extend inventoried items:

Import a Managed Object Format (MOF) file by using the import functionality, which allows you to browse for MOF files (Chapter 3, “Looking Inside Configuration Manager,” discusses MOF files and their structure.)

Export the settings to a MOF file, which can be imported into another ConfigMgr environment

MIF files can extend hardware inventory information or collect information that is not available in the system. You could write a tool that collects information from an end user, with output in MIF format ready to be picked up by ConfigMgr inventory. MIF file information is sent to and stored in the site database with the default client inventory data. There are two types of MIF files:

Modify MIF storage locations in the Registry by changing the values that specify the locations of the NOIDMIF and IDMIF files. The single Registry key is located under HKLMSoftwareMicrosoftSMSClientConfigurationClient Properties, and you need to modify the NOIDMIF Directory and IDMIF Directory values.

The ConfigMgr client scans the hardware currently installed on the client and sends that information to the site server. Inventory takes hardware changes (deltas) into account, letting administrators determine if there are changes to hardware. Inventoried hardware is defined centrally in the ConfigMgr settings—which you can adjust to include or omit specific hardware. If the client is not connected to the network during inventory, inventory occurs, and the data is uploaded when connectivity resumes. If the client is offline, inventory starts once the client is available.

Hardware inventory also inventories the software listed in the Programs and Features Control Panel applet, which typically suffices to determine software installed on a client. However, not all software is advertised in that applet; use software inventory for a full inventory of your software.

If standard hardware inventory does not provide the needed information, it may be that what is inventoried is not configured in the applied client settings, or new hardware may be available but unknown to ConfigMgr. You can modify ConfigMgr to enable inventory of extra or additional hardware, as discussed in online-only Appendix E, “Extending Hardware Inventory,” which you can download from the book’s companion website, at http://www.informit.com/title/9780672337901, on the Downloads tab.

Client policy retrieval

Client state messages to send to the site

Software installation requests using Application Catalog functionality

Required deployments

User-initiated software installation from Software Center or the Application Catalog is always permitted, regardless of metered Internet connection settings. If the data transfer limit specified on the client is reached, site communication is no longer initiated.

Remote Tools settings can remotely manage client desktops for troubleshooting purposes. This functionality enables remote control from a central point, providing logging capabilities and report functionality. Remote Tools leverages the Windows Remote Desktop Protocol (RDP) functionality. You can use it in several ways—to completely take over the desktop using Remote Desktop or to assist the end user by using the Remote Assistance functionality, where both the end user and help desk view the same desktop.

Remote control behavior depends on the client’s effective default or client device settings. Modify client settings by navigating to Administration -> Overview -> Client Settings and selecting Default Client settings and then modifying custom device settings or creating new settings. Open the Remote Tools section and click Configure to open the Remote Control and Windows Firewall Client Settings dialog. Enable the check box Enable Remote Control on client computers to be able to configure other settings:

Whether ConfigMgr can configure Windows Firewall on the destination computer automatically with the correct rules to allow it to be remotely controlled. Enable rules for the Domain, Private, or Public firewall profile or a combination of these.

Whether users can modify the policy or notification settings in Software Center. If enabled, users can specify whether to use the remote access settings specified by the ConfigMgr administrator or to override these settings with their own values.

Whether to enable remote control of an unattended computer.

Whether the user is prompted for remote control permission and presented with a dialog box to allow remote control.

Whether the user is asked for permission when content is transferred from the shared clipboard.

Whether remote control permissions are granted to members of the local administrators group and the type of access allowed. Available options are None, View Only, and Full Control.

Who can initiate remote control by configuring permissions, allowing AD users or groups.

The types of notifications a user receives when Remote Control is active, enabling a notification icon in the taskbar or a connection bar during a remote session. You can also configure a sound to play on the client, either at the beginning and end of the session or repeatedly.

Manage solicited and unsolicited Remote Assistance settings; if True, ConfigMgr manages Remote Assistance settings. You can also specify the level of access for Remote Assistance; the None, View Only, and Full Control options are available.

Whether ConfigMgr manages the Remote Desktop settings of the client receiving the client settings (set If Manage Remote Desktop to True).

Whether permitted viewers are allowed to connect; use the Remote Desktop connection for users specified in the Permitted viewers list to set up a remote connection.

Requiring network level authentication (NLA) on computers that run Windows Vista and later to configure the Remote Desktop connection to use NLA to connect to the remote computer.

For more information about the Remote Tools settings, see the “Using Remote Control” section, later in this chapter.

To configure software inventory, navigate to Administration -> Overview -> Client Settings. Select Default Client setting or Custom Device Settings. You can also create new custom device settings.

Configure software inventory in the Software Inventory section:

Enable inventory by setting the Enable software inventory on clients value to True and specifying a schedule that defines when clients should execute software inventory.

Select Set inventory reporting detail to specify what to report about the inventoried files: inventory details about the file only, the product associated with the file, or all information (using the Full Details option).

Click Set Types, which is part of the Inventory these file types option, to configure the types of files to inventory by opening the Configure Client Setting page:

Click the starburst icon to specify the files to inventory. Specify a specific filename or use the * or ? wildcard characters, as shown in Figure 9.12.

Specify where to look for the file, which is set to All client hard disks by default, and whether to search subfolders of the specified location. You can also specify to search encrypted and compressed files, which is disabled by default, and to exclude the Windows folder from searches.

Select Set Files to collect files and open the Configure Client Setting dialog. Click the starburst icon to open the Collected File Properties dialog box, where you can specify files to collect. Specify the filename, optionally using the * and ? wildcard characters, location, and whether to search subfolders. You can include encrypted and compressed files (which are excluded by default), and the total volume of files collected, which is 128KB by default. Collecting too many files can negatively impact network bandwidth capacity and your ConfigMgr infrastructure.

Software Metering device settings collect file usage data. Enable software metering by using default client settings or custom client device settings, described earlier in this section. To view data from software metering, navigate to Monitoring -> Reporting -> Software Metering.

After enabling software metering, you can create software metering rules. Follow these steps:

1. Navigate to Assets and Compliance -> Software Metering. ConfigMgr automatically creates a (disabled) software metering rule when 10% of computers in the hierarchy use a program and stopping automatic creation once 100 rules are created, by default. Click Software Metering Properties in the ribbon bar to modify these settings and data retention. To enable a rule, select it and click Enable on the ribbon bar.

2. Select Create Software Metering Rule on the ribbon bar to open the Create Software Metering Rule Wizard, which you can use to create a custom software metering rule.

3. Provide a name for the rule; type the name of the file to monitor or click Browse to browse to it. By browsing, ConfigMgr reads the details of the file from the file header and automatically fills in the file information.

4. Click Next to continue to the Summary page to review the software metering rule settings, and click Next again to create the rule. Click Close in the Completion page to close the wizard.

Use reports to view the information from software metering and create collections based on the information they provide. These collections are based on the Software Usage Data attribute class. Chapter 14 discusses creating collections.

State messages sent by ConfigMgr clients to their MP or FSP report the current state of ConfigMgr client operations. The result of these messages is shown in reports. Various data in the console depends on the state messages received, such as software updates and settings management.

For more information about state messaging, see Steve Rachui’s article at https://blogs.msdn.microsoft.com/steverac/2011/01/07/sccm-state-messagingin-depth/, and Chapter 3.

You can use device affinity when defining deployment types in applications. Chapter 11, “Creating and Managing Applications,” covers user and device affinity and using this information when deploying applications. Using default settings, a user device affinity mapping is created after the device is used for 48 hours (2880 minutes) within 30 days. For ConfigMgr to automatically create user device affinities based on the specified data, set Automatically configure user device affinity from usage data to True.

User and Device Affinity settings for users allow you to specify whether to enable a user to define their primary device. There is only one setting for user and device affinity for users—if it is set to True, users can set their own device affinity in the Application Catalog.

For Windows 7 and 8.1, telemetry can only be enabled or disabled. The following options are available for Internet Explorer data:

Disable

Enable for local internet, trusted sites, and machine local only

Enable for Internet and restricted sites only

Enable for all zones

Information about Windows 7 and 8.1 telemetry is available at https://go.microsoft.com/fwlink/?LinkID=822965. See https://msdn.microsoft.com/library/ms537183(v=vs.85).aspx for additional information about IE telemetry.

Start the Remote Control viewer from the Windows Start menu or the ConfigMgr console. ConfigMgr also lets you start a Remote Assistance or Remote Desktop session to the remote computer.

The notification bar in Figure 9.13 is quite visible on the remotely controlled computer and displays the account name of the user remotely controlling the computer. Remote control uses TCP port 2701; ports 2702 and 135 are no longer used. If Kerberos authentication fails when you want to control a computer remotely, the system prompts whether to use the less secure NT LAN Manager (NTLM) authentication mechanism. If the connection to the remotely controlled machine is disconnected, the remote computer is locked. Remote Control supports multiple monitors.

Start the Remote Control viewer from the command line with CmRcViewer.exe, located in the <%ConfigMgrInstallPath%>AdminConsoleBinx64 folder. Supply two values when connecting to a client computer with this utility:

The NetBIOS or FQDN of the client you want to administer remotely

The site server to which you want to send state messages

An example of the use of CmRcViewer.exe is CmRcViewer.exe albert.odyssey.com \ambassador.odyssey.com.

The following nodes appear in the Resource Explorer:

Hardware: Hardware shows hardware from the last hardware inventory. Extend the list by enabling extra classes or properties or add extra data to hardware inventory by extending it, as described in online-only Appendix E.

Hardware History: Hardware History shows what changed between hardware inventory scans, providing information about changes to inventory.

Software: Software provides insight into data coming from software inventory. It provides an overview of collected files, file details of inventoried files, when the last software scan was performed on the client, and information about which products were inventoried.

Enable hardware inventory.

Install the ConfigMgr agent on destination systems.

These are the external prerequisites:

Ensure that NICs support WOL and the use of magic packets.

Enable WOL on NICs and in the BIOS of destination systems.

If using subnet-directed broadcasts (discussed in the next section), configure the network infrastructure to forward these broadcasts.

The Wake On LAN tab provides several approaches to how the site wakes up computers. When enabling WOL on this tab, you must configure how to power on your clients. The following options are available:

Subnet-directed broadcast

Unicast

To view the port used for the magic packet, select the Ports tab of the <site> Properties dialog box. The default is UDP port 9; change it by double-clicking the Wake On Lan (UDP) entry in the list box or select it and click Properties to launch the Port Details dialog. A single port number is supported. Click Advanced to access advanced options, which are mainly network and ConfigMgr throttling controls; change these only if issues occur.

Unicast: Unicast WOL sends a single magic packet to the IP address of the system, taken from the hardware inventory of the destination system. This is a specially crafted UDP packet sent directly to the destination’s IP address. Some network adapters might not respond to wake-up packets when using unicast, depending on their configured sleep state.

The magic packet includes the system’s MAC address. The destination NIC compares the MAC address to its own before waking up the system; if it does not match, the NIC does not signal the system to wake up. Unicast is supported in both IPv4 and IPv6 environments.

If the ARP cache of the device no longer contains the MAC address of the target, it uses an ARP request to discover the MAC address. However, because responding to an ARP request is a function of a running OS, the magic packet cannot be delivered to the target. An exception is when the network card and driver installed on a system have a feature called ARP Offload and the feature is enabled.

Subnet Directed: ConfigMgr broadcasts the magic packet to the IP subnet of the destination system, where each NIC compares the MAC address in the magic packet to its own, waking up its system if there is a match and enabling ConfigMgr to wake up those systems with changed IP addresses still on that subnet. Subnet-directed WOL utilizes subnet-directed broadcasts, requiring support from your network infrastructure. These broadcasts are often disabled due to overhead or security concerns, as enabling them opens the network to possible distributed denial-of-service (DDoS) attacks such as Smurf attacks. Mitigate this by changing the default port used by subnet-directed WOL packets and configuring the network to allow only subnet-directed broadcasts from your site server.

For wake-up proxy to work correctly, at least three computers should be awake and receive guardian computer functionality, meaning they stay awake and ignore any settings related to power management.

The computers in the subnet that are powered on request that the network switch redirect broadcast traffic to themselves and keep the ARP cache for the sleeping computers populated. This issue, known as MAC flap, can cause network monitoring or network intrusion to create alerts or shut down ports. The authors recommend consulting your network group prior to implementing this feature.

For more information about implementing wake-up proxy, refer to https://docs.microsoft.com/sccm/core/clients/deploy/plan/plan-wake-up-clients.

Application management package/program mandatory deployments

Task sequence mandatory deployments

Software update mandatory deployments

A check box appears on the Deployment Settings page of the deployment wizard for each object if the deployment is set to Required; this cannot be changed after you create the deployment. ConfigMgr then sends the WOL request to the destination system at its scheduled mandatory time. Magic packets are sent only from the primary site server. When the destination system wakes up, it initiates any applicable mandatory deployments.

If a deployment becomes mandatory on a system after the time scheduled for the deployment—such as by being added to a collection where a deployment is past its mandatory time—that system will not have a magic packet sent to it.

WOL is a great addition to the ConfigMgr toolset, although third-party tools can enhance its functionality. The two primary third-party alternatives (Green Planet from Adaptiva and Night Watchman from 1E) fill some gaps and enable greater flexibility for both WOL and power management by providing peer-to-peer capabilities, where peer systems harvest MAC addresses and send WOL magic packets based on ConfigMgr and other events.

1. Navigate to Assets and Compliance -> Device Collections. Select the collection and choose Properties.

2. On the Power Management tab, select the Specify power management settings for this collection radio button.

Indicate peak hours by specifying the start and end times of the peak hours time frame. You can then specify the power plan to use during and outside specified peak hours. Select a plan by choosing it from a list. The following plans are available by default:

Customized Peak (ConfigMgr)

Customized Non-peak (ConfigMgr)

Balanced (ConfigMgr)

High Performance (ConfigMgr)

Power Saver (ConfigMgr)

Select View to open the power plan’s properties. Selecting the Customized Peak (ConfigMgr) or Customized Non-peak (ConfigMgr) power plan changes this option to Edit, allowing you to modify that plan, as shown in Figure 9.14, or create a plan by providing a new name and description. Power plan settings can be set for when a device is on battery or plugged in.

You can enable the option Wakeup time (desktop computers) and specify a time when a desktop computer will wake from sleep or hibernation to install software or updates.

Click Browse to copy power plan settings from a collection and then select a device collection from the Select Collection dialog.

When a device is a member of a collection where the power management option Never apply power management settings to computers in this collection is set, the computer does not apply power management settings even if it belongs to another collection with power settings. If it belongs to multiple collections with power settings configured, the least restrictive value is the effective value. Wake up is the time closest to midnight. Configuring power settings using a GPO overrides ConfigMgr settings.

Many reports analyze power consumption and check applied power settings. See https://docs.microsoft.com/sccm/core/clients/manage/power/monitor-and-plan-for-power-management for more information.

The chapter discussed using different client device and user settings, allowing you to granularly define those settings. It discussed managing the client, leveraging WOL using ConfigMgr to wake up clients, and configuring power plans to control the power settings configuration on ConfigMgr client agents.