Microsoft introduced the first version of its desktop management software, Systems Management Server 1.0 (code-named Hermes), in January 1994. SMS 1.1 came out in mid 1995, and SMS 1.2, discussed in the next section, followed in 1996.

Microsoft touted SMS 1.2 as a systems management solution that provided an array of tools—from remote control to software distribution—helping local area network (LAN) administrators to monitor and manage their networks. In reality, SMS 1.2 was behind the competition for the following reasons:

Microsoft released SMS 2.0 (code-named Opal) in January 1999, and shortly after that, its first service pack (SP). The product was one of the first management tools utilizing the Microsoft Management Console (MMC), and it incorporated major changes for SMS administrators and the worldwide community. Enhancements included the following:

The following sections discuss additional enhancements.

Microsoft launched SMS 2003 (code-named Emerald) in November 2003. Two major and three minor changes to SMS 2003 helped set it apart as the dominant systems management suite for Windows:

Service Pack 1 for SMS 2003 was released in September 2004. Although primarily a hotfix rollup, the service pack included new functionality:

Microsoft released SMS 2003 Service Pack 2 in June 2006. SP 2 included hotfix rollups and new functionality, including querying AD security groups, Fully Qualified Domain Name (FQDN) support, support for x64, IA64, and R2-based Windows Server 2003 installations, multithreaded software inventory processing, replicating decommissioned DDRs up the hierarchy, and updates to the Inventory Tool for Microsoft Updates (ITMU).

In late 2006, Microsoft announced its first SMS version using the branding R2 (for Release 2). SMS 2003 R2 built on SMS 2003 SP 2, with enhancements that included the Inventory Tool for Custom Updates (ITCU) and the Scan Tool for Vulnerability Assessment.

Service Pack 3 for SMS 2003 was released in April 2007. Microsoft’s acquisition of AssetMetrix introduced Asset Intelligence for SMS 2003, included in the service pack. Asset Intelligence brings categorization of over 400,000 software titles in over 100,000 categories. SP 3 also gave SMS administrators the ability to deploy Windows Vista using the Operating System Deployment (OSD) feature pack. Administrators could also deploy updates to Vista clients and applications as well as perform hardware and software inventory on Vista clients.

Microsoft released System Center Configuration Manager 2007 in August 2007. Known as SMS v4 during beta testing days, the product was rebranded toward the end of the development phase. This version is the first to include the previously separate “feature packs” directly in the product. Using SMS 2003, one might install four to eight different feature packs to incorporate various capabilities, but then some of these items did not show up on the administrator’s console without running a local installation!

In Configuration Manager 2007, Desired Configuration Management, Operating System Deployment, Device Management, Patch Management and other features come built in to every ConfigMgr console—these components previously required multiple, separate installations. ConfigMgr 2007 no longer has a Legacy Client; there is only one ConfigMgr client for all supported operating systems, starting with Windows 2000 Professional.

ConfigMgr 2007 has a concept of native mode as the security mode. Native mode allows using Public Key Infrastructure (PKI) to secure client-to-server communication, as discussed in detail in Chapter 6, “Architecture Design Planning.” ConfigMgr also supports an implementation model known as Internet-Based Client Management (IBCM). IBCM allows managing clients across numerous firewalls, including unmanaged ones. This implementation allows ConfigMgr administrators to push software or updates to clients surfing the Web from home or a hotel. Chapter 6 also discusses IBCM.

Table 2.1 compares the SMS 2003 and ConfigMgr 2007 feature sets.

Microsoft released Service Pack 1 for Configuration Manager 2007 in May 2008. SP 1 includes hotfix rollups and adds support for Vista SP 1 and Windows Server 2008. The service pack also provides support and integration with the Intel Active Management Technology (AMT), which allows remotely powering on and off systems as well as remote diagnostic capabilities. Asset Intelligence-related changes in the service pack include its addition as an independent node in the ConfigMgr console, an expanded catalog, new customization capabilities, new reports, hardware and software inventory enhancements, software license management capabilities, Client Access License-related data for Windows Server and Exchange Server, and Key Management Servers (KMS) for Windows Vista activation.

The R2 release of ConfigMgr 2007 (August 2008) incorporates a number of new features:

Now that you have had a glimpse of the history of Configuration Manager, it is time to look at some key terminology for the product.

The site server is a site system role assigned to the server where the Configuration Manager setup program runs. By definition, each ConfigMgr site has at least one site server. This system has the ConfigMgr binary files installed on it, and can have clients assigned to it for management purposes. The site server manages all components belonging to its site, including management points and distribution points.

Site servers are divided out into two types:

Although both are types of site servers, there are significant differences between the two, differences you will need to understand to place them properly in your organization. The next sections discuss these differences.

Site systems are servers, and in some cases workstations, that host roles for the Configuration Manager infrastructure. Site systems include the following:

