Jeff Huston at myITforum.com

Under SCCM (and SMS), there are two different methods for the deployment of software "bits" to an end-user's system.  These two different methods have clear distinctions in how they operate and what they should be used for, but there is a gray area between them that can be a bit muddled to deal with.

Software Updates

The Software Update system in SCCM is designed, primarily, for the distribution of binary patches to existing software.  The most obvious example are Microsoft security updates.  These updates are installed in, essentially, a non-interactive mode and return a simple numeric exit code to determine success, reboot needed, or failure.  SCCM has a built in detection mechanism and uses state messages to track the progress of deployment.

Software Deployments

The Software Deployment subsystem, however, is designed to distribute full software packages - especially new installations.  Software is expected to return either an exit code or a MIF file to determine status.  Deployments are targeted to collections of computers that must use membership queries (based on inventory) to determine applicability of the package.  For instance, if the primary console user of a machine is in a particular user group, deploy (or offer to deploy) the ACME Widget software.

The gray area starts to show up when a software update is provided as a full software package.  Think of Apple QuickTime Player or Adobe Reader as examples.  Although IT staff wish to deploy the updated version due to security vulnerabilities, they are faced with deploying a full product.

Most of these products come as a collection of files, which Software Deployments are good at delivering.  However, in many cases, those files can be collected into a self-extracting executable (such as one created by the SMS Installer), which is what is required by Software Updates.

Since it is an update, it is tempting to use Software Updates to determine its applicability and handle the deployment.  The rules provided by Software Updates, however, are essentially the same as what is available to collections for Software Deployments (registry keys, file information, WMI lookups).

What doesn't help the matter is when vendors provide what are essentially full software installs as Software Updates.  Dell does this.  Even Microsoft does this (such as Windows Live branded products).

For items that do not come in a catalog (where we would have to use the Custom Updates Publisher), we have chosen to stay faithful (if that is the right term here) to the original purpose of Software Deployments vs Software Updates. 

If the software is a single-file binary patch, it goes through Software Updates.  If it is a full version of the software, it goes through Software Deployments.

Hopefully this advise helps some out there.

SCCM has made huge changes and improvements with software update delivery/installation as well as the introduction of very much needed functionality with service windows.

However, there are some "gotchas" for maintenance windows that you should be made aware of.

With regular software deployments, the maximum runtime value is used to determine if the program will be run within a given maintenance window.  For software updates, there is no opportunity to input this data.  Instead, SCCM has defaulted to a runtime of 35 minutes per software update (75 for each service pack).  When the update deployment routine runs, it requires a maintenance window of at least 35 minutes in order to deploy the updates.

Another gotcha is users that configure their own update installation schedule via the Configuration Manager control panel applet (on the Updates tab).  If the user selects a time that is outside of defined maintenance windows, the updates will NOT be installed.  It appears that SCCM just treats this as another schedule item and evaluates it like any other running program (with maintence window exclusions in-tact if excluded by the original advertisement).

Finally, software update deployments that have a grace period of, say two weeks, assigned to computers with a maintenance window between the original advertisement and the mandatory deadline will not install automatically during one of the intervening maintenance periods.  The software updates will only be automatically installed once the mandatory deadline has been exceeded (during the next maintenance window).  If you have laptop computers, this may prove to be challenging to setup correctly and to establish end-user expectations.  For example, if the mandatory period is set for Thursday night at midnight (during a maintenance window), if a computer is on, it will be patched and rebooted.  If the computer was off during the maintenance period but comes on the following morning, one of two things will happen.  If the exclusion to only run during maintenance windows is enabled, the laptop will not get the updates.  If the exclusion is to run anytime after the mandatory date is reached, the computer will get the patches and potentially reboot (if that exclusion is also enabled).

DCM in SCCM 2007 allows the administrator to use scripts to detect if a particular configuration item is applicable as well as if a particular setting is valid.  Unfortunately, the documentation that comes with the product does not show how to author the scripts to make it work.  I found the info in the beta version of the SCCM SDK (thanks to Wally Mead for the clue) and I wanted to share with you what I've found.

Detection Method Scripts

For Application configuration items, you can specify a script to determine if an application is installed (as opposed to an MSI installation GUID).  To do that, simply create a script that returns any kind of text.  If text is returned, DCM believes that the application is installed.  If no text is returned, DCM believes that the application is not installed.

For example, I've created a configuration item that ensures that any Intel NICs installed in Windows XP workstations is set to AUTO.  In order to do this, I need to know if the Intel NIC is installed.  I use the following script to do this:

Set WMI = GetObject("winmgmts:\\.\root\cimv2")
Set RS = WMI.ExecQuery("SELECT * FROM Win32_PNPEntity WHERE DeviceID like 'PCI\\VEN_8086&DEV_109A%'")
If RS.Count > 0 Then WScript.Echo "Device Found"

You can see that if a matching device is found, text is returned, causing DCM to continue processing the configuration item.

Setting Scripts

For setting validation scripts, DCM treats text returned as the "value" of the script.  This is similar to looking at a REG_SZ registry key.  You can evaluate based on the specific text returned to return an Information, Warning, or Error level event.  In addition, you can ensure that some string is returned by setting the Report a non-compliance event if the instance count fails and set the requirement to be Greater than 0.

For the same example, here is the script used:

'This script will check the speed duplex setting
'
DeviceIDs = Array("pci\ven_8086&dev_109a")
'
Set REG = GetObject("winmgmts://./root/default:StdRegProv")
'
Const HKLM = &H80000002
Const Root = "SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}"
'
'Enum configuration subkeys
REG.EnumKey HKLM, Root, ConfigKeys
'
'Look for matching device id
For Each ConfigKey in ConfigKeys
 MDID = ""
 On Error Resume Next
 REG.GetStringValue HKLM, Root & "\" & ConfigKey, "MatchingDeviceID", MDID
 On Error Goto 0
 For Each DID in DeviceIDs
  If Left(UCase(MDID),Len(DID)) = UCase(DID) Then

'Check the speed setting here
   REG.GetStringValue HKLM, Root & "\" & ConfigKey, "SpeedDuplex", SD
   If SD = "0" Then
    WScript.Echo "Set correctly"
   End If
  End If
 Next
Next

For the Validation tab, I'm checking that the string returned is "Set correctly" and that there is at least 1 string returned.

Hope that this helps!

We are starting to deploy the new Quad-Quad Dell R900 servers here (16 cores) via BDD 2007.  We have had great success with the Dell PowerEdge 2950, which uses a similar Braodcom dual-driver NetXtreme II 1GigE net card.

For the 2950, we would run a custom script in Windows PE to load both halves of the driver stack (since Win PE does not detect newly attached PnP devices).  The drivers that worked for the 2950 would NOT work for the R900.

Dell, unfortunately, did not make drives available for the R900 in a format that could be used.  Via their support site, I could download the installer package for the drivers, but it attempts to actually install the drivers, not just deliver them in a flat directory for me to import into BDD.  What to do?

I downloaded the CD-ROM ISO that Dell provides for OS installation.  This CD would normally be used by booting off of it and running through a little wizard to configure an UNATTEND.TXT file, then swapping it out for the OS CD/DVD upon which the installation completes.  Obviously, the drivers for the system must be in there somewhere.

Buried on the CD was a tool to handily extract said drivers for me.  Buried in the Server_Assistant\Driver_Tool\Bin directory (from the 5.3 version of the CD) was a tool called make_driver_dir.exe.  This tool would take a couple of parameters and provide a directory of extracted drivers for a given server model and operating system.  The CD supports all 6th generation servers up through the current models and for the following operating systems:

• Red Hat Linux in 32-bit (rh30, rh40, rh50) and 64-bit (rh30_64, rh40_64, rh50_64) versions
• SUSE Linux in 64-bit (suse9_64, suse10_64) versions
• VMware ESX (esx310)
• Windows 2000 (w2000)
• Windows 2003 (w2003, w2003_64, w2003sbs)
• Windows 2008 (w2008, w2008_64, winlh, winlh_64)

The nicknames listed in bold are the OS names to use with the tool to extract drivers.

Using this tool, I was able to obtain working Broadcom drivers that work for the system.  In addition, I changed how I install those drivers.

For Windows PE, I am now making use of the monolithic stack drivers (the RIS driver) since I now have a version that is 64-bit.  I had to clean up the INF file a bit before importing it into the BDD Workbench (remove the empty sections 64-bit sections from the 32-bit driver and the empty 32-bit sections from the 64-bit driver).  When will manufacturer's learn?

For the OS build, I now include the virtual bus driver (which is tied to the actual PCI device ID) in my SYSPREP.INF file (along with RAID card drivers).  This causes that driver layer to be pre-installed for deployment and will be removed if not needed (just like unusued RAID cards).  In addition, the Broadcom NIC drivers (that associate with the virtual device ID) are located in a static directory that is referenced in Sysprep's OEMDriverFiles search path.  This was done because BDD only includes drivers for devices that it enumerates while under Windows PE (which would exclude the virtual NIC device).

So, with all of that done, my Windows PE deployment is much more streamlined and I can successfully deploy to R900 (and 2950) servers.