To a new ConfigMgr administrator, hardware inventory sounds like collecting specific hardware information for a client. Although true, that is only a small subset of the information you can collect in hardware inventory. Hardware information is collected from Windows Management Instrumentation (WMI) and the Windows Registry (via WMI). Refer to Figure 12.3, which displays the standard hardware inventory queried from a Windows XP Professional client named Tarzan in the SCCMUnleashed domain.

Figure 12.3. Resource Explorer for a Windows XP Professional client

As the Resource Explorer in Figure 12.3 shows, ConfigMgr inventories a significant amount of hardware by default, such as network adapters, SCSI controllers, disk drives, and partitions. You also see information such as Add/Remove Programs (software that appears in Add/Remove Programs), Services (Windows services on the inventoried system), and various operating system information. To launch the Resource Explorer, simply right-click a computer object in a collection and select Start -> Resource Explorer.

Once you are introduced to hardware inventory, you will probably find it to be vital information you want to collect in your environment. Perform the following steps to enable hardware inventory:

Figure 12.3 shows hardware inventory is configured by default to inventory a significant amount of data. You may find that you need more or less information. Use the SMS_Def.mof file to enable or disable the inventory of specific classes as well as properties within those classes. The SMS_Def.mof file is located in <ConfigMgrInstallPath>inboxesclifiles.srchinv. Make a backup copy of the file, and then edit the original file using a standard text editor such as Windows Notepad.

The following example modifies the SMS_Def.mof file to inventory ConfigMgr http ports configured on the client. This class is disabled by default, as shown in Figure 12.6.

Figure 12.6. Default inventory configuration for Win32Reg_SMSAdvancedClientPorts from SMS_Def.mof

To change SMS_Def.mof to inventory the http ports, perform the following steps:

ConfigMgr hardware inventory is very extensible. All data located in WMI or the Windows Registry can be easily collected using ConfigMgr hardware inventory. If the desired data does not currently exist in WMI or the Registry, you can always use ConfigMgr’s software distribution component to run a script or executable on each system to populate the Registry with desired data and then collect it using hardware inventory.

For additional information, Microsoft provides documentation on extending hardware inventory at http://technet.microsoft.com/en-us/library/bb680609.aspx. You may also want to consider purchasing the SCCM Expert’s book Start to Finish Guide to MOF Editing, by Jeff Gilbert, available at http://www.smsexpert.com/MOF/Guide.aspx. This book provides an in-depth look at modifying and customizing hardware inventory.

For information on how SMS_Def.mof and Configuration.mof are used in Configuration Manager 2007, see Chapter 3, “Looking Inside Configuration Manager.”

Software inventory collects information about files and file locations. The General tab for the Software Inventory Client Agent Properties dialog box is very similar to the General tab for hardware inventory, previously described in the “Hardware Inventory” section of this chapter. Enable the software inventory agent, and select to use a simple or custom schedule (review the “Using a Simple Schedule” sidebar). On the Inventory Collection tab, select the file type and path for files to inventory. As Figure 12.8 shows, ConfigMgr 2007 inventories .exe files by default.

Figure 12.8. The Inventory Collection tab of the Software Inventory Client Agent Properties dialog box

To add an additional file type, click the orange starburst in Figure 12.8 to open the Inventoried File Properties tab shown in Figure 12.9.

Figure 12.9. Defining a new filename to inventory

Figure 12.9 shows a new rule being created to inventory all pre–Access 2007 databases (*.mdb extension) located in the %PUBLIC% path environment variable. Options specified include searching subdirectories and including compressed and encrypted files. Although this example uses a file extension, you can also inventory for an exact filename (budget.mdb) or partial filename (budget*.mdb). The ConfigMgr integrated help provides additional assistance on wildcard usage.

