Steve Pruitt at myITforum.com

Here’s a summary of some of the most significant differences I found in patching between SMS 2003 and SCCM 2007. Note that other differences I don’t list may be significant to your deployment process. It’s vital to thoroughly test this and plan the changes you’d make to your environment. Also, these reflect the results of my testing; your results may be different. Also, read Chris Mosby's blog, where he offers a preview of Chapter 14 of his book about SCCM. It describes the Software Update process in SCCM

ITMU becomes WSUS (plus more)

• Greater variety of updates can be deployed
• ITMU supports nearly all security updates
• WSUS supports all updates that are in Microsoft Update
• That, in turn, means you need to pay closer attention to what’s newly released. It may include non-security updates that you don’t want to deploy.
• This also makes it much easier to deploy these non-security updates, if desired.
• Install ITCU to be able to deploy non-Microsoft updates from hardware vendors, Adobe, etc. It’s fairly easy to add your own upgrade deployments for any applications or products.
• The new Desired Configuration Management capabilities let you use patch scanner-like analyses of all sorts of characteristics; this can be used in conjunction with patching or independently

Scanning

• Synchronization with Microsoft Updates happens on a specified schedule and can be run on demand
• SCCM does not allow you to schedule scans separately by collection; there is one global schedule for the system
• Scans are initiated by the client as part of various activities, along with the scheduled scans
• Scans run at random times during the two hours after the machine policy is received, to spread out the load on the network and servers
• There is no apparent way to schedule scans on specific dates, so the only way to assure accurate patch requirement reports at the beginning of a patch cycle is to run scans daily
• It is easy to change the scanning schedule, so you could easily scan daily for the first days of a patch cycle and use some longer interval the rest of the month
• There is a separate schedule for rescanning based on updates that were scanned previously (i.e., no attempt to find other updates to scan for)

Deployment Scheduling

• You can still deploy with different options to different collections
• It’s now much easier to use staged deployments:
• Create an Update List of the updates you want to deploy
• Create multiple Deployments targeting the desired collections with the desired options
• Use Deployment Templates to assure consistency
• This can include a mix of interactive and silent deployments with different schedules
• Only one Deployment Package is created and distributed to the DPs
• In SMS 2003 you can create a package that allows postponement for a specified time from either the Time Authorized or the Time Available
• In SCCM the deadline is only based on Time Available, which is the “advertisement” start time

Baseline Patching

• SMS 2003 requires that you have a separate deployment package of updates from past months with a separate advertisement as the most efficient way to rescan for past updates and reapply them as required
• SCCM has a rescan schedule that is distinct from the regular scanning schedule
•  SCCM rescanning can use the original update deployment packages; there is no need to combine them
• SCCM software updates will get update executables from any available package; that means you could combine updates from previous months into rollup packages for easier management if desired
• Many other ways of combining past and/or current updates are possible, to accomodate any desired update management practices
• Keep in mind the effects on network traffic and DPs of adding or moving updates between packages - make sure your plans will be effective and efficient at all levels
• Also remember that the most valuable reporting may be based on the deployment structure

Migration

• You have to uninstall all scanners except ITMU before upgrading from SMS 2003 to SCCM 2007
• If you do a side by side upgrade you can install ITMU under SCCM 2007 to support SMS 2003 client
• If you can’t complete updating all clients from SMS 2003 to SCCM 2007 between two patching cycles, keep one SMS site server operating in case you need to deploy any ESUIT updates. These can not be deployed through SCCM 2007.
• Install WSUS 3.0 before SCCM, and cancel out of the wizard without configuring it –SCCM will configure WSUS when that site role is installed

User Interface

• The appearance of the balloons and dialog boxes, and the steps needed to run the updates now or a specified later time are different
• If an update does not require a reboot, there’s no dialog box saying the update has completed as there is with SMS 2003
• The deployment process and schedule at your company may change if you take advantage of new features
• All of these changes must be communicated clearly to users shortly before your first SCCM update deployment to minimize confusion and calls to the Help Desk, and the disruption resulting from such confusion
• If there are file changes pending a reboot when new updates are distributed, the user is informed in the regular dialog box - the system does not force the reboot until the patching deadline (note: I’ve heard reports of other behavior, but my testing has been consistent)

Reporting

• I found it frustrating not having the advertisement-based reports and queries for scanning and updating that I was used to
• The new reports are based on the current patch status of each machine, not the status of the scanner and deployment executions plus patch status
• Be prepared for this, and think carefully about what reporting you’ll need
• There are many new reports – study them before creating your own, you may not need them after all!