System Center Configuration Manager 2007 : The History of Configuration Manager

Figure 1. SMS and Configuration Manager versions from 1994 through 2008

The Earliest Versions

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.

Systems Management Server 1.2

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:

• The software was cumbersome to use, with SMS site servers requiring installation on a Windows NT 4.0 backup domain controller (BDC).

• SMS 1.2 could only manage the domain it resided in.

• The end-user experience was very poor; you can still hear people joke today about the extremely long logon times in SMS 1.2. These long logins were due to the product inventorying the client systems during their network login, using a login script.

• SMS 1.2 was Microsoft’s management software during the latter part of the 1990s, but the console only ran on a Windows NT 4.0 workstation. This was at a time when NT 4.0 was competing with Windows 95 and 98, two systems that were able to run on laptop computers much more efficiently. The console platform limitations further limited the adoption of SMS 1.2.

Systems Management Server 2.0

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:

• Logon experience— Eliminating the use of login scripts (although smsls.bat was still used with logon points).

• Software discovery— Removing the requirement to specify the software files to inventory (a poor way to determine what exists because you obviously don’t know the information to begin with).

• Site server placement— Eliminating the requirement for the site server to reside on a BDC or domain controller (DC).

• Subnet targeting— Targeting a group of subnets as its management scope. Targeting subnets made the tool much more flexible and allowed managing multiple domains from a single SMS site.

The following sections discuss additional enhancements.

Inventory

SMS 2.0 introduced separate Hardware and Software Inventory Agent components. The agents were configurable independently of one another and able to run on completely different schedules. Most noticeably for the end-user experience, inventories did not run at login time. These changes allowed administrators to become aggressive and run inventories based on business requirements, without affecting end users’ systems.

Microsoft listened to the SMS community’s feedback and coded the Hardware Inventory Agent to run 15 minutes after the SMSExec service started if inventory was scheduled. The Software Inventory Agent was coded to behave similarly, 30 minutes after the service started.

Software Metering and License Enforcement

SMS 2.0 introduced software metering and license enforcement. Although the initial implementation was not as successful as Microsoft hoped, SMS 2.0’s software metering served as a learning opportunity for what corporations considered acceptable regarding license management. The SMS 2.0 version allowed administrators to track applications, ensure license compliance, and monitor software usage throughout their organization.

The component required its own database, did not support mobile computing, and was generally intrusive on the user experience. The issues associated with metering, which grew exponentially as laptops became increasingly prevalent in the workplace, ultimately shut down most deployments.

Software Updates and Patches

SMS 2.0 released in early 1999, just prior to Y2K (Year 2000). One of the product’s biggest draws—a feature used by SMS administrators worldwide—was its ability to implement Y2K patches. Y2K patching was a huge milestone for SMS and led to a large adoption rate for version 2.0. The flip side of this was that the quick adoption rate created a situation where many bugs were uncovered, some quite serious, almost immediately.

Data Discovery Record Processing

The most noteworthy feature in Service Pack 5, released in 2003, was its vast improvement in data discovery record (DDR) processing. SMS uses DDRs to report discovery information to the site database. Prior to SP 5, a DDR took approximately 1 second to process. (Because SP 5 was only a service pack, Microsoft did not update official numbers about the improved scalability.)

Total Rewrite

The SMS product team and veteran SMS administrators still remember the hectic early days of SMS 2.0. SMS 2.0 was a complete rewrite from the ground up and had numerous bugs. There is still debate today over whether SMS 2.0 became a truly stable platform with Service Pack 2 (released June 2000) or until SP 3 (released in August 2001). Service Pack 4 for SMS 2.0 became available in August 2002, and Microsoft released SP 5 in April 2003.

However, one of SMS 2.0’s largest failings was that none of its service packs included integration with Active Directory (AD), which released with Windows 2000 just a year after the base release of SMS 2.0.

SMS 2003

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:

• The two major changes were Active Directory Integration and the Advanced Client.

• The minor, not-so-well-recognized changes included the following:

  • Implementing software metering in a passive, silent fashion

  • Adding a built-in reporting system

  • Leveraging Background Intelligent Transfer Service (BITS) to handle bandwidth throttling

    Incorporating BITS helped minimize the impact of software updates and downloads on the user experience.

Active Directory Integration

SMS 2003 had the capability to extend and store key configuration data about its hierarchy in AD, using a small handful of schema extensions that were an optional part of the installation. This led to a number of benefits:

• Site boundaries— Using Active Directory let SMS administrators use AD sites rather than specify subnets for site boundaries.

  Using Active Directory sites as site boundaries added flexibility to SMS and saved hours of painstaking and tedious work. Incorporating AD sites also let SMS 2003 implementations easily adapt to network changes, because SMS could automatically detect changes when network administrators changed subnets at various locations and in Active Directory.