Use the File Collection tab, visible in Figure 12.8, to collect a file (or files) from each client. Click the orange starburst on that page to create a new file collection entry. Figure 12.10 shows a sample file collection entry. Similar to software inventory, file collection allows you to specify an exact filename or use wildcards. You can also specify a specific path, or accept the default that queries all local hard disks for the file. You will also notice that there is a Maximum Size (KB) option—this specifies the maximum size of all files this rule will collect. As an example, if you specified *.ini as the rule, an attempt would be made to collect all .ini files, but if the sum of the size of those files is greater than the Maximum size, none of the files will be collected.

Figure 12.10. Creating a new file collection entry

File collection occurs during a scheduled software inventory cycle. Once files are collected, you can use Resource Explorer to view the files.

The last tab of the Software Inventory Client Agent Properties dialog box (Figure 12.8) is Inventory Names. You can use this to help make more sense out of software inventory data. The header properties in files are not always consistent, which often makes reporting of this data confusing. A name is often listed in multiple ways; as an example, Microsoft can be represented as Microsoft Corp., Microsoft Corporation, Microsoft, and so on. Microsoft has already prepopulated some data for Microsoft products to help make inventory more concise, as shown in Figure 12.11.

Figure 12.11. Configuring inventory names

Figure 12.11 shows that each name specified in Inventoried Names will be grouped and considered as the display name of Microsoft Corporation. By clicking on the starburst by Display name, you can easily add to this list to group other software as well.

As an example, say you have six different programs from Acme Corporation and notice that different names are inventoried for Manufacturer (Acme Corp., Acme, Acme Corporation, Acme Corp. International, and so on). You can add a new display name of Acme Corporation and then enter each inventoried name into the Inventoried Names section in the Software Inventory Client Agent Properties dialog box. You can perform this same grouping for the Product property by changing the Name type option in Figure 12.11.

Configuring the Advertised Programs Client agent enables software distribution for the site. Software distribution is one of the core functions of ConfigMgr. Check the first box in Figure 12.12 to enable software distribution.

Figure 12.12. The General tab of the Advertised Programs Client Agent Properties dialog box

The three check boxes in the Client Settings frame help you customize software distribution:

The Notification tab of the Advertised Programs Client agent gives you the ability to display a notification message and play a sound if desired when new programs become available. You can also configure a countdown for when a mandatory advertisement will run.

The Computer Client agent provides many general settings. Figure 12.13 shows the General tab of the Computer Client Agent Properties dialog box. Specify a Network Access Account to allow ConfigMgr clients to access network resources during software distribution and Operating System Deployment (OSD). This should be a low-rights user account, which simply has access to file shares you may require.

Figure 12.13. The General tab of the Computer Client Agent Properties dialog box

You also specify the default policy polling interval on this tab. The polling interval is the interval that the ConfigMgr client checks its management point for new or updated client policy (including software update deployments and software distribution). Depending on your environment, you may have reason to increase or decrease this interval:

You can also modify the polling interval on a per-collection basis if desired.

The final option on the General tab is configuring the state message reporting cycle (in minutes). Software Updates deployment, task sequence advertisements, and Desired Configuration Management (DCM) use state messages to send state information to the ConfigMgr site. During these operations, the client may create several state messages. Leave the default of 15 minutes, and extend this interval if you start to receive backlogs of state messages.

The Customization tab of the Computer Client Agent Properties dialog box allows you to add customized branding to Software Updates deployments. This can provide a better user experience, and helps your end users know that updates are being deployed by your Information Technology (IT) organization.

The Reminders tab allows you to configure the interval for system tray balloon notifications for software updates, mandatory software distributions, and task sequence advertisements. Gently remind users of possible disruptions to their schedule, and allow them to install mandatory distributions in advance of deadlines when possible.

Configure the BITS tab to manage client communications and the maximum transfer rates for each client. As shown in Figure 12.14, BITS (Background Intelligent Transfer Service) throttling can be configured three different ways:

Figure 12.14. The BITS tab of the Computer Client Agent Properties dialog box

As you can see in Figure 12.14, you specify a throttling window start and end time, as well as the transfer rate during that window. You can set the maximum transfer rate during the throttling window between 0 and 9999 Kbps.

You can also check the box to allow BITS downloads outside the throttling window, and specify the maximum transfer rate outside the window. This gives you the flexibility to restrict transfers during peak hours of network traffic, and then relax your transfer rules during off-peak hours, thus allowing the branch distribution point (and all other clients, if desired) to download content faster from the ConfigMgr site.

The Restart tab of the Computer Client Agent Properties dialog box allows you to specify how much notice a user receives before a restart occurs.

Simply check the box to enable Desired Configuration Management. By default, the compliance evaluation schedule will be a simple schedule of every 7 days. Similar to configuring hardware inventory, you can create a custom schedule if desired. Chapter 16, “Desired Configuration Management,” provides additional information on DCM.

Mobile Device Client Agent Properties is your one-stop-shop to configure those mobile devices that ConfigMgr will manage. From this single dialog box, you define the polling interval, inventory properties, software distribution, and file collection. Figure 12.15 displays the default configuration of the Mobile Device Client agent. The article at http://technet.microsoft.com/en-us/library/bb693474.aspx provides more information about managing mobile devices with ConfigMgr.

Figure 12.15. The Mobile Device Client agent

The mobile client performs operations similar to the ConfigMgr client. Table 12.1 lists several differences to consider.

You enable the Remote Tools Client agent to connect to remote systems so you can control the user’s desktop. Figure 12.16 displays the General tab of the Remote Tools Client Agent Properties dialog box.

Figure 12.16. The Remote Tools Client Agent Properties dialog box

Check the first box to enable Remote Tools. Use the configuration settings on the General tab to manage the level of access. Some companies prefer not to ask for permission for remotely accessing clients; other companies require that a user is asked for permission before granting remote access.

You can grant rights to users and Active Directory groups to use remote control on a sitewide level or on a collection level. For example, you could grant the Server Operations group Remote Control rights to a collection containing servers, and grant the Service Desk group Remote Control rights to a collection containing workstations. Chapter 20, “Security and Delegation in Configuration Manager 2007,” contains additional information regarding Remote Tools security.

Use the Notification tab to configure if and how you will notify an end user a remote control session is active. This setting applies only to Remote Tools.

You can also control the Remote Assistance and Remote Desktop settings of ConfigMgr clients from the respective tab on the Remote Tools Client Agent Properties dialog box. The settings you configure are sitewide, and they override any local policy configured on the client. Domain policy takes precedence over these settings.

Enable the check box on the General tab of the Network Access Protection Client Agent Properties dialog box to configure Network Access Protection (NAP). On the Evaluation tab, specify the frequency of NAP reevaluation after the client has successfully connected to the network. You can also force a fresh scan for each evaluation instead of allowing clients to offer a cached Statement of Health, as displayed in Figure 12.17.

Figure 12.17. The Evaluation tab of the Network Access Protection Client Agent Properties dialog box

Use software metering to monitor and collect software usage data on ConfigMgr clients. Once this is enabled, you can identify users who use a certain application, the peak usage times of the application, and more.

The default schedule collects data from each client every 7 days. After enabling the agent, right-click the Software Metering node in the ConfigMgr console and then select Properties, as shown in Figure 12.18.

Figure 12.18. Software Metering Properties dialog box

The Data Retention property in Figure 12.18 specifies how many days the data obtained from the metering rules will be stored in the database. The 90-day default setting should be sufficient, unless you plan to trend usage data for over 3 months. (When using Asset Intelligence, you will need to enable software metering to identify and report on various assets. This is discussed in Chapter 18.)

Enable the check box to auto-create metering rules from recent usage inventory data. The rules ConfigMgr creates require that you enable them. The two additional settings in this frame allow you to configure the requirements for auto-creating rules. By default, rules are auto-created when an executable runs on 10% of the computers in the site, unless the total number of rules for the site exceeds 100. To view rules, simply click the Software Metering node. To enable a rule, right-click a disabled rule and select Enable. By allowing ConfigMgr to auto-create metering rules, you will get a better idea of the software that is installed on a large number of systems in your environment, and have the ability to easily enable metering for the software.