Site systems should always reside in the same AD forest as the site server. Spanning Active Directory forests with Configuration Manager sites is not recommended because you would span the Active Directory security boundary by allowing administration from a different forest.

Although not recommended, it is possible to have the following site systems in a remote forest:

Site hierarchies exist when there are more than one Configuration Manager site server and the servers have a parent/child relationship defined between them. Hierarchies can be very simple and flat or complex and deep to support an organization’s requirements for systems management.

A parent ConfigMgr site implies there is at least one child site. A parent site can have many children, and those children can have children. Secondary sites cannot have child sites, and the parent of a secondary site is always a primary parent site, because secondary sites do not have their own database.

Only the PMP and DP roles can leverage the sender that the secondary site relies on for communication to the parent primary site.

A common hierarchical model is for a central site to manage servers and a child primary to manage workstations. This architecture provides a structure for the server administrators to manage their systems and the workstation administrators to manage their systems while segregating the management of those systems, the features enabled, schedules, and so on. Figure 2.2 illustrates an example of a three-tiered hierarchy with two branches, one of which is two-tiered.

Figure 2.2. A three-tier Configuration Manager hierarchy, illustrating parent/child relationships

Configuration Manager 2007 uses a new client, known as the Configuration Manager client. This client is the agent residing on all managed systems. The ConfigMgr Client agent periodically checks in with the ConfigMgr infrastructure, using an administrator-defined interval. This interval is every 60 minutes by default, and can be set to be as wide as 1,440 minutes (every 24 hours). The client supports installation in a number of ways—preloaded into an image, manually installed, installation with a silent command line, via WSUS, or a pushed installation by the ConfigMgr server (manually or automatically) using the discovery processes defined later in the “Discovery” section of this chapter.

The ConfigMgr client is responsible for installing and removing software, running inventory, reimaging a system, performing patch management compliance scans, monitoring desired configuration compliance, software metering, remote control support, maintenance tasks, file collection, downloading policies, and uploading status messages. The client is bandwidth aware and leverages BITS to determine available network capacity and utilize that to download packages without affecting end-user performance. Chapter 5, “Network Design,” describes BITS in detail.

Installing the Configuration Manager Computer Client agent gives an administrator the ability to enable hardware and software inventory client agents to collect specific types of data and upload them to the ConfigMgr infrastructure in an efficient and compressed XML format. Hardware and software inventory run under the client SMS Agent Host service. The settings (policies) defined for the various client agents, often referred to as sitewide settings, affect all clients monitored by the ConfigMgr site.

Hardware Inventory

Hardware inventory enables collecting data on client systems from their motherboard, BIOS, hard disk, CPU, video card, network card, Registry, WMI, and other components. Hardware inventory uses MOF (Management Object Format) files to define what is to be inventoried and the format used to report that data. The Hardware Inventory Client agent defines hardware inventory frequency.

ConfigMgr incorporates a major shift in handling MOF files. In earlier versions, the SMS_Def.mof file was the only MOF file SMS provided natively to collect inventory. The problem was most administrators modified the file directly to extend inventory to include things such as proxy settings or antivirus definition dates and versions. Service packs and site resets overrode any customizations to the SMS_Def.mof file, making it critical to maintain backups.

ConfigMgr 2007 MOF files are functionally similar to OpsMgr management packs. The Configuration.mof file defines the data classes inventoried by the Hardware Inventory Client agent. You can create data classes to inventory existing or custom WMI repository data classes, or registry keys present on client systems.

The Configuration.mof file also defines and registers the WMI providers used to access computer information during hardware inventory. Registering providers defines the type of provider used and the classes it supports. WMI and Configuration Manager 2007 hardware inventory will only access registered providers.

The SMS_Def.mof file defines the reporting classes used by the Hardware Inventory Client agent to determine whether specific client data class information is reported. Reporting classes are based on the WMI repository data classes and the attributes of those classes; these exist on clients by default, or you can add them by customizing the Configuration.mof file.

Reporting class information in SMS_Def.mof is converted into a reporting policy provided to clients during their normal computer policy polling interval. After the client compiles the new reporting policy, the reporting policy information is stored in the client system WMI repository in the InventoryDataItem class of the RootCCMPolicyMachine WMI namespace.

The initial hardware inventory generated by the client is a full inventory. Subsequent inventories are deltas, information that has changed since the initial inventory. All of the hardware inventory data is viewable via the Configuration Manager Resource Explorer, displayed in Figure 2.3, which shows hardware for the Alamo computer system.

Figure 2.3. Configuration Manager Hardware Inventory for the Alamo system, viewed in the Resource Explorer

Software Inventory

ConfigMgr 2007’s Software Inventory Client agent has the ability to scan files, inventory them, and upload this data to the site server. The Software Inventory Client agent can also collect and copy files to the site server. The ConfigMgr administrator enables and configures the Software Inventory Client agent from the Configuration Manager console.

Caution

File Collection Warning

Be careful when you identify files to collect. If you specify collecting a 1MB file, for example, ConfigMgr will collect every occurrence of that file on each client; with 10,000 clients, you would send 10GB across the network and to the site server. Sending this amount of data will affect server storage capacity and introduce network bandwidth concerns.

Software Inventory scans the header and footer of every file with a file extension specified in the user interface (UI). By default, ConfigMgr scans only .exe files. Individual organizations may add additional file types to this list to identify specific software. When Software Inventory initially runs on a system, it performs a full scan of the drive and generates a manifest of all files the system contains. All subsequent inventories generate delta reports, thus minimizing network traffic and server processing load. Software Inventory catalogs file and product details, including a file’s publisher, product name, creation date, and file version, to name a few. Figure 2.4 shows Software Inventory for the Alamo system.

Figure 2.4. Configuration Manager Software Inventory viewed in the Resource Explorer

With Software Inventory, the ConfigMgr administrator can define which drives to scan, and whether to include the Windows system directory, encrypted files, or compressed files. Similar to the Hardware Inventory Client agent, a schedule can be specified determining when the Software Inventory Client agent will run.

The agent also has the ability to group various files it has scanned, which may come from the same manufacturer but show up with different names, under the same overall name. This feature is very similar to the Asset Intelligence integration introduced in SMS 2003 SP 3.

Configuration Manager 2007 uses the MMC, version 3.0, to provide the user interface to configure the Configuration Manager hierarchy and manage clients. An important part of ConfigMgr deployments is installing the ConfigMgr console on administrators’ workstations. A best practice is to run the console from a remote system, not directly from the server.

Table 2.3 lists the platforms on which you can install the Configuration Manager 2007 console.

When upgrading to ConfigMgr 2007, many organizations have SMS 2003 and Configuration Manager 2007 coexisting to maximize end-user support. If performing an upgrade or migration from SMS 2003, you can run the SMS 2003 and the Configuration Manager 2007 consoles on the same computer in parallel. In addition, most functions an administrator can perform on a secondary site server, using the primary parent SMS Administrator console, are available with the ConfigMgr 2007 console.

Because the console now uses MMC 3.0, it can take advantage of a new feature called the Actions pane. This pane is context sensitive and allows administrators to quickly see and execute different tasks, based on what they selected elsewhere in the console. The console is used to configure and manage the ConfigMgr infrastructure, to execute tasks such as distributing packages and advertising packages and task sequences, to review inventory, and so on.

The ConfigMgr console displays what are known as top-level objects, also referred to as nodes. SMS 2003 had 12 top-level objects in the SMS Administrator’s console. Microsoft substantially redesigned the ConfigMgr 2007 console to be more intuitive and logical in regard to grouping objects that work in conjunction with one another. The console now has only five top-level objects: the Site Management, Computer Management, System Status, Security Rights, and Tools nodes.

You can view an example of how this change is implemented by looking at the top-level Computer Management object, which has 12 child objects. Software Distribution is one of the child objects and contains packages and advertisements, which are two nodes where administrators spend a lot of time. Figure 2.5 displays the Configuration Manager console with the Software Distribution node highlighted.

Figure 2.5. The Configuration Manager 2007 console

Collections are logical groupings of computer systems, users, or groups. They identify objects for a variety of purposes, such as the following:

You can populate collections using a direct membership or query membership rule. Both these methods allow the administrator to populate a collection. Collections are discussed in more detail in Chapter 14, “Distributing Packages.”

Collections can have subcollections. This is useful for organizational reasons as well as for software distribution, due to the ability to advertise a package to a collection or its subcollections. Subcollections are also discussed in Chapter 14.

Collection security gives Configuration Manager administrators the ability to manage which administrators will have varying levels of access to specific collections. Configuration Manager 2007 uses an implementation of WBEM (Web-Based Enterprise Management) security, a standard created by the DMTF (Distributed Management Task Force). Chapter 3, “Looking Inside Configuration Manager,” discusses WBEM and the DMTF. The WBEM security model leverages a class/instance model and is extremely granular. Most ConfigMgr objects have specific rights, which you can grant unique to an object.

ConfigMgr discovers resources in a networked environment using a variety of built-in discovery methods. These discoveries create DDRs, which you can display in collections and queries. ConfigMgr has six types of discovery methods:

The Active Directory discovery methods have the ability to specify LDAP paths for which you want to discover objects. Although some discovered objects such as users and groups are not capable of management, they are useful for reporting and using in query criteria to populate collections for application distribution.

Each discovery method has its own schedule, allowing configuration on a recurring interval and at non-peak times. See Chapter 12, “Client Management,” for further information on discovery methods.