• Schema extensions— SMS schema extensions are a series of classes and attributes stored within AD and replicated among global catalog servers. Schema extensions facilitate client installation, site assignment, and global roaming.

• Advanced security— Advanced security allowed administrators to use machine accounts in AD to grant permissions across the organization.

  Using machine accounts eliminated a plethora of problems, including account lockout issues, password resets, site resets, and broken clients due to corporate password change policies. (Security problems were such an issue in SMS 2.0 that Microsoft’s only workaround for account-related issues was recommending SMS administrators place sites in resource domains with looser security!)

  With advanced security, only one service account was necessary to push clients from the server, allowing a cleaner security implementation.

• Discovery process— AD Integration allowed SMS administrators to be selective about the objects they discovered. Administrators could target any Organizational Unit (OU) or Lightweight Directory Access Protocol (LDAP) path possible for any system, user, or group discovery process. This eliminated maintaining unneeded objects in the site, database, or collections because of product limitations.

• Distribution points— Distribution points (DPs) were also able to leverage AD, by using AD sites defined as their boundaries.

  SMS administrators could define who could and could not connect to a DP by specifying permitted AD sites. This stopped clients from pulling content from a remote DP, improved the overall end-user experience with fast package installation times, and minimized the risk of saturating wide area network (WAN) links due to a package installation occurring across a slow link.

• Roaming boundaries— Roaming boundaries were a new concept in SMS 2003 and took advantage of AD integration as well.

  Roaming boundaries allowed clients to move from one Internet Protocol (IP) network to another without uninstalling the client, a major drawback with SMS 2.0. Roaming always involves an IP network change for the client, either between offices or from an office to the user’s home network. SMS 2.0 uninstalled the client and then reinstalled it when the computer returned to the corporate network, initiating new full hardware and software inventories and potentially package installations, depending on their configuration. Although there were some workarounds for this behavior in version 2.0, they did not really address the roaming issue as well as the Advanced Client did in SMS 2003.

Advanced Client

The single biggest improvement in SMS 2003 was undoubtedly the Advanced Client, referred to as the Mobile Client during the beta test cycle. The Advanced Client had a completely new architecture, which included the following features:

• Sending inventories using a compressed eXtensible Markup Language (XML) format.

• Not automatically uninstalling clients.

• Easily building clients into an image, without concern of duplicating the client Globally Unique Identifier (GUID).

• AD site-aware clients.

• Clients checking into AD themselves and storing their history in Windows Management Instrumentation (WMI), not in the file system like the 2.0 client. Therefore, uninstalling and reinstalling a client did not mean the user got all the applications he or she previously received, again.

The Advanced Client used BITS and downloaded packages from DPs using the Hypertext Transfer Protocol (HTTP). Using BITS allowed a download to pick up where it left off if the connection was broken during the download (also known as checkpoint restarting). BITS increased package deployment success rates and minimized deployment times for the following reasons:

• Clients now could download the package to their local cache in the background, during daily activity.

• At execution time, the clients could be configured to run the package from a local disk, thus reducing server disk contention on DPs and allowing clients to run packages when not connected to the infrastructure.

If an Advanced Client traversed the WAN, it would still only receive policy from its own site, thus addressing another issue SMS 2.0 was plagued with—the traveling corporate user. No longer would these users automatically be reassigned to a site because they spent time working there.

SMS 2003 also included a Legacy Client, which was purely for backward compatibility to support Microsoft operating systems unable to run the Advanced Client. These systems included Windows 95 and 98, Windows NT 4.0 SP 6a, and Windows 2000 systems prior to SP 4.

SMS 2003 Service Packs and R2

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

• SP 1 limited legacy support to Windows 98 and Windows NT 4.0 SP 6a only—support was removed for Windows 95, Windows NT 4.0 SP5, and earlier versions. Optionally, administrators could publish a child site server in the hierarchy running an older version of SMS to support these clients if necessary.

• The service pack dropped the requirement for the Windows Internet Naming Service (WINS) if the AD schema was extended and DNS was configured to enable SMS clients and servers to resolve each other’s NetBIOS names.

• The service pack provided SMS administrators the ability to categorize and organize objects in the SMS Administrator console using folders, a new feature with SP 1.

• SP 1 provided SMS support for managing systems that were members of a workgroup.

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.

Configuration Manager 2007

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. ConfigMgr also supports an implementation model known as Internet-Based Client Management (IBCM). IBCM allows managing clients across numerous firewalls, including unmanaged ones.

Table 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:

• Application virtualization

• Client status reporting

• Multicast delivery of images

• Forefront client monitoring using a new Desired Configuration Management (DCM) configuration pack

• OSD unknown computer support

• Run As capability in the run command-line option of the Task Sequence Wizard

• The ability to convert from the traditional ConfigMgr reporting environment to using SQL Reporting Services for reports

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.