3. Configure the Site Server
You will now start working in the Configuration Manager Console, which you can find in Microsoft System Center => Configuration Manager 2007 in the Start menu. You can see the console in Figure 7.
The console is split into the usual navigation pane on the left,
contents pane in the center, and context-sensitive Actions pane on the
right.
3.1. Configure the Site
The navigation pane reveals
the site database for this primary site, DPL or Deploy on the server
DeploySrv. The navigation pane breaks down into a number of areas:
Site Management
This area is where the
site administrators will configure things like the role services,
database operations, client deployment, discovery, and client agent
configuration.
Computer Management
This area will be the most
frequently used part of ConfigMgr. Here you will create and use
collections, manage software distribution, run update deployment, run
reports, and of course, do your OSD.
System Status
This area is where you can check on the health of your site systems and start your troubleshooting.
Security Rights
By default, the
administrator of the site server has complete rights over the entire
site. You can delegate rights to specific parts of ConfigMgr, a class of
objects, or selected objects. We recommend that you learn how to do
this if you will be responsible for ConfigMgr.
Tools
This area allows you to manage the many services that are used by ConfigMgr.
|
You should make a habit of
visiting Component Status and Site System Status for your site on a
frequent basis. ConfigMgr does a very good job of keeping an eye on its
own health. The errors and warnings also come with a lot of good
information explaining any issues and some potential solutions.
You may be thinking how much
work goes into installing a ConfigMgr site server. You've only seen the
tip of a real-world deployment. Many things can go wrong, and a visit to
System Status will usually shine a spotlight on any problems.
However, be aware that you
will get some warnings no matter how well your installation goes. For
example, some automated behind-the-scenes tasks won't run correctly
directly after an installation. Typical of these are some of the
warnings for the database.
|
You should start by preparing your ConfigMgr site. Some of the actions will take a while to run behind the scenes.
The first thing you should
do is configure your site boundaries. Boundaries provide a way of
specifying which computers should be a member of ConfigMgr site. You can
use things like IP subnets, IPv6 prefixes, or Active Directory sites.
The latter is handy because your ConfigMgr site can quickly take
advantage of AD sites, which probably match up nicely. In this exercise,
you can use the default Default-First-Site-Name site as your boundary. You are familiar with the use of Windows PE.
You probably noticed that your boot image is not a domain member and
therefore does not know about the Active Directory sites. Configuration
Manager uses Windows PE as a boot image for OS deployment and image
capturing. You should also add the IP subnet (192.168.1.0) as a boundary
so that non-AD members (such as boot images) will be aware of what
ConfigMgr site they are in (DPL - DeploySrv).
|
You will learn very
quickly that little happens immediately in ConfigMgr. It is a product
designed to manage thousands of computers. You rarely expect immediate
results in those circumstances. That means you can get frustrated when
working in a lab. There are a few tricks to speed some things along, but
you must learn to sit back and relax more than you might be used to.
|
When we work with bare-metal
PCs, they are not members of the Active Directory. This means that they
must access ConfigMgr resources, such as the distribution point(s),
using the network access account (deploy\configmgrnw). You need to configure this access in ConfigMgr.
Navigate into Client Agents
and edit the properties of Computer Client Agent. You should set the
Network Access Account option as dep1oy\configmgrnw
and enter the password for the account by clicking the Set button.
Failing to do so will cause all boot images (CD, PXE, or USB) to not be
able to access the distribution point and then cause OSD operations to
fail.
You will want to deploy the ConfigMgr client to your lab network computers. You can do this manually (using Ccmsetup.exe in \\Dep1oySrv\SMS_DPL\C1ient\)
or using a Client Push Installation method in Client Installation
methods. You need to enable the process and provide credentials for it.
You should already have a domain-based account that has local
administrator rights on all required computers. That is the ConfigMgrSvc
user account. Make sure your clients have had time to apply Group
Policy if you are using the GPO Restricted Groups method to add that
user to the local Administrators group of your computers. You can always
run gpupdate/force on those machines to speed things along.
A client installation
requires that you have Discovery Methods enabled. Active Directory
System Discovery should be configured. You might want to enable the
other Active Directory methods in a production environment. Associate
the discovery method with an OU or the domain (the latter is perfect for
this exercise), configure a polling schedule, and select the check box
Run Discovery As Soon As Possible. You'll note the default schedule is
every day, which is perfect in a real-world scenario but not always
useful in a lab.
You can start seeing the
results of your efforts by looking at the contents of your collections
under Computer Management. Collections also have an update schedule.
This means data must be discovered. Then this data is queried on another
(per collection) schedule to populate a collection. You can alter that
schedule, and you can also force a collection update by right-clicking
on the collection and selecting Update Collection Membership.
After a while (you must be
patient!), you will see that your lab computers will start to appear in
the relevant collections. You will also start to see the client status
change from No to Yes for each machine, assuming that the computer's
domain account is okay and that the ConfigMgrSvc
does have the required rights on the computer. Any computer with a
client status of Yes will now be running a client with the configured
client agents. A number of new objects will now appear in the Control
Panel of those computers.
You'll notice collections for
Windows XP and Windows Server 2003. You can create a Windows 7
collection using the following query criteria:
Operating System.Name is like "Microsoft Windows 7%"
Collections for other
operating systems can be created similarly. You can pull in collected
hardware information to get even more specific.
|
Configuration Manager will
probably try to store data on the C: drive of your server. This could be
quite annoying if you have gone to the expense of provisioning a D:
drive with a lot of space. You can prevent this from happening by
creating a file called NO_SMS_ON_DRIVE.SMS on your C: drive.
You can control where ConfigMgr will store Software Distribution files, or the distribution point, by navigating into \Site Management\<Site Name>\Site Settings\Component Configuration
and editing the properties of Software Distribution. You can enter a
drive where you want the distribution point to be located, for example D:\.
|
3.2. Add Site Roles
The previously
discussed client discovery process will take some time. As mentioned,
ConfigMgr requires patience so you should move on by doing some other
work to help pass the time.
A number of site roles must
be deployed within a ConfigMgr site to allow the complete OSD process to
work. Take the following steps:
Navigate into the Site Systems area under Site Settings.
Right-click
on the site server and select New Roles. Add roles (if not already
added to the site) in the following list. You can see the screen for
enabling these roles in Figure 8.
Server Locator Point
This will enable non-AD members to find the site server.
State Migration Point
This will allow
captured user states to be temporarily stored in the previously created
shared folder. USMT can instead use hard-link migration which is a more
efficient process.
PXE Service Point
This will allow you to use network-located boot images to boot up computers with no operating system for OSD.
Reporting Point
Using this, you can generate reports from the ConfigMgr database and track the process of running deployment jobs.
Software Update Point
This allows ConfigMgr to deploy security updates to managed computers.
You
are asked if you want ports to be opened to allow the PXE service point
to work. Click Yes if you plan to capture a user state using USMT and
store it on the network. You can use the site database for the Server
Locator Point.
|
The User State
Migration Toolkit has traditionally used a file share or the state
migration point to temporarily store the user state in a safe location.
You can choose to do so if you wish to keep data off the machine. USMT
4.0 introduces a feature called hard-link migration. It is much faster.
Rather than copying a captured user state to a file share and then
restoring it later, it remaps the locations of the files in the file
system. These files are left untouched during the operating system
rebuild and are moved back into the correct location afterward.
|
Configure the state migration point, if installed, as shown in Figure 9, with the location of the folder you created. In this example, it is D:\USMT.
NOTE
Note that if you use MDT you won't have to install the
state migration point. You can configure multiple locations. You can
specify the maximum number of clients that can be installed and how much
free space should be left in the location.
You can also
use the state migration point properties to specify how long data
should be retained after being restored to a PC. You can delete the data
immediately or accept the default of keeping it for one day. Keeping
the data consumes disk space but does allow you to recover from glitches
that might happen. Would you really want to lose a user's profile and
data when you could have the option to keep it around for a few days
before having it automatically deleted?
The PXE service point has a number of options, as you can see in Figure 10.
By default, ConfigMgr will not allow unknown computers to boot up using
a network-provided boot image. Any new computer would need to be
pre-provisioned. This would be required in highly secure networks.
However, most organizations might want something a little more
administrator- and user-friendly.
On
the PXE - General screen, select the Enable Unknown Computer Support
check box to allow ConfigMgr to facilitate PXE service for these new
machines. You can optionally protect the PXE service with a password,
enable it on only selected interfaces, and delay the response (which is
useful in multi-VLAN networks with many PXE services).
|
A PXE boot might fail for a
number of reasons. If the DHCP part of the boot times out, then you
should start by checking for an Active Directory-approved DHCP server
with a valid scope for your network. There should be free IP addresses
in the scope. Check that the PXE service point is listed as an approved
DHCP server using the DHCP console. This is because PXE is based on the
same network protocol. If you see an error related to architectures,
ensure that you have both x86 and X64 boot images available on the PXE
distribution point.
|
Continue
to accept the defaults until you get to the Software Update point
configuration. You might need to configure a proxy server if you have
one.
In
Active Settings, configure the Port Number and SSL Port Number to match
the ports that your WSUS server installation uses. You can then set up
the Microsoft Catalog synchronization. This includes the schedule, the
classifications of updates, and the products that you wish to update.
Note
that Windows 7 won't appear in here as a product until the first
synchronization has taken place. Don't select too much if you are just
working on a lab because it will take time to process.
Finally
there is the annoying Languages screen. Clear the unwanted languages
here. A number of languages are selected by default and there is no
quick way to clear them other than going through each one, one at a
time. Not clearing the unwanted ones will increase the work you need to
do later when working with update management in ConfigMgr. Production
environments should download all the languages that are supported on the
network.
Check
on the System Status a little while after the role installation is
completed. Any problems with dependencies will be highlighted and you
should resolve them before progressing. Note that some errors or
warnings will be created just because the roles are only being created
or starting up for the first time. They could eventually work themselves
out.
You
could allow time for the initial Microsoft catalog software update
synchronization to take place. Or you could force a synchronization to
happen by navigating into \Computer Management\Software Updates, right-clicking on Update Repository, and selecting Run Synchronization. Wait a few minutes, and check the site status (Component Status\SMS_WSUS_SYNC_MANAGER) to see the results. Then you can go into Site Settings\Component Configuration\Software Update Point Component
and select whatever products you wish to manage updates for (such as
Windows 7, which is now visible). The selected update types for the
selected products can now be updated and managed using Software Updates.
If
you install the Software Update Point role, then also return to Client
Installation Methods in Site Settings and enable Software Update Point
Client Installation.
