If you are performing
a zero touch installation with ConfigMgr, you need a way to accurately
identify which machines to upgrade, without even visiting them.
ConfigMgr will, by default, perform a hardware audit
on all machines that the client is installed on. You can use this data
to build a collection, or collections, and these collections can be used
for targeting the deployment of the reference image.
1. A Deployment Strategy
One of the all-time classic quotes from comic book
lore is "With great power comes great responsibility." ConfigMgr is the
most powerful product that you can have on your entire Microsoft
network. A forest or domain administrator can deploy the ConfigMgr
client to every Windows machine in the Active Directory forest and do
whatever they want via that client. It would be very easy to deploy an
operating system image to every available machine, believing that all
would go well.
When you've worked on complex projects for a while,
you remember that Murphy's Law is never far away. Imagine you deploy an
operating system image to a thousand PCs and something goes wrong. If a
thousand people cannot work because of a mistake you made, you will be
in the not-working category very quickly too. Not only will testing
minimize the risk to a widespread, zero touch installation, but a
documented and managed testing process will protect you to a certain
extent from angry supervisors.
We have discussed how it is important to use a
collection of machines for building and testing the operating system
reference image. You should perform a series of tests with as many
variations of the build as possible. Try to obtain access to various
types of hardware. Thanks to the zero touch features of ConfigMgr, those
machines could be on the other side of the planet, as long as they are
in a ConfigMgr site with a nearby distribution point.
Eventually you will exit the testing phase. This is a
good time to eat your own dog food. You should use ConfigMgr to deploy
the reference image to a small set of PCs in IT and then increase the
number gradually. You cannot expect someone to accept something that you
will not do to your own machines.
|
You may wonder why we're talking about feeding a pet.
Microsoft staff use the phrase "eating our own dog food" to describe
how they test their products on themselves before releasing it to the
public. This allows them to learn how to optimize the associated
processes and to tweak the product.
You can apply this approach to your own production
environment by applying an OSD solution to your own PCs. This method can
be your first step outside of the test lab, where you can trial the
solution in a real world environment. You can limit visibility and limit
damage. If there are problems, you can return to the test lab to make
the necessary changes. If all goes well, then you can publicize it to
gain business confidence in your solution.
|
The PC ecosystem in a large enterprise is quite
varied, no matter what controls you try to put in place. These
variations can cause bugs that you do not expect. For example, BIOS
issues could arise. If they do, that would be a perfect time to
investigate whether the hardware manufacturer has an extension for
ConfigMgr to upgrade the affected machines' firmware. The only way to
detect these issues is to conduct a pilot. Try to involve a small set of
IT-friendly power users from a variety of locations. You want them to
be IT friendly because things might go wrong. Non- IT-friendly users
will not react well to problems. If something does go wrong, then a
power user will know to write down and communicate error messages, and
they might even be able to help troubleshoot the issue.
If all goes well and you get approval from
management, you will reach the point where you need to plan the
deployment. ConfigMgr will be more than able to distribute a new
operating system to every PC in the organization at once. But will your
organization be able to handle that? You need to think of your
colleagues in the help desk. You will communicate with users to let them
know that a change is coming, but as you know few of these
communication attempts receive much attention. Users who are confronted
with a new and unexpected operating system when they walk in the
following morning will be quick to call the help desk. Not everything
will go as planned (some piece of software somewhere will slip through
the cracks or some scanner with an odd driver will fail to load).
You should separate your deployment into manageable
chunks. This strategy allows you to complete some basic training with
users. The operating system can be deployed and the help desk will be
able to handle the small increase in work. Once a team, site,
department, or division is completed, you can move on to the next one.
2. Creating a Collection for Windows 7 Deployment
A collection or a set of collections must be created that will meet all of the following criteria:
The collections must be suitable for your deployment strategy.
All member machines do not run Windows 7.
The hardware of the member machines meets the required specifications for running your applications and Windows 7.
The Microsoft Assessment and Planning Toolkit is one
way of gathering this data. It could be used to generate a set of
collections for an OSD.
Alternatively, you can use the data that is gathered
by the ConfigMgr Hardware Inventory Client Agent to build a collection
or collections. In this example you are going to create a collection
where all machines that meet the following requirements will be targeted
for deployment with the new reference image:
The operating system is Windows XP.
The CPU is faster than or equal to 1.8 GHz.
The CPU is a 64-bit processor.
The machine has 2 GB of RAM.
The hard disk is at least 40 GB.
The computer is a member of the HeadOffice Active Directory site.
You can accomplish this with a few minutes' work in the Configuration Manager Console.
Launch the New Collection Wizard by navigating into Collections and clicking on the New Collection action. Name the collection Head Office Windows 7 Capable Systems and click Next to progress to the Membership Rules screen.
Click
the yellow database button on the right side to create a new query.
This opens the Query Rules Properties dialog box shown in Figure 1.
You can name the query (Head Office Windows 7 Capable Systems) and use
the Limit To Collection option to limit this query to members of the All
Windows XP Systems collection. All members of this new collection must
be running Windows XP. Click the Edit Query Statement button to generate
the new query.
The
Query Statement Properties dialog box opens. Select the Criteria tab to
create a new part of the query statement. Clicking the button with a
star icon will create a new criterion. This allows you to do a query
from the database. Each criterion can be combined with other criteria
using Boolean algebra. Clicking the Select button allows you to define
the Where part of the statement. Clicking Operator allows you to say
that something must be equal to a value, not equal to a value, greater
than a value, and so on. You can either type in an explicit value or
click the Value button to see values that have been collected by the
installed ConfigMgr clients. Figure 2
shows a criterion where Processor - Max Clock Speed must be greater
than or equal to 1800. That means only machines that meet this criterion
can become a member of this collection. You can click OK and create
more criteria that are combined with Boolean algebra.
This tool allows you to build up
quite a complex set of criteria for determining collection membership.
An example that meets the criteria we just defined is shown in Figure 3.
You
can see that there is an explicit statement in the criteria to exclude
Windows 7 machines. A newly rebuilt Windows 7 machine may update its
operating system status in a hardware audit when it boots up for the
first time. But it will remain in the Windows XP collection until the
Windows XP collection reruns its collection membership query (once a day
by default). The Windows 7 exclusion will help to clean things up.
Click
OK and continue through the New Collection Wizard. If you are doing
lots of frequent deployments, then you might want to set the update the
schedule for the collection to run more frequently than the default once
per day. No results will appear in the collection until a membership
update is done. You can select the collection, run the Update Collection
Membership, and refresh the view to see the results.
3. New Computers
How you deal with new bare-metal PCs depends on your network security policy:
Locked Down
If you only want to deploy the operating system
image to known machines then you will need to create a computer
association for every purchased machine and join it to a suitable
collection. This will require some additional manual labor.
Password-Protected PXE Service Point
With this solution, a newly purchased computer
will temporarily join the unknown the All Unknown Computers collection
until the ConfigMgr client is installed and running and has fed enough
details to ConfigMgr for other collections to update their membership
according to their individual schedules. There is a single password on
the PXE service point that will be controlled by IT staff and not shared
with users. That way, all new builds of PCs must be initiated by IT or a
trusted representative. The OSD advertisements must be linked to the
All Unknown Computers collection.
Self-Service Provisioning
The current trend in IT services is to empower
users to help themselves as much as possible. Assuming that the PCs
store no data and that there are no security issues, it should be
possible for end users to boot a new PC using PXE and allow it to
install the operating system. This means that a PC can be delivered
straight to the desk and the end user can start work within a few
minutes with no assistance from IT.
The lesson to take away is
that the collections mechanism is very flexible. It allows you to create
a Windows 7 deployment strategy that suits the needs and policies of
your organization.
