Let's talk about maintenance windows in SCCM, a new feature for software distribution and software updates. Maintenance windows usually make sense in a server-based scenario where servers have defined service windows where they can be taken down for changes, including software updates. You can define a maintenance window for a collection by choosing "Modify Collection Settings" and then going to the Maintenance Windows tab.
The window uses an estimated time to execute the entire install. This time is comprised of the following settings:
1. Restart countdown time (Restart countdown time has a default of 5 min and is available to change on each collection in the Admin UI).
2. System restart turnaround time (Site Control File-only setting, which has a default of 10 min).
3. Maximum Run Time, which is the per-update installation time and has a Site Control File-only default setting of 20 min for Updates and 60 min for Service Packs. However, the difference from below is that this setting can be changed in the Admin UI for each update. This setting for each update can be found in a list view when looking at updates in the update repository node, update list node, or in a search folder
If more than 1 update is needed to be installed, say Update 1 with Max Run Time (MRT) of 20 min, Update 2 with MRT of 5 min, and Update 3 with MRT of 30 min, we will start by installing the update with the smallest MRT, in this case Update 2. We watch the installation & if Update 2 finishes, we look for the next shortest MRT and see if that will fit in the window, and so on, until we run out of available time.
In the the situation when the only thing left to do is a pending reboot when waiting for a Maintenance Window, we will only use the restart countdown time and the system restart turnaround time and not use the MRT.
One of the most useful new objects in System Center Configuration Manager 2007 is the Update List. An update list is, well, a list of software updates - that is, it is a fixed list of updates that can be created through a wizard (which also allows downloading of updates). Security rights can be assigned to update lists to enable delegation scenarios. We also have a couple of key compliance reports that use update lists as inputs. The first new compliance report is the "Overall Compliance" report, which gives per-machine compliance for a given update list on a collection. This report assesses whether any of the updates in the list are out of compliance and reports the totals for all machines in the collection. The other new report gives per-update compliance for an update list on a collection, giving the results across the collection for a single update.
Also new to SCCM, search folders are the best way to identify exactly which updates should be put in an update list. To create a search folder, simply navigate to the search folders subnode under the Updates Repository node & select the "new search folder" action. It is easy to create a list of updates, for example, that have the following criteria: critical, security, applicable to Windows, released within the last month, not superseded.
Update lists can be used by the Deploy Software Updates Wizard, Deployment Templates, and the Download Wizard, either through right-click/action pane or by drag and drop.
I thought I could put some thoughts down about the Software Update Point (SUP), which is a new site role within SCCM 2007. The job of the SUP is provide software update metadata to clients that are using the Windows Update Agent (WUA) to scan for missing updates. The underlying component of the SUP is an installed WSUS 3.0 server with an additional SCCM component. The additional component is called the WSUS Control Manager, which allows the SCCM site server to control the behavior of the SUP.
In practice, the first thing you need to do to get started with Software Updates Management in SCCM is to install the SUP. The basic steps to do this are:
1. Download the latest WSUS 3.0 bits from their website.
2. Install the WSUS server on the machine that is slated to be the SUP
3. If the SUP is remote from the SCCM site server, then the WSUS admin console needs to installed on the SCCM site server.
4. Once WSUS is installed, go to the SCCM admin console and go to the site systems node, pick the server with WSUS and start the New Site Role wizard to install the SUP.
5. Let synchronization happen between the WSUS server and SCCM site server - you can monitor progress of the sync by looking at the wsyncmgr.log file
6. Once this sync has completed successfully, you are done! You can now see updates in the updates repository subnode under the Software Updates main node.
These are only high-level steps - the detailed instructions can be found here.
The top level SUP gets its metadata catalog from Microsoft Update and stores that catalog in its database. That database is also put into the SCCM database via the sync process. For software updates scanning, SCCM clients utilize the WUA to connect with a SUP and get the specific metadata that are relevant for the client. The client is scanned for missing or installed updates and results from the scanning are stored in a WMI repository. The SCCM agent collects the results and passes them through the State message system and those results are stored in the SCCM database for every client and every update. Reports can then be generated from the scan data to produce accurate and detailed compliance reports.
One hurdle that every SCCM installation or upgrade will need to get over is the successful SUP sync - it is an indication that you have covered all the important parts and now can begin deployments. But there are some things that I think you should know about:
1. The most common problems I have seen have been around the proxy settings for the SUP - be sure to put the right settings in there, or the SUP won't be able get to the Microsoft Update site to get the catalog
2. You need a SUP at every primary site - unlike other WSUS-based implementations, SCCM requires one at every site to function.
3. Don't get concerned if the sync does not succeed right away, especially if you installed the WSUS server after the SCCM site server. The SUP first needs to successfully complete its initial sync with Microsoft Update to get the metadata catalog, which can take a while. If this process is not completed, you will see failure to sync errors in the wsyncmgr.log, which is normal.
4. In a similar vein, it can take up to a few hours for the initial sync between SUP and SCCM site server to complete, which can be a CPU-intensive process. I don't recommend trying to complete this while other CPU-intensive SCCM processes are happening.
5. As the metadata catalog is revised with new or expired updates within the SUP database, the SCCM site server needs to re-sync. This sync can be accomplished automatically on a schedule as well as through a manual initiation from the updates repository node.
6. All legacy scan tools other than ITMU should be uninstalled prior to upgrade from SMS 2003 and should not be re-installed after upgrade. They will not work anymore with SCCM and can cause serious problems that can break your site.
This being the first post on my new blog, I would like to start out by stating some goals:
1. Discuss some of the interesting or practical things about the Software Update Management (SUM) feature within the System Center Configuration Manager 2007 product (SCCM), which my team is helping to produce.
2. Highlight interesting things in the other parts of SCCM 2007, other System Center products or general neat things related to Microsoft.
3. Perhaps hear from folks outside my personal sphere on how we are doing with SMS and SCCM.
4. Write down some personal thoughts on IT management, technology, innovation, or any other interesting bits that come to mind.
Now, it's time to get going on some posts!