- How to make new stuff from your piles of obsolete tech
- Why your computer sucks
- 10 recession-proof IT skills
- Juniper execs share network vision
- 9-year-old plots his fifth Microsoft certification
In This Chapter
Design Concepts
Active Directory Integration
Configuration Manager and WMI
Components and Communications
Inside the ConfigMgr Database
Status Messages and Logs
Microsoft’s System Center Configuration Manager (ConfigMgr) 2007 delivers a variety of configuration management and system support services via a flexible and distributed architecture. ConfigMgr 2007 takes advantage of standards-based network protocols and security for its internal working and interaction with client systems. Configuration Manager components store and use data about ConfigMgr infrastructure and activity, the environment, and managed site systems in the site database. Microsoft provides an extensive set of queries and reports based on this data, as well as facilities for extracting data for your own queries and reports.
This chapter examines the inner workings of Configuration Manager. It describes the design concepts and working principles of ConfigMgr 2007, along with the ways that ConfigMgr utilizes core Windows technologies, specifically Active Directory (AD) and Windows Management Instrumentation (WMI). It also discusses the various components of Configuration Manager, how they communicate with each other, and how they work together to implement ConfigMgr features. The chapter looks inside the site database, which is the heart of Configuration Manager. It shows how you can view the inner workings of ConfigMgr through its status messages and logs, as well as through other tools for viewing database and process activity. The emphasis of this chapter is on depth rather than breadth. The authors have chosen some of the most important feature sets and data structures to use as examples throughout the chapter, rather than try to provide a comprehensive exposition of all ConfigMgr functionality.
For those readers who are simply looking to get Configuration Manager up and running, some of the material in this chapter may not be essential. These readers may still find a quick review of the “Schema Extensions” section helpful for planning purposes. They may also find some of the methods used in the “Status Messages and Logs” section useful for troubleshooting purposes. The “Managing WMI” section provides some additional guidance on troubleshooting WMI issues. For those who desire a deeper understanding of what is going on behind the scenes with ConfigMgr, the material in this chapter will help you grasp the architectural principles of the product and guide you into exploring the inner workings of Configuration Manager.
Microsoft designed Configuration Manager 2007 to deliver enhanced management services to a wide variety of Windows-based systems. Its predecessor, Systems Management Server (SMS), eases managing desktop and laptop computers in an enterprise network environment. (For information regarding the different versions of SMS, see Chapter 2, “Configuration Manager 2007 Overview.”) Configuration Manager builds on the core functionality of SMS and adds an enhanced feature set that includes advanced operating system (OS) deployment capabilities and asset management features as well as support for new Out of Band (OOB) Management technologies. ConfigMgr also extends management capabilities to managed computers accessible through the Internet.
In this latest release of its systems management software, Microsoft emphasizes security and compliance, scalability and operational simplicity. To help customers meet security and compliance goals, Configuration Manager 2007 implements the following features:
Patch Management—One of the most important features of ConfigMgr 2007’s SMS 2003 predecessor was its capabilities for deploying patches to Windows clients and reporting on system patch compliance status. Configuration Manager improves and extends this capability by integrating with Microsoft’s Windows Software Update Service (WSUS) and implementing Network Access Protection (NAP) to prevent noncompliant systems from joining the network. Chapter 15, “Patch Management,” discusses patch deployment and NAP.
Configuration Management—ConfigMgr’s Desired Configuration Management (DCM) allows you to ensure compliance with defined standards to prevent misconfigurations and reduce the attack surface of your systems. You will find a discussion of DCM in Chapter 16, “Desired Configuration Management.”
Active Directory Integration—Configuration Manager 2007’s integration with Active Directory provides authentication and access control. The “Active Directory Integration” section of this chapter discusses these features.
Security—Configuration Manager uses certificate-based authentication, encryption, and data integrity controls to secure communications between the site systems and clients. Configuration Manager provides a new security mode, called native mode, which is required for some but not all certificate-based functionality. Chapter 6, “Architecture Design Planning,” discusses certificates and native mode.
Microsoft has also made ConfigMgr 2007 more scalable. Some scalability enhancements include the following:
Distributed processing—SMS 2003 includes the ability to distribute functional roles to other systems in the environment. ConfigMgr 2007 introduces additional roles that can be distributed, helping to balance the processing load required by any single server.
Scale out—Network Load Balancing (NLB) clusters enable scaling out certain roles.
Flexible hierarchy—ConfigMgr’s flexible hierarchy model enables deploying its services to remote locations with limited network connectivity. This includes the branch distribution point capability, new with Configuration Manager 2007.
Manageability—Configuration Manager uses Internet-standard protocols to extend management capabilities to Windows mobile devices and managed systems accessible through the Internet.
Chapter 6 includes a discussion on configuring site system roles, hierarchy design, and management of mobile devices and Internet clients.
Configuration Manager’s capabilities can help simplify your operations in the following areas:
Planning—Inventory and discovery data provide a central information store you can use in intelligently planning your operations. The “Inside the ConfigMgr Database” section of this chapter introduces the database and some of its potential uses.
Deployment—Features for capturing, managing, and distributing system images and migrating user state information make it easier to provision new systems and upgrade existing ones. Chapter 19, “Operating System Deployment,” presents ConfigMgr’s Operating System Deployment (OSD) capabilities.
Enhancing—Configuration Manager provides capabilities to easily deploy and maintain software applications on large numbers of client systems. Chapter 14, “Distributing Packages,” discusses ConfigMgr software distribution in detail.
Life cycle management—ConfigMgr 2007’s improved Asset Intelligence capabilities help you track and manage hardware and software assets throughout their life cycle. Chapter 18, “Reporting,” discusses the use of Asset Intelligence.
To implement these capabilities, Configuration Manager leverages key elements of the Windows platform. The two most important Windows components are AD and WMI. The next sections look in depth at how ConfigMgr uses these technologies.
Active Directory is the central information store that Windows Server uses to maintain entity and relationship data for a wide variety of objects in a networked environment. AD provides a set of core services, including authentication, authorization, and directory services. Configuration Manager requires an Active Directory environment and takes advantage of AD to support many of its features. For more information about Active Directory in Windows Server 2003 and Windows Server 2008, see the following references:
http://www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/default.mspx for information regarding Windows Server 2003 and Active Directory
http://www.microsoft.com/windowsserver2008/en/us/active-directory.aspx for details on Active Directory in Windows Server 2008
In an Active Directory environment, all processes run in the security context of a user or a security context supplied by the operating system. System accounts are special accounts included on each Windows system used to run processes in a context supplied by the operating system. Prior to AD, the only built-in system account context was the Local System account. The Windows NT Local System account provided unlimited access to system resources, but you could not use it for network requests.
Using Active Directory, each system has a computer account that you can add to user groups and grant access to resources anywhere on the network. Windows Server 2003 and later operating systems add two other built-in accounts with limited access:
The Local Service account has essentially the same rights on the local system as a nonprivileged user and no access to the network.
The Network Service account has rights and network access similar to a nonprivileged user account.
ConfigMgr 2007 makes extensive use of system and computer accounts to run processes. Using system accounts greatly simplifies administration, eliminating the need to create and manage the large number of service accounts required using early versions of SMS.
In addition to authentication and access control services, Configuration Manager 2007 can use AD to publish information about its sites and services, making ConfigMgr easily accessible to Active Directory clients. To take advantage of this capability, you must extend the AD schema to create classes of objects specific to Configuration Manager. Although extending the schema is not required for ConfigMgr to work, it is required for certain Configuration Manager features. Extending the schema also greatly simplifies ConfigMgr deployment and operations. The “Schema Extensions” section of this chapter discusses extending the AD schema, and the “Benefits of Extending Active Directory” section covers the feature dependencies and administrative advantages provided by the schema extensions.
Configuration Manager can also take advantage of Active Directory in the following ways:
Discovering information about your environment, including the existence of potential client systems. Chapter 12, “Client Management,” discusses the discovery process.
Assigning and installing clients through group policy, also described in Chapter 12. In addition, you can use group policy to configure basic services used by ConfigMgr.
Using certificates and certificate settings deployed through AD to enhance its own security, as discussed in Chapter 6.
All objects in Active Directory are instances of classes defined in the AD schema. The schema provides definitions for common objects such as users, computers, and printers. Each object class has a set of attributes that describes members of the class. As an example, an object of the computer class has a name, operating system, and so forth. Additional information about the AD schema is available at http://msdn.microsoft.com/en-us/library/ms675085(VS.85).aspx.
The schema is extensible, allowing administrators and applications to define new object classes and modify existing classes. Using the schema extensions provided with Configuration Manager eases administering your ConfigMgr environment. The ConfigMgr schema extensions are relatively low risk and involve only a specific set of classes not likely to cause conflicts. Extending the schema is a recommended best practice for Configuration Manager because it allows you to avoid additional configuration tasks and implement stronger security. Nevertheless, you will want to test any schema modifications before applying them to your production environment.
You can extend the schema in either of two ways:
Running the ExtADSch.exe utility from the ConfigMgr installation media
Using the LDIFDE (Lightweight Data Interchange Format Data Exchange) utility to import the ConfigMgr_ad_schema.ldf LDIF file
If you are extending the schema on a Windows 2000 domain controller, you must use the LDIF file.
Using ExtADSch.exe is the simplest way to extend the schema, and in SMS 2003, it was the only way to extend the schema. ExtADSch.exe creates the log file extadsch.log, located in the root of the system drive (%systemdrive%), which lists all schema modifications it has made and the status of the operation. After the list of attributes and classes that have been created, the log should contain the entry “Successfully extended the Active Directory schema.”
LDIFDE is a powerful command-line utility for extracting and updating directory service data on Active Directory servers, beginning with Windows 2000. LDIFDE provides command-line switches, allowing you to specify a number of options, including some you may want to use when updating the schema for ConfigMgr. Table 3.1 includes the options that you are most likely to use.
|
Switch |
Description |
|
-i |
Turns on Import Mode. (Required for updating the schema.) |
| -f |
Filename. (Used to specify the location of the ConfigMgr_ad_schema.ldf file.) |
| -j |
Log file location. |
| -v |
Turns on Verbose Mode. |
| -k |
Ignore Constraint Violation and Object Already Exists errors. (Use with caution. May be useful if the schema is previously extended for SMS.) |
The options vary slightly, depending on the Windows Server version you are running. You can see a complete listing of LDIFDE syntax by entering the following command:
ldifde /?
You can also find detailed information about using LDIFDE at http://technet2.microsoft.com/windowsserver2008/en/library/8fe5b815-f89d-48c0-8b2c-a9cd1d6986521033.mspx?mfr=true. A typical command to update the schema for ConfigMgr would be something like this:
ldifde –i –f ConfigMgr_ad_schema.ldf –v –j SchemaUpdate.log
The verbose logging available with LDIFDE includes more detail than the log file generated by ExtADSch.exe. The ConfigMgr_ad_schema.ldf file allows you to review all the intended changes before they are applied. You can also modify the LDF file to customize the schema extensions. As an example, you can remove the sections for creating classes and attributes that already exist as an alternative to using the –k switch referred to in Table 3.1.
Be Careful when Editing the LDF File - Do not attempt to edit the LDF file unless you have a thorough understanding of LDF, and remember to test all modifications before applying them to your production environment.
Each AD forest has a single domain controller that has the role of schema master. All schema modifications are made on the schema master. To modify the schema, you must log on using an account in the forest root domain that is a member of the Schema Admins group.
About the Schema Admins Group - The built-in Schema Admins group exists in the root domain of your forest. Normally there should not be any user accounts in the Schema Admins group. You should only add accounts to the Schema Admins temporarily when you need to modify the schema. Exercising this level of caution will protect the schema from any accidental modifications.
The ConfigMgr 2007 schema modifications create four new classes and 14 new attributes used with these classes. The classes created represent the following:
Management points—Clients can use this information to find a management point.
Roaming boundary ranges—Clients can use this information to locate ConfigMgr services when they connect to the network at a location not within the boundaries of their assigned site.
Server locator points (SLPs)—Clients can use this information to find an SLP.
ConfigMgr sites—Clients can retrieve important information about the site from this AD object.
Real World: Tips and Techniques about Changing the Schema - You will want to exercise caution when planning any changes to the AD schema, particularly when making modifications to existing classes, because this may affect your environment.
When you modify the schema, you should take the schema master offline temporarily while you apply the changes. Regardless of the method you use to extend the schema, you should review the logs to verify that the schema extensions were successful before bringing the schema master back online. This way, if there is a problem with the schema modifications, you can seize the schema master role on another domain controller and retain your original schema!
Before actually extending the schema for ConfigMgr 2007, run the dcdiag and netdiag command-line tools, part of the Windows Support Tools. These tools validate that all domain controllers (DCs) are replicating and healthy. Because it may be difficult to validate the output of these tools, you can output the results to a text file using the following syntax:
dcdiag >c:\dcdiag.txtSearch the output text file for failures and see if any domain controllers are having problems replicating. If any failures are present, do not update the schema. Upgrading the schema when domain controllers are not healthy or replicating correctly will cause them to be orphaned as AD is revved to a higher version. The machine will then need to be manually and painfully cleaned out of AD.
Chapter 6 describes the Management Point and Server Locator Point server roles.
Schema Extensions and ConfigMgr 2007 Updates - There are no changes to the schema extensions from the RTM (Release to Manufacturing, or initial release) version of Configuration Manager 2007 in either Service Pack (SP) 1 or Release 2 (R2) (it is unknown at the time of writing this chapter whether SP 2 will incorporate schema changes). The ConfigMgr schema extensions include previous changes from the SMS 2003 version of the schema extensions.
Although you can deploy ConfigMgr with only the SMS 2003 schema extensions applied to AD, you will not have all the functionality provided by the ConfigMgr schema extensions. Configuration Manager features not supported by the SMS 2003 Schema extensions include Network Access Protection and native mode security. The “Benefits of Extending Active Directory” section of this chapter discusses these features.
If you are curious about the details of the new classes, you can use the Schema Management Microsoft Management Console (MMC) snap-in to view their full schema definitions. Before adding the snap-in to the management console, you must install it by running the following command from the command prompt:
regsvr32 schmmgmt.dll
After installing the snap-in, perform the following steps to add Schema Management to the MMC:
Select Start, choose Run, and then enter MMC.
Choose Add/Remove snap-in from the File menu of the Microsoft Management Console.
Click the Add button and then choose Active Directory Schema.
Choose Close and then click OK to complete the open dialog boxes.
The left pane of the schema management tool displays a tree control with two main nodes—classes and attributes. If you expand out the classes node, you will find the following classes defined by ConfigMgr:
mSSMSManagementPoint
mSSMSRoamingBoundaryRange
mSSMSServerLocatorPoint
mSSMSSite
Clicking a class selects it and displays the attributes associated with the class in the right pane. The list of attributes for each class includes many attributes previously defined in Active Directory, in addition to those attributes specifically created for ConfigMgr 2007. You can right-click a class and choose Properties to display its property page. As an example, Figure 3.1 shows the general properties of the mSSMSSite class. You can see an explanation of these properties by clicking the Help button on the Properties page.
FIGURE 3.1
General properties of the schema class representing ConfigMgr sites
You can see the 14 ConfigMgr attributes under the Attributes node in the schema management console. The names of each of these attributes start with mS-SMS. You can right-click an attribute and choose Properties to display its property page. Figure 3.2 shows the properties of the mS-SMS-Capabilities attribute.
FIGURE 3.2
General properties of the schema attribute representing site capabilities
Verifying the Schema Extensions - Check ExtADSch.log for failures. Seeing the Event IDs 1137 in the Directory Service Event Log alone is not confirmation that the schema was extended properly; several experiences in the field have found what seemed to be a successful schema extension to show failures in the log file.
After extending the schema, you must complete several tasks before ConfigMgr can publish the objects it will use to Active Directory:
Creating the System Management container where the ConfigMgr objects will reside in AD. If you previously extended the schema for SMS, the System Management container will already exist. Each domain publishing ConfigMgr data must have a System Management container.
Setting permissions on the System Management container. Setting permissions allows your ConfigMgr site servers to publish site information to the container.
Configuring your sites to publish to AD.
The next sections describe these tasks.
You can use the ADSIEdit MMC tool to create the System Management AD container. If you do not already have ADSIEdit installed, you can install the tool yourself. The steps to install ADSIEdit will vary depending on the version of Windows Server you are running.
On Windows Server 2008, add ADSIEdit using Server Manager. Note that configuring the domain controller server role automatically adds ADSIEdit to the Administrative Tools program group.
To install ADSIEdit on Windows Server 2003 or Windows 2000 Server, perform the following steps:
Run the Windows Installer file at \SUPPORT\TOOLS\suptools.msi from the Windows Server 2003 installation media. (For Windows 2000 systems, the installer file is adminpak.msi.)
Select Start, choose Run, and then enter MMC.
Choose Add/Remove snap-in from the File menu.
Click the Add button and choose ADSI Edit.
Choose Close and then click OK to complete the open dialog boxes.
To create the System Management container from ADSIEdit, perform the following steps:
Right-click the Root ADSI Edit node in the tree pane, select Connect to..., and then click OK to connect to the default name context.
Expand the default name context node in the tree pane. Then expand the node showing the distinguished name of your domain (this will begin with DC=<domain name>) and right-click CN=System node.
Select New and then choose Object.
Select Container in the Create Object dialog box and click Next.
Enter the name System Management and then click Next and Finish, completing the wizard.
Figure 3.3 shows ADSIEdit with the tree control expanded to the CN=System node and the Create Object dialog box displayed.
FIGURE 3.3
Using ADSIEdit to create the System Management container
You can view the System Management container and set permissions on it using the Active Directory Users and Computers (ADUC) utility in the Windows Server Administrative Tools menu group. After launching ADUC, you need to enable the Advanced Features option from the View menu. You can then expand out the domain partition and System container to locate System Management.
By default, only certain administrative groups have the rights required to create and modify objects in the System Management container. For security reasons, you should create a new group and add ConfigMgr site servers to it, rather than adding them to the built-in administrative groups. Perform the following steps to grant the required access to the ConfigMgr site server security group:
Right-click the System Management container, choose Properties, and then select the Security tab.
Click the Add button and select the group used with your ConfigMgr site servers, as shown in Figure 3.4.
Figure 3.4
Selecting the Site Server security group
Check the box for Full Control as displayed in Figure 3.5, and choose OK to apply the changes.
FIGURE 3.5
Assigning permissions to the System Management container
Perform the following steps to configure a ConfigMgr site to publish site information to AD:
Navigate to System Center Configuration Manager -> Site Database -> Site Management -> <Site Code> in the ConfigMgr console (select Start -> All Programs -> Microsoft Configuration Manager to open the Configuration Manager console).
Right-click the site code and choose Properties. Click the Advanced tab and then select the Publish this site in Active Directory Domain Services check box as shown in Figure 3.6. Choose OK to apply your changes.
FIGURE 3.6
Configuring a site to publish to AD
After extending the schema and taking the other steps necessary to enable your sites to publish to AD, you should see the ConfigMgr objects displayed in the System Management container. Figure 3.7 shows the ConfigMgr objects viewed in Active Directory Users and Computers.
FIGURE 3.7
The System Management container displayed in Active Directory Users and Computers
Once you extend the Active Directory schema and perform the other steps necessary to publish site information to AD, clients in the same AD forest as your ConfigMgr sites can query AD to locate Configuration Manager services and retrieve important information about your ConfigMgr sites. Those clients in workgroups and domains without trust relationships are not able to take advantage of the schema extensions.
The following ConfigMgr features require extending the AD schema and publishing site information to AD:
Global roaming—Roaming in ConfigMgr allows clients such as laptop computers to connect to the network at various locations and receive certain services from the local site. The schema extensions allow a client to query AD for the mSSMSRoamingBoundaryRange objects and determine whether a site exists on the IP subnet of their current network location. This is known as global roaming. Without the schema extensions, clients can only receive services when at their assigned site or roaming to the sites below their assigned site in the ConfigMgr hierarchy.
Global roaming can make content available to clients at network locations where it would otherwise not be available. Global roaming can also prevent unnecessary network traffic otherwise caused by those clients at remote locations requiring services from their assigned site. For more information about global roaming, see Chapter 12.
Network Access Protection—You can use ConfigMgr’s NAP capabilities to prevent clients that do not comply with specified security patch requirements from connecting to the network. NAP requires the client to retrieve health state reference information stored in the attributes of the mSSMSSite AD object. Chapter 15 discusses Network Access Protection in detail.
ConfigMgr clients can also receive a number of services through the extended schema that may be available in other ways. Chapter 12 discusses many of these features. In each case, the alternatives are more difficult to implement and some require extensive manual effort. You can use the schema extensions for the following capabilities:
Client site assignment—To receive ConfigMgr services, you must first assign a client system to a site. The schema extensions provide an option for the client to retrieve the information from AD that it needs to identify and contact its assigned site.
Client installation properties—A number of configurable options, such as the size of the download cache, are available through the extended schema.
Site mode settings—The extended schema can supply information to the client about the site’s security mode and certificate information required for native sites.
Server locator point and management points—Clients can use Active Directory to identify the server locator point and management points. Without the schema extensions you must provide this information in other ways, such as manually creating special Windows Internet Naming Service (WINS) entries.
Custom Transmission Control Protocol (TCP)/Internet Protocol (IP) Port information—If a site has been configured to use nonstandard ports for client communications, this information can be provided through the schema extensions. See Chapter 5, “Network Design,” for a discussion of port customization.
In addition, the schema extensions allow for automated public key exchange, thus facilitating site-to-site communication. If you have clients assigned to your central site and do not have the schema extended, recovery from a site failure can require reprovisioning all clients manually using the trusted root key.
The AD schema extensions are a key enabling technology for Configuration Manager. You should extend the schema and take the other steps previously listed in the “Schema Extensions” section of this chapter to publish site information to Active Directory, if this is possible.
Rss FeedRss Feed
The Leader in Network Knowledge
Comment