Software metering in ConfigMgr is passive, collecting data for a specified amount of time about the usage frequency of applications. Software metering gives administrators the ability to monitor specific application usage across the entire enterprise. Unlike in earlier versions, administrators no longer need to define most commonly used applications because ConfigMgr creates these rules automatically if an administrator-specified percentage of the environment is using an application.

ConfigMgr uses packages to distribute software and changes to clients. Think of a package as a change in a client’s configuration. Historically, administrators have only thought of packages as software installs. Packages can be the silent uninstallation of an application, a remediation package from a desired configuration baseline that has been strayed from, a change to a Registry key, the startup behavior of a service, and so on. See Chapter 13, “Creating Packages,” for a discussion of packaging.

Packages are distributed to DPs where they reside for clients to access. This distributed copy of the package architecture allows efficient use of bandwidth-sensitive links and minimizes the impact to the network infrastructure. Clients can download packages into their local cache and execute them later, mitigating the scenario where hundreds of clients all run an installation off a server at the same time.

Once distributed, packages are advertised to collections, which contain computer, user, or group resources. This process allows the package command line to execute according to a strict schedule and set of parameters that determines how the package will run and how the client operating system behaves, not only while the package is installing but also after it completes.

Advertisements are policies that ConfigMgr clients download and execute on a schedule. Advertisements define when clients can execute the program in a package and whether to run it from a distribution point or copy it to their local cache and run it locally. Chapter 13 also discusses advertisements.

By definition, advertisements require a user to initiate launching the package command. Mandatory advertisements do not require any user input and are actually a push-install, opposed to the pull-install used with advertisements in their default mode. You can use features such as Wake On LAN (WOL) in conjunction with mandatory advertisements to minimize impact to the end-user community.

ConfigMgr administrators can create DPs throughout an enterprise having a large number of client systems, thus minimizing network traffic over the WAN and slower links. Distribution points can utilize BITS, but not for throttling package traffic from the site server to the DP. BITS also allows checkpoint restarting. In other words, if there was an interruption to a download at 60% completion, using BITS allows the download to resume at that point instead of starting over again from the beginning, which is what happens when clients connect to DPs using Server Message Block (SMB) traffic. Distribution points can be installed on a system as either a package share or a server share. See Chapter 14 for additional information regarding the use of distribution points.

Senders are located on primary and secondary sites. Senders define how ConfigMgr sites use existing network connectivity to manage the connection, ensure the integrity of transferred data, recover from errors, and close the connection if no longer needed.

Sender types include the following:

The most common sender used is the standard sender, which is the only type required when there is basic network connectivity across a LAN or WAN. Microsoft designed the courier sender for sending excessively large packages across a network with slow links. The purpose of the courier sender is to create a parcel, which is a collection of files from a package, and ship the parcel on tape or CD to the remote site location where the administrator can then load the package into the site. Chapter 5 discusses the courier sender. Asynchronous RAS, ISDN, X25, and SNA senders communicate over each of those respective types of links.

Addresses define a site code and the security account used to communicate with a remote site. Addresses also give ConfigMgr administrators the ability to schedule when traffic can flow between the two sites by priority of the traffic, as well as the percentage of bandwidth the sites may use during communications. All communication between ConfigMgr sites use SMB and travels on TCP port 445. By default, ConfigMgr secures site-to-site communication by secure key exchange, which only needs to be defined per parent/child connection. Figure 2.6 displays the Rate Limits tab for the Dallas site, limiting the transfer rate used to send data to that site.

Figure 2.6. Properties of Configuration Manager 2007 addresses

BITS is a subcomponent of IIS, a component of Windows. Using BITS allows administrators to prioritize and throttle asynchronous file transfer between two Windows systems. BITS uses available network bandwidth to handle transfers, making them transparent to the end user’s experience. BITS monitors network traffic on the local network interface and throttles itself accordingly. BITS also provides the ability to continue transferring data when network connectivity is intermittent or unreliable by leveraging checkpoint restarting.

Task sequences are new in ConfigMgr 2007. Task sequences consist of a series of customizable tasks or sequentially performed steps running in an unattended fashion on a system. Task sequences often are only thought of in the context of operating system deployments. Because you can advertise task sequences directly to client systems, you can use them for a multitude of things, including chaining a series of actions together. Task sequences allow each action in the sequence to be independent of the other, let you change the order of tasks, and allow each action to have its behavior individually defined if errors occur. Task sequences consist of actions, custom and built-in actions, conditions, and steps. Task sequences also support grouping of actions for organizational purposes.

ConfigMgr maintains status on many of its technologies. Package status provides a summary of the version and time packages were copied to various distribution points. Advertisement status details when clients have received advertisements and started advertisements. It also shows the succeeded or failed status in the overall execution of the advertisement. Site status gives administrators a bird’s-eye view of the health of the entire ConfigMgr site’s infrastructure. ConfigMgr’s component status details the health of each individual component in the site, such as discovery method’s running state, sender health, DPs, MPs, and so on. Figure 2.7 shows the site status system from the ConfigMgr console.

