Installing Configuration Manager 2007 : Site Installation (part 3) - Installing ConfigMgr 2007 R2

3/25/2013 4:31:53 AM

3. Installing ConfigMgr 2007 R2

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

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 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

Figure 15. ConfigMgr 2007 site with R2 installed

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 provides more information.

4. Configuring Site Properties

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 16.

Figure 16. The General tab of the Site Properties dialog box


As Figure 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. 

Wake On LAN

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). The Wake On LAN tab of the Site Properties dialog box enables you to configure Wake On LAN, as shown in Figur 17.

Figure 17. The Wake On LAN tab of the Site Properties dialog box

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. 

If you select the first or third option in Figure 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 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 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 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.

Figure 18. The Ports tab of the Site Properties dialog box

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 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 19 shows the available options for the Advanced tab.

Figure 19. The Advanced tab of the Site Properties dialog box

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. 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 to determine if you need to publish to DNS. Information on configuring ConfigMgr clients to find their MP using DNS publishing is available at

  • 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.

Site Mode

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. 

Configuring Mixed Mode

Figure 20 shows there are several settings to configure while in mixed mode.

Figure 20. The Site Mode tab of the Site Properties dialog box, 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 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.

Preparing for Native Mode

 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). 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 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 for additional information on certificate requirements for native mode.

Enabling 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 21 for the BXL site.

Figure 21. Enabling Native Mode on the ConfigMgr Site and specifying the Site Server Signing Certificate

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:

  • SMS_MP_CONTROL_MANAGER MessageID 4629— The management point has successfully reinstalled.

  • SMS_POLICY_PROVIDER MessageID 5116— The site server has signed all policies with the site server signing certificate.

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
PS4 game trailer XBox One game trailer
WiiU game trailer 3ds game trailer
Top 10 Video Game
-   Skyforge [PC] Open Beta Gameplay Trailer
-   Armored Warfare [PC] PvE Trailer
-   F1 2015 [PS4/XOne/PC] Features Trailer
-   Act of Aggression [PC] Pre-Order Trailer
-   Sword Coast Legends [PC] Campaign Creation E3 2015 Trailer
-   Sword Coast Legends [PC] Campaign Creation E3 2015 Dungeon Run Trailer
-   Naruto Shippuden: Ultimate Ninja Storm 4 Trailer
-   Danganronpa Another Episode: Ultra Despair Girls Trailer 2
-   Project X Zone 2 Trailer
-   Poly Bridge Early Access Trailer
-   Rodea The Sky Soldier Trailer
-   CABAL 2 Launch Trailer
-   The Smurfs Trailer
-   Act of Aggression Pre-Order Trailer
-   Project X Zone 2 [3DS] Trailer
Game of War | Kate Upton Commercial