IN THIS CHAPTER
Finally! By now, you have spent a considerable amount of time reading the first seven chapters of this book. You have studied the terminology, examined those components you plan to install, and carefully designed your ConfigMgr 2007 hierarchy, paying very close attention to wide area network (WAN) links and administrative requirements. You have also documented and verified your site boundaries, and have determined whether you will operate in mixed mode or “go native.” Due to its nature, a successful Configuration Manager (ConfigMgr) implementation requires substantial planning.
This chapter covers installation of the central site server and basic configuration tasks. It also reviews multisite installation considerations as well as discusses the installation of primary and secondary child sites. In addition, the chapter discusses troubleshooting approaches for site installation and configuration.
You may notice the use of multiple site servers in this chapter. The lab environment used in this book has a central site (CEN) running on Bluebonnet, and four primary sites, all in the SCCMUnleashed.com domain. Here are the primary sites reporting to the central site:
• DAL (Dallas)— Running on the Wildflower server
• HOU (Houston)— Running on the Mockingbird server
• BXL (Brussels)— Installed on the Tumbleweed server
• BEJ (Beijing)— Installed on the Roadrunner server
This chapter discusses the installation of Configuration Manager 2007 on the central site server, and uses the BXL primary site for examples as well. The CEN, DAL, and BXL sites are running Configuration Manager 2007, whereas HOU and BEJ run SMS 2003. Chapter 9, “Migrating to Configuration Manager 2007,” steps through the process of upgrading the HOU primary site to Configuration Manager 2007. The Configuration Manager console installs as part of your site server installation; Chapter 10, “The Configuration Manager Console,” includes a discussion of installing the console on other systems.
You are almost ready to begin the ConfigMgr site installation. Before launching the installation program (setup.exe), assess the points in this section to ensure you have completed all prerequisites. If you have multiple ConfigMgr sites and/or servers in your design, verify you have that information documented, including what servers handle which ConfigMgr site roles, as well as required prerequisites for each server. Review the following questions:
• Will you configure the central site for mixed mode or native mode?
Chapter 6, “Architecture Design Planning,” discusses site security modes.
• Will your hierarchy contain all primary sites, or primary and secondary sites? Will you need any branch distribution points?
Chapter 2, “Configuration Manager 2007 Overview,” introduces primary and secondary sites as well as the use of branch distribution points.
• Will you install all site components on your central site, or distribute them over multiple servers?
Chapter 6 discusses distributing components across multiple servers.
• How much drive space do you need on each site server?
See Chapter 6 for disk space requirements.
• Do you need to extend the Active Directory (AD) schema?
Chapter 3, “Looking Inside Configuration Manager,” discusses extending the schema.
• Is your hardware sufficient?
See Chapter 4, “Configuration Manager Solution Design,” and Chapter 6 for hardware requirements and planning.
These are questions you will want specific answers for before deploying your first production ConfigMgr site. If the answers are not completely clear, do not pass Go! Spend some additional time reviewing the previous chapters, particularly Chapter 6.
Before starting the installation process for ConfigMgr, verify you have installed and configured all software prerequisites. The next sections briefly describe those requirements. For additional information on prerequisites when installing Configuration Manager, refer to http://technet.microsoft.com/en-us/library/bb694113.aspx.
Configuration Manager 2007 depends on a number of Windows components. Depending on your site design, you may not need all components on each ConfigMgr site in your hierarchy. Table 8.1 provides a brief overview of the Windows components required for each site server and site role. See http://technet.microsoft.com/en-us/library/bb680717.aspx for a complete list of ConfigMgr-supported configurations.
Windows Server 2008 will have some default components configured differently from Windows Server 2003. For example, WebDAV extensions require a separate download, and Remote Differential Compression is not enabled by default. For instructions on configuring these components for Windows Server 2008, review the article on configuring Windows Server 2008 for site systems at http://technet.microsoft.com/en-us/library/cc431377.aspx.
All primary sites use Microsoft SQL Server 2005 with Service Pack 2 or greater for the Configuration Manager database. Consider using Enterprise edition if you are planning to use clustering with more than two nodes or if you have a very large site. SQL Server Standard edition will be sufficient for almost all environments.
Microsoft now supports upgrading the site database to SQL Server 2008 if you apply a hotfix:
• For the base or Released to Manufacturing (RTM) version of ConfigMgr 2007, apply the hotfix discussed at http://support.microsoft.com/kb/955229. Apply the hotfix to the following servers:
• Primary site servers using SQL Server 2008 to host the site database.
• Secondary site servers reporting to primary sites that use SQL Server 2008 to host the database.
• Systems with the Configuration Manager 2007 console installed and connecting to a site that uses SQL Server 2008 to host the database.
• Servers hosting a remote Systems Management Server (SMS) provider.
• For ConfigMgr Service Pack (SP) 1, follow the instructions at http://support.microsoft.com/kb/955262. If applicable, apply the hotfix to the following servers:
• Primary site servers using SQL Server 2008 to host the database.
• Systems with the Configuration Manager console installed and connecting to a site using SQL Server 2008 to host the database.
• Servers hosting a remote SMS provider.
If you plan to use ConfigMgr to deploy Microsoft security patches, you must install WSUS 3.0 (for ConfigMgr 2007 RTM) or WSUS 3.0 SP 1 (for ConfigMgr 2007 SP 1). For information on WSUS with ConfigMgr, see http://technet.microsoft.com/en-us/library/bb693886.aspx. Chapter 15, “Patch Management,” discusses using ConfigMgr 2007 for security patch management.
Running the ConfigMgr prerequisite checker confirms whether your system meets the minimum installation requirements for ConfigMgr 2007. The prerequisite checker verifies requirements such as administrative rights, SQL Server version, .NET Framework version, eXtensible Markup Language (XML) version, MMC version, and required Windows updates and hotfixes. Microsoft provides a complete list of setup prerequisite checks at http://technet.microsoft.com/en-us/library/bb680951.aspx.
The ConfigMgr prerequisite checker automatically runs during site installation. You can also run it separately by using one of the following methods:
• Select the prerequisite checker from the ConfigMgr installation menu (Splash.hta) in the root of the installation media.
• Call setup.exe with appropriate command-line arguments. For example, to verify the prerequisites for a secondary site, open a command prompt (Start -> Run, and type cmd) and type
Setup.exe /prereq /sec
For a complete list of arguments, see http://technet.microsoft.com/en-us/library/bb681060.aspx.
After verifying the prerequisites and deciding whether to extend the Active Directory schema, you are ready to begin ConfigMgr site installation.
Tip
Use SMS Trace to Monitor ConfigMgr Installation
SMS Trace (also called Trace32 and introduced in Chapter 3) is a utility in the ConfigMgr Toolkit used to view log files in real time. Download the ConfigMgr Toolkit from Microsoft at http://www.microsoft.com/downloads (search for ConfigMgr Toolkit), and install it on your soon-to-be primary site. After you begin the ConfigMgr installation, launch Trace32 and open the ConfigMgr installation logs (%SystemRoot%ConfigMgrPrereq.log and %SystemRoot%ConfigMgrSetup.log). You will see the logs dynamically update as the installation proceeds.
Perform the following steps to install the primary site:
- Browse to your installation media and launch Splash.hta, found in the root of the installation media. As shown in Figure 8.1, you have several options in the splash screen, including running the prerequisite checker, reviewing the release notes, and installing ConfigMgr.
- Review the release notes for late-breaking information about known issues, bug fixes, and other important information. When you are ready, select the option Install Configuration Manager 2007 to view the Welcome screen.
- Verify you are ready to move forward and then click Next to choose a setup option, as shown in Figure 8.2.
-
Provided you are attempting to install on a supported server operating system (OS), select the option Install a Configuration Manager site server. Then click Next to view the license terms. Read the license agreement, and if you agree to the terms, click Next to proceed.
Tip
Install the ConfigMgr Console on a Workstation for Everyday Use
Another option on the Available Setup Options screen is Install or upgrade an administrator console. A common misconception for new ConfigMgr administrators is that you must run the Configuration Manager console on the site server. You can actually install it separately on a workstation operating system (such as Windows Vista or XP). While installing the console, you will select a site to manage. After installation, you can also attach to additional ConfigMgr primary sites and manage them all from a single console, without needing explicit administrative rights to the server. Chapter 10 discusses using the ConfigMgr console.
-
On the Installation Settings page displayed in Figure 8.3, you finally can start selecting those decisions you reviewed in the “Pre-Installation” section of this chapter prior to starting the installation. Choose between custom settings and simple settings:
• Custom settings allow you to specify the installation path, configure individual component settings and client agents, port settings, and more.
• Simple settings are most useful in a test environment, but the authors recommend using custom settings so you are more aware of the configuration options and the process required for production deployment.
Choose the Custom settings option and click Next to continue.
- On the Site Type page shown in Figure 8.4, select Primary site. Because you are installing your first site, this will also be your central site.
-
After you specify the site type, the wizard asks you to participate in the Customer Experience Improvement Program. Review the documentation at http://technet.microsoft.com/en-us/library/bb693975.aspx and be familiar with your corporate policies. Then choose whether to participate.
Joining the Customer Experience Improvement Program can help the Configuration Manager development team understand your pain points in Configuration Manager. You can change this option after installation by using the Help menu in the ConfigMgr console.
- Specify the product key for your Configuration Manager installation. Enter a valid product key and then click Next to continue.
- On the Destination Folder page, select the installation directory to install the software.
- On the Site Settings page shown in Figure 8.5, enter the three-character site code, along with a site name (or description). Use those three characters wisely, because you will be unable to change the site code or the site name after installation completes. Figure 8.5 uses the code CEN and the name CENTRAL SITE.
-
On the next page, the wizard asks you to specify the desired site mode. As discussed previously in Chapter 6, be sure to make your selection wisely. If you choose to “go native” right now, have your signed security certificate ready to import.
If you will be supporting SMS 2003 clients or Windows 2000 systems in this site, the site will need to use mixed mode. Mixed mode is also required if your site has a parent site configured for mixed mode.
It is recommended you install the first site in mixed mode (although you can always switch back and forth; see http://technet.microsoft.com/en-us/library/bb693556.aspx for details). After completing installation and confirming everything is working properly, migrate the site to native mode. For this sample installation, select mixed mode for now. The “Preparing for Native Mode” and “Enabling Native Mode” sections of this chapter give an example of configuring a site in native mode.
- You are now ready to enable client agents for your site. As shown in Figure 8.7, enabling client agents is as simple as checking a box. With the exception of Network Access Protection, all client agents are enabled by default.
-
On the Database Server page (shown in Figure 8.8), identify the SQL Server computer name and instance, and specify the ConfigMgr site database name. If the database name does not exist, the Configuration Manager setup program will create a new database if SQL Server is installed on the local system.
If you specified SQL on a remote server, you must first create the database manually and add the machine account of the primary site server to the local Administrators group of the remote SQL server. Also during installation, the user account that is running the ConfigMgr install must have administrative rights on the SQL server, or be assigned the sysadmin SQL Server role on the remote SQL server. Microsoft provides detailed documentation on installing ConfigMgr with a remote SQL Server at http://technet.microsoft.com/en-us/library/bb693554.aspx.
To specify a remote SQL database, simply enter the NetBIOS name of the remote SQL server and ensure that both you (as the installer) and the ConfigMgr site server have administrative rights to the SQL Server computer for installation and configuration.
Figure 8.8 shows the Database Server page with the name of the database server and the (default) site database name specified. The database will be installed on the default instance of the Bluebonnet central site server. If you want to use a named instance, simply enter it using the format specified in Figure 8.8.
Tip
Multiple Primary Sites—Use a Consistent Database Name
You may encounter a situation where it is necessary to modify your site database configuration. If you have multiple primary sites (which means you have multiple site databases, because each primary site has its own database), you may want to consider changing the database name to a consistent name (for example, “ConfigMgr”). Because using the default site database name results in a unique name for each database on each site, as shown in Figure 8.8, if you need to run a SQL script on each of your databases, you may have to change the script for each site. Using a consistent database name for all sites provides additional opportunities to automate configuration and maintenance changes.
-
The next page of the setup wizard is the SMS Provider Settings page. Specify the NetBIOS name of the server to install the SMS provider.
The SMS provider is your communication method between the ConfigMgr console and the ConfigMgr database. It is also the supported avenue to ConfigMgr data using Windows Management Instrumentation (WMI). The SMS provider is typically installed on the ConfigMgr primary site. You can also install the SMS provider on the SQL Server system or an entirely separate server. Do not install the provider on a clustered SQL Server instance or a SQL Server containing databases for multiple sites, because Microsoft does not support the provider in these scenarios. For larger sites, you may consider offloading the provider to increase performance. Microsoft provides documentation on choosing the SMS provider installation location at http://technet.microsoft.com/en-us/library/bb694290.aspx.
- On the Management Point page, choose to install a management point (MP) if you will be assigning clients to this site. All ConfigMgr clients require access to the management point to communicate with the ConfigMgr site. You can install the management point on the site server or a separate supported server operating system. Check the management point system requirements in Table 8.1 for additional information. You can create a new management point, or move an existing management point once site installation completes.
-
On the Port Settings page, select the default port (80) or use a custom port for client communications, provided you configured the site to use mixed mode. (If you’re configuring for native mode, HTTPS settings are also available for configuration.)
-
On the Updated Prerequisite Components page, you have the option to automatically connect to the Internet and download all prerequisite components, or you can specify an existing path to where you have previously downloaded the components. Setup will download several components, such as the Windows Update Agent, a WMI update, the Microsoft Remote Differential Compression Library, and a BITS update. Multiple supported languages are automatically downloaded as well.
Tip
How to Download Site Prerequisites Before Installation
Depending on your environment, you may not have access to the Internet from your ConfigMgr site, or you may have a slow Internet connection. Alternatively, you may be like us and prefer that everything you need is available before installing your site.
To download the prerequisites in advance, ensure you have Internet access, connect to your ConfigMgr installation media, and run the following command:
<Media Path>SMSSETUPBINI386Setup.exe /DOWNLOAD <Destination>
Here,
<Destination>is the location destination for your download—ensure this folder exists prior to running the setup command.You can run this command from any supported Windows OS (Windows Vista, Windows XP, and so on). The download takes approximately 5 minutes with a high-speed Internet connection.
-
The Updated Prerequisite Component Path page will do one of two things, depending on your selection on the Updated Prerequisite Components page:
• If you selected Check for updates and download newer versions to an alternate path, specify the path to download the files.
• If you selected The latest updates have already been downloaded to an alternate path, simply specify the path so the installation can use those files.
- Review the Settings Summary page, displayed in Figure 8.9, to ensure you entered all configuration information accurately. You can reconfigure some of these settings later, but others (such as Site Code and Site Name) are permanent. Click Next, which automatically launches the prerequisite checker.
- The Installation Prerequisite Check page verifies installation of all prerequisites, with results displayed in Figure 8.10. The complete list of setup prerequisite checks at http://technet.microsoft.com/en-us/library/bb680951.aspx provides detailed information of all ConfigMgr prerequisites. For any items that fail the check, double-click the individual result to see additional information. You should be able to remediate most problems while leaving the setup page open. If the server must be rebooted, you will need to restart the installation process from the beginning.
- After correcting any items that failed prerequisite checks, click Run Check to rerun the prerequisite check. After all checks pass, click OK to begin the ConfigMgr site installation. During the installation process, review the installation log located at %SystemRoot%ConfigMgrSetup.log. An installation progress page appears, as displayed in Figure 8.11.
- The Completing the Microsoft System Center Configuration Manager 2007 Setup Wizard page appears at the end of the installation. If you haven’t been watching the ConfigMgrSetup.log using SMS Trace (see the earlier note “Use SMS Trace to Monitor ConfigMgr Installation” regarding SMS Trace), click the View Log button to review the log, as shown in Figure 8.12.
Tip
Always Review ConfigMgrPrereq.log and ConfigMgrSetup.log
If you are like the authors of this book, you will be very excited when you see the message in Figure 8.12 that reads “Setup completed all operations successfully.” Although there is a very good chance that this message is completely accurate, it is highly recommended you take the time to review the logs. Installations have occurred that appeared (and reported) to be successful, but were not completely successful due to problems such as improper SQL configuration or improper rights between servers. The message in Figure 8.12 gives a good indication of success, but the logs give the best indication. Browse %SystemRoot%ConfigMgrPrereq.log and %SystemRoot%ConfigMgrSetup.log to view additional installation information.
With the central site installed, you can use the same procedures to install other primary site servers. You would then join the sites together, as discussed in the “Attaching to Parent” section of this chapter. You will also want to upgrade your site servers to the current service pack level and ConfigMgr 2007 Release 2 (R2), as discussed in the following sections.
Note
Performing a Silent Installation of ConfigMgr
You can perform a silent/unattended installation of ConfigMgr. The article at http://technet.microsoft.com/en-us/library/bb693561.aspx provides information on unattended setups and includes additional links to sample script files and command-line parameters.
Before installing a service pack, read the Readme file included with the service pack media. As always, ensure you have a proper backup before attempting the upgrade. Chapter 21, “Backup, Recovery, and Maintenance,” contains information about configuring ConfigMgr scheduled backups.
Note
Disable All SQL Replication Before Performing the Site Upgrade
To upgrade successfully, you must first remove any existing database replication and subscriptions. Microsoft provides an article on disabling SQL Server database replication at http://technet.microsoft.com/en-us/library/bb693954.aspx. The “Disabling SQL Replication” section later in this chapter also discusses the steps to disable replication.
Before upgrading a site, you should perform a site database upgrade test. This test is a destructive test, so be sure to make a copy of your database, as described in the “Making a Copy of the ConfigMgr Database” sidebar.
The database copy does not need to reside on the production ConfigMgr site—in fact, it doesn’t even need to be on a ConfigMgr site! Simply attach the database copy to any SQL Server instance running the same version and service pack level as your site database.
After copying the database, perform the following steps:
-
From the installation media, run the following command line, replacing
SMS_XXX_COPYwith the name of your test database:SMSSETUPBINI386setup.exe /testdbupgrade <SMS_XXX_COPY>
The prerequisite checker will run briefly.
-
Select Begin TestDBUpgrade.
Once again, the log files %SystemRoot%ConfigMgrPrereq.log and %SystemRoot%ConfigMgrSetup.log are updated, this time with information about the database upgrade test. A message appears stating ConfigMgr has been successfully upgraded.
Successfully performing a test upgrade on your database is an indicator that the database portion of the site upgrade will run smoothly.
The remainder of the process of installing the latest service pack for ConfigMgr is very similar to the initial installation of your site. Follow the steps previously described in the “Installing ConfigMgr” section of this chapter:
• Perform the same steps for running the prerequisite checker and downloading additional prerequisites.
• Because your site is already a primary site, the Available Setup Options page gives you the ability to upgrade or uninstall. As shown in Figure 8.13, select the option Upgrade an existing Configuration Manager or SMS 2003 installation.
• You may be prompted to uninstall an older version of the Windows Automated Installation Kit (WAIK) first; if so, be certain to restart your server after removing the WAIK.
To ensure proper functionality, also upgrade all remote consoles, using the same process as when upgrading your site.
Tip
Upgrade Your New Site to the Current ConfigMgr Service Pack Before Attaching to Your Hierarchy
When installing a new site, be sure to upgrade the site to your standard service pack level for ConfigMgr before you attach the site to your hierarchy. When you attach a site, all parent sites initiate a replication to ensure that the new site has proper content. A similar process occurs when you install a service pack on a child site. By your upgrading to your standard service pack level before attaching the site, the new site only needs to process one complete replication instead of two. Save yourself, your network, and your new site some processing cycles by ensuring the new site has your standard ConfigMgr service pack installed prior to attaching. The “Attaching to Parent” section of this chapter provides information about attaching a primary to a parent primary site.
After the upgrade completes, review the installation logs %SystemRoot%ConfigMgrPrereq.log and %SystemRoot%ConfigMgrSetup.log. Next, launch the ConfigMgr console, expand the Site Database node, and click Site Management to view the version information for your site. Figure 8.14 shows an example of the central site with ConfigMgr with SP 1 installed—both the version and build number have changed from the base release of ConfigMgr 2007.
Tip
Order of Operations—Upgrade Central Site First
If you have a multisite hierarchy in place, be sure to upgrade the central site first and then move down the hierarchy from the top.
For additional information about upgrading a ConfigMgr site to the latest service pack, search the Microsoft TechCenter for the appropriate ConfigMgr Service Pack check list. As an example, the ConfigMgr 2007 Service Pack 1 Upgrade check list is at http://technet.microsoft.com/en-us/library/cc161792.aspx.
After upgrading the site, you must upgrade the clients attached to the site. Clients can be upgraded with the Client Push Installation Wizard, Software Updates, Software Distribution, or Software Update Point Client Installation. See Chapter 12, “Client Management,” for additional information on upgrading clients.
Installing R2 is similar to installing a service pack on a site server. Fortunately, R2 is a much smaller installation. Prior to installing R2, you must install ConfigMgr SP 1 (or the latest service pack).
Note
Disable All SQL Replication Before Upgrading the Site to ConfigMgr 2007 R2
Similar to when you install a service pack, remove all database replication and subscriptions. Before upgrading to R2, check Microsoft’s article on disabling SQL Server database replication, located at http://technet.microsoft.com/en-us/library/bb693954.aspx. The “Disabling SQL Replication” section later in this chapter also discusses the steps to disable replication.
To upgrade to ConfigMgr 2007 R2, perform the following steps:
- Close all instances of the MMC on the site server (this includes the ConfigMgr console, SQL Server Management Studio, Computer Management, and so on).
- Launch Splash.hta from the R2 installation media.
- Click to install Configuration Manager 2007 R2.
- Review the Welcome page.
- Review and accept the license agreement.
- Verify the information and enter a valid product key.
- Click Finish to complete the installation.
Unlike when you install a service pack, the site version information does not change after R2. In addition, there is no client code update with ConfigMgr 2007 R2. Remember that if you have a multisite hierarchy in place, you need to upgrade your central site first.
To verify the R2 installation, check Add or Remove Programs or right-click the site in the ConfigMgr console and select Properties to view the Site Properties, as shown in Figure 8.15 for the CEN site. For additional information about upgrading your ConfigMgr Site to R2, read the Configuration Manager 2007 R2 installation check list at http://technet.microsoft.com/en-us/library/cc161948.aspx.
Note
Installing ConfigMgr on Windows Server 2008
Windows Server 2008 requires additional configuration changes when you install a ConfigMgr site or ConfigMgr site system. The document on configuring Windows Server 2008 for site systems at http://technet.microsoft.com/en-us/library/cc431377.aspx provides more information.
Site Properties is one of the first objects to configure after you install a new site. To access the Site Properties from the ConfigMgr console, select Site Database -> Site Management. Right-click the desired site (BXL is selected in this example) and select Properties, as displayed in Figure 8.16.
As Figure 8.16 shows, the General tab of the Site Properties dialog box provides important information about the BXL site installation, including the type and version, whether R2 is installed, and the build, site server, SQL server, and so on. You may also attach or detach from a parent site from this tab by selecting the Set Parent Site button. The “Attaching to Parent” section of this chapter demonstrates how to attach to a parent site.
ConfigMgr is able to “wake up” systems that are in a powered-off, hibernate, or sleep state. Once this is set, you can configure the wake-up on a per-advertisement or per-mandatory software update deployment (that is, a software update deployment configured with a deadline, as discussed in Chapter 15). The Wake On LAN tab of the Site Properties dialog box enables you to configure Wake On LAN, as shown in Figure 8.17.
To enable any support within ConfigMgr for Wake On LAN, first enable the Enable Wake On LAN for this site check box. (If a ConfigMgr 2007 service pack is not installed, the options are slightly different.) Select from the three available options, depending on the type of clients you will manage:
• The first two options describe power-on commands. These are primarily for managing Intel Active Management Technology–provisioned systems. AMT uses a different method for waking up systems than traditional wake-up packets, often referred to as magic packets in documentation and on the Internet.
• If all systems you intend to manage are AMT-provisioned, select the option Use power on commands only.
• If you have traditional wake-up packets, choose Use wake-up packets only.
• If you have a mixture of AMT and traditional wake-up packets, select the first option, Use power on commands if the computers support this terminology. Otherwise, use wake-up packets.
Remember that simply having systems with AMT support in the BIOS does not provision them for enterprise management. Review the information in Chapter 15 to ensure your clients are properly provisioned.
If you select the first or third option in Figure 8.17, you must also specify the Wake On LAN transmission method—either subnet-directed broadcasts or unicast—at the bottom part of this page.
Tip
About Subnet-Directed Broadcasts
To use subnet-directed broadcasts, you may need to work with your network teams to configure network hardware to allow these broadcasts from your primary site. Although subnet-directed broadcasts comprise the easiest method, your network team may consider this method the least secure. The ConfigMgr integrated help contains additional information regarding subnet-directed broadcasts versus unicast.
Click the Advanced button in Figure 8.17 to configure additional site settings for the wake-up process. The Advanced properties allow you to configure the retry count and delay, the number of systems woken up before a pause, and how much time in advance to wake up a system before a mandatory advertisement (or software update deadline) is scheduled to occur.
Note
Configure Clients to Support Wake On LAN
Configuring your ConfigMgr site to support Wake On LAN is pretty straightforward and is half of the required configuration. The other half is dependent on the client, which also must be configured to allow Wake On LAN. This is a BIOS configuration, and you can change it manually. Most computer manufacturers allow it to be configured by running an executable or script. Check with your computer manufacturer for specifics. If you still have problems after configuring the BIOS, verify you are using the vendor-provided network interface card driver, as the Windows-provided driver may have limited functionality. The article at http://technet.microsoft.com/en-us/library/bb932199.aspx includes information on troubleshooting Wake On LAN issues.
Use the Ports tab to customize ports the client will use to communicate with the site, as well as the port used by the site for Wake On LAN. As shown in Figure 8.18, you can configure both HTTP and HTTPS ports for client communications, and for each of these you can create an alternate port should you decide to change from the default ports.
If you want (or need) to use a different website than the default IIS website, enable the Use custom web site check box at the bottom of the dialog box in Figure 8.18. Enabling this check box requires previously configuring a custom website named SMSWeb on all site systems that require IIS for this site and any secondary sites attached to this site. The article at http://technet.microsoft.com/en-us/library/bb693482.aspx provides additional information on configuring custom websites for ConfigMgr sites.
The Advanced tab of the Site Properties dialog box allows additional configuration of your ConfigMgr site. Figure 8.19 shows the available options for the Advanced tab.
These options can have significant impact on the health of the ConfigMgr clients assigned to this site. The first part of this page deals with conflicting records.
• Automatically create new client records for duplicate hardware IDs— This is the default setting, and it should not be changed. Exceptions would be if you have a small site or a site requiring close monitoring of ConfigMgr client reinstalls or operating system reinstalls and if you need to preserve ConfigMgr client inventory history. (Automatically creating new client records was the only configuration available in SMS 2003, and it could not be modified.)
• Manually resolve conflicting records— This option gives the ConfigMgr administrator more power to determine how to handle duplicate hardware IDs. (Duplicate hardware IDs are discussed further in Chapter 21.) Using this option, systems with duplicate hardware IDs appear in the Conflicting Records node of the ConfigMgr console. To resolve conflicting records manually, you can choose which process to apply to the conflicting records:
• Merge the record—Merging combines the new record with the existing record. This can be an excellent option if you know the old resource is the same as the new resource, and you want to preserve hardware and software inventory. An example of this would be if you needed to reinstall the ConfigMgr client on a system.
• Create a new record—Creating a new record makes the newer record the official record and marks the old record as obsolete.
• Block—This process creates a new record for the client and marks it as blocked. ConfigMgr does not manage systems in the blocked state, and the older record remains in the database. You may want to consider blocking a system while investigating the reason for the record conflict.
When a new record is created, the old record is marked obsolete and purged from the ConfigMgr database, based on configured maintenance tasks. Remember that as long as a system appears in the Conflicting Records node of the ConfigMgr console, it is in an unmanaged state.
Note
Client Records and Direct Membership Rules in Collections
When a new record is created (automatically or manually), the client also receives a new ResourceID. The ResourceID is a key property of the client and is used to create direct membership rules for collections. When the client receives a new ResourceID, although all direct membership rules that referenced the ResourceID with the old computer account still exist, they will not apply to the new client record. This is very important to remember when troubleshooting software distribution problems.
The client membership is typically retained for query-based membership rules, because the query-based rule is generally dependent on a specific hardware configuration, NetBIOS name, or other static information on the client.
The second section of the Advanced tab of the Site Properties dialog box allows you to specify settings for publishing and secure key exchange:
• Publish this site in Active Directory Domain Services— Use this option to leverage Active Directory for content location requests and site assignment for ConfigMgr clients. If you previously published to Active Directory and then choose to clear this check box, the information is not removed from Active Directory and you must delete it manually.
• Publish the default management point in DNS (intranet only)— This choice will publish the default management point in DNS as a Service Location (SRV) record. Consider this option only if the site system is configured with the management point role.
Tip
Publishing the Default Management Point to DNS
If you are not leveraging Active Directory and do not use WINS, consider enabling the option to publish to DNS. Review the information at http://technet.microsoft.com/en-us/library/bb633035.aspx to determine if you need to publish to DNS. Information on configuring ConfigMgr clients to find their MP using DNS publishing is available at http://technet.microsoft.com/en-us/library/bb633030.aspx.
• Require secure key exchange between sites— Leave this option enabled to maintain a higher level of security for site-to-site communications. With this option enabled and site data published to Active Directory, no additional configuration is required. If the site is not publishing site data to Active Directory, use the Preinst.exe hierarchy maintenance tool from the ConfigMgr toolkit to copy the child site’s public key to the parent site.
Chapter 3 provides information on Active Directory schema extensions for ConfigMgr, and http://technet.microsoft.com/en-us/library/bb632936.aspx includes instructions on manually publishing the default management point to DNS.
The Site Mode tab allows you to configure native mode or mixed mode and provides additional settings required for each mode. At first glance, the Site Mode tab appears to be simple, in that you can easily switch from mixed mode to native mode. Chapter 6 includes a complete discussion of when to switch to native mode.
Figure 8.20 shows there are several settings to configure while in mixed mode.
The Approval settings section allows you to determine how ConfigMgr will approve systems. Every system (except mobile device clients) that installs the ConfigMgr client must be approved before it can be managed in a mixed mode site. Select one of the three available options to manage approval for computers joining the site:
• Manually approve each computer— This is obviously the most labor-intensive approach, and requires the administrator to approve each new client. The manual approval process occurs at the ConfigMgr site to which the client is assigned.
• Automatically approve computers in trusted domains (recommended)— This is the suggested setting, because it is the most secure. The setting allows ConfigMgr to approve all computers joined to domains trusted by the site server. For this setting to be secure, processes should be in place to prevent untrustworthy computers from joining trusted domains. If you have multiple trusted domains, you must configure the sites’default management point with a Fully Qualified Domain Name (FQDN).
• Automatically approve all computers— This setting is the least secure, and allows all assigned computers to join the site.
Tip
Reverting from Native to Mixed Mode?
In native mode, approval is not required because client authentication using PKI certificates takes the place of approval. It is common to see clients with a state of “unapproved” in the ConfigMgr console while in native mode. If you must revert to mixed mode, you will need to approve the unapproved clients manually to manage them.
Other settings in Figure 8.20 include the following:
• If you have ConfigMgr clients only (meaning there are no SMS 2003 clients), keep the default enabled setting of This site contains only ConfigMgr 2007 clients. This setting enables a more secure method of communication, but is not compatible with SMS 2003 clients.
• The final mixed mode setting, Encrypt data before sending to the management point, is used to encrypt hardware inventory, software inventory, and other client data to prevent easy viewing of intercepted client data.
Chapter 6 discusses planning for site security modes. Migrating to native mode requires significant knowledge of your Public Key Infrastructure (PKI), so be sure to know that infrastructure (or know someone who does). Chapter 11, “Related Technologies and References,” includes information on PKI management. Migration to native node is relatively simple when only the first site is deployed, site properties are not configured, and clients are not yet installed.
You can find a detailed check list with the steps to migrate a site to native mode at http://technet.microsoft.com/en-us/library/bb632727.aspx. You will also find links from that document that provide more detail for each step (and any additional required steps).
Three types of certificates are required for native mode:
• Site server signing certificate— Use this certificate to sign client policies. The certificate must be created and deployed to the ConfigMgr site before switching to native mode. In a multisite environment, you must configure this certificate directly on each primary site database. You cannot use the console on a parent site; to make the configuration changes, you must be directly connected to that site.
• Web server certificate— Use this certificate to encrypt data and authenticate the server to clients. The certificate must reside on ConfigMgr site systems such as the management point and distribution point.
• Client certificate— Install this certificate on computers that will be ConfigMgr clients to allow the client to authenticate to ConfigMgr site systems. Installing this certificate on the management point enables monitoring management point health.
See http://technet.microsoft.com/en-us/library/bb680733.aspx for additional information on certificate requirements for native mode.
To enable native mode, perform the following steps:
- Navigate to the Site Mode tab of the Advanced properties dialog box of the connected site. (Remember, you must be logged in to the site you are converting to native mode, and using the ConfigMgr console on that local site.)
- Change the Site Mode selection from Mixed to Native. Click Browse.
-
From the Available Certificates dialog box, select the certificate issued to the name The site code of this site server is xxx. Verify it has an intended purpose of Document Signing and then click OK. (This example uses BXL as the site code. Your certificate must contain the site code under Issued to name; otherwise, ConfigMgr will refuse it.)
After you select the certificate, native mode settings will appear similar to those displayed in Figure 8.21 for the SCCMUnleashed.com BXL site.
- Click OK to apply the configuration. ConfigMgr will start the process of migrating the site to native mode. The time to complete the migration will vary, depending on the number of policies that require signing. For this particular fresh install of ConfigMgr, the migration was complete in less than 5 minutes.
- To verify the migration is complete, expand System Status in the ConfigMgr console and then click Status Message Queries. Right-click All Status Messages and select Show Messages. Accept the default of 1 hour for the prompted value so that status messages from the last hour display. Search the results for the following status messages:
The site is now migrated to native mode.
The next step is enabling client communication to the native mode site, which is straightforward because there are no existing clients and the ConfigMgr components are not yet configured. You will need to configure IIS to use the web server certificate to allow client communications.
The steps to configure IIS vary, depending on the version of Windows Server that is running:
• For Windows Server 2003, perform the following steps:
1. Open IIS Services Manager, expand the Web Sites node, right-click the Default Web Site, and select Properties.
2. Select the Directory Security tab and then click Server Certificate.
3. Follow the wizard and select Assign an existing certificate.
4. Select the proper certificate; verify the Intended Purpose field has a value of Server Authentication.
5. Verify the SSL port is configured to number 443 and then finish the wizard.
• Perform the following steps if you are using Windows Server 2008:
1. Open IIS Services Manager, expand the Sites node, right-click on Default Web Site, and select Edit Bindings.
2. Select the https entry and click Edit.
3. Select the appropriate certificate and verify that the Intended Purpose field has a value of Server Authentication.
4. Click OK and then click Close to complete the configuration.
Note
Enabling IIS with Distributed Site Systems
If management points, distribution points, or other client-facing roles are configured on multiple servers, you must configure IIS on each server to use the web server certificate.
The final native mode migration step is to ensure clients have a proper certificate for communications to your management point, distribution point, and other roles that interface with the client (the fallback status point and server locator point roles do not require certificate-based communication). Work with your PKI team to force clients to receive the required certificate automatically. For additional information on deploying PKI certificates for native mode, see http://technet.microsoft.com/en-us/library/bb680312.aspx.
You now have a healthy ConfigMgr site in native mode. The next task is to install site systems, which is covered in the next section of this chapter. Chapter 2 introduces the different types of site systems.
Site systems “make the world go ‘round” in the ConfigMgr world. As with most site configuration, almost all of these settings are configured once and typically do not require later modification. Each ConfigMgr site contains a site server and one or more site systems. Site systems are components of ConfigMgr, a number of which you may or may not desire to use. Although some components are required, most are optional, depending on the specific configuration. In smaller sites, all site systems (also called site roles) may be installed on a single server. Earlier in the “Installing ConfigMgr” section of this chapter, we selected Custom Settings for the installation type, and accepted the default configuration for a custom installation. Based on the options selected during site installation, ConfigMgr installs the following site systems automatically:
• Component server— This site system does not have configurable options. Any site server running a site system requiring the ConfigMgr 2007 service will have the component server listed as a site system.
• Distribution point— A distribution point is used to stage source installation files, driver package files, operating system images, and software updates for client use. By default, this is a standard distribution point, meaning that when clients request a location for content (installation files), ConfigMgr forwards a Universal Naming Convention (UNC) path to allow the client to access the data via service message blocks (SMBs).
If you want to use Download and Execute for installation packages, you must enable the check box to allow clients to transfer content using BITS, HTTP, and HTTPS. This is often referred to as a BITS-enabled DP. When this check box is enabled, the client will access content from the distribution point using HTTP and use BITS to “trickle” the installation files to the local system. Chapter 14, “Distributing Packages,” contains additional information about distribution points.
You also can create a branch distribution point for a new site. Branch distribution points are described later in this section.
Use the Group Membership section at the bottom of the Distribution Point Properties dialog box to create distribution point groups. This capability allows you to group DPs easily and becomes very helpful when sending content to distribution points. As an example, you can make a DP group of all your DPs in Europe, and then any time you need to send content to the Europe DPs, simply select the group rather than the tedious process of selecting each DP manually.
The Multicast tab appears when ConfigMgr 2007 R2 is installed, and it’s only used during Operating System Deployment (OSD). From this tab, you may specify the User Datagram Protocol (UDP) ports to use, the transfer rate, and the maximum clients. You can also enable scheduled multicast. With scheduled multicast, you can configure the start delay from the time the first system requests content, as well as specify the minimum session size. When scheduled multicast is enabled, the multicast begins either when the Start Delay time is exceeded or the number of session requests to the DP is larger than the minimum session size, whichever comes first. Multicast requires distribution points that are BITS enabled. For additional information, check Microsoft’s documentation discussing multicast configurations for OSD at http://technet.microsoft.com/en-us/library/cc431383.aspx.
The Virtual Applications tab also appears with ConfigMgr 2007 R2 installed. Enable this option to configure application streaming to target computers. You must BITS-enable the distribution point to enable virtual application streaming.
• Management point— If you will be assigning clients to this site, the MP role must be enabled. The management point is the primary connection point between clients and the ConfigMgr site. Depending on how many systems will use this MP, you may want to consider offloading the MP role from the site server. Each primary site has one active MP, which clients use to obtain policy, forward inventory, and the other client communication requirements. If you plan to manage mobile devices from this site, enable the check box to allow devices to use this management point.
The MP can be configured to use a database replica. If the SQL database on your primary site is very busy all the time, you may consider configuring a SQL database replica and configuring the MP to use the replica for content information. By default, the MP computer account is configured to connect to the database. You may need to grant rights to allow this communication. Alternatively, you can specify an MP connection account to establish this communication if desired. The “Using Replicas and Offloading Site Roles” section of this chapter contains information for creating a database replica.
• Site server— This is a standard role added during every site server installation. No configuration is required.
• Site system— A site system can be a server or share that supports the site. The site system may perform more than one role. It is highly recommended that you specify the FQDN for intranet clients (the FQDN must be specified for Internet-based clients).
If you have multiple domains and do not use a fully replicated WINS or have a disjointed namespace, you may see errors in client logs where the client is unable to obtain content for a distribution. One of the first places to look to resolve this issue is whether you have specified an intranet FQDN. When the site is in native mode, the FQDN specified in the server certificate subject name must match the intranet FQDN specified in the Site System Properties page, as displayed in Figure 8.22.
By default, the site server’s computer account is used to install the site system, although you can specify a different account on this page if desired.
You can also specify the option Enable this site system as a protected site system. By checking this box, you then select the boundaries that can use this site system. For example, you may have a DP on a remote WAN, and you want to ensure that only systems in that remote site have the ability to access content from the DP, enable the protected site system, and select the boundaries to protect. Protected systems are used for DPs and state migration points.
The final check box, Allow only site server initiated data transfers from this site system, can be used for systems that are configured for site system roles that are supported across forests. Checking this box forces the ConfigMgr site to use the Site System Installation account to connect to the remote site system. Even if a trust exists, the Site System Installation account will be used.
• Site database server— This site system displays the SQL Server name and the SQL database name used by this ConfigMgr site. No configuration is required for the site database server.
As this discussion shows, Configuration Manager automatically configures many site systems, even when using a custom configuration for the ConfigMgr installation. Let’s look at the other site roles and using additional servers for site roles.
Use the Site Role Wizard to add more roles to an existing site system. Right-click the server name and then select New Roles to initiate the Site Role Wizard. The first step in the wizard allows you to configure the same options visible in Figure 8.22, which shows the Site System Properties dialog box. Verify the settings for this site and then click Next in the wizard to select additional roles. The rest of this section describes each of the remaining roles you can configure from the Site Role Wizard:
• Fallback status point— Configure a fallback status point (FSP) before you begin to deploy clients. The FSP helps you verify successful client installation, identify client installation failures, and provide a method for clients to report when they are not able to contact a management point. The FSP also helps identify communication problems with clients in native mode.
You can configure how many state messages to forward to your ConfigMgr site each throttle interval, thus preventing the FSP from overwhelming your ConfigMgr site. If your site is configured in native mode and you have specified an Internet FQDN, you can configure the FSP to allow intranet-only connections or both intranet and Internet connections.
You may need to perform additional configurations to ensure that your clients use the FSP. The section “How to Assign the Fallback Status Point to Client Computers” in the ConfigMgr integrated help file provides additional information.
• PXE service point— Use a PXE service point to leverage the Preboot Execution Environment (PXE) for ConfigMgr Operating System Deployment. When you enable the PXE service point, you receive notification that ConfigMgr will open UDP ports 67, 68, 69, and 4011 on the site system so it can respond to PXE requests.
If you have ConfigMgr 2007 R2 installed, you also have the option to enable Unknown Computer Support. This allows you to deploy imaged systems not currently managed by ConfigMgr.
Caution
Unknown Computer Support and the PXE Service Point
Use extreme caution when using Unknown Computer Support and the PXE service point. When Unknown Computer Support is enabled, any unknown computers that boot to PXE will attempt to run mandatory task sequences. If you have mandatory task sequence advertisements for OSD, you may encounter unexpected results on a new (unknown) system, or an unhealthy ConfigMgr client. Automatically deploying an image to an unknown computer (which happens to be a critical web server for your company) may cause you to quickly dust off your resume. On the lighter side, it may also help you standardize on Windows! To prevent an unintentional operating system deployment to one or multiple systems, create a text file that contains the Media Access Control (MAC) addresses (one per line in the text file) for the systems to exclude and then store it on each PXE service point. Separate the MAC address elements with colons (for example, ab:cd:01:23:45:67). Also, in the Registry on each PXE service point, add a string value named MACIgnoreListFile at HKEY_LOCAL_MACHINESoftwareMicrosoftSMSPXE and point it to the full path to the text file. See http://technet.microsoft.com/en-us/library/cc431378.aspx for more information.
You can also enable the option Require a password for computers that boot to PXE, which allows you to restrict PXE OS deployment to users who know the password (this typically is your service desk and on-site support teams).
One final important step for configuring PXE is that you must either create a self-signed certificate or import a certificate. If your site is configured for native mode, you must import a certificate from a trusted root Certificate Authority.
• Reporting point— Create a reporting point to view reports and dashboards for your site. Many ConfigMgr administrators also refer to this as web reporting. ConfigMgr contains over 300 built-in web reports. If you install ConfigMgr R2, you will have nearly 400 built-in web reports. You can also create additional web reports as required. You must install IIS prior to installing the reporting point.
Review Figure 8.23 for reporting point configuration. The information shown is the default settings. Because the site code in Figure 8.23 is BXL, the report folder is SMSReporting_BXL by default. The report folder name will be part of the URL used to access the web reporting site.
Two types of rights are required for access to view web reports:
• Add users and user groups to the local SMS Reporting Users security group on the server to grant them access to the Web Reporting site.
• Grant the users or user groups class rights to view all web reports, or instance rights on specific reports, as needed.
Chapter 18, “Reporting,” contains additional information about reporting points.
• Reporting services point— With ConfigMgr 2007 R2, you can optionally install a reporting services point as well. Install SQL Reporting Services (SRS) before attempting to configure a reporting services point.
Note
Multiple Instances of SQL Reporting Services May Cause Issues
If multiple instances of SRS exist on the same site, you may encounter unexpected results when installing a reporting services point. During installation, ConfigMgr queries WMI on the server for all instances of SQL Reporting Services, and it always installs the reporting services point on the first instance returned.
• Asset Intelligence synchronization point— If you have Microsoft Software Assurance (SA), you can create an Asset Intelligence synchronization point to download Asset Intelligence catalog information and upload custom software title catalog information (if desired). To configure the synchronization point, you must obtain a certificate from Microsoft and import it during configuration. You can also specify a proxy server and proxy server account if your network requires proxy authentication. By default, the synchronization schedule runs every 7 days. See Chapter 18 for additional configuration information.
• Out of Band service point— If you have systems with Intel Active Management Technology (AMT), enable the Out of Band service point to improve control of Wake On LAN and other remote management needs. AMT is a technology used in vPro; systems with vPro installed can be managed using the Out of Band (OOB) service point. OOB in this instance refers to systems that are connected on the LAN, but not running Windows (or you don’t have access remotely to Windows on the system). Using vPro, you can remotely connect to these systems, even while the system is powered off, provided all configurations are completed in advance.
As displayed in Figure 8.24, you can configure the properties of the Out of Band service point role to increase or reduce the network and CPU utilization of the site due to the OOB service point. As an example, when you create and enable Wake On LAN for an advertisement, the OOB service point will wake all targeted vPro-enabled systems using the settings specified in Figure 8.24. Review the ConfigMgr help file for additional information regarding each property in Figure 8.24.
Note
Provision Computers for AMT
You must set up and configure (provision) AMT-based computers so ConfigMgr can manage them with the Out of Band service point. There are two types of provisioning:
• Out of Band— A system without a ConfigMgr 2007 SP 1 client
• In Band— A system with a healthy ConfigMgr 2007 SP 1 client
Check the document at http://technet.microsoft.com/en-us/library/cc431371.aspx for a discussion of the provisioning process. The check list at http://technet.microsoft.com/en-us/library/cc161943.aspx specifies the steps to enable Out of Band Management in ConfigMgr 2007. Chapter 11 discusses AMT.
• Server locator point— Create a server locator point (SLP) for clients to complete site assignment and find management points when they cannot find that information in Active Directory. As discussed in Chapter 4, those scenarios requiring an SLP include the following:
• You have workgroup clients or clients from another Active Directory forest.
• You have not extended Active Directory.
• You have extended Active Directory, but have not configured all ConfigMgr sites to publish information to Active Directory.
You do not need to install an SLP if all sites are configured for Internet-based client management (IBCM).
Configure IIS on the site system before installing the SLP. When installing the SLP, you can choose to use the site database or a database replica. You can also specify a server locator point connection account if you require a different account than the SLP computer account. See the “Using Replicas and Offloading Site Roles” section for information on creating a database replica.
Specifying the Server Locator Point
You can specify the server locator point for clients using one of the following methods:
• Manually publish the server locator point in WINS so that clients can automatically locate it. Client computers search WINS for the server locator point if the client.msi installation property SMSDIRECTORYLOOKUP=NOWINS has not been specified.
• Assign the server locator point to clients during client installation, using the client.msi property SMSSLP=<server locator point name
> on the CCMSetup command line.
If the SLP needs to be added manually to WINS, such as when Computer Browsing in the domain is disabled, perform the following steps:
- Open a command prompt (Select Start -> Run, and then type cmd).
- At the command prompt, type netsh and then press Enter.
- Type wins and press Enter.
-
Type server and then press Enter.
To manage a remote WINS server, type server <\<servername> or XXX.XXX.XXX.XXX>, specifying the NetBIOS name or IP address.
-
Type the appropriate command on a single line, as in the following example:
Perform the following steps to validate the SLP was added to WINS successfully:
- Open a command prompt.
- At the command prompt, type netsh and then press Enter.
- Type wins and then press Enter.
-
Type server and then press Enter.
To manage a remote WINS server, type server <\servername > or XXX.XXX.XXX.XXX>, specifying the NetBIOS name or IP address.
-
Type the appropriate command, as in the following example:
show name Name=SMS_SLP endchar=1A
• Software update point— Create a software update point (SUP) to use the Software Updates feature of ConfigMgr. Configure IIS and install WSUS 3.0 SP 1 prior to adding this role. Your first SUP (usually installed on your central site) synchronizes with Microsoft Update over the Internet to obtain patch detection and download information. If you have multiple sites in your hierarchy, all child site SUPs will synchronize with the parent SUP. All primary sites must have an active SUP. Clients also connect to the active SUP (for its assigned site) to perform updates scanning to determine patch applicability.
When creating the SUP role, specify the proxy server name and configure an SUP proxy server account if needed. You can configure this for both the central site to access Microsoft Update and for child sites to access SUP on their parent site. Also, be sure to enable the new SUP as the active SUP, so that clients can use it.
You must configure the SUP component after installing the SUP role. Refer to Chapter 15 for additional information about configuring the SUP.
• State migration point— Create a state migration point (SMP) to store user state migration data during reimaging or hardware replacement. Figure 8.25 shows configuring an SMP. You can see the directory D:UserData is specified on the local drive of the ConfigMgr site. The Max Clients setting indicates the maximum number of clients that can be saved to the folder at any given time. Minimum Free Space prevents additional migration data from writing to the disk, if the drive falls below minimum free space.
Also in Figure 8.25, you can see the deletion policy is configured as 10 days, so that once the data has been successfully restored (and marked for deletion), the data is automatically removed after 10 days. If you check the box Enable restore-only mode, all requests for user state store will be refused for this SMP, although the SMP will remain operational for restore operations. Chapter 19, “Operating System Deployment,” contains additional information about state migration point configuration.
• System Health Validator point— Install a System Health Validator point if you will use ConfigMgr for Network Access Protection (NAP). Installing the role is very easy because there are no settings to configure! However, you must install this site system role on Windows Server 2008 configured with the Network Policy Server (NPS) role. Refer to Chapter 15 for more information.
• Branch distribution point— Create a branch distribution point (BDP) on a branch office computer to allow clients in that office to access content locally. Think of a small office with 10 computers—you may not want to install a dedicated server and primary or secondary ConfigMgr site. When you install a branch distribution point, systems in the branch office will still traverse the WAN for management point traffic (ConfigMgr machine policy, submitting inventory, and so on), which is nominal traffic. The branch distribution point allows systems to install software and software updates from a local distribution point, thus removing WAN traffic for those installations without incurring the overhead of another site at the remote location. You can install a branch distribution point on Windows XP, Windows Vista, Windows Server 2003, Windows Server 2008, and newer Windows operating systems.
Create a new site system (as described in the next section, “New Site System Server Wizard”) on a new server or workstation and then select Distribution Point as the role. (In order to create a branch distribution point, the target system must be a healthy ConfigMgr client.) Configure the next page of the wizard as shown in Figure 8.26 to create a branch distribution point. The example in Figure 8.26 allows ConfigMgr to determine which partition to use on the site system. If the site system has multiple partitions, you can specify a specific partition if desired. You can also reserve space on the drive for the operating system, to prevent ConfigMgr from using the entire drive. Figure 8.26 shows reserved space configured as 500MB. For additional information about configuring multicast and enabling virtual application streaming, review the bullet at the beginning of this section regarding distribution points.
Branch distribution points use BITS to download content from a standard BITS-enabled distribution point. If the standard BITS-enabled DP is configured with protected boundaries, the boundaries of the BDP must be included or else the BDP will not be able to download content from the standard DP. Another important consideration is that when a client accesses a BDP for content, the content is only accessed via SMB (not BITS).
Note
Comparing Distribution Points to Branch Distribution Points
After reviewing the information for both distribution points and branch distribution points, you may wonder which is best for you. And as almost all things technical, it depends. Consider BDPs for small-office scenarios. Here are a few points to consider:
• The BDP depends on the ConfigMgr client to be installed and properly configured.
• The BDP must be a member of the domain, and not a Windows 2000 system.
• BDPs are not supported on Internet-based clients.
• BDPs do not support multicast for OSD.
• If a BDP is installed on a workstation operating system (for example, Windows XP or Vista), it is limited to 10 concurrent client connections.
Microsoft provides information about standard and branch distribution points at http://technet.microsoft.com/en-us/library/bb680853.aspx. Another helpful document is at http://technet.microsoft.com/en-us/library/bb932184.aspx.
Now that you know how to configure each site role, it’s important to know that you can offload site roles to reduce the load on your primary site server. For many environments, offloading roles may not be required. However, if you notice one role is using a large amount of bandwidth, or CPU cycles, consider offloading it by creating a new site system, as described in the next section.
Use the New Site System Wizard to enable additional servers (or workstations in the case of branch distribution points) for your site. As discussed in Chapter 4, many site system roles can be offloaded from the ConfigMgr site. The site server that you add will typically be a server operating system. The current exception is for a branch distribution point, which is a supported site role on any valid operating system higher than Windows 2000 SP 4.
To create a new site system, perform the following steps:
- Right-click Site Systems in the ConfigMgr console and select New -> Server.
-
In the new Site System Wizard, enter a name for the site server (usually the server name) and enter an FQDN if possible, as shown in Figure 8.27.
You can also specify an alternate account for installing the site system, if the ConfigMgr Site computer account does not have administrative rights on the new server.
- Click Next in the wizard and then select any valid role for the new site server. The role(s) selected in this page determines the remainder of the configuration pages for the wizard. Each selected role will have its own configuration page to complete the wizard. You may also choose not to select any roles at this time, and just configure it as a site system.
Use the New Site System Server Share Wizard to create a distribution point on a share on a server. Using this method lets you control exactly where ConfigMgr places source files on the drive. Also with a server share, no ConfigMgr components are installed on the server—it’s simply a share clients connect to for obtaining content. If you enable the server share for BITS, ConfigMgr will automatically configure a website on the server. Virtual application streaming is also available (for R2 sites), but multicast is not.
Create a share on the desired server and then grant the site server’s computer account control of the share. This is displayed in Figure 8.28.
A number of ConfigMgr activities can affect the performance of your site server; these include the number of clients, the frequency of machine policy polling intervals, the frequency of hardware and software inventory, software updates, and so on.
Chapter 4 introduced an approach for improving performance known as offloading site roles. You can offload site roles such as distribution points and the management point in larger sites. This helps site server performance in the following ways:
• Offloading the distribution point results in fewer connections to the site server, because all clients connect to the DP to download and install software.
• Offloading the management point means clients no longer need to connect directly to the site server.
You may also want to consider offloading other site roles such as the reporting point, software update point, proxy management point, device management point, and server locator point.
When you offload the management point to another server, clients in your site will connect to that offloaded server to forward inventory, query for machine and user policy, and perform other MP functions. However, offloading the management point may not relieve as much activity from the site server as you had hoped. Every time a client queries the MP for policy, the management point queries the site database to determine policy information for the client. (You can see this traffic by running SQL Trace on the site server ConfigMgr database and enabling verbose and debug logging for the management point logs.) You may want to offload this often resource-intensive function by creating a SQL database replica. In ConfigMgr 2007, you can use a replica for the management point, proxy management point (PMP), device management point (DMP—part of a management point), and server locator point.
SQL Server replication uses a publisher (this is the source database, typically your ConfigMgr primary site) and a subscriber (the destination of data replica, a server with SQL Server installed). Before setting up replication, ensure your primary site is configured properly and is healthy. Next, install SQL Server on the Windows system that will be the subscriber. (You can have multiple subscribers, although the examples in this chapter only refer to a single subscriber.) You will also create a snapshot publication, which is typically used to publish data when data changes are infrequent and there is a small amount of data. This data is read-only on the replica, and does not have to be synchronized back to the publisher. The next sections discuss the process of creating a replica and offloading the management point to the replica server.
Before setting up replication, you must configure both the publisher and the subscriber. Perform the following steps:
- Run the SQL Server 2005 Surface Area Configuration Wizard (Start -> Programs -> Microsoft SQL Server 2005 -> Configuration Tools -> SQL Server Surface Area Configuration Wizard). This tool configures required services and connections, and Common Language Runtime (CLR) integration. Click the link near the bottom of the page for Surface Area Configuration for Services and Connections, displayed in Figure 8.29.
- Expand the Database Engine node and select Remote Connections. Select Local and remote connections and then choose Using TCP/IP only. Click OK and then select the link for Surface Area Configuration for Features, also shown in Figure 8.29.
- Expand Database Engine and select CLR Integration. Check the box Enable CLR Integration, select OK, and then exit the utility.
-
Modify SQL Server so that data larger than the default size of 64KB will replicate successfully. The length of some data to be replicated may be longer than the default maximum. Open SQL Server Management Studio on the publisher (site server database) and open a new query. Be sure to select your ConfigMgr database as the source database in the dropdown at the top. Execute the following command:
EXEC sp_configure 'max text repl size', 2147483647
-
Review the Messages window for any reported issues. Next, run the following command to commit the configuration changes to SQL Server:
RECONFIGURE WITH OVERRIDE
- Verify the command completed successfully.
- Use SQL Server Management Studio to create a new database for the subscriber. A logical name would be the site database name appended with “_REP” at the end. This example uses SMS_BXL_REP to indicate the database is a replica database from the ConfigMgr BXL primary site.
Now it is time to perform the tasks to set up replication. These consist of setting up the publisher and the subscriber and creating a publication. Configuring the publisher computer can be time consuming. Before performing these steps on a production server, it is best to create your first replica on a test site.
Perform the following steps to configure the publisher to publish the site database for replication:
- Create a share on the publisher (the server with the ConfigMgr site database). Grant the proper access for SQL Server to properly read and write to that share. This example creates a directory named D:SQLDataRepl with a share named \TUMBLEWEEDREPL.
- Launch SQL Server Management Studio on the server containing the ConfigMgr site database. Right-click Replication in the left node and then select Configure Distribution to start the wizard.
- After the Welcome page, select the default option ‘<servername>’ will act as its own Distributor, as displayed in Figure 8.30. Click Next, and SQL Server will create a distribution database and log.
- On the Snapshot Folder page, enter the UNC path to the share previously created. For this example, enter \TUMBLEWEEDREPL.
- On the Distribution Database page, specify the name and location of the database and database log file. Take the defaults as shown in Figure 8.31.
- On the Publishers page, select the SQL Server computer that hosts the ConfigMgr site database.
- On the Wizard Actions page, check the Configure Distribution box and then click Next. Verify the settings and then click Finish.
- Wait several minutes for the Configure Distribution Wizard to finish configuring the distributor and enabling the publisher. The wizard will display “Success” or “Fail.” Close the wizard.
The next task is to configure a new local publication of the required ConfigMgr tables. Fortunately, only a small number of objects (approximately 100) in the ConfigMgr database require replication. Because each environment can vary, there is no exact rule regarding size, but you can expect the size of a SQL replica database to be approximately 80% to 90% smaller than the ConfigMgr site database. Perform the following steps:
- On the server running the ConfigMgr site database, launch SQL Server Management Studio and then expand the Replication node. Right-click Local Publications and then select New Publication to start the New Publication Wizard.
- After the Welcome page, select the ConfigMgr site database as the publication database, as shown in Figure 8.32.
- For the publication type, select Transactional Publication. In a transactional publication scenario, a replica database pulls an entire snapshot the first time it connects, and then the publisher streams transactions to the subscribers.
- The next page of the New Publication Wizard is the Articles page, where you select database tables and other objects (views, functions, stored procedures, and so on) required for replication. This will be the most time-consuming page of the entire replication process. Be sure to take your time, and select all necessary objects.
Additional Steps for Replicating Objects
The objects in the tables may change from one service pack to the next (as an example, the ConfigMgr original release requires 48 tables, whereas ConfigMgr SP 1 requires 49 tables for replication), so perform the following procedures each time you upgrade or install a new ConfigMgr site:
-
In SQL Server Management Studio, open a new Query Window and select the ConfigMgr database as the current database. Execute one of the following commands, depending on the role of your replica:
• If your replica is for a management point, execute this command:
Select ObjectName from ReplicatedObjects where SiteSystemType = 'MP'
• If the replica is for a server locator point, execute
Select ObjectName from ReplicatedObjects where SiteSystemType = 'SLP'
Information contained in the MP query is inclusive of the information for the SLP query, so if you are creating one replica for both the MP and SLP, run the first command only.
-
Copy the results into your favorite spreadsheet program for easy reference. At this point, you will need to browse through tables, views, stored procedures, and functions in the wizard to select all required objects.
Functions generally start with fn, views generally start with v_, and stored procedures generally start with sp, MP, or DMP. Just about everything else is a table.
- Click Next to continue. Figure 8.33 shows the Articles page of the New Publication Wizard.
- Review the information on the Article Issues page and click Next to continue.
- Click Next on the Filter Table Rows page, because no filters are required.
- On the Snapshot Agent page, displayed in Figure 8.34, check the box Create a snapshot immediately and keep the snapshot available to initialize subscriptions.
- On the Agent Security page, click the Security Settings button and enter a valid Windows account, or select the option to run the agent under the SQL Server Agent service account.
- On the Wizard Actions page, select the option Create the publication and then click Next. Enter a publication name (BXL_Publisher in this example) and click Finish. The Creating Publication dialog box may appear for several minutes while creating the snapshot. Verify “Success” in the dialog box and then close the wizard.
You have successfully created the publisher. A single publisher can provide replication for many subscribers. As an example, you could have five secondary sites with proxy management points, all using a SQL replica of the primary site database.
With the publisher created, it is time to configure the subscriber. Perform the following steps:
- On the server intended to host the subscriber, launch SQL Server Management Studio, expand the Replication node, right-click Local Subscriptions, and then select New Subscriptions.
- After the Welcome page, enter the name of the SQL Server running the publisher you previously created and select that publisher, as displayed in Figure 8.35.
- On the Distribution Agent Location page, leave the default of Run each agent as its Subscriber (pull subscriptions). Click next.
- On the Subscribers page, select the replica database name (SMS_BXL_REP).
- On the Distribution Agent Security page, click the ellipsis (...) either to configure a process account or to configure the agent to run under the SQL Server Agent service account.
- On the Synchronization Schedule page, configure the agent to run on a schedule. Click the dropdown box and select Define Schedule.
- On the New Job Schedule page, configure the job to run every 15 minutes.
- On the Initialize Subscriptions page, configure the initialization to occur immediately.
- On the Wizard Actions tab, check the box Create the subscriptions. Click Next.
- Review the Summary page and then select Finish to start the subscription process.
The replication will complete within several minutes. To monitor status, expand the SQL Server Agent, right-click Job Activity Monitor, and then select View Job Activity. If the Job Activity displays an error for the replication job, you can view the logging for that job by expanding SQL Server Agent -> Jobs, right-clicking the job in question, and selecting View History to display the Job Activity Monitor, as displayed in Figure 8.36.
SQL replication is now configured. Several post-replication setup configuration tasks are necessary to allow ConfigMgr site systems to use the replica. Perform the following steps:
-
Start by creating database roles. Three roles are required, with proper permission granted to those roles. Using SQL Server Management Studio, execute the following statement on the site replica (subscriber) database:
-
After successfully creating the roles, grant each role proper access to the replica. The following SQL statements (listed at http://technet.microsoft.com/en-us/library/bb633288.aspx) are specific to ConfigMgr 2007 SP 1. Execute these statements on the site replica (subscriber) database (you can also find these statements in the article referenced in the previous sentence, which will make it easy to copy/paste):
Note that these SQL statements were updated for SP 1, and the SQL statements may need to be updated at a future date. Review http://technet.microsoft.com/en-us/library/bb633288.aspx for current information.
-
Now it is time to grant the appropriate rights for the site systems to access the site database replica. Use the Local System account or create connection accounts. This example uses the Local System account. Execute the following SQL statement against the subscriber server:
In this case, SCCMUNLEASHED is the domain name and Telephone$ is the name of the computer account.
-
Add the roles for the MP, DMP, and SLP by executing the following SQL statements:
Congratulations! You have configured your SQL database replica for use by ConfigMgr. For additional information on configuring SQL Server site database replication, refer to http://technet.microsoft.com/en-us/library/bb693697.aspx.
When planning to upgrade a site to a new ConfigMgr service pack (or upgrading to a newer version of ConfigMgr), you must first disable SQL Server replication. Perform the following steps:
-
To disable replication from the publisher, open SQL Server Management Studio, right-click Replication, and then select Disable Publishing and Distribution. Follow the wizard, and select the option in Figure 8.37 to disable publishing. Click Finish to disable replication from the publisher.
Caution
Disabling Publishing Drops All Publications and Subscriptions Associated with That Distributor
Note the information in the Disable Publishing page in Figure 8.37. This process will drop all publications and subscriptions as well as disable the distributor. If your ConfigMgr site shares a database with another application, verify that the only replication used on this server is for ConfigMgr before you disable replication.
- To delete local subscriptions from the subscriber, open SQL Server Management Studio, expand Replication, and select Local Subscriptions. Right-click the subscription to your site database (see Figure 8.38) and select Delete. Click Yes to confirm subscription deletion.
- After performing the required ConfigMgr upgrades or service pack installations, review the steps earlier in the “Replication Setup Tasks” section to re-create your replica.
If you have a very busy site with a very large number of systems assigned to it, you will want to consider both offloading the MP and using a SQL replica to alleviate some of the stress on your primary site. If you offload the MP without creating a replica, each time a client polls for new policy, the offloaded MP queries the primary site database. Configuring the MP to use a database replica results in that traffic no longer going to the primary site database, thereby relieving stress on the primary site.
After creating a database replica on a new server (the subscriber), perform the following steps to install your management point to this new server and use the database replica. For this example, the new server (Telephone) has the replica configured, and is not currently used by ConfigMgr for any roles. Similar to installing the roles on the site server, ensure the new server meets the required prerequisites listed in Table 8.1 for the role. For example, the MP role requires IIS. Here are the steps to follow:
- In the ConfigMgr console, expand Site Management -> Site Database -> Site Systems. Right-click Site Systems and then select New -> Server. Enter a valid name and the intranet FQDN, as shown in Figure 8.39. Also, grant the proper rights for the site server to install the site system. To use the site server’s computer account to install this site system, add the site server’s computer account to the local Administrators group of the new server.
- Click Next in the New Site System Server Wizard, select Management Point for the role to install on the new site server, and click Next. The Management Point configuration page is shown in Figure 8.40.
- Click Next and then Finish, thus completing the wizard. Review the Site Status messages as well as the SMSLogs directory on the new site system server. MPSetup.log provides additional information about the MP installation on the new server.
As you worked through Chapter 6, you documented the desired site boundaries for your ConfigMgr site. To add a site boundary, navigate to the desired site in the ConfigMgr console and then expand Site Settings -> Boundaries. Right-click Boundaries and then select New Site Boundary. Enter and select the correct properties for the site, as shown in Figure 8.41, and then click OK to set the boundary.
You have the option to select an IP subnet, Active Directory site, IPv6 prefix, or IP address range for the site boundary.
Note
You have the ability to “protect” boundaries on distribution points and state migration points. By creating protected boundaries, you allow only client systems within those boundaries to access the content. A common scenario for this would be a distribution point located across the WAN for your primary site. You may install a distribution point at a remote office so that systems in the office can obtain content locally. To prevent systems from the main office from obtaining content from that remote DP, add protected boundaries to the DP to “protect” it from WAN traffic.
To protect a distribution point, configure a valid site boundary on the site server for the remote office. Depending on your environment, this could be an IP subnet, Active Directory site, or any other validated site boundary. Next, in the ConfigMgr console, navigate to the server name under Site Systems, right-click the ConfigMgr site system role, and select Properties, as shown earlier in Figure 8.22. Check the box Enable this site system as a protected site system. Finally, click the Select Boundaries button to select the desired boundaries.
Larger or more distributed environments typically have multiple ConfigMgr sites. Chapter 6 includes information to help determine which type of sites you require for your enterprise. The next sections will help you configure communication between sites and create child sites.
ConfigMgr uses sender addresses for site-to-site communication. When you create a secondary site, you will automatically configure the address during the site-creation process. You must manually create addresses when creating a primary site. There are several different types of sender addresses:
• Standard sender address— Standard senders are used for LAN and WAN communications, when routers connect through multiple LANs.
• Courier sender address— This capability is installed and configured by default. You will find the Courier Sender Address option in the Start Menu in the ConfigMgr program group. Courier sender is very useful when you have large packages that require excessive time or bandwidth to send over the network. You simply create the offline media (CD, DVD, portable hard drive, and so on), deliver it to the destination site (via postal mail or another delivery process), and use courier sender at the remote site to import the packages properly.
• Various RAS sender addresses— RAS sender addresses are used for RAS communication. These include the following:
You can control the network load for each address, to prevent ConfigMgr from using all available bandwidth for that connection. You can also create multiple addresses to the same site for redundancy, if desired. The following steps go through the process of creating a standard sender address from the central site (CEN) to a child primary site (BXL):
- From the central site, expand Site Settings, right-click Addresses, and select New -> Standard Sender Address.
-
Specify the site code of the destination site and then enter the name of the child site server, as shown in Figure 8.42. You can enter the NetBIOS name or FQDN.
By default, communications occur using the computer account, so ensure that the computer account of the parent site has admin access to the new child site. As an example, the following command run from the Tumbleweed (BXL) site server will give the computer account administrative access:
NET LocalGroup Administrators /Add SCCMUNLEASHEDBLUEBONNET$
This command adds the central site server (Bluebonnet) to the local administrators group on Tumbleweed. If you prefer not to use the local computer account, you can specify a site address account.
-
The next page of the New Standard Sender Address Wizard allows you to configure a schedule for handling multiple priority levels differently. By default, all priorities are open 24 hours a day. Figure 8.43 shows a schedule configured to be open for all priorities during off-business hours (in this case, Monday through Friday 7:00 a.m.–6:00 p.m.), and to only allow medium and high priority communications during the defined business hours.
Note
About Throttling Site Addresses
By default site addresses are not throttled—they are configured as “Open for all Priorities,” which allows the ConfigMgr sender to use the maximum number of threads as configured in the “Concurrent distribution settings” section of the Distribution Point tab of Software Distribution Properties. If you create an address schedule as shown in Figure 8.43, all traffic from the sender to a site will become serial, which may slow the amount of time it takes to send software to new distribution points at the target site.
If you have multiple addresses for this site, use the check box on the Schedule screen in Figure 8.43 to define whether this address can be used as a substitute if another address to the destination site fails.
-
The Rate Limits page of this wizard allows you to configure rate limits to manage network load between sites during specific hours of each day. By default, rate limits are configured as unlimited. You can also manage the rate limits by pulse mode, or limit it to a maximum transfer rate by hour.
Select Pulse mode and then specify the size of the data block (in KB) that ConfigMgr sends to the address. Also, specify the delay between data blocks (in seconds).
Alternatively, specify the maximum transfer rates per hour. In Figure 8.44, the rate limit is configured as unlimited during off-business hours, and to utilize only 50% of available connection bandwidth during the business day.
Perform the same steps to configure a sender address from the child site to the parent.
By default, standard and courier senders are installed automatically on every site server. To configure additional senders, refer to http://technet.microsoft.com/en-us/library/bb694245.aspx, which discusses preparing servers for different senders.
Depending on the number of child sites, you may need to modify the sender properties. Figure 8.45 displays the default settings for the standard sender.
The Advanced tab allows you to specify the maximum number of concurrent connections the ConfigMgr server can make, the number of retries allowed, and how often the sender may retry a failed attempt.
The “Maximum current sendings” section allows you to specify the maximum number of simultaneous communications allowed for this sender and each destination site:
• All sites— Specifying a number here will set the total number of simultaneous connections. This number should always be larger than the Per site setting.
• Per site— This setting determines how many simultaneous connections are permitted to a single site.
For a smaller hierarchy, the default settings may be sufficient. If you have more than two or three child sites, you may want to consider increasing these numbers, provided there is available bandwidth from the parent site. See http://technet.microsoft.com/en-us/library/bb632976.aspx for additional information on sender properties.
After installing the primary site and configuring the addresses and senders, you are ready to attach to a parent site. Perform the following steps:
- To attach a primary child site to a parent, connect to the ConfigMgr console of the child site, expand Site Management, right-click the primary site name, and select Properties.
- In the General tab of the Site Properties dialog box, click the Select Parent Site button.
- Because you have already created the proper addresses, simply click the Report to parent site radio button displayed in Figure 8.46 and select the parent site from the dropdown list. (If you have an Asset Intelligence synchronization point configured on the child site, you must remove this role before attaching to the parent site.)
Once you complete the wizard, replicating objects from the parent site to the child site may take from a few minutes to several hours, depending on the number of objects (packages, programs, collections, software updates, and so on) on the parent site. Review sender.log on both the parent and child site to verify site connectivity. Also, when you attach your site to a parent site, you may experience backlogs in some of your inbox folders (for example, ddm.box, dataldr.box, sinv.box, statmgr.boxstatmsgs, and statesys.box, to name a few). During the attachment process, local inbox processing is paused until the child site has forwarded all site and client information to its new parent site.
This chapter has discussed the process of installing a ConfigMgr site. The steps outlined apply to configuring both the central site and any child primary site.
To install a primary site, follow the steps in the “Site Installation” section for installing a ConfigMgr site.
When installing a ConfigMgr site that will be a child site, install the site and then apply the same level of service pack (and R2 and hotfixes, if applicable) on the parent site before attaching the child site to the parent site.
After attaching the child primary site to the parent site, perform any additional configurations necessary. You will also want to review the “Transfer Site Settings Wizard” and “Copy Packages Wizard” sections of this chapter—these two tools can help simplify (and standardize) configuring child sites.
Two methods are available for installing secondary sites:
• Installing directly from the ConfigMgr installation media
• Installing the secondary from the ConfigMgr console of the parent site
If you choose to install using installation media, you will also need to ensure you apply the appropriate service pack (and R2, if required). Installing the secondary site from the ConfigMgr console will install the same version of ConfigMgr that is on the parent site. Regardless of the method you choose, you should run the prerequisite checker first, as described earlier in “The Prerequisite Checker” section of this chapter.
To install a secondary site from its parent, perform the following steps:
- From the ConfigMgr console of the parent site, expand Site Database -> Site Management, right-click the parent site name, and then select New Secondary Site to begin the Secondary Site Creation Wizard.
- After the Welcome screen, specify the site code and site name. Click Next.
- At the Site Server page, specify the site server name (NetBIOS name) and installation directory (for example, C:ConfigMgr). Click Next.
- Select Copy installation source file over the network from the parent site server. If the secondary site is on a very slow link, you may want to consider pre-staging the source files on the new server and then specify the path.
- Specify a new sender address (use the FQDN if possible). Also, specify a site connection account, or ensure that the system account of the parent site has administrative access to the new secondary site server.
- Specify the sender address from the secondary site to the primary (use the FQDN if possible).
-
Complete the installation wizard, and monitor the following log files on the new secondary site:
• SMS_BOOTSTRAP.log
• ConfigMgrPrereq.log
• ConfigMgrSetup.log
After ConfigMgrSetup.log indicates the installation is complete, several background processes will continue to complete the configuration. You can view the installation and configuration status in the ConfigMgr console from the parent site, as shown in Figure 8.47, which shows the state as “Pending.” Review the ConfigMgrSetup.log for any potential problems.
- After installation completes, install R2 (if applicable).
Several common deployment issues may occur with secondary sites, including the following:
• Failure to exchange secure keys between parent/child and child/parent.
• Secondary site status stays in pending state, with the site control file not making it up from the secondary site.
• Establishing an address from the primary to the secondary but not having one from the secondary to the primary.
The next sections discuss these issues.
You can configure parent and child sites to require secure key exchange for communication. When you’re installing a secondary site configured to use secure key exchange to communicate with its primary site, the key transfer may occasionally fail.
Although the secondary site installation will be successful, communication between the sites will fail, because the primary parent site will reject communication until there is a secure key exchange. This is evidenced by entries in the despool.log file at the parent site server, the despooler inbox folder at the parent, and status messages regarding secure key exchange issues:
• Despool.log— The despool.log file is located on the parent site server—the default location is %ProgramFiles%Microsoft Configuration ManagerLogs. The Despooler component is responsible for all incoming and outgoing communications between sites. The despool.log file logs all site-to-site communication, including communication failures.
When site communications fail due to the missing secure key, despool.log will contain the following entries:
Both entries state that Configuration Manager tries to locate the key. It retries this every 5 minutes, for a maximum of 100 times.
• Despooler inbox folder at the parent site— Secure key exchange communication failures can also be identified when the inboxesdespoolr.box eceive folder becomes backlogged with files. These files have extensions of .ins and contain site instructions. When site communication is successful, these files are sent, processed, and then deleted from the eceive folder. When the key is missing, those files remain in the folder at the parent site.
• Status messages— The SMS_Despooler will generate the following status messages for the receiving site:
• Message ID 4404—The Despooler component received an instruction and package file from a site that will not be processed because the site does not allow unsigned key exchange between sites.
• Message ID 4405—The site has received an instruction file containing intersite replication data that will not be processed and retired because a valid public key cannot be located for the sending site.
To resolve the public key exchange issue, you must exchange the keys between the sites manually with the hierarchy maintenance tool (preinst.exe). This tool is installed by default with Configuration Manager 2007. The following procedure discusses the steps to manually exchange the public keys using the hierarchy maintenance tool.
Perform these steps at the child/secondary site:
- Go to Start -> Run and then type CMD to open a command prompt.
- At the command prompt, navigate to the location of the preinst.exe tool. The tool is located in the <ConfigMgrInstallPath>ini386<language code> folder on the site server.
- Type preinst /keyforparent to export the public key of the child site server. The key file is <Site Code>.ct4, and is stored at the root of the system drive.
- Move the <Site Code>.ct4 key to the <ConfigMgrInstallPath>inboxeshman.box folder at the parent site.
Perform these steps at the parent site:
- Go to Start -> Run and then type CMD to open a command prompt.
- At the command prompt, navigate to the location of the preinst.exe tool. The tool is located in the <ConfigMgrInstallPath>ini386<language code> folder on the site server.
- Type the command preinst /keyforchild to export the public key of the parent site server. This key file is <Site Code>.ct5 and will be stored at the root of the system drive.
- Move the <Site Code>.ct5 key to the <ConfigMgrInstallPath>inboxeshman.box folder at the child site.
Communication will start within 5 minutes once the keys are exchanged. To monitor the process, check the contents of the despool.log file.
If the site control file is not created successfully, the secondary site may remain in a pending status and never go active.
When you install or upgrade a secondary site, the final installation step is for the Site Control Manager service at the secondary site to copy the .ct2 control file to its parent. This file contains the information that the installation or upgrade was a success.
To force the Site Control Manager service to create the .ct2 control file, perform the following steps:
- Verify that the secondary site server is indeed successfully installed, and that all services and components are up and running.
- At the secondary site, browse to the <ConfigMgrInstallPath>inboxessitectrl.box folder. Copy the SiteCtrl.ct0 file to a temporary location (for example, c: emp).
- At the temporary location, change the name of the earlier copied Sitectrl.ct0 file to 00000000.ct2.
- Copy the 00000000.ct2 file to the <ConfigMgrInstallPath>inboxeshman.box at the parent site.
This procedure informs the parent site that there is an updated site control file, and it will process this file immediately.
When you deploy a secondary site through the console of the primary parent site, the Secondary Site Creation Wizard enables you to configure the address for the primary and secondary sites. However, the configuration of the sender address for the primary site at the secondary site may occasionally fail. If the sender address is missing, site communication fails and sender.log at the parent site server will contain the following entries:
When this occurs, you can create the sender address manually. Use the ConfigMgr console to configure the address. Because secondary sites do not have a database, you must manage them through a console connected to the primary site database in the console. Refer to the “Configuring Addresses” section of this chapter for the steps to add a standard sender address.
Use the Transfer Site Settings Wizard to transfer site settings between sites. You can transfer settings down the hierarchy, or you can export configuration settings to an XML file and import them to a different site. Perform the following steps:
- Right-click any site in the ConfigMgr Admin console to start the Transfer Site Settings Wizard. At the Welcome page, click Next to continue.
- You have the option to export or import settings. For this example, select Export settings. Then, on the next screen, select the site to transfer settings from (the source site).
- Click Next to select the site settings to transfer (or export), as shown in Figure 8.48.
- Select the destination site(s) or click Next to export the site settings. If you selected one or more destination sites, the wizard will automatically begin applying the site settings to each site.
- A success dialog box will appear upon completion.
Caution
Verify Settings for Transfer Site Settings Wizard
The Transfer Site Settings Wizard will do exactly what you tell it to do—so if you tell it to transfer discovery methods and include Active Directory containers, you may begin discovering duplicate objects from different sites, thus causing additional backlog and confusion at your central site.
If you chose to export the settings to an XML file, you can later import those settings to any site.
The Copy Packages Wizard allows you to easily add multiple packages to a distribution point. You can copy four different types of packages, each requiring that you initiate the wizard from a different location:
• The Packages node, under Software Distribution
• The Deployment Packages node, under Software Updates
• The Boot Images node, under Operating System Deployment
• The Driver Packages node, under Operating System Deployment
Right-click any of the nodes listed here and then select Copy Packages. In the Copy Packages Wizard displayed in Figure 8.49, select the destination distribution point. The next page of the wizard allows you to select multiple packages. You can also click the Source button to select an existing distribution point. This allows you to easily select all packages for the new distribution point that are on the source distribution point.
The process begins when you complete the wizard. This process uses the same process as if you manually added distribution points, so monitor the distribution status for each package selected, if desired.
Another useful tool is the Preload Package tool, also known as the package loader tool. This tool allows you to manually copy compressed Software Distribution package source files to the new site. You can also use the tool to import the package properly into ConfigMgr at the remote site. You can download the Package Preload tool from Microsoft’s download site at http://www.microsoft.com/downloads (search for PreloadPkgOnSite.exe).
Troubleshooting site installation may appear overwhelming at first, but take your time and go step by step to identify problems. Keep in mind that first you have a site installation, and then component installation/configuration. Almost all site installation information will appear in the logs on the root of the system drive, namely ConfigMgrPrereq.log, ConfigMgrSetup.log, and SMS_BOOTSTRAP.log (this appears on secondary site installations when initiated from its parent site). Install the ConfigMgr toolkit prior to site installation. Open Trace32.exe from the toolkit to associate .log files with Trace32. Trace32 makes ConfigMgr log files easier to read.
Always verify prerequisites using the latest information from Microsoft. You can find this information in the release notes of the installation media and updated information with service packs and R2. If you are able to access the ConfigMgr Admin console, navigate to System Status -> Site Status to review site component information. SMS Executive is a good place to begin.
See http://technet.microsoft.com/en-us/library/bb693526.aspx for additional information when verifying a successful site installation. You will also want to review Appendix A, “Configuration Manager Log Files,” for a comprehensive list of ConfigMgr log files.
Depending on the specific components installed on a server, there may be as many as nine different Windows services running specifically for ConfigMgr 2007, with many threads running under those services. The ConfigMgr Service Manager, installed as a tool with Configuration Manager 2007, enables you to manage all services and each thread in those services independently.
Perform the following steps to access the ConfigMgr Service Manager:
- Expand the Tools node in the ConfigMgr console.
- Right-click ConfigMgr Service Manager.
- Select Start ConfigMgr Service Manager to open the ConfigMgr Service Manager console.
The ConfigMgr threads are grouped by components and by servers:
• If you have only one server supporting all site roles, the list of components will look identical.
• If you are using multiple servers to distribute the components, the Servers view may provide additional functionality for you.
Clicking the Components node provides additional detail about each component (or thread) for ConfigMgr. Figure 8.50 shows components in the BXL primary site.
Each component listed in the Service Manager has either a green arrow, red box, or an empty circle to its left. When you first open ConfigMgr Service Manager, it displays only empty circles. Here are some points to keep in mind:
• To query a component, right-click the component on the detail pane and select Query to see the current status of that component.
• To query all components, right-click a component and then choose Select All. Right-click again and select Query to see the status for all components. When querying all components, you may wait several minutes for the results to display.
After querying a component, you can right-click to start, stop, resume, or pause the component. After you click one of the actions, you just requery the component to display the current state. ConfigMgr generally does a great job of managing the components required for the site to run properly. It is only necessary to adjust components when troubleshooting your site. As an example, you may find that the Discovery Data Manager log (ddm.log) is reporting errors reading discovery data, but the files are processed from the inbox (inboxesauthddm.box) so quickly that you are unable to inspect them. To disable this process temporarily, stop the SMS_DISCOVERY_DATA_MANAGER thread using ConfigMgr Service Manager. After inspecting the files, restart the thread.
Tip
Managing Components (Threads) Using the Registry
Microsoft recommends using ConfigMgr Service Manager to manage the ConfigMgr components. If you are unable to open the ConfigMgr console, you can use the Registry to manage the ConfigMgr threads. On the site server, run Regedit (Start -> cmd, and then type regedit). Navigate to HKEY_LOCAL_MACHINESoftwareMicrosoftSMSComponentsSMS_ExecutiveThreads and select the thread you wish to manage.
As an example, select SMS_Despooler. You can see the current state and startup type. To stop the thread, simply change the value of Requested Operation from None to Stop. Refresh the Registry key information and, in several seconds, you will see the Current State has changed from Running to Stopped, and the Requested Operation is reset to None. To restart the service, change the Requested Operation value to Start.
Another important feature in ConfigMgr Service Manager is the Logging property for each component. By right-clicking and selecting Logging on a specific component, you can enable or disable logging, specify the path and filename for the log, and specify the maximum log size (in MB).
Highlighting multiple components and right-clicking Logging allows you to configure the properties for multiple logs at the same time. Exercise caution, because you may inadvertently specify the same log filename for multiple components. Although supported, this may cause confusion when troubleshooting.
This chapter walked you through the basic process of installing a ConfigMgr 2007 site. As you can see from the multiple installation and configuration procedures, a thoroughly documented process customized for your environment will provide a valuable reference when moving from a test environment to production.
Spend the necessary time up front to plan your hierarchy, to ensure you build the infrastructure required to support the needs of your environment.
The next chapter takes an existing SMS 2003 primary site and upgrades it to Configuration Manager 2007.