A classic example of using this feature is to find a large number of systems with software such as Microsoft Visio installed. When you see this new rule, you enable it, and from software metering web reports, you find that only 20% of the systems that have the software installed use it on a regular basis. You can now use this information to support the removal of the licensed application on nearly 80% of the installation base, thus reducing your software costs.

To create a new rule, right-click the Software Metering node and select New -> Software Metering Rule to launch the New Software Metering Rule Wizard, as shown in Figure 12.19.

Figure 12.19. The New Software Metering Rule Wizard

Figure 12.19 shows a basic rule to meter Microsoft Office Word. Specify the name of the rule and the exact filename (no wildcards). You can manually enter the filename, or you can click the Browse button, navigate to the file, and select it to populate the details automatically on this page. Alternatively, you can specify the original filename, obtained by reading the filename from the header of the file. You can enter a version number to meter a specific version, or use an asterisk to inventory all versions.

The default language in the wizard is English. If you are uncertain whether the file you desire to meter will have a consistent language (or if it doesn’t have a language at all), select -Any- from the dropdown. Specify the site code that this rule applies to, and determine whether you want to apply the rule to all child sites of the specified site code.

Configure the Software Updates Client agent to leverage one of the most popular (and most important) features of ConfigMgr 2007—patch management.

Simply enable the check box on the General tab for the default configuration of the Software Updates Client agent, as shown in Figure 12.20.

Figure 12.20. The Software Updates Client Agent Properties dialog box

You can then choose for the scan to run a simple or custom schedule. The “Using a Simple Schedule” sidebar earlier in this chapter discusses choosing a simple or custom schedule. On the Update Installation tab, you can choose the client to install all mandatory deployments, even if a deployment has a deadline in the future. In this situation, you have multiple deployments targeting a system, with multiple deadlines. If you enable this check box, all mandatory updates will be deployed when the first deadline is reached. This helps to eliminate multiple reboots, and provides a better end-user experience. You can also choose to hide all display notifications from end users if desired—this is a sitewide setting, meaning all Software Updates notifications will be hidden from the user. To hide notifications on a per-deployment basis, modify the properties of the desired deployment. The Deployment Re-evaluation tab allows you to configure enforcement of a patch that was uninstalled. By default, the client will reevaluate every 7 days to ensure compliance. Chapter 15 includes information about patch management.

Active Directory (AD) System Group Discovery is a discovery method that polls the domain controller for System Group objects in the domain or Lightweight Directory Access Protocol (LDAP) path specified on a schedule configured by the ConfigMgr administrator. Here are the default group account attributes returned by Active Directory System Group Discovery:

AD System Group Discovery will only discover these attributes for systems that have previously been discovered by some other method (AD System Discovery, Heartbeat Discovery). After enabling AD System Group Discovery, click the starburst to configure the desired container to search. As displayed in Figure 12.21, you have the ability to select the local domain or local namespace or use a custom LDAP or GC query.

Figure 12.21. Active Directory System Group Discovery

Review the log file adsysgrp.log for detailed information when the discovery method executes.

Active Directory Security Group Discovery is a discovery method that polls the domain controller for Security Group objects in the domain or LDAP path, based on a schedule configured by the ConfigMgr administrator.

Configuring this discovery method is very similar to configuring AD System Group Discovery. AD Security Group Discovery will only discover these attributes for systems previously discovered by some other method (AD System Discovery, Heartbeat Discovery). Specify the container to discover, and determine if you want to discover recursively, and within groups. Finally, set a polling interval. Review the adsgdis.log file for detailed information when the discovery method executes.

Active Directory System Discovery is the key discovery method used to create data discovery records (DDRs) for computers. DDRs contain data such as operating system (OS) name and version, Internet Protocol (IP) addresses and subnets, and AD site names. You can use these DDRs to target installations for client deployment. Active Directory System Discovery is agentless, and you can use it to discover what is in your environment before installing client agents on computers. This capability gives the administrator an understanding of the network infrastructure and deployment challenges in advance.

Configuring this discovery method is very similar to configuring AD System Group Discovery. Specify the container to discover, and determine if you want to discover recursively, and within groups. Finally, set a polling interval.

If you used Systems Management Server (SMS) 2003, you will also notice a new tab named Active Directory Attribute. This tab allows you to add more Active Directory attributes to the system discovery process. You can add any computer object attribute from Active Directory, such as OperatingSystemServicePack and terminalserver. You can find all available attributes using the ADSIEdit MMC snap-in. Microsoft provides documentation on ADSIEdit at http://technet.microsoft.com/en-us/library/cc773354.aspx. You can find a list of AD search computer property attributes at http://www.winzero.ca/Active-Directory-computers.htm. Review the adsysdis.log log file for detailed information when the discovery method executes.

Active Directory User Discovery is a discovery method that polls the domain controller for user objects in the domain or LDAP path specified on a schedule configured by the ConfigMgr administrator. Here are the default user attributes returned by Active Directory User Discovery:

The first two tabs are configured the same as the other Active Directory discoveries—simply specify the container and polling interval. The most interesting tab is the Active Directory Attribute tab, shown in Figure 12.22.

Figure 12.22. Active Directory User Discovery Properties dialog box

The System Required column indicates whether the Attribute name is a required attribute. All the attributes where System Required is equal to No in Figure 12.22 are attributes manually added to discovery. As you can see, it is possible to discover much more information about users than the defaults. You can identify employeeID, mail (email address), manager, department, and more. You can find all available attributes using the ADSIEdit MMC snap-in.

Review the adusrdis.log file for detailed information when the discovery method executes.

Heartbeat Discovery is a ConfigMgr capability that enables deployed ConfigMgr clients to send DDRs to their management point. This enables clients to keep the ConfigMgr database current with discovery-related data that often changes, such as IP addresses. Heartbeat Discovery is the only required discovery method and the only one that must be enabled.

Configure a simple schedule, ensuring the schedule is configured to run more frequently than the client rediscovery period of the Clear Install Flag task in Site Maintenance. The Clear Install Flag task relies on accurate data that is forwarded from Heartbeat Discovery. If a heartbeat is not forwarded within the client rediscovery period, the install flag is cleared, causing a new attempt at installing the client and unnecessary utilization of your site and clients.

Network Discovery allows ConfigMgr administrators to collect discovery data by IP subnet, domain, Simple Network Management Protocol (SNMP) community, SNMP device, or DHCP server (which must be a Microsoft-based DHCP server).

Enable Network Discovery and then choose the type of discovery to perform:

Figure 12.23 shows Topology selected as the discovery type.

Figure 12.23. Network Discovery Properties dialog box

Figure 12.23 also shows the Out of Band (OOB) Management frame currently disabled—you must have ConfigMgr Service Pack (SP) 1 installed to even see this frame at all. You must configure the OOB service point and configure a provisioning account before you can enable discovery of Out of Band management controllers. Here are some points to keep in mind:

Microsoft’s document at http://technet.microsoft.com/en-us/library/bb693986.aspx contains additional information about Network Discovery. You will also want to review netdisc.log for detailed information when the discovery method executes.

When you install the ConfigMgr client, you have more than 50 command-line properties to choose. This section covers the most popular commands. The article at http://technet.microsoft.com/en-us/library/bb680980.aspx provides a complete list.

ConfigMgr uses CCMSetup.exe and CCMSetup.msi as the main programs for client installation. Other files are required (Windows Update Agent, XML Parser, and so on), but only CCMSetup.exe and CCMSetup.msi are called directly with command-line options.

