If you're upgrading an existing SMS 2003 site, you have a number of options,
decisions, and prerequisites to consider. First, before you can add SCCM to
the mix, your SMS 2003 site must be running SMS 2003 SP2. Second, SCCM doesn't
support Windows 2000 servers, so you'll need to upgrade any SMS systems running
on that OS. Third, you need to decide whether you'll use a side-by-side or in-place
upgrade strategy.
Organizations that aren't heavily invested
in their current version of SMS will find
the side-by-side upgrade acceptable. This
upgrade amounts to bringing up the new
SCCM site, then reassigning and upgrading
existing managed systems to the new site.
More probable though, is an in-place upgrade.
An in-place upgrade migrates your existing
data to the new database schema and lets
you run in an interoperable mode while you
convert to SCCM 2007. One caveat is that
the upgrade process removes any unsupported feature packs—particularly those for
OS deployment and device management.
However, although the upgrade removes the
legacy feature packs, their functionality is
replaced natively in SCCM 2007, and the new
SCCM-native features will use the settings
previously configured for the feature packs.
When you upgrade, you should go from the top of your hierarchy down. One helpful
tip is to consider placing a central SCCM 2007 site above your existing SMS
2003 primary site, then let your data flow up. Using this scenario, you can
familiarize yourself with the new SCCM console while using your own data. From
the SCCM 2007 console, you can view—but not edit—SMS 2003 site
settings. You can upgrade secondary SMS 2003 sites to SCCM 2007 manually, by
pushing them via SMS, or by installing them through remote control. You can
assign SMS 2003 clients to SCCM 2007 sites, and SCCM 2007 clients—in
mixed mode—can roam back to an SMS 2003 site for interoperability.
Client-Deployment Considerations
You can assign SCCM clients based on AD OUs so that the assignment strategy
can be more aligned with the structure of your business than an SMS site structure.
In addition to standard push-client installations and software distribution
methods, there's a new way to perform client installation. Using the Software
Update Point, you can piggyback on your WSUS implementation to overcome client-installation
obstacles such as account permissions and unopened ports. When Microsoft releases
SCCM to manufacturing, the company will provide an .adm template for distributing
SCCM client settings via Group Policy.
Microsoft has also made notable improvements to the SCCM client-installation
executable. The tool uses a single binary file—
ccmsetup.exe—for all client installations. The
new executable has bandwidth awareness
through BITS, and it downloads a simple XML
manifest first to determine which components
are applicable to a given client, then downloads and installs only what is necessary.
Other Caveats
SCCM's native mode and the PKI infrastructure it requires are requirements for
Internet-based client management. Also, you're going to have to modify your
AD schema to use NAP, but that prospect isn't as scary as it might sound. If
you're comfortable with it, you can run the ExtADSch.exe file (from \SMSSETUP\BIN\
I386) on the SCCM 2007 installation media, or you can use a Microsoft-provided
LDF file. The LDF file documents the classes and attributes added in the process
of modifying the schema, as well as the SCCM features they're associated with.
(NAP is one such feature that requires an update to the AD schema.)
Worthwhile Investment
Microsoft's investment in its four-pillar strategy of simplicity, deployment,
security, and configuration should pay dividends for IT organizations ranging
in size from medium to huge. Existing SMS users will benefit greatly from an
upgrade to Microsoft's latest and greatest configuration management tool, and
SCCM's new capabilities and usability add up to a compelling argument for deployment
in many IT organizations where previous versions of SMS might not have made
the cut.