IN THIS CHAPTER
As you may have already realized from reading Chapter 4, “Configuration Manager Solution Design,” and Chapter 5, “Network Design,” planning a Configuration Manager (ConfigMgr) implementation is a complex task. When it comes to architecture design planning, you will want to base your Configuration Manager design on your specific organization and the solutions you plan to deliver.
Decision points to consider regarding your environment incorporate information relating to a number of areas:
• The business dynamics of your solution
• Your business objectives
• The services and solutions you plan to deliver
• Geographic, language, and cultural considerations
• Organizational structure
• Your Information Technology (IT) environment
• Business, regulatory, and IT policies that govern operations
• Security requirements
• Administrative model
• Support considerations
• Your technical environment
This chapter focuses on infrastructure and solution delivery planning. To apply the material presented here effectively, you will need a good understanding of your environment and organization. The preplanning worksheets included with Configuration Manager product documentation (http://technet.microsoft.com/en-us/library/bb694080.aspx) provide an excellent vehicle for pulling together information about your environment. Here are some additional factors you should consider not specifically addressed in these worksheets:
• Regulatory compliance requirements affecting your organization
• Configuration management processes in place, especially if your organization has an enterprise Configuration Management Database (CMDB) with which you want to integrate data stored in Configuration Manager
• Release management processes that you may want to consider when planning for software distribution, software updates, and operating system (OS) deployment
• Enterprise storage architecture, particularly if you are considering a SAN back-end for software distribution files
• Enterprise services such as monitoring and backups that are necessary to support your Configuration Manager infrastructure
Microsoft’s planning worksheets (http://technet.microsoft.com/en-us/library/bb694186.aspx) are designed to help with your infrastructure planning. The material in this chapter dealing with infrastructure planning is intended to complement the planning worksheets.
The chapter gives emphasis to delivering the following solutions:
• Patch Management and Patch Compliance
• Mobile Device Management
• Internet-Based Client Management (IBCM)
• Operating System Deployment (OSD)
• Out of Band (OOB) Management
These features either are new to Configuration Manager 2007 or have changed substantially from Systems Management Server (SMS) 2003. Chapter 2, “Configuration Manager 2007 Overview,” presents a more extensive list of new or enhanced features. The features discussed in this chapter present special requirements that may affect your site and hierarchy planning. Proper planning can help you take advantage of these improvements more effectively.
Tip
Several chapters in this book discuss planning aspects. If you have not already, you will want to look at Chapters 4 and 5.
Once you have a good understanding of your objectives and environment, your first planning task is to design your Configuration Manager hierarchy. A hierarchy consists of one or more ConfigMgr sites, and potentially additional SMS 2003 sites. Although you can have more than one Configuration Manager hierarchy in your organization, you generally will want to organize all your sites into a single hierarchy.
Configuration Manager clients receive their policy from their assigned site. Within a site, client agents and other components share a common configuration. As an example, Remote Tools options are enabled on a per-site basis. The site therefore defines a natural administrative boundary for those clients that share configuration options and should be managed together.
Sites also align with geographic and network boundaries. Communications within a site require a high level of network services, whereas communications between sites can take advantage of scheduling, compression, and other optimizations for remote communications. Chapter 5 discusses intersite communications.
Each Configuration Manager site is identified by a unique three-character site code. Site codes can consist of upper- and lowercase letters and/or numeric digits. Be aware of the following restrictions when using site codes:
• Avoid using reserved names such as AUX, CON, NUL, PRN (see http://msdn.microsoft.com/en-us/library/aa365247.aspx for the list of reserved filenames), or SMS when choosing site codes.
• Avoid reusing site codes previously used in your Configuration Manager hierarchy. Site codes are stored in the site databases of other sites in the hierarchy and in some configurations are saved in Active Directory and WINS. If you were to reuse a site code, it is possible that all references to the old site were not removed completely or are reintroduced from a restored backup. This could cause problems resolving the site.
The site at the top of your hierarchy is the central site. In some cases, this may be the only site you need. Most large or geographically dispersed organizations will benefit from having additional sites. A simple hierarchy example is shown in Figure 6.1. This figure shows part of a proposed hierarchy design for the domain used in this book, SCCMUnleashed.com. Not all sites in that domain are shown in Figure 6.1, and some sites may be combined in the final design.
Figure 6.1. A possible three-tiered hierarchy for SCCMUnleashed.com sites in Europe and the Asia/Pacific (APAC) region
You may want to consider additional sites in the following instances:
• Locations are separated from other existing or planned sites by wide area network (WAN) links— Generally, a site should be within a well-connected region, such as a local area network (LAN) environment. To avoid managing an unnecessarily large number of sites, locations with small numbers of computers should generally be part of the existing site with the best connectivity.
• Groups of machines require different client agent settings— You will want to create a separate site for machines requiring different client agent settings, because client agent settings are configured on a per-site basis. It is possible to override sitewide settings on individual clients using local policy; however, this is not generally recommended because it makes troubleshooting more difficult.
• Support is required for down-level clients— If sites are in native mode, you may need a separate mixed mode site to support older clients, such as SMS 2003 Service Pack (SP) 3 clients. Native mode and mixed mode are discussed in the “Planning for Site Security Modes” section of this chapter.
• Multilingual requirements— Locations that will be using different language versions of the Configuration Manager client and server software should generally be separate sites.
• Scalability considerations— Regardless of other considerations, very large organizations will need multiple sites for scalability reasons. The maximum number of clients supported by a single site is 100,000.
The best practice for multisite hierarchies is to have a central site with no clients other than the site server itself. All sites other than the central site are joined to a parent site. Each site may have only one parent site but may have more than one child site.
ConfigMgr 2007 can incorporate primary and secondary sites in a hierarchy. A primary site is a site with its own SQL Server database. Primary sites can have secondary sites or other primary sites as child sites. Configuration Manager clients are assigned to primary sites, and they receive policy from their assigned sites. Secondary sites are used at remote locations to provide Configuration Manager services locally to clients assigned to primary sites in the hierarchy. Secondary sites cannot have child sites and they do not have clients assigned to them. Secondary sites are administered from their parent site.
You may decide to add primary sites for the following reasons:
• Administrative advantages— Each client is assigned to a primary site. Clients receive policies, including client agent settings, from their assigned site. If your clients need different client agent settings than those at the parent site, you may choose to deploy an additional primary site. Secondary sites are administered though their parent site. Delegating administrative privilege to local personnel, such as the ability to distribute software at the site, is simpler at a primary site than a secondary site.
• Hierarchy advantages— You can disjoin a primary site from its parent site and join it to a different site, but you must reinstall a secondary site to move it in the hierarchy. This is important if your organizational structure frequently changes due to office closures and relocations, mergers and divestitures, and so forth. A primary site can also have child sites; secondary sites cannot.
• Scalability advantages— With proper design, a primary site can support over 100,000 clients. A secondary site can support around 1,000 clients.
You may decide to use a secondary site based on the following considerations:
• No need to install and support SQL Server— Primary sites require access to Microsoft SQL Server to access the ConfigMgr database. Unless you already have a SQL Server installation at a primary site, you will need to install SQL Server either on the site server or on a separate server. In either case, this will require additional hardware resources and support efforts.
• Licensing costs— Currently, secondary sites do not require a Configuration Manager 2007 server license or a SQL Server license. Of course, all site systems require a Windows Server license. Chapter 4 includes a discussion of ConfigMgr licensing.
A consistent principle in Configuration Manager is that a parent site must be at least as advanced in its software version and configuration as its child sites. This is true in terms of both code version and security mode. As an example, a Configuration Manager 2007 SP 1 site can have a child site without SP 1, but could not report to a parent site without SP 1. A Configuration Manager site can have SMS 2003 SP 2 or higher child sites, but cannot have an SMS 2003 parent site. Similarly, a native mode site can have a mixed mode child site, but not vice versa. Figure 6.2 shows some possible parent/child relationships that are allowed and others that are not allowed.
You should plan your hierarchy such that upgrades, service packs, and other enhancements can be easily applied, starting from the central site and then proceeding down the hierarchy. You should also consider capacity, bandwidth, and latency issues when deciding how to structure your hierarchy. Figure 6.3 shows an alternate hierarchy for the same sites previously shown in Figure 6.1.
Figure 6.3. A possible two-tiered hierarchy for SCCMUnleashed.com sites in Europe and the APAC region
The flatter hierarchy displayed in Figure 6.3 has the following advantages:
• Less processing and storage capacity is required in the Beijing (BEJ) and Brussels (BXL) primary sites. With the original hierarchy design, these sites have to process communications and store data from their child sites as well as from local clients.
• Network communications between the central site and the Amsterdam (AMS), Katmandu (KAT), and Mumbai (MUM) sites as configured in Figure 6 will introduce additional latency because of the need to send data through an intermediate site. This is particularly true if sender scheduling limits the hours for sending certain data. Chapter 5 discusses latency issues.
• Overall bandwidth consumption may be lower because communications between the central site and the AMS, KAT, and MUM sites can take the optimum network route, rather than necessarily going through the intermediate primary site. As an example, if your sites are connected through a Multi Protocol Label Switching (MPLS) cloud, traffic between a site and its direct child site requires one trip through the cloud, whereas an intermediate site will store and forward data, which requires an additional trip.
• The impact of a site or communications failure affecting the BEJ or BXL site is limited to that site. Site recovery at those sites will be considerably simpler in this model. See Chapter 21, “Backup, Recovery, and Maintenance,” for a discussion of site recovery.
• Future restructuring may be easier. As an example, if Beijing were part of a divestiture or office closing, the Katmandu site would not need to be reinstalled in the flat hierarchy model.
• Legal requirements such as export controls may prohibit certain software or data from traversing certain intermediate sites.
The more structured design in Figure 6.1 also has some advantages:
• Software packages, software updates, and operating system images can be distributed using a fan-out mechanism, which reduces the workload of the initiating site and the network link between the initiating site and other sites. For example, a package needed at the BEJ, KAT, and MUM sites can be copied once across the link from the central site to Beijing, and then copied from Beijing to Katmandu and Mumbai. This example uses a central site in North America, and Beijing, Katmandu, and Mumbai are in the Asia/Pacific region. This is an important consideration because the WAN links from the central site to the APAC sites have less available bandwidth than the connections within the APAC region.
• Administrators in the APAC region can connect to the BEJ site to administer the KAT secondary site rather than needing to connect to the central site. Similarly, administrators in Europe can administer the AMS secondary site through BXL. Although a relatively flat hierarchy is generally recommended, it may make sense to introduce additional layers into the hierarchy if several sites are in a region that is remote from your central site.
Using SMSMap to Document Your Hierarchy
SMSMap (described at http://technet.microsoft.com/en-us/magazine/cc137998.aspx) is a freeware utility you can use to automatically generate Visio drawings of ConfigMgr 2007 and SMS 2003 sites and site servers. You can run SMSMap from any machine with Microsoft Visio installed. Here are some key points:
• As shown in Figure 6.4, you can enter credentials for an account with at least read access to your Configuration Manager site database and connect to any primary site server.
• To map your entire hierarchy, connect to the central site. The utility gives you a choice of six layout designs; the Options tab, shown in Figure 6.5, allows you to specify the level of site detail to gather. The program will automatically generate a map showing your site servers and the other details you specify. Once you save the drawing, you can edit it in Visio to suit your preferences.
Jeff Tondt, a Senior Consultant for Microsoft Consulting Services, developed SMSMap, which is available at http://www.tondtware.com/downloads.html. Microsoft TechNet magazine took an in-depth look at this valuable utility in July 2007 (http://technet.microsoft.com/en-us/magazine/cc137998.aspx). Several enhancements have been added since that article was written, including support for Configuration Manager.
After defining some (or all) of your primary and secondary sites, you can begin to plan the site infrastructure and services at each site. The major tasks involved in site planning include determining the site systems to deploy, sizing the hardware for each site system, and determining the boundaries and security mode for the site. These areas are discussed in the next sections.
The server infrastructure is the foundation of your site. The following sections present key issues to consider as you decide how to distribute system roles among servers as well as specifications for server hardware.
The minimum server requirement for a Configuration Manager site is a single site server. The site server can be configured for all the site system roles deployed at your site, or you can assign some roles to additional servers. Here are some reasons for assigning site system roles to servers other than the site server:
• Network topology— For sites that span WAN links, you will generally want to make distribution points available at each physical location.
• Security— You may want to move client-facing roles such as the management point (MP), distribution point (DP), and software update point (SUP) off the site server to prevent clients from accessing the site server directly. You will definitely want to do this if you support Internet clients, in which case you would deploy those servers accessible from the Internet in a DMZ (demilitarized zone).
• Scalability— For large sites you may want to distribute the computing load between multiple systems. For very large sites, you may need to use Network Load Balancing (NLB) clusters with certain site systems. Chapter 4 includes a discussion of configuring site systems in large sites. You can also configure the management point and server locator point to use a replica of the site database. Using a SQL replica distributes the load across multiple servers, but introduces replication latency, which increases the time for updates to become available to client systems. See http://technet.microsoft.com/en-us/library/bb693697.aspx for a description of configuring SQL replication for Configuration Manager.
• Management— In general, you will get sufficient performance if you install SQL Server on your primary site servers and keep the Configuration Manager database local on the site server, provided the site server has adequate hardware resources. Many organizations have SQL database servers already deployed and supported by database administrators. In this case, it may make sense to move the site database to one of these servers, particularly if that will enable you to take advantage of SQL Server clustering and use 64-bit SQL Server editions.
SQL Server is the only site system that supports failover clustering, and it’s the only ConfigMgr role that Microsoft recommends running on the 64-bit versions of Windows. Configuration Manager is a database-intensive application. If the database is not on the site server, it is essential to have very good connectivity between the site server and the SQL Server system.
Table 6.1 displays the minimum requirements for Configuration Manager 2007 site systems.
As with any Windows installation, Microsoft only supports hardware components listed on the Windows Hardware Compatibility List (HCL). The HCL for each Windows version is located at http://www.microsoft.com/whdc/hcl/default.mspx. For maximum supportability, it is best to use hardware bearing the Windows Server Hardware logo. Information about Windows logo certified hardware is available in the Windows Server catalog, at http://go.microsoft.com/fwlink/?LinkID=80785.
Other installation requirements include the following:
• All site systems must be belong to a Windows 2000, Windows 2003, or Windows Server 2008 Active Directory domain. With the exception of the site database server, Microsoft does not support installing Configuration Manager 2007 site servers or any other site systems on a Windows Server cluster instance. Computers that are physical nodes of a Windows Server cluster instance can be managed as Configuration Manager 2007 clients.
• Using a Storage Area Network (SAN) is supported as long as a supported Windows server is attached directly to the volume hosted by the SAN.
Install the site database on the default instance or a named instance of SQL Server, using SQL Server 2005 Service Pack 2 or greater. You can also configure the instance used to host the site database as a SQL Server failover cluster instance.
Configuration Manager 2007 R2 introduces three new site system roles:
• Client Status Reporting Host System
• Distribution Point for Application Virtualization
• Reporting Services Point
The Client Status Reporting Host System role is supported on all versions of Windows Server 2003 SP 1 and above, Windows Server 2008, and on client operating systems (including Windows XP Service Pack 2 or higher, excluding consumer editions). The Reporting Services Point and Distribution Point for Application Virtualization roles are supported on Standard and Enterprise editions of Windows Server 2003 (SP 2 or higher) and Windows Server 2008. The Reporting Services Point role is also supported on the Datacenter editions of Windows Server.
The placement of distribution points (DPs) is especially important in site planning. DPs are generally implemented in the following manner:
• One or more standard (unprotected) DPs at the primary network location of the site. Additional distribution points will provide load balancing and redundancy. Clients at the central location and clients not assigned to a protected distribution point will use these unprotected DPs.
• Protected distribution points at remote locations with adequate server infrastructure.
• Branch DPs at smaller locations without server infrastructure. You may also choose to use a branch DP to take advantage of Background Intelligent Transfer Service (BITS) transfers across the WAN and on-demand package deployment.
Chapter 5 discusses network considerations around the placement of distribution points at remote locations. Distribution point management is discussed in Chapter 14, “Distributing Packages.”
Both distribution points and software update points may require substantial storage. Storage requirements for distribution points depend on the number and size of software packages and OS images they host. The “Software Update Planning” section of this chapter discusses storage considerations for software update points.
Heavily used distribution points and software update points will handle a large amount of network traffic; you will want to provision them with the fastest network card your network infrastructure supports.
The minimum/published (“box”) hardware specs are far below what you should consider for anything more than a small lab environment. A typical site server for a moderately sized site with 1,000–5,000 clients might have two to four quad core processors and 4GB–8GB of RAM. Because Configuration Manager 2007 is a 32-bit application, Microsoft recommends running it on a 32-bit version of Windows Server for best performance. SQL Server fully supports 64-bit computing, and performs best on a 64-bit platform.
If you use System Center Operations Manager (OpsMgr) to monitor your environment and are considering deploying Configuration Manager on a 64-bit server OS, you should review the information presented at http://wmug.co.uk/blogs/cliffs_blog/archive/2009/02/14/configmgr-monitoring-configmgr-2007-with-operations-manager-2007-in-a-64-bit-environment.aspx. The issue Cliff Hobbs discusses is that the ConfigMgr client is 32-bit only, so its performance counters are only captured by the 32-bit OpsMgr agent. However, because the OS is 64 bit, this means performance counters are only captured by a 64-bit OpsMgr agent—and you can’t install both versions of the agent on a single system.
Similar considerations may apply to other monitoring applications. ConfigMgr 2007 Service Pack 2 will add native 64-bit performance counters to the ConfigMgr client, so it can be monitored along with the OS and other 64-bit applications using a 64-bit Operations Manager agent. Chapter 2 includes a discussion of the planned service pack. Using Operations Manager to monitor Configuration Manager is discussed in Chapter 21.
Note
About Addressable Memory for 32-bit Windows
To utilize more than 4GB of physical memory on a 32-bit Windows version, you must use the Enterprise or Datacenter Edition and enable the Physical Address Extension (PAE) feature. For more information about memory support of Windows Server versions, see http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx. For information about PAE, see http://msdn.microsoft.com/en-us/library/aa366796(VS.85).aspx.
Configuration Manager is an I/O-intensive application, and it will benefit from the fastest disk subsystem you can provide. Here are some points to keep in mind:
• The volume on which you install Configuration Manager and the volume containing the site database will experience the heaviest disk utilization. For best performance using local storage, install Configuration Manager on a separate array from the OS and other applications, using a separate controller if available.
• If you install SQL Server locally on the site server, you should also consider separate disk arrays for the SQL Server application and the SQL log files. Corporate standards may specify the RAID (redundant array of independent disks) levels for the OS and application partitions.
Chapter 4 includes specifics on server configuration and disk placement for several site designs. Table 6.2 lists a representative storage configuration for an all-in-one site server.
Microsoft describes the different RAID types in an article at http://technet2.microsoft.com/windowsserver/en/library/cb871b6c-8ce7-4eb7-9aba-52b36e31d2a11033.mspx?mfr=true. For optimal performance, implement all RAID arrays at the hardware level. For details on implementing hardware-based RAID, consult the documentation from your hardware vendor. If using SAN storage, you should install Configuration Manager on a dedicated Logical Unit Number (LUN), if available.
Note
About Deploying Site Systems on Virtual Machines
All Configuration Manager 2007 site server roles are supported on virtual machines running the appropriate Windows Server versions as guest operating systems on a Microsoft Virtual Server 2005 R2 host with or without SP 1. Hyper-V is also supported, and Cliff Hobbs has an excellent article on migrating your virtual machines to Hyper-V at http://wmug.co.uk/blogs/cliffs_blog/archive/2009/02/10/hyper-v-how-to-migrate-vms-to-hyper-v.aspx.
It is important to review Microsoft’s support policy before deploying any ConfigMgr site system roles to Windows Server systems running on other virtualization platforms such as VMware. There is anecdotal evidence that Configuration Manager has been successfully deployed on VMware ESX; however, Microsoft does not guarantee to fully support software running on any non-Microsoft virtualization technology. You should read and consider Microsoft’s “Support policy for Microsoft software running in non-Microsoft hardware virtualization software” (http://support.microsoft.com/kb/897615) before deploying any Microsoft software on non-Microsoft virtualization platforms. Virtualization platforms listed in the Server Virtualization Validation Program (SVVP) are supported for all site system roles, subject to the terms of that program. For more information about SVVP, see http://go.microsoft.com/fwlink/?LinkId=134672.
In general, demanding applications such as a site server or a SQL Server database for a large primary site are not good candidates for virtualization. In this context, a site with more than 1,000 clients reporting to it, including clients at child sites, is a poor candidate for a virtualized site server. The authors have seen instances where even a virtualized site server at a site with a few hundred clients may present problems.
Disk defragmentation should be run on a regular basis. It is also important to use a consistent SMS_Def.mof file throughout your hierarchy to allow multithreaded processing of hardware inventory data. For more information about the SMS_Def.mof file, see Chapter 12, “Client Management.”
For a detailed discussion of choosing, tuning, and benchmarking hardware, check the following references:
• For Windows Server 2003, see http://download.microsoft.com/download/2/8/0/2800a518-7ac6-4aac-bd85-74d2c52e1ec6/tuning.doc.
• The Windows Server 2008 version is located at http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Perf-tun-srv.docx.
To avoid performance degradation, establish appropriate virus-scanning exclusions for all inboxes on the site server. The individual inboxes are subfolders of the inboxes folder (%ProgramFiles%Microsoft Configuration ManagerInboxes by default) with .box folder names. Some enterprise antivirus products are capable of applying exclusions selectively to certain processes. In this case, the Configuration Manager processes listed in Chapter 3, “Looking Inside Configuration Manager,” should be listed as low-risk processes for access to the inbox folders. You should also consider virus-scanning exclusions for the following areas:
• All server and client log files
• The client cache folders and WMI (Windows Management Instrumentation) folders
• All SQL Server databases and transaction logs
• Site backup files and volume shadow copy files
Chapter 20, “Security and Delegation in Configuration Manager 2007,” discusses virus-scanning exclusions in more detail.
Very large sites, especially those with 25,000 or more clients, have some special considerations to include in your planning. Chapter 4 discusses this in detail. You may also want to check Microsoft’s documentation at http://technet.microsoft.com/en-us/library/bb932180.aspx.
Configuration Manager clients use site boundaries for two purposes:
• Automatic client assignment during installation.
• Locating services during normal operations. (For more information about client assignment and service location, see Chapter 12.)
It is important to plan and maintain site boundaries that are appropriate to your network topology and do not overlap. Overlapping boundaries will cause problems for Configuration Manager clients.
Automatic site assignment can have unpredictable results when a client is located within the boundaries of more than one site. Overlapping boundaries will also cause problems with software distribution. Clients access content from the distribution points of the site in which they currently reside; having conflicting site boundaries can result in the client failing to locate available content or downloading content from an inappropriate location. You can specify boundaries by Active Directory (AD) sites, Internet Protocol (IP) subnets, IP address ranges, or IPv6 prefixes.
Each Configuration Manager site can be in one of two security modes—native or mixed mode. Here are some reasons you may choose to use native mode:
• Native mode sites use mutual, certificate-based authentication between site systems and between clients and servers. Native mode also provides advanced encryption and signing for secure exchanges. This is the most secure option for a Configuration Manager site.
• Native mode is required for Internet-based client support.
Here are some reasons to choose to use mixed mode:
• Native mode requires a properly implemented Public Key Infrastructure (PKI). PKI design, testing, and implementation involve a major organizational investment and require proper planning. Your PKI deployment should take into account other applications and requirements you may have in addition to your Configuration Manager requirements. Chapter 11, “Related Technologies and References,” includes a discussion of PKI.
• Mixed mode sites support SMS 2003 (SP 3 or higher clients), as well as Windows 2000 clients. Native mode sites do not support these older clients.
• Your organization requires WINS (Windows Internet Name Service) for clients to locate their default management point. Chapter 5 explains the reasons you may need to use WINS.
All software is subject to possible bugs or design flaws that may introduce security vulnerabilities or other defects into your environment. Software vendors, including Microsoft, regularly release updates, or patches, to their software to address these problems. Software updates may also introduce new or enhanced functionality to software products. Testing software updates and deploying them to a large number of systems in a timely manner is an increasingly important challenge for all IT organizations.
The next sections present an overview of how Configuration Manager components can work together to support your enterprise patch management requirements. They also discuss the infrastructure requirements for Configuration Manager patch management. Chapter 15, “Patch Management,” provides detailed guidance on using ConfigMgr software update functionality.
Patch management is a vital component of an enterprise security policy. The average time from the publication of a vulnerability to the appearance of an exploit has gone from several months in the 1990s to just several days. Zero-day exploits, which appear before a patch is released, are increasingly common. You should therefore plan for both standard releases and emergency releases of software updates.
To test patches prior to production implementation, create test collections of machines with a representative cross-section of your hardware and software configurations. Your test plan should include procedures to deploy updates to test collections and monitor both the deployment process and the impact on test machines.
Note
About the Risk of Delaying Software Updates
Some organizations, including at least one branch of the U.S. armed forces, have determined that the risk for them of postponing patches even briefly outweighs the risk of deploying untested patches. For this reason, they immediately push all newly released patches. You need to carefully evaluate what is right for your security and availability needs.
In addition to the Software Updates capability integrated into Configuration Manager, the following Configuration Manager features are available to support a good patch management and patch compliance solution:
• Collections— In addition to test collections, you should create and maintain collections for systems that have special considerations for software updates. For example, you may decide to handle software updates to a collection of systems in scope for Sarbanes-Oxley Act (SOX) or HIPAA controls differently due to change control requirements.
• Reports— Chapter 18, “Reporting,” shows some examples of how Configuration Manager reporting capabilities can provide visibility into patch management and compliance.
• Maintenance Windows— A new feature of Configuration Manager—maintenance windows—gives you the ability to specify times during which Configuration Manager will apply changes to systems. If a system belongs to a collection with defined maintenance windows, then software updates, operating system (OS) deployments, and software distribution are suppressed during times that fall outside a maintenance window. For emergency deployments, distributions can be set to ignore maintenance windows.
• Wake On LAN and Intel Active Management Technology (AMT)— These features allow you to send software updates, advertisements, and OS deployments to systems that are online but powered down. You should consider deploying these services to support your Software Updates solution.
The “Out of Band (OOB) Management Planning” section of this chapter discusses Wake On LAN and AMT.
Your patch management solution should also integrate with the following IT processes:
• Change management— Deploying software updates on a scheduled or emergency basis should be subject to the controls of your change management process. The use of maintenance windows makes it simpler for you to comply with many change management policies.
• Configuration management and release management— Inputs from these two processes should help you to systematically identify vulnerabilities that may apply to your environment. They can also help you identify baselines against which patches need to be tested and to determine which systems and software store and process regulated data.
• Security risk management— Prioritizing risks and maintaining and staying current with known vulnerabilities and exploits are essential to effective patch management practices. An effective security risk management program will also help in identifying mitigating factors that may allow some patches to be deferred until regular maintenance or the release of a new build.
Each Configuration Manager primary site that provides software update services to clients must have an active SUP. ConfigMgr clients use the active SUP as follows:
• The client system connects to the SUP to run vulnerability scans.
• The client then retrieves any required patches from the distribution point and applies the patches to the client system.
The SUP is an optional system role in a secondary site. If a secondary site does not have an active SUP, clients residing in the boundaries of the site will use the SUP at the parent site. The advantage of configuring an active SUP at a secondary site is that it reduces network bandwidth consumption on the link between the site and its parent. The SUP system role is configured on a server with WSUS 3.0 installed.
The active SUP at the central site synchronizes with the Microsoft Updates Internet site. The active SUP in every other site synchronizes with the active SUP at its parent site.
Intranet clients run vulnerability scans from the active SUP at their local site. If the site is in native mode and the active SUP is accessible from the Internet, you can configure the active SUP to accept connections from clients on the Internet as well as intranet clients. If your active SUP does not accept Internet connections, you can configure a separate Internet-based SUP. Internet-based SUPs at secondary sites are not supported and do not work, although the user interface allows you to configure them. Figure 6.6 shows some options for Software Updates synchronization and client support.
In Figure 6.6, the active SUP for the Brussels (BXL) primary site is configured to accept both Internet and intranet access. Katmandu does not have an active SUP, so clients synchronize with the parent site. The LAB site shown is a separate hierarchy on an isolated network. Software updates are exported to an external hard drive and imported in the lab.
Note
About Environments with Standalone WSUS
Do not configure the WSUS functionality on your SUP outside of ConfigMgr. ConfigMgr will overwrite any settings configured in WSUS. You also should remove any group policy for WSUS that might affect ConfigMgr clients. Clients with WSUS settings established by group policy cannot be managed by ConfigMgr software updates. For additional information about software updates and WSUS, see Chapter 15.
The storage requirements for software update points depend on the software update point component properties. You choose which products, classifications, and languages to support:
• Currently supported products include all supported versions of Windows (Windows 2000 and higher), Microsoft Office products, server products such as Exchange, ISA, and SQL Server, and Microsoft security products. Microsoft does not currently provide updates for third-party products as part of the catalog. Independent software vendors and application developers can use the System Center Updates Publisher (SCUP) to integrate their updates with ConfigMgr. For information about SCUP, go to the Microsoft Downloads Center (http://www.microsoft.com/downloads) and search for System Center Updates Publisher (SCUP) 4.0.
• Here are the classifications:
• Critical Updates (non-security-related patches fixing major defects)
• Definition Updates (for items such as virus signatures)
• Drivers
• Feature Packs (for new or enhanced functionality)
• Security Updates
• Service Packs (major rollups with full regression testing)
• Tools
• Update Rollups (combine multiple fixes with basic regression testing)
• Updates (all other non-security fixes)
• Approximately 25 language versions are available
Note
About Managing Malware Signature Files
The minimum synchronization time for ConfigMgr software updates is 24 hours. The 24-hour time period is not suitable for virus definition files and similar updates required by anti-malware programs, because these files may need to be updated on a more urgent basis. ConfigMgr Software Updates is therefore not a supported solution for managing signature files for Forefront Client Security and other anti-malware products.
An alternative to configuring an SUP to participate in a synchronization hierarchy is scheduling or manually initiating export and import operations using the WSUSutil utility. See http://technet.microsoft.com/en-us/library/bb680473.aspx for procedures to synchronize updates using WSUSutil. You might choose to use WSUSutil to synchronize software update points in an isolated lab without network connectivity, or to take advantage of third-party replication tools in a SAN environment.
The proliferation of smartphones, PDAs, and other mobile devices presents a wide range of challenges and opportunities to IT organizations. Applications on these devices, along with access to corporate email, instant messaging, and line-of-business applications, are vital to the productivity of an increasingly mobile workforce. Devices such as point-of-sale systems and RFID scanners play business critical roles in many enterprises. To effectively deploy and support mobile devices, it is essential to implement device configuration standards, efficiently install applications to those devices, and secure both data on the devices and connections into the enterprise network.
A number of point products (products providing a solution to a single problem) exist for mobile device management. Using Configuration Manager for device management has several advantages over using a separate device management solution:
• You can leverage the same infrastructure you have deployed, licensed, and supported for computer management.
• Device data will be integrated into your Configuration Manager database.
• Configuration Manager enables you to use a consistent approach for managing all systems.
Configuration Manager 2007 device management extends a subset of ConfigMgr client services to a variety of mobile devices running the Windows Mobile and Windows Embedded CE operating systems. A complete list of supported versions is located at http://technet.microsoft.com/en-us/library/bb693782.aspx. The R2 release adds support for Windows Mobile 6.1.
Some point products offer a more extensive set of device management features than Configuration Manager provides, and they support a more extensive array of devices. You should consider the range of devices you need to support and your management needs, as well as cost, in deciding on a device management solution.
Using Configuration Manager for device management provides several benefits:
• Hardware and software inventory supply data about the mobile devices you support and the applications installed on those devices:
• Although hardware inventory on PCs relies on configuration data exposed through WMI, because mobile devices do not support WMI, this limits the information you can collect. Basic device information gathered includes CPU, device name and ID, memory, phone number, user, and OS details. This is essential data for targeting software distribution and asset management.
• Software inventory is similar to software inventory for PC clients.
• File collection allows you to back up files from mobile devices and acquire file-based data from mobile devices for use in enterprise systems. Typical file collection tasks include centralizing contact information and acquiring data stored in files on embedded systems.
• Software distribution enables you to deploy Windows Mobile, Windows CE, and Pocket PC–based applications needed by mobile workers.
• Mobile device configuration items allow you to enforce options such as device locking and password options on mobile devices in your enterprise.
In the early 1990s, Microsoft undertook two innovative but unsuccessful attempts to create Windows-based handheld devices. In 1994, Microsoft combined the development teams to form the Windows CE team. Two years later, Microsoft released the first version of Windows CE for the then nascent PDA market. The Windows CE kernel is not based on the Windows kernel, but is designed to provide Windows-like functionality with minimal computing resources.
Over the years a variety of operating systems and devices based on the CE kernel have been released under brands such as Windows CE, Palm PC, Pocket PC, Smartphone, and Windows Mobile. Today’s Windows CE core supports component-based, embedded, real-time operating systems requiring minimal storage.
Two distinct families of operating systems are now based on Windows CE technology:
• Windows Mobile family— Designed for smartphones and PDAs
• Windows Embedded CE— Used in a wide variety of embedded applications.
For more information on Windows Mobile, see http://www.microsoft.com/Windowsmobile/default.mspx. For additional information on Windows Embedded CE, see http://www.microsoft.com/windows/embedded/products/windowsce/default.mspx.
Mobile devices communicate with site systems through the HTTP/HTTPS protocol. A Configuration Manager site must be in native security mode to manage Internet-based mobile devices. Mobile devices connected through a VPN gateway can receive services from mixed mode sites; however, this configuration requires configuring Internet Information Services (IIS) for anonymous access on the distribution point.
Three Configuration Manager site systems communicate directly with mobile devices:
• Mobile Device Management Point (MDMP)— Mobile devices receive policy from the MDMP and send inventory, state, and status messages as well as collected files to the MDMP. Before configuring an MDMP, first configure the server as a management point and have IIS installed with BITS and WebDAV (Web-based Distributed Authoring and Versioning) enabled. To enable a management point for device support, check the Allow devices to use this management point box on the management point’s properties page, as shown in Figure 6.7.
This page is located in the Configuration Manager console under System Center Configuration Manager -> Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Site System -> <Site System>.
• Distribution Point— Mobile devices download content from distribution points, much like standard clients. To support mobile devices, a distribution point must have the Allow clients to transfer content from this distribution point using BITS, HTTP, and HTTPS option enabled. In addition, if the site is in mixed mode, you must enable the Allow clients to connect anonymously option for device support. Enable these options on the General tab of the distribution point’s properties page, displayed in Figure 6.8.
To access this page, navigate to System Center Configuration Manager -> Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Site System -> <Site System> in the Configuration Manager console. Although you must enable BITS on the distribution point, devices do not actually use BITS to download content.
• Fallback Status Point (FSP)— A mobile device can contact an FSP to report status if it is unable to contact its management point.
Just as the Configuration Manager client must be installed on managed computers, client software must be installed on mobile devices before they can receive Configuration Manager services. The options available to install the mobile device client depend on whether or not your devices synchronize with a PC through Mobile Device Center for Windows Vista or use ActiveSync for Windows XP.
Tip
About Windows Device Synchronization Technologies
For more information about Mobile Device Center and ActiveSync, see http://go.microsoft.com/fwlink/?LinkId=81724.
Using Mobile Device Center or ActiveSync simplifies the installation process via a platform-agnostic installation folder. The client installation program (DMClientXfer.exe) on the synching PC will automatically select and install the correct version of the mobile client for the OS on the device. To distribute the mobile device client to a device that synchronizes with a PC, the following options are available:
• You can copy the installation folder to the PC and manually run DMClientXfer.exe from the connected device.
• If the PC is a Configuration Manager client, you can use software distribution to deploy an advertisement to the PC, which will automatically initiate setup when the device synchronizes.
For those devices that do not synchronize with a PC though Mobile Device Center or ActiveSync, you will need to create a platform-specific installation folder with the correct versions of the setup files. You then place the folder on a location that is accessible to the device, such as a memory card or network share. You can initiate the platform-specific setup program (DMInstaller <platform type>.exe) manually from the device. Regardless of the installation method used, the installation folder must contain the following items in addition to the client setup files:
• The mobile client settings file, DMCommonInstaller.ini, for installations through a Mobile Device Center or ActiveSync-connected PC, or ClientSettings.ini for other installations. The settings file contains installation options, information needed to contact the Configuration Manager site, certificate metadata, and other information.
• Any required certificates for native or server authentication mode.
For detailed mobile client deployment procedures, see http://technet.microsoft.com/en-us/library/bb680634.aspx.
After installing the client, you can send upgrades over the air using ConfigMgr’s software distribution functionality.
The Mobile Device Client Agent settings control the schedule, options for policy downloads, and inventory. You can configure these settings on the properties page under System Center Configuration Manager -> Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Client Agents -> Device Client Agent in the ConfigMgr console. Figure 6.9 shows the default settings for the General tab of the client agent properties page, which controls the policy download schedule and retry settings.
Figure 6.10 shows how to enable file collection and collect all files with the .log extension. The remaining tabs are used to enable or disable hardware and software inventory and software distribution, and to set the frequency of hardware inventory.
Most organizations have users working from home or remote offices without a direct connection to the enterprise network. Mobile workers will also use laptops at locations that are on the network and at remote locations. In other cases, systems such as kiosk computers or point-of-sale systems require remote management. As long as these computers have a connection to the Internet, Configuration Manager provides two options for managing them, using either a Virtual Private Network (VPN) or Internet-Based Client Management (IBCM), as discussed in the next sections.
SMS 2003 and earlier versions required a VPN connection to manage computers without a direct physical connection to your enterprise network. To establish a VPN connection, client computers or other devices authenticate with a gateway on your network across an unsecure network, generally the Internet. Once the client is authenticated, it establishes an encrypted session (or tunnel) through which private communications can take place. You can use VPN connections to support all Configuration Manager 2007 features.
Configuration Manager 2007 provides a new capability called IBCM, which allows you to deliver certain services directly over the Internet without requiring a VPN connection. VPN services require a significant investment in infrastructure and support. Even if you have a VPN in place and available to all client systems, there are reasons why it may not be an ideal vehicle for delivering Configuration Manager services:
• Client systems must make an additional connection to the gateway.
• Challenges in managing the VPN address space as part of your site boundaries.
However, depending on your business requirements and existing infrastructure, a VPN-based solution may be the best way to manage computers that must connect through the Internet. VPN supports all of Configuration Manager’s features, whereas IBCM supports only a subset. IBCM also requires a PKI deployment and in most configurations requires deploying an additional server. You should consider the capabilities of both solutions when deciding how to meet the needs of your Internet-based clients.
IBCM supports the following Configuration Manager features:
• Hardware and software inventory, including file collection
• State and status reporting
• Software Distribution
• Software Updates
• Software Metering
IBCM does not support other Configuration Manager features such as client deployment, OSD, Remote Tools, and Network Access Protection (NAP).
Sites supporting Internet-based clients must be primary sites in native mode with certificates deployed to servers and clients. See the “Certificate Requirements Planning” section of this chapter for a discussion of certificate requirements planning. The systems that directly support Internet-based clients must be accessible from the Internet via HTTP/HTTPS (complete firewall requirements are provided at http://technet.microsoft.com/en-us/library/bb633122.aspx). Systems that may provide services for Internet clients include the following:
• Management point— This is the only required role, providing policy to clients and receiving inventory, state, status, and other data from clients.
• Distribution points— One or more standard distribution points are required for software deployment. These distribution points must be site systems rather than server shares. Internet-facing branch distribution points are not supported.
• Fallback status point— The FSP is recommended to allow clients that are having problems contacting the management point to report status to the site.
• Software update point— The SUP is required for software updates.
Chapter 2 previously introduced these site systems.
Each of these systems require configuration to accept connections from the Internet, and the site system properties must include a Fully Qualified Domain Name (FQDN) that is resolvable from the Internet. Internet-facing site systems cannot be protected site systems.
For security reasons, systems accessible to Internet-based clients should always be deployed in a DMZ (generally referred to in the product documentation as a perimeter network). Microsoft supports several scenarios for site and server placement:
• A site that does not support intranet clients and spans the perimeter network and intranet. The site server is in the intranet. All Internet-based site systems are in the perimeter network and accept connections for clients connecting over the Internet.
• A site that does not support intranet clients and is in the perimeter network only.
• A site supporting both Internet and intranet clients, which spans the perimeter network and intranet. All Internet-based site systems are in the perimeter network and support connections for clients connecting over the Internet. A second management point, SUP, FSP, and additional distribution points, along with other site systems, are in the intranet for those clients connecting over the intranet.
• A site that supports both Internet and intranet clients, and bridges the perimeter network and the intranet. There is a single management point. This is both the site’s default management point and the Internet-based client’s management point.
These scenarios are described in detail in http://technet.microsoft.com/en-us/library/bb693824.aspx.
When designing your solution, your primary consideration will be the level of security you need. Providing services through the Internet potentially exposes you to unauthorized access. You should involve any necessary resources to ensure that proper security risk management and secure network design principles are followed.
Each of the scenarios Microsoft supports involves three security zones:
• The Internet (least secure)
• The perimeter network (more secure)
• The internal network (most secure)
The purpose of the perimeter network is to protect your internal network, where your most valuable systems and data reside. If a host in the perimeter network is compromised, it is the job of the inner firewall, the one between the perimeter network and the internal network, to protect your high-value assets. One basic principle of network security is that allowing any connections to be initiated from a less secure zone to a more secure zone is a risk. As you step through the supported scenarios, focus on the allowed protocols at the inner firewall. The options that allow inbound connections are likely to be less secure than those that do not.
A special risk is introduced by solutions that bridge the perimeter network and the internal network. In this case, you do not have a dedicated inner firewall. If one of the bridging hosts is compromised, it could be used to attack the internal network. If you choose to implement this model, you should take special care to harden the systems as much as possible, monitor them closely, and verify that you have disabled routing between the network cards. Many organizations have security policies that forbid using servers to bridge security zones.
Take your own secure network architecture into account as you consider each of the scenarios Microsoft supports for deploying servers to support Internet clients, because you may need to adapt these scenarios to meet your own security requirements. Carefully consider the relative advantages of each model.
The first option to consider is whether to have a dedicated site for Internet clients. Using a dedicated site provides some options that simplify your security planning. If you use a dedicated Internet-only site, you should have only an Internet-based management point and not a default MP. The most secure configuration is a dedicated site, totally within the perimeter network, that is absolutely separate from the hierarchy supporting intranet clients. This configuration, shown in Figure 6.11, does not require connectivity between the Internet-accessible systems and your internal network.
For complete isolation, you would need a separate Active Directory forest in the perimeter network. This configuration does not support clients that connect both as Internet and intranet clients. Even if you have mobile clients that sometimes connect directly to your network, or clients that sometimes establish a VPN connection, you will need to configure them as Internet-only clients, which will have the more limited IBCM management capabilities.
A dedicated site for Internet clients can also reside in the perimeter network but be joined to a parent site in your internal network. This configuration requires you to allow site-to-site communications across your inner firewall.
You can configure a site to span the internal network and the perimeter network. A site that spans these zones can be dedicated to Internet clients only or can have both Internet and intranet clients. In this configuration, the site server and SQL database server are in the internal network. You can provide services to intranet clients either by deploying separate client-facing systems in the internal network or by configuring site systems in your DMZ to accept connections from both intranet and Internet clients and then allowing outbound client connections though the internal firewall.
Configure Internet-facing systems using the option Allow only site server initiated data transfers from this site system. You can configure this setting on the site system properties page, found under System Center Configuration Manager -> Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Site Systems -> <Site System> -> Site System, which is displayed in Figure 6.12. This configuration eliminates the need to allow inbound connections to the site server though the inner firewall.
Figure 6.12. Use the site system properties page to specify the site server will initiate communications
You can also eliminate the need for inbound SQL connections by deploying a SQL replica in the DMZ, which requires considerable configuration but can enhance security. Configuring site database replication is described in Chapter 8, “Installing Configuration Manager 2007,” and at http://technet.microsoft.com/en-us/library/bb693697.aspx.
Configuration Manager requires a properly configured Public Key Infrastructure for native mode operations. Mixed mode sites can also use certificates for a limited set of functions without a PKI implementation. The next section (“About PKI”) briefly introduces basic PKI concepts. It then discusses how ConfigMgr uses PKI and how you should plan to deploy a PKI solution or leverage your existing PKI for ConfigMgr.
Public key cryptography, discussed in depth in Chapter 11, is currently the principal cryptographic standard for secure communications on the Internet and on private networks. The algorithms behind public key cryptography allow messages to be encrypted and decrypted using a key pair. The keys in the pair are numbers that are mathematically related such that a message encrypted with one of the keys in the pair can only be decrypted with the other key. Each user (or system) that uses public key cryptography has a unique key pair. One of the keys in the pair is kept secret. This is the private key. The other key, the public key, is published to make it available to other users. You can use key pairs in two different ways:
• You can encrypt a message with a user’s public key and send it to the user. Only the user with the matching private key can decrypt and read it.
• You can sign a message by encrypting it with your private key. Users who have your public key can decrypt and read the message. Because the recipients know that the message was encrypted with your private key, they can be confident that you are the sender and the message has not been tampered with.
On a small scale, it would be possible for all users to know each other’s public keys. This is not practical on a larger scale. To allow the use of public key cryptography in large environments, including the Internet, PKI technology was developed. PKI provides a framework for securing both session-based and messaging communications using a hierarchy of Certificate Authorities (CAs). At the top of a PKI hierarchy is the root CA, a system whose public key is known and trusted by all parties who will participate in that PKI. A CA is used to issue binary objects known as certificates to other systems or users. Certificates can be issued for specific purposes and validate the identity of the certificate holder. Because a compromised root CA would compromise the integrity of an organization’s entire PKI, the root CA is generally kept offline and not used to issue certificates directly to users and systems. A set of subordinate CAs receive certificates from the root, which allow them to also issue certificates.
In native mode, most client-to-server communications are mutually authenticated, signed, and encrypted using the HTTPS protocol. Here are the principal types of certificates used by native mode sites:
• Client certificates, used by the client to authenticate to site systems
• Web server certificates, used by site systems to authenticate to clients
• The document-signing certificate, used by the site server to ensure the integrity of client policy and content
All native mode ConfigMgr systems that communicate by HTTPS require PKI certificates. These systems include the following:
• Clients
• Management points
• Standard distribution points when using the download-and-run option
• Software update points
• State migration points
Each server supporting HTTPS requires a certificate based on the Microsoft web server template or equivalent. All computer client systems require a computer or workstation certificate. Mobile device clients require an authenticated session certificate. Detailed descriptions of the required certificates can be found at http://technet.microsoft.com/en-us/library/bb680733(TechNet.10).aspx. All communications with Internet-based clients and Internet-based device clients require PKI certificates on the clients and site systems, except for sending status messages to the FSP. Status messages sent to the FSP are essentially a call for help when a client is having problems contacting the site, so HTTP is used in case certificate-related issues are causing the problem.
Note
About Encrypting Communications Between Servers
Server-to-server communication is not encrypted in either native mode or mixed mode sites. To secure communications between servers, you should consider using IP Security (IPSec). Chapter 20 discusses the use of IPSec on ConfigMgr.
In addition to supporting HTTPS communications between clients and site systems, native mode ConfigMgr sites use PKI to support OSD for signing policies and task sequences, and for client certificate deployment. Here are some key points:
• To sign policies, the site server must have a document-signing certificate installed.
• For OSD task sequences, you must install a client authentication certificate to provide authentication to the management point temporarily until the client is fully provisioned with its permanent certificate.
• A root certificate from each root CA supporting ConfigMgr site systems must be imported into the site configuration for certificate signing. For information about configuring OSD, see Chapter 19, “Operating System Deployment.”
For Configuration Manager clients and site systems to operate successfully in native mode, all systems must trust the CAs that issue the certificate, as well as any root and intermediate CAs in the certificate hierarchy. Certificates issued by certain well-known public authorities are trusted by default on all Windows computers and many mobile devices. If you use your own PKI, however, you will need to make sure that your CA certificates are added to the trusted store on all systems. In an Active Directory forest, you can use AD services to achieve this. You also need to deploy the certificates themselves to all site systems and clients. Using Microsoft Certificate Services with an Enterprise Certification Authority simplifies many of these operations; however, you can use any PKI supporting x.509 version 3 certificates. Chapter 11 discusses PKI management.
You can configure mixed mode sites to use self-signed server certificates to secure client communications with the management point and state migration point only. Mixed mode sites can also use certificates to sign policy and sign content. Clients will verify the signature if the option to download content from the distribution point and run locally is selected in the advertisement properties. Configuration Manager 2007 manages certificates used by mixed mode sites, and you cannot use these certificates outside ConfigMgr operations. Using certificates in mixed mode sites does not require a PKI infrastructure.
Support for Windows Server 2008 clients or site systems require Configuration Manager 2007 SP 1. There are no special considerations for Windows Server 2008 client support on servers running full installations of Windows Server 2008. Microsoft supports the client on Windows Server 2008 core installations; however, Desired Configuration Management and Out of Band Management do not work with the Core build. There are several items to note regarding Windows Server 2008 site systems:
• You cannot install site systems on Windows Server 2008 Core installations.
• Site servers, management points, distribution points, branch distribution points, and reporting points require options not enabled by default on Windows 2008 servers.
The article at http://technet.microsoft.com/en-us/library/cc431377(TechNet.10).aspx provides step–by-step instructions on how to configure Windows Server 2008 for site system roles. Here are some specific features and settings you must enable:
• IIS, BITS, and WebDAV are required for management points and BITS-enabled distribution points. WebDAV is not an included component in Windows Server 2008. You can download and install WebDAV from http://go.microsoft.com/fwlink/?LinkId=108052.
• After installing WebDAV, use IIS Manager to enable WebDAV and to create and enable an authoring rule to allow read access to all content for all users. You also need to configure the following WebDAV settings:
• Allow anonymous property queries
• Allow property queries with infinite depth
• Allow access to hidden files (on BITS-enabled distribution points only)
• Disallow custom properties
• You must modify the requestFiltering options on BITS-enabled distribution points. Edit the configuration file %windir%System32inetsrvconfigapplicationHost.config as follows:
• Locate the <requestFiltering> section.
• For each file extension that will be included in packages on that distribution point, change the value of the allowed attribute from False to True.
Using PowerShell to Identify Required File Extensions
If you have a set of existing packages in a source folder or on a distribution point, you can use PowerShell to obtain a list of the file extensions in your packages. Enter the following at the PowerShell prompt:
Here, <pkgshare
> is the local or UNC path of your package folder. For example, if your packages were stored on \MineolaSMSPKGE$, you would enter the following:
Windows PowerShell is a powerful and flexible scripting and shell language included on the installation disk for Windows Server 2008. PowerShell is also available for download for Windows XP, Windows Vista, and Windows Server 2003 SP 1. PowerShell offers numerous enhancements over both the MS-DOS-style command and batch file language and VBScript, and it’s rapidly becoming an essential tool for administering Windows and Microsoft server applications. Microsoft has added extensions to support functionality in applications including Operations Manager 2007, Exchange Server 2007, and Virtual Machine Manager.
You can visit the Windows PowerShell Technology Center at http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx for additional information about PowerShell. The article at http://www.windows7th.com/?p=22028 includes a nice description of using PowerShell V2 with the ConfigMgr provider.
• Site servers and branch distribution points use remote differential compression (RDC) to generate package signatures and perform signature comparison. RDC is not installed by default on Windows Server 2008 but can be installed through Server Manager.
• Finally, you must add ASP.NET on reporting points. This can be done through Server Manager. You should choose the Windows Authentication security option for ASP.NET.
Configuration Manager also takes advantage of the Windows Deployment Service (WDS) in Windows Server 2008. This provides advanced functionality such as multicast operating system deployments. Chapter 19 discusses Configuration Manager integration with WDS.
Like its SMS predecessors, Configuration Manager provides a range of useful functionality. At each point in its history, though, SMS had a “killer app” that drove its adoption.
In the early days of SMS the one thing IT departments wanted was remote control. As remote control became ubiquitous and eventually built in to Windows, it was no longer as compelling a reason to deploy SMS. The release of SMS 2003 brought a new killer app that met a critical need facing the IT community—patch management. Although the need for effective patch management has become even more critical and the Configuration Manager feature set supporting it has been improved, it may well be that the most important new feature of Configuration Manager 2007 is OSD.
Provisioning new systems to corporate standards is a repetitive chore without suitable automated tools. Deploying new operating systems with increasingly demanding hardware requirements and potential application compatibility issues can be a daunting challenge for IT departments whose resources are already stretched thin. Microsoft has made a major investment in Configuration Manager OS deployment. Driving shorter adoption cycles for new operating systems is undoubtedly a strategic goal for Microsoft, so this is one part of the product the company is particularly motivated to get right. Whether or not OSD will prove to be the killer app for Configuration Manager 2007 remains to be seen, but the product certainly has some useful and well-thought-out capabilities. Here are some of the major capabilities of OSD:
• Image capture and deployment— ConfigMgr uses a Windows Image Format file (.WIM) image that can be applied to a target computer. You can use an existing image, if one is available, or you can capture an image from a reference computer. A reference computer is a computer that you configure exactly as you would like to deploy production machines with the same base hardware configuration.
• User state migration— When you want to provide a new computer to an existing user, the Windows User State Migration Tool (USMT) can capture the user’s environment, settings, and data for transfer to the new machine. The Configuration Manager state migration point receives user state data from the USMT and stores it for deployment to the target machine.
• Task sequences— A task sequence can encapsulate the entire process of configuring source computers, capturing and deploying images, migrating user state and other settings, and running any post-installation tasks such as deploying ConfigMgr packages to the new machine.
• Application Compatibility Toolkit— Although not strictly part of OSD, this ConfigMgr R2 feature makes the planning of a major OS rollout much simpler.
This section highlights some of the key planning issues around OSD. Chapter 19 presents this feature set in detail.
You can choose from several options for deploying images and task sequences:
• If upgrading an existing ConfigMgr client computer, you can use ConfigMgr to initiate the installation from a distribution point.
• You can initiate the installation from bootable media configured to connect to the distribution point.
• You can use PXE (Preboot Execution Environment) Boot to initiate the installation. Most network cards will initiate a PXE Boot request sequence if an operating system is not already installed. The ConfigMgr PXE service point is capable of responding to PXE Boot requests and initiating an installation from a distribution point.
• You can use standalone media containing all the necessary installation files. This avoids the network traffic generated by installing from a distribution point, but requires you to build and distribute complete images, including all drivers and other required files.
• If you are replacing a user’s existing machine, you can use a state migration point to transfer user state data.
Tip
Task Sequences Are Not Just for OSD
Task sequences are not only for OSD deployments. You can advertise a task sequence to existing clients just as you would a program in a package. To advertise a task sequence, just right-click the Advertisements node in the ConfigMgr console and choose Advertise Task Sequence. This launches the New Advertisement Wizard, which allows you to select the task sequence, target collection, and specify other advertisement properties. For an interesting discussion of the possibilities provided by advertising task sequences, see http://wmug.co.uk/blogs/r0b/archive/2008/09/08/configmgr-using-task-sequences-to-deploy-more-than-operating-systems.aspx.
When preparing your boot image, you must include all necessary network card and mass storage drivers. You should inventory additional drivers in your target environment and add them to the driver catalog you make available on your distribution points. You may include applications in your OS image, provided the applications do not contain unique identifiers that cannot be generalized by Sysprep. You can also install applications separately from the image as a post-install task. Including applications in your images can increase the number of images you need to create and maintain, but can make the installation process faster. OS images are often 2GB or larger. You should consider your storage requirements when sizing distribution points.
You should also consider the bandwidth required to deploy images when planning your deployment strategy. You may choose to use courier sender to distribute images between sites on physical media rather than using the network for this task. You should also consider backing up user data to the network or using existing backups rather than migrating user data as part of the user state migration.
ConfigMgr 2007 R2 introduces multicast capability for OS image deployment. Multicast can greatly reduce bandwidth consumption when deploying images to multiple machines. For an excellent discussion of ConfigMgr multicast capability, see http://blogs.msdn.com/steverac/archive/2008/10/19/setting-up-multicasting-in-sccm.aspx.
The Application Compatibility Toolkit (App Compat), new in ConfigMgr 2007 R2, helps with two key tasks:
• Inventorying applications in your environment and reporting on compatibility with Windows Vista
• Providing reports on which devices in your environment are Vista compatible and what driver upgrades may be required
Although not a replacement for testing applications with your specific build and environment, App Compat can help to quickly identify the applications and hardware that are likely to cause problems with your migration. Chapter 18 describes how to use the Application Compatibility Toolkit.
An increasing number of organizations are using power management features to reduce energy consumption by partially or even completely shutting down idle computers. The Advanced Configuration and Power Interface (ACPI) specification, which has become the industry standard for PC power management, defines various “sleep states,” ranging from S0 (On and fully functional) to S5 (Off and powered down). Wake On LAN can be used to “wake up” computers in sleep states S1 through S5.
Configuration Manager can use Wake On LAN to deploy software updates or mandatory advertisements to client computers connected to the network that are in a sleeping state. You can use this capability to deploy applications during off-hours to avoid affecting users, while ensuring critical patch deployments are not delayed by waiting for computers to power up.
Using Wake On LAN requires the following:
• The power supply must support Wake On LAN.
• The client network interface cards (NICs) must support the standard magic packet format.
• The Basic Input/Output System (BIOS) settings for the NIC must have wake-up packets enabled.
Windows Logo–compliant NICs are required to support the magic packet format.
Tip
About Magic Packets
The magic packet is a standard wake-up frame that targets a specific network interface. The packet is a broadcast frame sent by the data link or OSI-2 layer. The packet enables remote access to a computer that is in a power-saving state (the computer is powered off, but some power is reserved for the NIC). When the listening computer receives this packet, it checks the packet for correct information, then switches on and boots.
The Configuration Manager 2007 client is required for Wake On LAN functionality, and Wake On LAN must be deployed at a primary site with hardware inventory enabled. Limitations to Wake On LAN include the following:
• The functionality does not support Internet-based clients.
• Wake On LAN is not aware of maintenance windows.
You can use either unicast packets or subnet-directed broadcasts for Wake On LAN:
• Unicast packets, also known as directed packets, are sent to the last-known IP address for the target computer based on hardware inventory.
• Subnet-directed broadcasts are targeted to the last reported subnet of the target machine. This allows subnet-directed broadcast packets to reach their target even if the IP address has changed.
To support subnet-directed Wake On LAN broadcasts, your network infrastructure must allow IP-directed broadcasts between the site server and client computers. For security reasons, by default most routers do not allow subnet-directed broadcasts. Enabling subnet-directed broadcasts can expose your network to certain types of denial-of-service attacks.
To prevent attacks, if you choose to use subnet-directed broadcasts you should use a nondefault port and allow broadcasts only from the site servers. If you use unicast packets, you need to configure switches to forward User Datagram Protocol (UDP) packets. Unicast packets also may not work with all sleep states on some network adapters.
One of the most exciting developments in desktop technology in recent years is Intel’s Advanced Management Technology (AMT), based on the vPro technology. For many years, server vendors have offered Out of Band (OOB) Management capability using a dedicated network connection, network card, and processor. Due to cost, this type of configuration is generally not practical for desktop systems. Intel’s introduction of network cards and chipsets supporting AMT, while not providing the hardware redundancy of the server class solutions, brings the same manner of management functionality to desktop systems. This section looks at the ways Configuration Manager takes advantage of AMT features. More information about AMT and vPro technologies can be found at http://www.intel.com/technology/vpro/index.htm.
OOB Management uses Windows remote management technology (WS-Management) to connect to the management controller on a computer. Configuration Manager 2007 SP 1 introduces support for OOB Management capabilities, including the following:
• Remote helpdesk functions— Using the Out of Band Management console, a separate management console that ships with SP 1, you can connect to systems and perform functions such as the following:
• Changing the power state of sleeping systems
• Watching the boot sequence before the operating system loads
• Managing system BIOS settings
• Redirecting IDE drives to network locations or other devices
• Powering up sleeping systems— This capability enables software distribution, software updates, and OSD.
• ConfigMgr updates can be scheduled or done on demand.
• AMT provides better security than Wake On LAN, including Kerberos authentication and encryption.
If you are planning to use OOB Management, your desktop infrastructure and PKI deployment must meet several requirements to support it. Even if you do not plan to use this functionality immediately, you may want to plan for it in your new hardware purchases. Table 6.3 lists the key dependencies to plan for if you want to use OOB Management.
For details on configuring Out of Band Management, see http://technet.microsoft.com/en-us/library/cc161822(TechNet.10).aspx.
Note
The Distributed Management Task Force (DMTF) has introduced the Desktop and Mobile Architecture for System Hardware (DASH) standard to bring standardization to advanced desktop management technology. Intel AMT 3.2.1 is fully DASH compliant and has additional functionality making it a superset of the DASH specification. Other hardware vendors such as AMD have also released management technology based on the DASH standard. It seems likely that in the future Configuration Manager will work with these technologies as well.
This chapter discussed some of the key planning considerations around deploying Configuration Manager and preparing to use some of its most important features. It looked at planning your hierarchy and sites, including hardware sizing, site boundaries, and security modes. The chapter then discussed planning for software updates and supporting mobile devices and Internet clients. It considered the certificate requirements for ConfigMgr and special issues with Windows Server 2008. Finally, the chapter discussed planning for OSD and the use of Wake On LAN and OOB Management functionality.
The next chapter discusses how to test, refine, and extend your planned Configuration Manager deployment.