In almost all scenarios, you will call CCMSetup.exe with the appropriate command-line options. CCMSetup.exe then downloads and installs the required components and launches CCMSetup.msi with the proper command-line options. The only exception to this is when you are deploying the ConfigMgr client using Active Directory. Table 12.2 lists popular command-line options for CCMSetup.exe, and Table 12.3 lists popular command-line options for CCMClient.msi. As mentioned previously, you generally will not call CCMClient.msi directly; you will simply execute CCMSetup.exe and pass command-line options for both CCMSetup.exe and CCMSetup.msi.

The command-line options in Tables 12.2 and 12.3 are used throughout the various client installation methods appearing in this chapter.

One other aspect of client installation that is consistent is the client installation logs ccmsetup.log (appears when ccmsetup.exe is used to install the client) and client.msi.log (appears for every client installation). Review these log files in the %windir%system32ccmsetup folder for x86 systems, and in %windir%ccmsetup for x64 systems. Also, check ClientIDManagerStartup.log to verify that the client has successfully registered with its site. A client will not successfully pull policy until it is registered with the site. Additional information on common registration issues is available at

Although manual client installation is probably not the method you will use to install all clients, it is a method that all environments will use, most often in service desk or on-site support scenarios. Having a well-documented process for reinstalling a ConfigMgr client is essential.

First, you must locate the installation files. By default, you will find these files in the %ProgramFiles%Microsoft Configuration ManagerClient folder. CCMSetup.exe is the file you will use to initiate the installation, and depending on the operating system version, additional windows components (XML Parser, Windows Update Agent, BITS, and so on) are installed from this folder. ConfigMgr requires these additional components for a healthy client. Fortunately, you don’t have to manage the installation of each of these components. There are three primary methods to install the client manually:

Now that you have seen these three options, you may ask which one is the best. As with all things technical, it depends. The authors prefer the /mp: switch for almost all manual installation scenarios. Using this switch means you need access to CCMSetup.exe (and of course a healthy management point). ConfigMgr handles the source file folder, and the files are accessed by the client via HTTP.

Enable Client Push Installation to deploy the client agent automatically to those systems discovered and assigned to the site. Before enabling Client Push Installation, it is highly recommended you use the Client Push Installation Wizard for testing individual systems and individual collections. The only configuration difference between Client Push Installation and the Client Push Installation Wizard is the first check box in Figure 12.24. Figure 12.24 shows the General tab of the Client Push Installation Properties dialog box.

Figure 12.24. The General tab of the Client Push Installation Properties dialog box

As you can see in Figure 12.24, the Enable Client Push Installation to assigned resources box is checked. When you enable this check box, you can then determine the system types to target. Servers and workstations are enabled by default; domain controllers and site systems are disabled. Click the Accounts tab to configure Client Push Installation accounts, as displayed in Figure 12.25.

Figure 12.25. The Accounts tab of the Client Push Installation Properties dialog box

Use the Accounts tab to add accounts to install the ConfigMgr client. To add a local account, simply follow the same pattern shown in Figure 12.25. For the local administrator account, simply enter .Administrator and the appropriate password. Enter multiple accounts to ensure you have at least one administrator account for each system you desire to install. To configure installation settings, use the Client tab, as shown in Figure 12.26.

Figure 12.26. The Client tab of the Client Push Installation Properties dialog box

By default, the SMSSITECODE public property is visible. You can add Windows Installer command-line properties (see Table 12.3) to configure the client at install time. As an example, to modify the cache size, add the property SMSCACHESIZE=1024, where 1024 is the size (in MB) to configure. The ccm.log file on the site server provides client installation information.

If the site is unable to install the client (because of rights, the system not being on the network, and so on), the site attempts to install the client every hour for 168 hours (1 week). See Microsoft’s document on Client Push at http://technet.microsoft.com/en-us/library/bb632380.aspx for additional information. Note that Client Push does not need to be enabled to push clients, as discussed in the next section.

The Client Push Installation Wizard uses the same process as Client Push Installation. The title makes it obvious that the only difference is the wizard itself. It is highly recommended you test deployments using the Client Push Installation Wizard prior to enabling Client Push Installation, because you have more control.

To configure the Client Push Installation Wizard, simply configure the Accounts and Clients tabs (Figures 12.25 and 12.26, respectively). To use the wizard, perform the following steps:

You can use the Client Push Installation Wizard even after you have enabled Client Push to force a reinstall on a client or multiple clients, or to upgrade clients.

Pre-installing the ConfigMgr client into an operating system allows you to get your ConfigMgr client up and running as soon as the image is deployed.

To install the ConfigMgr client, follow the steps described in the “Manual Installation” section of this chapter, and omit the SMSSITECODE property. When the SMSSITECODE property is omitted, the client does not attempt assignment. Delete the SMS section in the Computer Account Certificates Store, displayed in Figure 12.28.

Figure 12.28. ConfigMgr client certificates

Microsoft provides additional information for installing ConfigMgr clients using imaging at http://technet.microsoft.com/en-us/library/bb694095.aspx.

You can use group policy and the SUP to install the ConfigMgr client. With this installation method, you are not able to specify Windows Installer properties on the command-line settings, but you can specify the properties using group policy. If you have extended the Active Directory schema, clients will be able to discover their assigned site properly.

A key point to remember with this installation method is that once the ConfigMgr client installation succeeds, it will verify the client is configured to use the correct SUP (according to ConfigMgr Site assignment and site boundaries) and modify it if required. If the deployed group policy configures the client to use a different SUP, the client configuration (of the SUP) will fail and generate errors in the ConfigMgr client logs. See http://technet.microsoft.com/en-us/library/bb633194.aspx for complete details.

To uninstall the client, simply run ccmsetup.exe /uninstall—you can use ccmsetup.exe in the client installation directory or copy ccmsetup from a site (there is no need to copy the entire installation directory).

You may encounter failures on some corrupted clients (mostly from WMI errors) when attempting to uninstall. In extreme cases, installations may be successful if you use ccmclean.exe from the SMS 2003 Toolkit. Technically, this is not supported on ConfigMgr, but if you have a corrupt client that you cannot reinstall, or uninstall, try using ccmclean.exe.

Say you have successfully deployed ConfigMgr, and you have a healthy site. A few months later, you now have a service pack for ConfigMgr. You have successfully upgraded your site(s) to the new service pack, and now you need to upgrade the clients, because clients do not automatically upgrade.

If you have a small, single site, the easiest method to upgrade clients is to use the Client Push Installation Wizard. Simply right-click the desired collection and then select Install Client. Follow the remaining steps in the “Client Push Installation Wizard” section of this chapter, and force a reinstall/upgrade on targeted clients.

A great method to perform this upgrade in larger environments is to use ConfigMgr software distribution (see Chapter 13, “Creating Packages,” and Chapter 14, “Distributing Packages,” for information on creating and distributing packages). Simply create a package and specify the package source as the ConfigMgr client installation files (by default, %ProgramFiles%Microsoft Configuration ManagerClient). Then send this package to your distribution points. Create a program that executes ccmsetup.exe. Do not specify the SMSSITECODE property, unless you want to change the site code. You can add other Windows Installer properties, such as FSP and the SMSSLP (http://technet.microsoft.com/en-us/library/bb680980.aspx) to change the current configuration of the existing client. Finally, create an advertisement targeting desired systems.

Using either the Client Push Installation Wizard or traditional software distribution, you will not need to specify a different installation for x86, x64, or IA64. CCMSetup.exe will handle the need to install the appropriate client on the appropriate platform.

A client patch is somewhat different to deploy than a client upgrade:

A client patch will typically be a Windows Installer patch (with an .msp extension). To deploy this patch, create a new package and use traditional software distribution methods. A sample command line for Microsoft Knowledge Base article 955955 would be

Although the command line appears as more than one line here, it is actually one line. KB article 955955 at http://support.microsoft.com/kb/955955 provides an example of how to deploy a ConfigMgr client patch.

This section discusses several general troubleshooting scenarios. Table 12.4 lists several common issues to help get you started.

The Internet is your best friend for both ConfigMgr documentation and ConfigMgr troubleshooting. Table 12.5 provides some favorite tools and sites for online assistance.

ConfigMgr creates unique hardware IDs to define unique computers. Based on 10 computer properties (SCSI adapter, processor serial number, MAC address, and so on), a unique hardware ID is created. If a system is reimaged (and no hardware replaced), the hardware ID will be consistent from the previous install to the new install.

When this occurs, ConfigMgr will have two records for the same resource, often called duplicate hardware IDs. As discussed in Chapter 8, the Advanced tab of the Site Properties provides the option to create new client records manually or automatically.

The ConfigMgr Toolkit is available from Microsoft’s download center at http://www.microsoft.com/downloads/details.aspx?FamilyID=948e477e-fd3b-4a09-9015-141683c7ad5f&DisplayLang=en (or at www.microsoft.com/downloads, search for ConfigMgr Toolkit). It includes seven tools to help you manage and troubleshoot Configuration Manager 2007. Table 12.6 describes these tools.

In troubleshooting ConfigMgr, Trace32 (also known as SMS Trace) will be your best friend. You may be used to reading log files using Windows Notepad or another log reader such as Tail. For ConfigMgr, nothing beats Trace32. In addition to being customized to read ConfigMgr logs, it allows you to view those logs in real time, meaning as ConfigMgr writes new data to the log, the data will appear in Trace32. You can open log files using Trace32 on both local and remote systems. Figure 12.29 shows Trace32 viewing the execmgr.log log file.

Figure 12.29. Viewing execmgr.log from Trace32 (a.k.a. SMS Trace)

If you have viewed sitecomp.log using Notepad, you will see a significant difference in human readability with Trace32. Trace32 is configured to automatically parse date/time stamps as well as format the data to make it easier for the administrator to view. By default, Trace32 highlights keywords such as Error and Warning. You can also define additional keywords to highlight. Figure 12.30 shows the Filter feature.

Figure 12.30. Filtering content using Trace32

Filter (from the Tools option) allows you to customize the view to see only specific words or phrases, and even a specific date/time. You can also open multiple log files in one view, which may help you see the bigger picture when troubleshooting.

Also from the Tools option, you will find Error Lookup. Error Lookup prompts you to enter a Windows error message, and it displays the description for that error. As an example, entering error number 32 displays “The process cannot access the file because it is being used by another process.” Spend some time with Trace32 and the reference documentation located in ConfigMgr Toolkit help.

Clispy, the SMS Advanced Client Troubleshooting Tool and part of the Toolkit, is another great tool for troubleshooting client issues. Clispy allows you to view the following for both the current computer and remote computers:

Use Policy Spy to view ConfigMgr client policy on either a local or a remote computer. As shown in Figure 12.31, you can view machine policy as well as user policy.

Figure 12.31. Policy Spy from the ConfigMgr Toolkit

Policy Spy allows you to view the complete policy, as downloaded from the client’s management point. It also allows you to delete policy instances as well as reset policy (which basically removes all nondefault client policy and then queries the management point for all assigned policies). Check the ConfigMgr Toolkit documentation for more information.

Many techs will uninstall and reinstall the ConfigMgr client at the first sign of trouble. It is really best to avoid this process, because it is often more time consuming and does not always solve the problem. Software Updates is a great example. Just because patches are failing to install does not mean that the client is corrupt—it could be that the Automatic Updates agent is not working properly. Before uninstalling the client, perform some basic tests to determine what is working, if anything. Here are several basic functionality tests to try, which may help you narrow the scope of the problem at hand.

Spend some time troubleshooting clients, and read the client logs carefully. The logs are very detailed, and usually help you determine the root cause of the problem.