As with any major Information Technology (IT) project, implementing and supporting Microsoft Configuration Manager (ConfigMgr) requires a phased approach when transforming your initial vision into a working production system. Microsoft provides guidance on managing the life cycle of IT initiatives through two complementary sets of best practices, Microsoft Operations Framework (MOF) and Microsoft Solutions Framework (MSF):
• MOF, introduced in Chapter 1, “Configuration Management Basics,” is a framework for IT operations.
• MSF, described in Chapter 4, “Configuration Manager Solution Design,” provides guidance on developing and implementing new IT initiatives.
Together, these frameworks address the phases you need to go through to plan, build, deploy, and operate a technology-based business solution.
Chapters 4 through 6 took you through the process of envisioning, designing, and planning solutions based on Microsoft Configuration Manager 2007. Chapter 4 discussed how you might begin to envision and plan your solutions. Chapter 5, “Network Design,” presented the network infrastructure considerations you should take into account during the planning phase, whereas Chapter 6, “Architecture Design Planning,” provided guidelines for planning the details of your sites, hierarchy, and feature set implementation.
This chapter discusses how to test your solution before deploying it to your production environment, and how to stabilize and customize your solution as you begin the deployment phase. The latter is the stage where you are actually building, testing, and refining your solution. Even if you have not adopted the Microsoft frameworks or a similar formal set of best practices, you can still apply the principles they suggest in guiding your efforts during this critical phase of your deployment.
Building, testing, and stabilizing your solution includes several major activities:
• The first step is building a proof of concept (POC) implementation. A proof of concept is a trial deployment that implements the essential features of your solution but is not designed to be part of your production environment.
• Later in your implementation, you will carry out a pilot deployment in your production environment. The pilot is a controlled implementation to a selected subset of your production systems.
Throughout this phase, you will monitor and test your solution. Based on the test results, you may need to make adjustments and customizations so the final solution will work well in your production environment.
Depending on the size and culture of your organization, you may follow a more or less structured approach to planning and building your solution. For any deployment, you will want to test the basic functionality you plan to use before deploying to production. You may require more or less extensive testing and formal release management processes, based on the following:
• The size and complexity of your environment— Deploying Configuration Manager in a large, complex environment calls for more extensive testing than a smaller deployment.
• The feature set you plan to use— Some ConfigMgr features such as Out of Band (OOB) Management and Operating System Deployment (OSD) have network and service infrastructure dependencies you need to consider when testing and building your solution. Similarly, some features such as Network Access Protection (NAP) and Software Updates impact clients more directly than lower impact Configuration Manager services such as inventory and reporting. Features that have a higher impact on clients introduce greater risk to your production environment. You need to account for those risk factors in testing, and incorporate risk avoidance or mitigation strategies as you build your solution.
• The extent to which your solution is customized and integrated with other elements of your environment— Relatively generic deployments may largely consist of deploying features that are well tested out of the box. These features may just need basic validation in your environment. In contrast, every customization and integration point should be thoroughly tested and documented as part of your solution build.
To prove that your design is conceptually sound, you will need to implement the essential features of your solution in a test environment. The primary goals of the POC include the following:
• Providing evidence that the proposed technical solution is feasible and addresses the business requirements. It is important to validate your processes and documentation as well as the technical design.
• Furnishing an opportunity for the support team to gain knowledge of the product.
• Identifying and addressing any gaps or weaknesses in the original design.
Here are the key requirements for an effective proof of concept:
• A POC environment that adequately reflects your production environment.
• A test plan that validates each element of your functional requirements.
• A communications plan that allows you to effectively share lessons learned and applies the results to improving your design, documentation, and processes.
Microsoft’s frameworks identify four stages of the IT project life cycle:
• Plan
• Build
• Deploy
• Operate
The build stage focuses on developing and stabilizing your solution and encompasses the activities described in this chapter. If you have followed MSF guidance during the planning phase, you will have several key deliverables that will help with the POC. As you enter the build stage for your Configuration Manager deployment project, you should have the functional specification, risk management plan, master project plan, and master project schedule in place. These planning documents will help you define clear goals as well as set entry and exit criteria for the POC. These documents will also define the requirements for the POC environment and your test plan. The documents essential to the POC include the following:
• The functional specification— This provides a detailed description of the feature set, and explains how each feature should look and behave. It also describes the overall architecture and design of each feature. This document will identify what ConfigMgr features you need to configure as well as the infrastructure requirements each feature depends on.
• The master project plan (MPP)— The MPP generally includes a deployment plan, capacity plan, security plan, and test plan, among other elements. One goal of the POC will be to validate each element of the MPP. The test plan in the MPP will be largely carried out during the POC phase.
To avoid delay, you can start setting up the test environment while your plans are being finalized and reviewed. Chapters 4, 5, and 6 discussed the planning process. You will want to carry out the preliminary work of providing a network, servers, workstations, and support tools in parallel with the planning phase. Be sure to establish backup and monitoring systems and processes if these are not already in place.
Ideally, your POC environment would be an exact replica of your production environment; however, in practice this is not feasible. Therefore, it becomes necessary to identify the critical systems, infrastructure, and activities that adequately represent the production environment. Organizations using MOF or other Information Technology Infrastructure Library (ITIL) practices can leverage information from the enterprise Configuration Management Database (CMDB) to help identify the relevant configuration items (CIs) that need to be replicated in the test environment. The CMDB includes details about both the individual CIs and the relationships between them. You should review your functional specification and master project plan and use the CMDB to map the dependencies relevant to the CIs in your Configuration Manager deployment. Here are a few examples of how you might use the CMDB to plan your test environment:
• The CMDB is the starting point for enumerating the client configurations you need to test. Although it may not be possible to test every configuration, your test environment should include as complete a sample of platforms as possible. At a minimum, you should include all operating system versions found in your production environment and the major hardware platforms you will be supporting. If you plan to use Configuration Manager to manage mobile devices such as smartphones running Windows Mobile, you should include devices on each carrier network as well.
• Your MPP calls for ConfigMgr sites in various locations such as Brussels and Beijing. The CMDB contains information about these sites including local area network (LAN) and wide area network (WAN) characteristics, Windows language and locale settings, the number and type of clients systems, information about the local IT and vendor support organizations, and possibly legal and regulatory requirements affecting the sites.
One way to replicate the network environment of these sites accurately in your POC would be with a distributed test environment, which would include systems physically located at these sites. An alternative method is to configure the physical or virtual network infrastructure to introduce bandwidth throttling, latency, and transient communications anomalies between sites to simulate your actual network characteristics and conditions.
• Your functional specification calls for delivering OOB Management to laptop and desktop computers supporting Intel Advanced Management Technology (AMT). The CMDB will help you identify all AMT-capable models in your environment so that you can include them in testing.
• Your functional specification includes a requirement to provide reports on software license compliance for all your standard desktop applications. You can use the CMDB to identify those applications you will need to report on and the available license data to incorporate in the reports.
Note
Terms: CMDB and CI
A CMDB is a repository of information related to all the components of an information system. In the ITIL context, a CMDB represents the authorized configuration of the significant components of the IT environment. A key goal of a CMDB is to help an organization understand the relationships between these components and track their configuration. The CMDB is a fundamental component of the ITIL framework’s Configuration Management process.
CIs form the basis of configuration management solutions. A CI is a collection or object related to the specific functionality of a larger system. Examples include requirements, code, documentation, models, and other files. The term configuration item and the CI acronym are used with a different meaning in Configuration Manager Desired Configuration Management (DCM). In DCM, a CI is an element of the configuration used to assess compliance. DCM is discussed in Chapter 16, “Desired Configuration Management.” A third usage for the term configuration item is specific to ConfigMgr Mobile Device Management (MDM). In MDM, a configuration item is a group of related settings you can assign to a device client. Chapter 6 introduces the concept of device CIs, with specific examples discussed in Chapter 20, “Security and Delegation in Configuration Manager 2007.”
If you do not already have an enterprise CMDB, you will need to use other means to gather data about your environment. Start with the existing documentation about your network, client and server hardware, and other elements of your environment. You may want to employ an asset discovery tool to update your documentation and fill in any gaps. The information and data collection methods you assemble may be useful to you later if you decide to develop a CMDB.
You can carry out a proof of concept in a physically isolated lab or in a controlled environment with connectivity to your production network. There are advantages and disadvantages to each:
• Using an isolated lab provides the greatest safety, and frees you from the need to consider possible impact on the live environment. However, this can take longer to set up because you have to duplicate infrastructure services.
• Implementing a POC in a test environment connected to your production network can save time and money because you can leverage existing infrastructure services rather than having to duplicate them in the test environment. The downside is that caution needs to be exercised at all times to avoid making changes that will affect your live environment.
The following sections discuss each of these environments.
Generally, you will deploy the POC in a lab environment isolated from your production network. Testing in an isolated lab gives you the freedom to try things out without having to worry about risks to your production environment. If your organization does not already have a suitable lab in place, you should consider building one. The test environment should mirror your live environment as closely as possible. Here are some points to keep in mind:
• Ideally, you should deploy Configuration Manager server roles on hardware identical to what you will use in production. You could accomplish this by “borrowing” the actual hardware you will use for your production site systems to use as part of the POC. This approach allows the most realistic testing, but requires you to tear down at least part of the POC environment when you move the production hardware to the live environment.
In general, it is a good idea to keep the POC environment available if possible. This gives you an environment for future testing of hotfixes, service packs, upgrades, new packages and operating system (OS) images, and any additional functionality you may decide to deploy. The POC environment is also a great place for training and experimentation. If you decide to use production hardware during the POC, you may be able to preserve the environment for future use by performing a P2V (physical-to-virtual) conversion of the site systems before removing them from the POC environment.
• In addition to the site systems, you should have a mix of clients in the POC environment representing a cross-section of the hardware, operating systems, and applications you will encounter in your live environment. The network infrastructure and core services should also replicate the essential features of your production environment. Although this may be expensive, it can save you from greater costs later if you encounter unexpected problems in the production environment.
A properly designed lab environment allows development and testing of your solution without affecting production systems. Everyone working in the lab should understand that test systems can become unstable and require reinstallation. It is not uncommon for an unstable lab environment to be a source of frustration, but you should keep in mind that many of the problems that arise in the lab would otherwise have occurred in your production environment! Encountering problems in the lab is actually a good thing, because you have the opportunity to address them before they affect the live environment. Because it is often necessary to roll back a test server to a previous state, you should maintain frequent backups or snapshots of all servers. Here are a few approaches:
• For virtual machines, reverting to a snapshot of the original build or a more recent baseline snapshot is generally the most efficient way to roll back to a previous configuration.
• For physical machines, you may be able to leverage Configuration Manager OSD to capture configuration baselines and redeploy them as necessary.
• To restore your ConfigMgr site server or other site systems required for OS deployment, you will need to use other recovery methods. In this case, you may need to do a bare metal restore or apply a standard server image and reinstall SQL Server and Configuration Manager. It may be helpful to maintain images of standard server configurations on removable media because machines are often “wiped” or reformatted. Developing scripted installations will help with this process, and you can use them in your production environment as well.
Regardless of how you manage recovery in your lab environment, you will need to follow the site recovery process described in Chapter 21, “Backup, Recovery, and Maintenance,” when restoring a site server that is part of a Configuration Manager hierarchy.
You can use the test environment to finalize infrastructure components, including server build specifications, service configurations, and deployment packages and scripts. You will want to develop test specifications and test cases around each of the feature sets you plan to deploy.
An optimum test environment may include both virtual and physical systems:
• Use at least one physical server or server cluster to validate the hardware configuration and site maintenance procedures for critical site systems, such as the site server and site database server.
• Install client systems on physical hardware to test hardware-dependent functionality such as OS Deployment and OOB Management.
• Using virtual machines allows you to scale your test environment far beyond the limits your budget would allow if you had to build a separate physical machine for each test system.
• Virtual machines can allow you to test more scenarios in less time and recover your test environment to a known-good state more quickly than using a lab configuration tied to physical hardware.
Configuration Manager 2007 requires certain infrastructure dependencies for installation and for certain features to work. Chapter 2, “Configuration Manager 2007 Overview,” covers feature dependencies. Your POC environment will generally need the following services to be in place:
• Active Directory (AD) is a required dependency for Configuration Manager 2007. The AD environment for your POC should closely resemble your production AD. The “Active Directory Considerations” section of this chapter discusses creating the AD environment for your POC.
• Domain Naming Service (DNS) is required for AD and for many ConfigMgr features. Using AD-integrated DNS meets this requirement when you deploy AD in the POC environment. If you use a non-AD-integrated DNS, you will need to configure similar DNS servers in the POC environment. If you want your DNS zones to mirror those in your production environment, you need to copy and edit the configuration and zone files from your production DNS. You should refer to the documentation for your DNS server software for details on completing this task.
• Windows Internet Naming Service (WINS) is required for certain functionality if you will not be using AD schema extensions or you have clients that cannot take advantage of AD schema extensions. For information on feature dependencies and requirements for AD schema extensions, and on how to use WINS in place of the extended schema, refer to Chapter 6.
• Public Key Infrastructure (PKI) is required for Configuration Manager native mode operation and for certain features such as OOB Management. Chapter 6 discusses PKI dependencies as well.
You should also deploy any security software you use in production, such as antimalware and host intrusion detection software, to the POC environment. Network-based security controls such as firewalls and intrusion detection systems should also be in place and configured consistently with those in your production environment.
Configuration Manager 2007 is closely integrated with Active Directory, making it important that your POC AD be as close as possible to your actual AD environment. You can use several approaches in creating a suitable AD implementation in a POC environment. The first method is often referred to as the peel-off method. In this scenario, you add a domain controller (DC) to each production domain you wish to replicate in your POC, peel the DC off from production, and move it to the POC environment.
To essentially clone an AD domain using the peel-off method, perform the following steps:
-
Add a new domain controller to your production domain. You can add a domain controller using the Dcpromo process, described in http://technet.microsoft.com/en-us/library/cc732887.aspx.
Do not make the new DC a global catalog server. If you are using AD Integrated DNS, you may or may not want to install DNS, depending on whether you want a copy of your production DNS in the lab. Your production DNS may include records such as aliases for Internet-based systems that you want to preserve. If this is not the case, you may be better off to start with a clean DNS installation after bringing the DC online in the lab.
- Shut down the newly added DC, remove it from the production network, and move it to the lab network.
-
On one of your production DCs, run the Ntdsutil command-line utility and use the metadata cleanup option to remove references to the DC you just removed from the network.
This is necessary to prevent errors that would otherwise occur when the DC’s replication partners attempt to contact it and when the Windows components responsible for AD replication attempt to generate a replication topology. You also need to remove DNS entries for the DC through the DNS console and use the ADSI Edit Microsoft Management Console (MMC) snap-in to remove File Replication System (FRS) references to the DC. This is the same process used after an unsuccessful domain controller demotion, as described in http://support.microsoft.com/kb/216498.
- Bring the DC you moved to the lab environment online, give it a new IP configuration for the subnet it is on, and perform the same process of metadata cleanup described in step 3 to remove references to other DCs in the production environment. Install DNS services on the DC if they are not already installed, and your lab DCs act as DNS servers.
- Seize the domain Flexible Single Master Operations (FSMO) roles on the new DC. If the domain is the forest root domain, you should also seize the forest FSMO roles. One way to seize the FSMO roles is to use Ntdsutil, as described in http://support.microsoft.com/kb/255504.
A variation on the peel-off method is to clone an existing DC instead of actually removing it from the domain and transferring it to the lab:
• Cloning a DC has the advantage of minimizing the impact on the production environment. In particular, the metadata cleanup in the production environment described in step 3 of the preceding procedure is not required, although the metadata cleanup in the lab environment is still necessary.
• To clone a DC on physical hardware, you may be able to use your backup software following procedures described in the backup vendor’s documentation. You may also be able to use imaging software or P2P (physical-to-physical) migration tools.
If you have a DC running as a virtual machine, the cloning process may be even easier. You will probably just need to shut down the DC and use your virtualization software’s management tools to clone the image. You can then copy the cloned image to the lab and bring the new virtual machine online on a host connected to the lab environment.
The major alternative to the peel-off method is standing up a new AD forest in the POC environment and reproducing the essential elements of your production AD in the new forest. To accomplish this you will need to consider the following steps:
- Create a new domain controller in the POC environment as the first domain controller in a new forest. You can create a domain controller in a new forest using the Dcpromo process, described in http://technet.microsoft.com/en-us/library/cc732887.aspx, previously referenced in this section.
- Again using Dcpromo, add any child domains and additional DCs you will need in your environment.
- Configure services such as DNS and Global Catalog servers in your new forest, and assign the FSMO roles to appropriately reflect your production environment.
- On a production DC, use the LDIFDE command or other tools to export the objects you need from your production AD. Chapter 6 introduced LDIFDE, and http://support.microsoft.com/kb/555636 describes the process of exporting and importing objects with LDIFDE.
- Transfer the output file from step 4 to the DC in the POC environment and use the same tools to import the AD objects.
-
Transfer any relevant group policy objects (GPOs) from the production environment to the POC environment. GPOs control many settings that affect Configuration Manager, such as security and network settings. At a minimum, you will want to import the default domain policy and default domain controller policy from your production environment.
You will find the Group Policy Management Console (GPMC) installed in the Administrative Tools program group on Windows Server 2008 systems when you choose the Group Policy Management role in Server Manager. You can also download the GPMC from http://www.microsoft.com/downloads/details.aspx?FamilyID=0a6d4c24-8cbd-4b35-9272-dd3cbfc81887&displaylang=en for installation on Windows Server 2003 or Windows XP systems. You can transfer group policy objects using the GPMC as follows:
a. Expand the Group Policy Management tree to locate the domain and the GPO you wish to export. Right-click the GPO and choose Back Up.... Alternatively, right-click the Group Policy Objects node and choose Back Up All....
Figure 7.1 displays the GPMC with the default domain policy for the sccmunleashed.com domain selected.
b. Complete the Back Up Group Policy Object dialog box and click Back Up. Figure 7.2 displays this dialog box.
You can also use scripts to export and import group policy. Microsoft provides sample scripts for various group policy–related tasks, including backing up and importing GPOs. You can find these sample scripts at http://technet.microsoft.com/en-us/library/cc784365.aspx.
If you are planning to use the AD schema extensions for Configuration Manager, you should include the schema extensions in your POC environment. Chapter 3, “Looking Inside Configuration Manager,” describes the AD schema extensions and the benefits of extending the schema.
Tip
Software Licensing for Your POC
If you are standing up a separate environment to evaluate Microsoft software, you may be able to take advantage of free limited-time evaluation software, or use reduced-cost licensing for full-featured evaluation software with subscription programs such as TechNet Plus and MSDN (Microsoft Developer Network). Evaluation software is not licensed for use in a production environment, and other license restrictions apply. Carefully review the licensing terms for all evaluation software before downloading and installing it. Information about evaluation software and subscription programs is available at http://technet.microsoft.com/en-us/evalcenter/default.aspx.
If your organization provides products, services, or solutions to customers based on Microsoft technology, you may also be eligible to receive licensing benefits for internal-use software by joining the Microsoft partner program. For more information about the Microsoft partner program and the licensing terms and conditions under this program, see https://partner.microsoft.com.
Although there are many advantages to having an isolated lab environment for your proof of concept, you may also consider doing POC testing on systems connected to your production network. This approach has the following advantages:
• The cost will be lower because you do not need to create a separate network infrastructure.
• The time to deploy the POC environment will be substantially less because you will typically be able to leverage existing services such as DNS, WINS, DHCP (Dynamic Host Configuration Protocol), and backup services. In a lab environment, you would need to install and configure these services independently of your production deployment.
• It may be difficult or impossible to adequately reproduce certain features of your environment in a test lab. Enterprise monitoring solutions, PKI infrastructure, and production security services are examples of services you may have deployed in production that would be prohibitively expensive to duplicate in a lab.
If you use a POC environment connected to production, you will generally need to create a separate AD environment for the POC. This is particularly true if you are using the schema extensions to publish site information to AD. You cannot use the peel-off method in this circumstance, so you will need to stand up a separate AD forest from scratch. If you have an existing ConfigMgr 2007 or Systems Management Server (SMS) 2003 deployment in production, you will also need to make sure that the site boundaries of your POC ConfigMgr sites do not overlap with the site boundaries of your production deployment, and that you do not use the same site code for more than one site!
A successful proof of concept will demonstrate that the proposed technical solution is feasible and help identify any gaps or weaknesses in the original design. To accomplish this, you need to test all functional components of the design and demonstrate how the system performs under stress. You should begin the POC phase with a comprehensive test plan that validates all functionality and yield performance metrics that will project the performance in the live environment.
Start by assembling a list of features you will implement in your ConfigMgr deployment with criteria to validate each feature. Functional testing verifies that each feature operates correctly. Some of the common areas of functional testing include the following:
• Site system installation— Chapter 8, “Installing Configuration Manager 2007,” presents the success criteria for server installation. Confirm that your POC deployment successfully meets these criteria.
• Client installation— Test each client installation method you plan to use in production. To confirm that the client agent and required components are installed and enabled, open Control Panel on the client system and view the Components tab of the Configuration Management applet. Figure 7.3 shows the component status displayed in Control Panel. You should also review the Client Deployment Failure Report and run the following status message queries:
• Client Configuration Requests (CCRs) Processed Unsuccessfully
• Client Components Experiencing Fatal Errors
Both these queries should return zero systems in their output. See Chapter 18, “Reporting,” for a discussion of ConfigMgr reports, and Chapter 17, “Configuration Manager Queries,” for status message queries.
• Client inventory— Schedule client inventory and review the results. Again, you do not want any errors or warnings. You can run the following status message queries to view possible errors or warnings during inventory collection:
• Clients That Reported Errors or Warnings During Inventory File Collection.
• Clients That Reported Errors or Warnings While Creating a Hardware Inventory File.
• Clients That Reported Errors or Warnings While Creating a Software Inventory File.
• Backup and recovery— As part of your POC, validate your backup and recovery processes for all site systems.
• Service delivery— Design functional tests and success criteria for each service you plan to deliver, such as software deployment, software updates, or remote administration.
One of the most challenging aspects of POC testing is generating a load approximating the load your systems will experience in a live environment. Client activity, which scales linearly with the number of client systems, generates much of the load on Configuration Manager site systems. As the number of clients increases, site systems will experience a heavier load from activities such as the following:
• Processing inventory data
• Processing other client data such as heartbeat discovery data, state messages, status messages, and software-metering data
• Processing requests to the management point for policy downloads
• Concurrent connections to distribution points
• Updating larger collections and running queries and reports against larger data sets
Tip
Scripting to Simulate Larger Client Loads
One way you can simulate some aspects of a larger client load is with scripting. For example, you can use a script provided by Microsoft (http://technet.microsoft.com/enus/library/bb633207.aspx) to initiate a Machine Policy Retrieval and Evaluation Cycle from a client workstation. You could add logic to the script to invoke the policy retrieval cycle repeatedly and run the script from multiple clients, simulating the load a management point at a busy site might experience.
The System Center Configuration Manager 2007 Software Development Kit (SDK) includes a more general discussion of automating client actions and includes sample code in Visual Basic Script and C#. The relevant section in the SDK is in the chapter on “Configuration Manager Client Programming,” under “Configuration Manager Client Automation.” You can download the SDK from http://www.microsoft.com/downloads/details.aspx?FamilyID=064A995F-EF13-4200-81AD-E3AF6218EDCC&displaylang=en (or from Microsoft’s Download Center at www.microsoft.com/downloads; search for ConfigMgr 2007 SDK.)
The SMS Object Generator (smsobjen.exe) is a tool Microsoft provided to simulate various objects for load-testing various versions of SMS. The SMS Object Generator is included with the SMS 2.0 Resource Kit tools, which are part of the BackOffice Resource Kit, version 4.5. Microsoft has not updated this tool for Configuration Manager 2007, and testing shows some but not all functions of this tool work with ConfigMgr. The tool is able to generate data discovery records (DDRs), which you can use to populate the ConfigMgr database with simulated client systems. These objects appear as legacy clients. However, Configuration Manager will not successfully process the inventory data generated by the tool. This is not surprising because the inventory data format for legacy clients is not supported in ConfigMgr 2007. You can use the tool to simulate the following:
• Discovery data
• Inventory data (processed as bad inventory files)
• Status messages
Using this tool allows stress testing the server components used for processing discovery, inventory, and status messages. By creating objects at a child primary site, you can also generate a load for the components involved in replicating data to the parent site. Populating the database with a large number of simulated client systems also enables you to create large collections for stress testing the collection evaluator. Figure 7.4 shows the SMS Object Generator user interface for generating DDRs. Enter the path of the Discovery Data Manager inbox in the DDR path text box. In the default ConfigMgr installation, the path is C:Program FilesMicrosoft Configuration Managerinboxesddm.box. Chapter 3 discusses the inbox folders for various components.
The exit criteria for the POC should include completing all functional tests and stress tests and completion of required deliverables. Be sure to review any unresolved problems that occur during testing to determine whether they are “showstoppers” that prevent you from moving to the pilot phase before making adjustments. Potential showstoppers include issues that would seriously affect existing functionality in your live environment, compromise security, or prevent required functionality from working. You can note less serious issues as exceptions and continue to investigate them in the POC environment while moving forward with your pilot.
Here are the major deliverables of the POC:
• Updated project plans based on test results and adjustments.
• Detailed process documentation providing procedures for each required ConfigMgr task.
• Any configuration elements you plan to use in production, such as scripted installations, site settings files, and object definition files. Chapter 8 discusses scripted installations. The next two sections of this chapter describe procedures for creating and using site settings files and object definition files.
If you have customized any group policy objects to support ConfigMgr functionality, you will want to use the procedures described in the “Active Directory Considerations” section of this chapter to transfer these settings to production. Examples of group policy settings that you can use to support ConfigMgr functionality are client site assignment and BITS (Background Intelligent Transfer Service) settings. Client site assignment is discussed in Chapter 12, “Client Management,” and BITS settings are covered in Chapter 5.
Site settings files are XML (eXtensible Markup Language) files that can be used to reliably reproduce site configuration items such as site component configuration, client agent properties, and site maintenance tasks. To create a site settings file for use in production, perform the following steps:
- Open the Configuration Manager Console and then navigate to System Center Configuration Manager -> Site Database -> Site Management in the console.
- Right-click the site and choose Transfer Site Settings. This launches the Transfer Site Settings Wizard. On the Welcome screen shown in Figure 7.5, click Next.
- On the Gather Settings screen displayed in Figure 7.6, confirm that the Export settings and Site settings radio buttons are selected and then click Next.
- On the Select Source Site screen shown in Figure 7.7, check the box next to the site(s) you want to export settings from and then click Next.
- On the Select Site Settings screen shown in Figure 7.8, expand the tree control and check the boxes next to the settings you want to transfer. Checking the box at the top of the tree will select all site settings.
- Select Export or Transfer Settings from the navigation bar on the right side of the wizard. In the Export or Transfer Settings screen shown in Figure 7.9, make sure the Export settings for later use box is checked and enter the path for the destination XML file. Check the Include current values for each setting box and then click Next.
- Review the information in the Summary screen shown in Figure 7.10. After clicking Next, you will see a progress information screen, and a confirmation screen appears when the settings transfer completes. You can now copy the XML file to your production network and use the same wizard to import the settings on your production site.
On your production site, you will use the Transfer Site Settings Wizard again to import the site settings. At step 3 of the preceding process, choose the Import Settings option instead of Export settings, and browse to the saved XML file. The rest of the process is essentially the same. For more information on the Transfer Site Settings Wizard, see http://technet.microsoft.com/en-us/library/bb632809.aspx.
You may have noticed the option to export packages and collections on the Transfer Site Settings Wizard’s Gather Settings screen, shown earlier in Figure 7.6. Microsoft designed this option to transfer settings such as collection-refresh schedules and package priority from one object to another within your site. It does not provide a way to transfer packages and collections developed in your POC environment to production.
You can use the ConfigMgr console to export the definitions of certain objects as MOF (Managed Object Format) files that you can import into your production environment. You can export MOF definitions for instances of the following ConfigMgr object types from the console:
• Collections
• Queries
• Reports
To export objects’ definitions to MOF files, right-click the parent node, choose Export Objects, and complete the wizard to choose the instances to export, specify the file location, and enter descriptive text. You can use a similar process to import objects from MOF files.
Note
Which MOF Is It?
This chapter uses the acronym MOF for two things—the Microsoft Operations Framework and Managed Object Format files. Although it is confusing, both are valid.
If you’re planning to use Configuration Manager OSD, you will want to develop and test your images, task sequences, and driver packages in the POC environment. You can export and import task sequences as XML files from the ConfigMgr console. Other OSD objects can be copied manually in their native file formats and imported into the production environment. Similarly, if you will be using ConfigMgr software deployment, you will want to develop and test software packages in the POC environment. To avoid introducing possible errors by manually re-creating packages, you can use package definition files to create consistent packages in the POC and production environments.
Microsoft provides information about creating and using package definition files at http://technet.microsoft.com/en-us/library/bb693959.aspx. OSD and software distribution are discussed in Chapter 19, “Operating System Deployment,” and Chapter 14, “Distributing Packages,” respectively.
During the pilot phase, you will work with a small subset of the users and systems in your live environment. Unlike the POC, the pilot environment is intended to become a permanent part of the production deployment of your solution. Typically, a pilot deployment begins with a single ConfigMgr site. Client systems are selectively added to the pilot. Often the initial group of clients in your pilot consists of computers in the IT department or those whose users are known as technically savvy and willing to be early adopters of new technology. It is important to keep users informed of any changes during the pilot and solicit feedback on any unusual conditions the users might experience, such as error messages or performance impact.
If you have an existing SMS implementation, you must make sure that the boundaries of your pilot site(s) do not overlap with the boundaries of any existing SMS sites. To avoid overlapping boundaries, you may need to create dedicated IP subnets and/or AD sites for your pilot deployment.
One of the essential goals of the pilot is to monitor the impact ConfigMgr has on your production systems and your network. This will be much easier if you are using an enterprise monitoring tool such as Microsoft System Center Operations Manager (OpsMgr). If you have Operations Manager in place, you should use the Base OS management pack to capture baseline data on your pilot systems before deployment. You can then track and investigate any major changes in performance or event characteristics that may occur.
If you do not have access to an enterprise monitoring tool, you can use the Windows performance monitoring tools to capture performance data on your site systems and some client systems. Here are some of the performance counters providing a general snapshot of utilization of principal system resources:
• Memory: Available Bytes
• Memory: Pages/sec
• Network Interface: Bytes Total/sec
• Network Interface: Output Queue Length
• Physical Disk (each instance): % Disk Time
• Processor (total): % Processor Time
• System: Processor Queue Length
For procedures for capturing this data, refer to the Windows help files for the version of Windows you are using. Capture a baseline prior to ConfigMgr deployment and capture additional data after deployment. You should consider the impact of any major changes in average system resource utilization or peak utilization that may be associated with ConfigMgr activity such as inventory collection.
You should also use any available network traffic monitoring tools to gather baseline statistics on WAN and LAN utilization prior to the pilot deployment, and compare the baselines with monitoring data gathered during the pilot. Most organizations have network monitoring in place, which may be managed by a dedicated network support team. If you do not already have network monitoring tools, you can locate a variety of tools through sites such as http://www.monitortools.com/.
As part of the exit review for each phase, you should consider the results of that phase and make adjustments to optimize your solution. Review the results for failure conditions, network and system performance impact, and usability concerns. In the case of failure conditions, you will need to consider whether you can proceed to the next phase before correcting the issues identified in testing. You should document failures of noncritical functionality or occasional failures; however, these types of issues should not delay moving to the next deployment phase. Here are some examples of adjustments you might make based on the results of your POC and pilot deployments:
• Scheduling changes to reduce performance impact, such as randomizing the client inventory schedule to reduce spikes in network activity or server load. Conversely, you may find that you need to schedule inventory collection for off-peak hours to reduce the impact on end users.
• Modifying your hardware specifications to address performance problems found during testing.
• Adjusting your site hierarchy, sender configuration, and server placement should you find bandwidth utilization issues during testing. Chapter 5 discussed network design considerations.
• Identifying known errors and providing support staff with troubleshooting procedures and the training to address these errors.
• Altering user-facing functionality such as notification policies for software updates to meet the needs and preferences of your user community.
During the proof of concept and pilot phases, place special emphasis on testing and validating any customizations and integration points of your solution. You may also decide to try various custom extensions to Configuration Manager to add value to your solution. Members of the System Center Alliance, a Microsoft partner program, offer products that extend, enhance, and connect your ConfigMgr solution. Some of the ways in which applications from alliance partners may add value to your solution include the following:
• Extending Configuration Manager’s management capabilities to non-Windows systems such as Unix hosts and BlackBerry or Symbian mobile devices.
• Enhancing manageability through tools to help administrators with tasks such as software packaging and inventory customization. You can also enable end users with enhanced services such as self-service portals for requesting software packages.
• Connecting your ConfigMgr deployment with external systems such as an enterprise job scheduler or a federated CMDB. Coordinating your scheduled Configuration Manager tasks with other scheduled activity can help you better manage your enterprise. Similarly, the wealth of data that ConfigMgr gathers through inventory and discovery can provide the CMDB with detailed knowledge of your Windows environment.
Most major personal computer (PC) and server hardware vendors also provide inventory extensions that allow you to add vendor specific attributes, such as asset tag numbers, to ConfigMgr hardware inventory. Microsoft publishes a directory of System Center Alliance members at http://www.microsoft.com/systemcenter/en/us/alliance-members.aspx.
This book discusses various customizations you can make to Configuration Manager:
• Chapter 3 discusses the ConfigMgr SDK, which can be used to provide access to ConfigMgr data and functionality for external applications and scripts.
• Chapter 3 also describes how to customize hardware inventory by editing the SMS_def.mof and configuration.mof files.
• Chapter 10, “The Configuration Manager Console,” discusses customizing the Configuration Manager console.
• Chapter 18 presents customizations used in reporting.
• Chapter 19 discusses custom solutions with the task sequencer.
The proof of concept phase is a great time to look at these customizations and try them in your test environment.
This chapter discussed the process of testing and stabilizing your Configuration Manager design. It described the goals of a proof of concept, how to create a POC environment, and the type of testing you can do in the POC phase. It then discussed the role of a pilot phase in your live environment. Finally, the chapter looked at how to adjust your solution based on the results of your testing, and how to use the testing phase to explore and validate customizations to your design.
In the next chapter, you will see how to install your Configuration Manager hierarchy and configure your site systems and client agent settings.