Figure 2.7. Configuration Manager 2007 status system example

DCM is a component built in to ConfigMgr that was previously provided in an SMS 2003 feature pack. DCM allows you to assess the compliance of computers with regard to a number of configurations, such as whether the correct Microsoft Windows operating system versions are installed and configured appropriately, whether all required applications are installed and configured correctly, whether optional applications are configured appropriately, and whether prohibited applications are installed. You can also check for compliance with software updates and security settings.

DCM is a framework where the ConfigMgr client has an agent, enabled at the site level, tracking baselines defined by the ConfigMgr administrator. You can also track deviations from the baseline. Each item, known as a configuration item, is tracked against a baseline; the item can be reported against or be corrected when the deviation occurs. System Center Configuration Packs, available from the Microsoft System Center Pack Catalog at http://go.microsoft.com/fwlink/?Linkid=71124, define Microsoft best practices for various product configurations.

You can evaluate both published and manually created baselines for compliance in your organization. Published configuration data from Microsoft and other vendors is available at http://go.microsoft.com/fwlink/?LinkId=71837. You can assign these configuration baselines to a collection, just like an advertisement, and evaluate them on a schedule independent of inventory and other agent schedules. Similar to inventory information, you can evaluate configuration baseline compliance when clients are offline; ConfigMgr sends the compliance data upon reconnection to the site hierarchy. Figure 2.8 displays the DCM home page in the Configuration Manager 2007 console.

Figure 2.8. Configuration Manager 2007 DCM home page

See Chapter 16, “Desired Configuration Management,” for a complete discussion of DCM.

NAP, new in ConfigMgr 2007, works with the Microsoft Windows Network Policy Server (NPS) on Windows Server 2008. NAP helps enforce compliance with selected software updates on clients capable of supporting NAP (NAP-capable clients). These clients include Windows XP SP 3 and Windows Vista. Using NAP, a client has restricted network access until it becomes compliant.

Configuration Manager by itself does not enforce compliance with Network Access Protection; it provides the means by which Configuration Manager clients produce a statement of health with a noncompliant status if they do not have the required software updates in the Configuration Manager NAP policies you configure. A Configuration Manager System Health Validator (SHV) point confirms the health state of the computer as compliant or noncompliant and passes this information to the Network Policy Server. Policies on the NPS then determine whether noncompliant computers will be remediated and, additionally, whether they will have restricted network access until they are compliant.

Remediation is the mechanism of making a noncompliant computer compliant to ensure that clients conform to compliance policies. Configuration Manager remediation uses the software update packages you have already created, with the Software Updates feature. See Chapter 15, “Patch Management,” for further discussion.

Reporting in ConfigMgr is functionally very similar to that in SMS 2003. Dozens of reports, utilizing Transact-SQL (T-SQL), expose detailed hardware and software inventory data about the clients in the hierarchy. ConfigMgr 2007 adds a number of troubleshooting reports.

You can launch reports directly through the ConfigMgr console or through the reporting point site system website, and you can easily create custom reports utilizing the existing SQL views exposing the ConfigMgr site’s data. Chapter 18, “Reporting,” discusses ConfigMgr reporting.

Figure 2.9 illustrates ConfigMgr reports; this particular report lists all software companies collected during software inventory. With Configuration Manager 2007 R2, you can choose to use Microsoft SQL Reporting Services for reporting.

Figure 2.9. Configuration Manager 2007 Report example

Reports only query data from the local site server, some of which will be from child sites in the hierarchy if they exist. Because inventory and other types of data flow up the hierarchy, child sites data will show up in ConfigMgr reports run on a parent site. ConfigMgr groups reports into categories to facilitate organization, and reports may link to one another to provide an experience similar to drill-down reporting. You can configure reports to prompt the user for data, to provide lists of available options for prompts, or to be fully automated.

Security in ConfigMgr is based completely on WMI, Microsoft’s implementation of Web-Based Enterprise Management. WBEM allows access to providers such as Win32, WMI, SNMP, and Desktop Management Interface (DMI). In addition to collecting data, WBEM provides a method to secure the data by utilizing a class and instance model. As an example, the Packages node is a class containing a package for Microsoft Office, which would be an instance within the Packages class.

As shown in Figure 2.10, you need to permit granular rights specific to the class to individuals or groups, and then to specific instances of that class. Although a ConfigMgr administrator may have administrative rights on the ConfigMgr server and the SQL database for ConfigMgr, if not granted class and instance rights through the ConfigMgr console, the administrator cannot access any of the ConfigMgr objects within the ConfigMgr console.

Figure 2.10. Granting security rights in Configuration Manager 2007

By default, only the account used to install ConfigMgr has rights to all ConfigMgr classes and instances. As a best practice, the account used to install ConfigMgr should be a service or application account.

Those topics are covered in Chapter 20, “Security and Delegation in Configuration Manager 2007.”

The most successful implementations of SMS, or any other software distribution tool, historically have been in standardized environments. Standardizing operating systems, patch levels, application loads, hardware, and overall configuration allows administrators to test their deployments before rolling them out to the enterprise. Hardware-independent imaging, only recently a reality, allows administrators to build a single image and inject drivers on the fly during the deployment process. This process allows you to use one image for any number of hardware manufacturers and models, creating the most standardized OS deployment process available today.

Inventory allows administrators to logically group systems by any combination of hardware and software. This inventory data is useful in defining deviations from the standards created by an organization. Inventory data allows organizations to see the software installed on client systems, and software metering allows organizations to see the software executed on client systems. Analyzing these two sets of data helps organizations make educated decisions regarding software deployments and licensing.

Operating system deployments and migrations allow organizations to standardize their environment, thus controlling installations and configurations at the operating system and application level. Historically, operating system deployments have been a manual and time-consuming process, making it extremely difficult for large organizations to standardize their environment. Now operating system deployments are easier than ever, allowing levels of standardization that previously were out of reach due to technology, resources, and expense.

Information Technology has increasingly become a top expense in today’s organizations. The ability to resolve issues quickly after they are identified requires tools that the first tier of support (usually referred to as Tier1) can use to perform tasks as though they were at the end user’s system. These tools are critical to managing and lowering TCO of IT assets.

Tools such as Remote Control, Remote Desktop, and Remote Assistance give administrators the ability to run commands, see the hardware and software installed, and above all see the user interface the user is seeing. This type of remote control support has become an industry standard for remote user support. Branch offices and micro-branch offices, which have fewer than 10 users, have become increasingly common as corporations change and grow to stay competitive. These business models further complicate the remote management issue, making site visits not an option and remote tools critical to the support of the environment.

Deploying software is one of the most primary functions of any Information Technology group. Getting users the applications, updates, security patches, and other changes required to keep an environment running is critical to a business’s success. For any company to stay agile in today’s market, IT must be able to adapt and meet the business’s needs in a timely, efficient, and inexpensive manner. Being able to deploy software to systems, regardless of location and user’s knowledge or rights of a system, is critical.

There are two primary methods to get a software update to a system—push and pull. Each of these methods ultimately gives the targeted systems the software desired for roll out, but there are many differences between the two and neither is necessarily right all the time.

Pulling Software

“Pulling” implies that the owner or recipient of the package must initiate some action. This allows the recipient to initiate the change when it is convenient, thus minimizing the impact on productivity. Allowing a user to pull down an application and install it at his or her leisure is also useful for rolling out software with user-specific settings the recipient needs to specify during installation. Even on locked-down systems where users have no rights, the end user can initiate and execute software installations as long as they were set up and approved by the IT administrative staff. Figure 2.11 illustrates the end-user notification that a program is available for installation.

Figure 2.11. Configuration Manager advertised program notification

The problem with a software change sent out in a “pull” fashion is that without that user initiation, the change never occurs. You can see how this will be a problem where there are changes that must take place on systems due to company policy. This could also be something a user may not want to do, such as removing a personal application from a company asset. This type of application distribution typically takes place when the users are very self-sufficient and avoiding negative impact to the end user is important.

Networks are critical to the daily functions of corporations today. Due to the heavy demand placed on networks, ConfigMgr utilizes several concepts and technologies to minimize the impact it places on the network infrastructure. Many of these technologies can be configured centrally, allowing other administrators to leverage the ConfigMgr architecture without needing deep knowledge of the enterprise’s network infrastructure. Technologies such as BITS, distribution points, branch distribution points, download and execute, senders, and compressed XML are just a few of the technologies available.

• BITS— BITS monitors traffic in and out of the local network interfaces and throttles itself throughout a download, utilizing only the available idle bandwidth. This minimizes impact to the user experience with other network-aware applications, such as Microsoft Outlook or Internet Explorer.

As users’ demand increases for more data from their applications across the network, BITS throttles itself down; as the demand drops, BITS throttles itself up to use as much bandwidth as available. Using BITS also allows an interrupted download to resume where it previously left off. BITS is covered in Chapter 5.

• Distribution Points— The “Distribution Points” section of this chapter previously touched on the DPs concept. It is important to understand that you can place distribution points anywhere, and it is not unusual to have multiple DPs on a single subnet! This is a common architectural design if there is a high demand to run packages from the distribution point or a large number of clients. A common design is to implement multiple DPs in a single location when there are concerns about router contention or high switch traffic.

