The first step in designing your solution is to understand the current environment. Knowing where you are is a first step in planning how to design your ConfigMgr solution. A detailed assessment gathers information from a variety of sources, resulting in a document you can easily review and update. A variety of sources may be used to gather information for an assessment document, including the following:

The data collected from these sources should be compiled into an architecture document describing the current state. This will serve as a reference point going forward, as well as a snapshot when looking back. This process frequently uncovers real business needs that may have not been known at the time the project was first envisioned.

The network infrastructure is given consideration as part of the envisioning phase of the project. The network is one of the most fragile and complex parts of an IT infrastructure. Areas to consider should include the following:

Once there are answers to these questions, the project team will have a better idea of the solution’s requirements and tasks to address with upper management and the security team to determine whether company policies may influence some of these answers.

Chapter 5, “Network Design,” discusses how you can design your ConfigMgr 2007 solution to address these areas.

The solution architecture needs to be conceptualized at this point of the project. This is when ConfigMgr topology conversations should occur. The decisions made here become a reference point for what the initial ConfigMgr architecture and topology will look like. Here are some key items to think about and discuss:

Chapter 6, “Architecture Design Planning,” covers a number of these items. You will also want to refer to the “Site Design,” “Capacity Planning,” “Licensing Requirements,” and “Extending the Schema” sections of this chapter for additional information.

Server architecture follows solution architecture because the decisions made in the solution architecture phase affect the server architecture. Server architecture is where the ConfigMgr team conceptualizes server requirements. This includes CPUs, RAM, and most importantly drive configuration. Decisions such as whether SQL Server is installed locally or on a separate server are critical to the drive configuration and memory required for sufficient performance. Decisions made in this phase of the ConfigMgr deployment will have an effect on licensing and procurement. The “Developing the Server Architecture,” “Disk Performance,” and “Capacity Planning” sections of this chapter provide additional discussion in these areas.

Client architecture is where the ConfigMgr team and sponsors conceptualize how the agents will be loaded and the settings they will have. Corporate policy often drives many of the ConfigMgr agent policy settings, such as whether or not to prompt for remote control access to a user’s computer.

Frequently, the corporate legal department may have stipulations about which agents may be loaded on certain systems. Discovering these corporate policies is usually time consuming and inflexible, and they may drive a different solution and server design than initially anticipated. The “Client Architecture” section of this chapter and Chapter 12, “Client Management,” discuss specifics of the client design and implementation.

Configuration Manager 2007 is a management solution and, as such, requires licenses for both management servers and managed clients (agents). Part of the requirements your organization may have for a given solution will include its licensing costs, and licensing is frequently an item driving part of the final ConfigMgr architecture.

Configuration Manager licensing is available with and without a SQL Server license. When the SQL Server installation is used only for ConfigMgr purposes, such as when installed on primary site servers, using the combined SQL Server/ConfigMgr license offers substantial savings. When ConfigMgr is licensed with the SQL Server, no other databases other than the ConfigMgr database can use the SQL Server, and no Client Access Licenses (CALs) are required for the SQL Server.

ConfigMgr licensing consists of three types of licenses:

Microsoft provided only one version of SMS 2003. Today, with ConfigMgr 2007, there are two versions of the product:

According to Microsoft’s ConfigMgr licensing page (http://www.microsoft.com/systemcenter/configurationmanager/en/us/pricing-licensing.aspx), the only real difference in the two versions is the server workload running in the OSE, which can be a single device, PC, terminal, PDA, or other device. An Enterprise Server ML is required for using the Desired Configuration Management (DCM) functionality of the Configuration Manager solution. The use of proactive management functionality in DCM is limited to the Enterprise Server ML, whereas the Standard Server ML provides operating system and basic DCM functionality.

To clarify this some, based on conversations with Microsoft, the difference between the Standard and Enterprise MLs is the ability to use DCM on SKUs other than the Windows Base Operating System. Here are some specifics:

Standard Server ML:

Enterprise Server ML:

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

During the discovery phase of the project, you will want to review your organization’s Microsoft licensing agreements for desktops and servers. If your organization already has the Microsoft Core Client Access License (CAL) Suite (see http://www.microsoft.com/calsuites/core.mspx), it is possible you already own the management license for each managed client. The CAL Suite encompasses four fundamental Microsoft server product families:

Using the Configuration Manager licensing page previously referenced in this section, Microsoft provides a licensing guide to use in estimating the cost of the various technologies. Costs given are in U.S. dollars:

To estimate the costs for a company with a single primary site server intending to do standard configuration management on the 50 servers that are clients and 950 workstation clients, use the following numbers:

The total cost of this estimate comes to $48,121. This is only an estimate using a single site server and does not include any operating system or other CALs required in a networked environment. In addition, your organization’s licensing costs will vary depending on the size of the organization and the type of license agreement held.

For more information on Microsoft Volume Licensing options and available discounts, visit http://www.microsoft.com/licensing/default.mspx.

Implementing any new tool brings a requirement for training administrative staff, support staff, and potentially even users. ConfigMgr is a technology that touches many areas—servers, databases, networks, and users workstations. Most groups in Information Technology (IT) will require some level of training specific to their job function and the impact ConfigMgr will have on them or the technologies for which they are responsible. At this point in the project, the design team should start addressing training requirements to address the various audiences. Training should begin before implementing Configuration Manager to help facilitate its adoption, understanding of the tool, its impact on the environment from a cost- and timesaving perspective, and the technical impact it will have on the various pieces of the IT infrastructure.

Your specific environment will determine the level and amount of training required. You may need to consider both user and technical training.

The proof of concept (POC) is where the solution’s architecture is validated. Those architectural features, processes, or options that do not meet the business and technical requirements will be flushed out during the POC. A number of different items should be evaluated and determined whether they will be in the POC—and ultimately in the solution. The following list is not comprehensive because your business may have unique requirements beyond these, but it’s a starting point for formulating the ConfigMgr solution:

The proof of concept should be limited to a sandbox-type lab environment where administrators can freely manipulate settings and learn how the ConfigMgr solution can help them more effectively manage their IT assets. Key business requirements should be identified by this time; these should be verified in the POC.

IT management, training, program management, and release management teams are typically involved in the pilot efforts. The pilot plan identifies the scope of the pilot, participants, locations, what will be tested, and success criteria. Planning the pilot phase involves project team members working out the logistics regarding the following:

Planning the pilot phase is essential to the success of the phase itself. The pilot phase is the first actual phase where the solution is tested in a production environment, with the user’s policies, network infrastructure, and skill levels all affecting and providing insight to the overall deployment plan and processes. The success of the pilot will illustrate the project team has tested the design in the production environment where users are working and has demonstrated the business and technical requirements have been met.

Once the project team and the business determine the pilot is successful, the next step on the road to the ConfigMgr solution deployment is its implementation. The plans made for piloting the solution should be leveraged for the production implementation. Most of the tools, lessons, and processes established as part of the testing and pilot phases can be leveraged to simplify and standardize the production rollout. This includes a list of tasks, issues encountered, their associated resolutions, and the overall monitoring of the server and client deployments. You can leverage the Microsoft Solution Framework for guidance around deliverables for various stages of MSF. Information on the MSF is available at http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx.

The design team should spend a considerable amount of time on the network infrastructure. Large amounts of data may be passed across the network, and the traffic patterns will match that which may be blocked by a variety of network intrusion detection systems (IDS), intrusion prevention systems (IPS), and firewalls. Major roadblocks in a managed client deployment often occur at the lowest layers in the Open Systems Interconnection (OSI) model, with large amounts of time spent troubleshooting it at the application level.

Network mediums such as Frame, ATM, and so on are usually transparent to the ConfigMgr solution. Little regard needs to be given to the network medium, but this is not the case with the individual circuit speed. Understanding circuit speeds, the number of clients at a given location, and the expectations of software distribution are the three most substantial factors in planning where to place distribution points (DPs). If client demands are significant enough, such as a large number of systems at a location with inventory and software distribution requirements, an additional primary or a secondary ConfigMgr site may be warranted.

The following times are examples of how long a circuit could be saturated pushing software such as Microsoft Office to a distribution point:

This scenario demonstrates how additional bandwidth may be required in locations that may have previously not needed such bandwidth capacity. You can recoup the return on investment (ROI) of this additional bandwidth with lower overall administrative costs, including the following:

The topic of multiple site servers and additional management points introduces the use of addresses and senders, where traffic can be scheduled and throttled across network segments. More information on these topics is available in Chapter 6.

Leveraging Active Directory with schema extensions provides a constant, redundant, easily accessible, and secure location when querying for ConfigMgr information. This makes extending the schema the preferred approach when implementing ConfigMgr. If you previously extended the AD schema for SMS 2003, it should be extended again because not all functionality for ConfigMgr 2007 exists in SMS 2003 schema extensions. Table 4.2 illustrates the ConfigMgr features that depend and benefit from AD schema extensions.

When the schema is not extended, ConfigMgr administrators have to perform manual maintenance tasks that could otherwise be automated with ConfigMgr 2007. These include running scripts and maintaining group policy objects (GPOs) as well as other items required to roll out clients and have them perform with acceptable functionality. Many of the workarounds published in the ConfigMgr online help file do not even scale to support medium-size deployments. Chapter 3, “Looking Inside Configuration Manager,” provides additional information about the benefits of extending the schema and discusses the process of extending the AD schema.

Secondary site servers, discussed in Chapter 6, are used in ConfigMgr to lessen the load on the primary parent site and reduce network bandwidth utilization. It is extremely important to understand how to leverage secondary sites over slow links when defining the distribution point architecture across the WAN. Secondary site servers can host a role known as the proxy management point (PMP), which, to conserve bandwidth, caches a local copy of the policies stored on the parent primary site.

If you place distribution points in a secondary site, clients that are local to the secondary site and within its boundaries can request content from a local DP rather than downloading it across the WAN. The benefit here is that although multiple clients request the content, it is only sent across the slower WAN link once and then installed locally across the LAN by each client. This conserves bandwidth and improves the end-user experience.

You can also use branch DPs in this manner, which provide the added benefit of being supported on client operating systems such as Windows XP and Vista. If you’re deploying secondary site servers purely for the sake of throttling transmissions to DPs, use branch DPs rather than creating secondary sites. However, although branch DPs will keep traffic down, they do not provide the ability to cache and push client inventories, status messages, and policies, as does the PMP of a secondary site server. Branch DPs are limited to 10 concurrent connections when being run from a client operating system rather than a server.

Secondary site servers have a number of advantages and limitations, which should be understood to implement them in your organization effectively. Advantages of secondary site servers include the following:

Here are some of the disadvantages of secondary site servers you will want to consider:

ConfigMgr provides two modes of security: mixed and native. If you are familiar with SMS 2003, that version used standard and advanced site security modes. Different from SMS 2003, if you upgrade the site to the more secure mode, you can downgrade it later. ConfigMgr 2007’s mixed mode is functionally equivalent to SMS 2003’s advanced security. Because self-signing of transmissions by the management point or the site server using certificates is only available with ConfigMgr, Internet-Based Client Management (IBCM) is not available on ConfigMgr sites running in mixed mode, as IBCM requires manipulating the certificate templates. On the other hand, authentication between clients and site servers uses the same proprietary technology as SMS 2003 when ConfigMgr is in mixed mode.

Native mode introduces new functionality and complexity to ConfigMgr security, such as using industry-standard Public Key Infrastructure certificates and Secure Sockets Layer (SSL) authentication between clients and site systems. ConfigMgr also supports third-party certificates, as long as their template is modifiable. SSL does not encrypt transmissions of policies; these are signed by the site server and management point. Metering data, status messages, policy, and inventory are all signed and encrypted. Because IBCM requires clients to communicate over HTTPS across the Internet to the ConfigMgr hierarchy, it requires native mode. If you will be implementing IBCM, you will want to analyze carefully the various supported deployment scenarios discussed at http://technet.microsoft.com/en-us/library/bb693824.aspx. Chapter 6 provides additional information about planning for site security modes.

ConfigMgr 2007 has numerous roles that serve various purposes. Some roles are mandatory, some are optional, and some are recommended. Table 4.3 lists the ConfigMgr 2007 roles. Chapter 2, “Configuration Manager 2007 Overview,” introduces the different roles, and Chapter 8, “Installing Configuration Manager 2007,” covers the specifics of installing them.

Each role has different purposes that create unique loads on the site system housing that role. You will need to plan to ensure the site system can handle the load placed on it once in production. The following sections touch on many of the common design considerations that go into a ConfigMgr deployment.

Distribution Points

Distribution points are typically the most heavily used role from an I/O perspective in all of ConfigMgr. Hundreds to thousands of clients may download or install packages from any given distribution point. Because each environment has unique circumstances around the volume of packages they push, the frequency in which the packages are pushed, and the average size of the packages, it is difficult to create a standard recommendation for sizing distribution points. Here are several best practices for DPs:

• Use BITS whenever possible to download and execute packages.

• Protect DPs on slow links or in remote locations.

• Verify there are enough spindles on the DP to support the packages pulled from them.

• Group distribution points as possible, for simpler administration.

• Make sure DPs have sufficient drive space to accommodate packages.

• If DPs are placed on a system with multiple purposes, such as a domain controller, make sure the load will not hinder other services the system provides.

• When placed on systems providing other network services, the DPs should be placed on a dedicated logical drive, if possible, to segregate I/O.

If a WAN link exists between a site server and the distribution point, using a secondary site server for the remote DP has a number of advantages. The primary benefit is the scheduling and throttling of traffic between the primary site server and secondary site server in regard to package replication. Here are some points to keep in mind:

• When the WAN link is reliable but somewhat small (such as a T1) or the link hosts important services for users across the WAN, a secondary site server housing the DP is highly recommended, as shown in Figure 4.5.

Figure 4.5. A DP on a secondary site server

• When the WAN link is unreliable or very slow (such as in a circuit under 1.5Mbps), it is best to use a branch DP, which enables leveraging BITS to replicate the package data.

CPU, RAM, and disk I/O are the three most important items when planning and configuring server hardware. The size, or robustness, of the server provisioned for any given role dictates how well it will handle the load. When discussing expectations of the overall solution, some level of understanding needs to be communicated and agreed on. ConfigMgr has many dependencies, including business and user requirements in addition to the overall infrastructure and network services requirements. This makes it difficult to predict expectations for the overall solution. Because each environment is different and has different requirements, there is no “one size fits all” solution.

Capacity requirements are frequently miscalculated in the initial planning phases of ConfigMgr deployments because adequate thought is not given to the actual amount of data that will be kept on each site server and site system. Adding storage after the fact is a rather difficult situation to deal with; it frequently requires outages, possibly moving roles around, and in general is something that could have been dealt with in advance if properly architected.

A number of items contribute to ConfigMgr capacity requirements:

• Software inventory has the ability to do file collection.

In a 5,000-seat environment, collecting a 1MB file will add 5GB of storage to the server, backups, and the network load while transferring the data. ConfigMgr software inventory file collection can be configured to limit the maximum amount transferred per client, but the site server and network infrastructure will need to handle this size times the number of clients reporting to the site server or hierarchy.

Adding a software file extension such as .dll to your inventory can easily double the ConfigMgr database size. Tables in the ConfigMgr database such as softwarefile can grow exponentially in size, affecting reporting and Resource Explorer performance. When designing your ConfigMgr solution, it is important to know what software file types will be inventoried to help determine backend storage requirements from a capacity and performance perspective.

• You can scale SUPs and MPs beyond 25,000 clients per site by implementing these site system roles with NLB, as illustrated in Figure 4.6.

Figure 4.6. Network load-balanced MPs and SUPs

If you are implementing NLB on an MP in a mixed mode site, IIS does not allow clients to authenticate to the site system using Kerberos authentication. To support an NLB implementation, you must reconfigure the website application pools running under the Local System account to run under a domain user account.

• Distribution points have disk I/O and network I/O constraints.

Considerations affecting the size of the volume needed include how many packages are planned to be kept on distribution points year-round, and the number of packages a given distribution point is expected to support. Although the ConfigMgr documentation states that a distribution point can handle up to 4,000 clients, network speed, disk performance, and package size greatly impact this value.

Tip

Capacity Planning Calculations

DPs and state migration points are site systems with unique capacity requirements. As a rule of thumb, take the current size of your existing software library volume and then triple it to use as a starting point for DPs or package source repository requirements.

• The state migration point (SMP) is a Configuration Manager 2007 site role providing a secure location to store user state, data, and settings, prior to an operating system deployment.

You can store the user state on the SMP while the operating system deployment proceeds, and then restore the user state to the new computer from the state migration point, as illustrated in Figure 4.7.

Figure 4.7. A state migration point role

Each SMP site server can only be a member of one Configuration Manager 2007 site. State migration points provide ConfigMgr administrators the ability to store users’ data and purge it automatically after it has become stale, a period defined by the ConfigMgr administrator. The concept behind this relies on the data being restored or backed up within the allotted threshold. Figure 4.8 shows the state migration point properties.

Figure 4.8. A state migration point properties page

Although state migration points allow for automatic scheduled deletion of data considered stale, capacity planning is still needed to handle the volume of data sent at the state migration point within the defined retention period. Chapter 19, “Operating System Deployment,” discusses state migration points in more detail.

ConfigMgr boundaries, discussed in Chapter 6, are logical groupings defining where the site server has management capabilities. You can specify boundaries using AD sites, Internet Protocol (IP) subnets, IP address ranges, or IPv6 prefixes. Figure 4.9 depicts the Dallas site boundary on the Bluebonnet central site.

Figure 4.9. ConfigMgr boundaries

When defining boundaries, the ConfigMgr administrator must define whether these boundaries are slow or fast (which really means unreliable or reliable). Boundaries should be unique to each site server and ideally not overlap.

When planning your ConfigMgr site boundaries, you may discover unique requirements for some AD sites or subnets, which may often lead to creating additional ConfigMgr sites. Some client settings at a site level only may not be allowed on certain subnets or AD sites (as an example, remote controlling a computer without user interaction). This action may be prohibited in the Accounting AD site or subnet and ultimately require an additional site server with unique settings for the location.

Although settings are often sitewide, they can be overridden using local policy. Local policies are described in Chapter 3.

Roaming in ConfigMgr is the capability allowing clients to move between sites in the hierarchy, yet still be managed, while making the best use of local network resources. ConfigMgr clients have the ability to roam throughout the hierarchy, allowing clients to leverage services from a nearby site server in the hierarchy so that traversing a WAN or “slow” network is not required. As an example, if a client is at a remote location supporting a site server the client does not belong to, the client can use the roaming feature to install packages off that site server’s DP if the packages are present, thus minimizing impact to the WAN and optimizing the end-user experience of software distribution.

Figure 4.10 illustrates how a client can roam to a different network defined as a slow or unreliable network managed by another site. This is a common scenario when laptops travel, which allows ConfigMgr clients to automatically download and execute packages rather than installing them across the WAN.

Figure 4.10. A roaming client

Designing a site involves analyzing several items and making decisions on the settings to apply to those items. You will need to analyze items such as client agent settings or policies to determine what the best setting is for the environment the site will be managing. A great example of this is the notification options selected for users to experience when they receive advertisements to run packages on their systems.

Site design items are not specific to client agent settings; they consist of many things, including the following:

Although some settings may only be useful in a disaster-recovery scenario, many of them can have negative impacts when used incorrectly. As an example, when you’re performing discovery from multiple ConfigMgr sites within a hierarchy, it is possible for a system to be discovered multiple times with its data discovery record (DDR) sent up the hierarchy and processed by each system that handles it. This not only results in duplicate DDR analysis effort, but every site will have to analyze each DDR and determine which is newer. It is best to let sites discover only resources that belong to that site, even for child sites—because discovered data flows up the hierarchy. This is easily viewable by looking at the properties of any discovered system or client in a collection.

Due to ConfigMgr’s scalable design, sites may host multiple ConfigMgr roles. In most implementations of 10,000 managed clients or fewer, you can use a single site server with specifications similar to those listed in the next sections. These designs are documented by Microsoft at http://download.microsoft.com/download/4/b/9/4b97e9b7-7056-41ae-8fc8-dd87bc477b54/Sample_Configurations_and_Common_Performance_Related_Questions.pdf (this link is also available in Appendix B), for scaling and providing adequate performance in the listed configurations.

When you define which agents will be loaded into the ConfigMgr client, you are actually defining the ConfigMgr client architecture. This architecture requires planning to ensure future initiatives will work without issues.

As an example, defining an initial ConfigMgr client cache value is an important task to perform before rolling out clients to the enterprise. Although you can modify the cache size on an individual client basis, initial packages may fail if they exceed the default cache size.

Another setting is choosing to have the client display a visual indicator or even generate an audible alert when the client is being remote-controlled. Enabling the audio is considered annoying by users, and systems have been known to have problems with it. Displaying a visual indicator is suggested, because it lets the user know the system is still being controlled and identifies when the remote administrator has closed the session.

ConfigMgr clients consist of multiple agents, each of which has unique settings that can be assigned to them. When the settings are defined, ConfigMgr creates XML (eXtensible Markup Language) policies, which are downloaded via the management point to clients. The following agents have policies defined that collectively make up the ConfigMgr Client architecture illustrated in Table 4.7.

Client architecture is fairly flexible in that if a setting is not initially deployed correctly, it can be changed centrally with the clients updating to the new setting in fairly quick fashion (as fast as the setting for the Computer Client Agent Policy Polling Interval). The importance of understanding the agents and their settings is primarily to facilitate creating a correct ConfigMgr site design and to position the ConfigMgr deployment team for success.

Chapter 12 further discusses client architecture.

In today’s global economy, more companies have networks spanning multiple countries than ever before. The nature of the different languages used from country to country presents new challenges for system administrators. When Microsoft Windows client operating systems are installed using the native, non-English language of the country, ConfigMgr administrators must look at available options to address their system management needs. The International Client Pack (ICP) is a specialized set of client files split across two separate downloads, supporting the following 22 languages. You can download the ConfigMgr 2007 SP 1 ICPs by searching for ICP at www.microsoft.com/downloads.

ICP1 contains the following languages:

ICP2 contains all languages from ICP1 plus the following:

ICPs are client files only. The files consist of the following: