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 http://technet.microsoft.com/en-us/library/bb693954.aspx.
To upgrade to ConfigMgr 2007 R2, perform the following steps:
1. | Close
all instances of the MMC on the site server (this includes the
ConfigMgr console, SQL Server Management Studio, Computer Management,
and so on).
|
2. | Launch Splash.hta from the R2 installation media.
|
3. | Click to install Configuration Manager 2007 R2.
|
4. | Review the Welcome page.
|
5. | Review and accept the license agreement.
|
6. | Verify the information and enter a valid product key.
|
7. | 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 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.
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.
General
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.
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 http://technet.microsoft.com/en-us/library/bb932199.aspx includes information on troubleshooting Wake On LAN issues.
Ports
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.
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.
Advanced
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.
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.
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.
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 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.
Enabling Native Mode
To enable native mode, perform the following steps:
1. | 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.)
|
2. | Change the Site Mode selection from Mixed to Native. Click Browse.
|
3. | 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 SCCMUnleashed.com BXL site.
|
4. | 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.
|
5. | 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.