• Branch Distribution Points— Branch distribution points, introduced in the “Site Systems” section, gives ConfigMgr the ability to push a package across a WAN link to a location with a very small number of clients and only traverse the WAN link one time with the package. SMS 1.x through 2003 pushed a separate package over the WAN link for every client in the remote location. Although third-party software existed to address this SMS architectural deficiency, it was costly and not well known. Now with support available for a client workstation to be a distribution point, the branch office or microbranch office model can easily be targeted and have packages pushed to it.

Whereas ordinary distribution points have packages published (also referred to as copied or pushed) to them by the ConfigMgr administrator, branch distribution points receive their package copy by updating their policy and then downloading the package source using BITS. This pull process is the opposite of how packages are ordinarily published to conventional distribution points.

• Download and Execute— Download and Execute is a feature introduced in SMS 2003; it leverages the BITS technology to cache a copy of the package from the DP. Many people ask, “Why would I want to cache a copy of a package if I have a local DP?”

The reason is quite simple: When packages are assigned, they are mandatory and will launch at the time stated in the advertisement. Because Kerberos tickets are time sensitive, clocks on computer systems today all synchronize with the clock on the PDC Emulator DC. This means that all clients with a mandatory advertisement will start it at exactly the same time, thus placing a heavy load on the local distribution point. The Download and Execute capability gives administrators the ability for clients to cache a copy of the package and upon execution, perform the installation from their local hard drive. BITS allows administrators to configure many things about its behavior, including how long to hold the copy of the package in its cache.

• Senders— Senders allow the throttling and prioritization of traffic by time between ConfigMgr sites. Administrators often overlook configuring senders, leaving the default of allowing all traffic at all times of the day. Without configuring senders, there is no throttling, and the network infrastructure may be utilized by traffic that could have waited until nonpeak hours of the day. Whenever parent/child relationships exist, you should experiment with senders to determine what is right for the environment in regard to time of day and workload.

• Inventory— Even at the inventory level, there are changes allowing a more efficient use of the technology now available. Hardware and software inventories are generated by their respective agents, with the output created in XML. This XML file is then compressed and sent up to the MP immediately. If the MP is not available, the client caches the inventory until the next time it is available or until the next inventory schedule, where it is rerun.

• Testing— With all this technology available to tread the network lightly, it is important to experiment with these settings in a lab environment. It is not uncommon for administrators to make mistakes that will saturate WAN links due to the nature of the product. Test whenever the ability exists to affect a network in a negative way, confirming in advance that the experience will be a positive one. Experimenting with different site configurations, package pushes, and client package execution can determine the overall load on the site, network, and distribution points.

Creating a lab for ConfigMgr is not only necessary for validating the site hierarchy and load testing, but it can also be used for package, security, patch, and upgrade testing. Figure 2.12 illustrates the lab environment used for the writing of this book. The lab incorporates a central site server (Bluebonnet) and four primary child site servers:

Figure 2.12. Configuration Manager 2007 lab example

• Wildflower—DAL site

• Mockingbird—HOU site

• Roadrunner—BEJ site

• Tumbleweed—BXL site

Mockingbird and Roadrunner are installed as SMS 2003 site servers; the HOU site, Mockingbird, is upgraded to ConfigMgr 2007 during the upgrade process in Chapter 9, “Migrating to Configuration Manager 2007.”

Branch distribution points were introduced earlier in the “Site Systems” section. They have the following characteristics:

Figure 2.13 shows the General Properties page for a DP; there is a radial button midway down the page to enable the DP as a branch distribution point.

Figure 2.13. Configuring a branch distribution point

The SUP installs as a site system role in the Configuration Manager console. Each site must have an active SUP before you can enable software updates. You can install a second SUP for communications from Internet-based client computers. You must create the software update point site system role on a server that has Windows Server Update Services (WSUS) 3.0 already installed and configured.

The software update point provides communication with WSUS and synchronizes with the WSUS database to retrieve the latest software update metadata from Microsoft Update, as well as locally published software updates. Once this is configured via the Configuration Manager console, the administrator does not need to perform any patch management in the WSUS console. Instead, all patch management configuration and administration occurs in the ConfigMgr console. Figure 2.14 shows the integration between Configuration Manager and WSUS.

Figure 2.14. Software Update Compliance Status Summary

The primary purpose of the fallback status point is to resolve client health issues. Client health describes the overall percentage of clients regularly checking into their designated management points, downloading policy, uploading inventory, and executing specified actions such as running an advertisement to install a package such as Microsoft Office.

The FSP in Configuration Manager 2007 always communicates with clients using HTTP, which uses unauthenticated connections and sends data in clear text, even when the site is in native mode. This makes the fallback status point vulnerable to attack, particularly when used with IBCM. To help reduce the attack surface, always dedicate a server to running the FSP and do not install other site system roles on that server in a production environment.

Install an FSP in the site if all the following scenarios exist:

PXE is a technology allowing individuals to boot a computer from the network instead of a local disk. You can use this capability in situations where the disk needs to be written to in a way where no files can be in use, such as deploying an operating system.

The PXE service point must be configured to respond to PXE boot requests by Configuration Manager 2007 clients so that those clients can interact with the ConfigMgr infrastructure to determine the appropriate installation actions to take.

Other site systems new to ConfigMgr 2007 include the state migration point and branch distribution point, both introduced in the “Site Systems” section of this chapter.

OSD in ConfigMgr is very different from the OSD Feature Pack on SMS 2003. ConfigMgr 2007 exposes a brand-new task sequencer, which sometimes is thought to be from BDD 2007 because it was available in the Business Desktop Deployment (BDD) Solution Accelerator released slightly earlier. The task sequencer from ConfigMgr was actually integrated into the BDD Solution Accelerator and Microsoft Deployment Toolkit (MDT). This integration allows for interoperability between OS deployments made in BDD/MDT and ConfigMgr. See Chapter 19, “Operating System Deployment,” for a discussion of OSD.

ConfigMgr also now provides the ability to build a complete reference PC, Sysprep, and image it all using a single unattended task sequence. This new capability provides administrators a mechanism to ensure the build process across all systems, regardless of platform or image, is consistent.

First introduced in SMS 2003 SP 3, Microsoft enhanced Asset Intelligence significantly in Configuration Manager 2007. The Asset Intelligence reports include nine new License Management reports, three new Hardware reports, and six new Software reports.

Besides tracking installed software, auto-start software, and browser helper objects, new Software reports provide information about recently used executables. In addition to the Hardware reports that track USB devices, processor age, and readiness for upgrade, these new reports identify computers that have software or hardware changes since the last inventory cycle. New Client Access License reports, added to the existing License Ledger reports, complete the ability to compare license usage with Microsoft License Statements. Figure 2.15 lists some of the Asset Intelligence reports included with ConfigMgr 2007. Asset Intelligence is discussed further in Chapter 18.

Figure 2.15. Configuration Manager 2007 Asset Intelligence reports

Mobile device management has changed substantially since SMS 2003. ConfigMgr device management enables discovering, inventorying, and reporting on the following mobile device categories:

ConfigMgr 2007 also adds support for the following mobile devices:

The R2 release adds support for Windows Mobile 6.1.

SMS 2003 required connecting mobile devices to a host device running the SMS 2003 client. In ConfigMgr, mobile devices can be managed over Ethernet, wireless, or via IBCM. You can manage mobile devices when they have a standard Internet connection.

IBCM allows you to manage ConfigMgr clients that are outside your network firewall. This configuration has a number of advantages, including the reduced costs of not having to run virtual private networks (VPNs) and being able to deploy software updates in a timelier manner.

Because of the higher security requirements of managing client computers on a public network, IBCM requires the site to be in native mode. Native mode ensures an independent authority mutually authenticates connections to the management point, software update point, and distribution points, and that data to and from these site systems is encrypted using Secure Sockets Layer (SSL). IBCM in essence allows ConfigMgr administrators to manage their client systems wherever they are (home, hotel, and so on) without them having to VPN in. See Chapter 6 for a discussion of IBCM.

Desired Configuration Management and Network Access Protection, both new in Configuration Manager 2007, were discussed previously in the “Desired Configuration Management” and “Network Access Protection” sections, respectively.

ConfigMgr 2007 requires a minimum of SQL Server 2005 with Service Pack 2 for the site database. Microsoft also supports using SQL Server 2005 SP 3 and SQL Server 2008.

The following caveats apply to using SQL Server 2008 with Configuration Manager 2007:

TCP/IP is the only protocol now used for SQL Server to communicate with ConfigMgr; there is no longer a reliance on Named Pipes. The default port SQL uses is 1433, which you can change using the SQL Server Configuration Manager utility. Ports are discussed further in Chapter 5.

In most cases, Microsoft recommends having SQL Server and ConfigMgr on the same server when you install a primary site. Alternatively, Microsoft now recommends that if you are going to use a remote SQL Server, to install an additional network card in both the SQL Server and the ConfigMgr server and dedicate each card to communicate with one another, similar to a heartbeat network on a cluster.

SQL Server has supported using instances (which are multiple installations of SQL in parallel on the same server) since SQL Server 2000. Microsoft now supports the installation of the ConfigMgr 2007 database on a SQL named instance.

ConfigMgr also supports SQL replications, where you can point the MP or SLP roles at a SQL replica to improve performance in low-bandwidth scenarios. This is discussed further in Chapter 8, “Installing Configuration Manager 2007.”

Microsoft does not support the Configuration Manager client on any operating system prior to Windows 2000 Service Pack 4. Installing the Configuration Manager client explicitly is not supported on the following operating system versions: