Using the ConfigMgr 2007 "Install Software" step to install a dynamic list of packages

For those of you familiar with how BDD 2007 and MDT used the SMS 2003 OSDSWDEXEC.EXE program to install packages specified via CustomSettings.ini or in the BDD/MDT database.  That same capability is present with ConfigMgr 2007 using the built-in "Install Software" step.  See more on that at https://technet.microsoft.com/en-us/library/bb680842.aspx.

From an MDT 2008 perspective, the implementation is nearly identical to what we did before with SMS 2003: we need to build up a list of packages using task sequence variables, specifying a common base name and a sequential numeric suffix.  In our default ConfigMgr task sequence template, we use a base variable name of "PACKAGES".  So you could specify entries in CustomSettings.ini like so:

PACKAGES001=XXX00001:Install
PACKAGES002=XXX00002:Install
PACKAGES003=XXX00003:Install

(Replace "XXXnnnnn" with your package ID and "Install" with your program name.  Also, in the case of CustomSettings.ini, we don't care if you specify PACKAGES1, PACKAGES2, PACKAGES3 or PACKAGES001, PACKAGES002, PACKAGES003 as we'll do the necessary translation to the ConfigMgr-mandated three-digit suffix.)

You could also specify the same values in the MDT database (on the Packages tab; we'll take care of building the proper list); in ConfigMgr collection or computer variables (you need to specify the PACKAGES001-style names, with no gaps in the sequence); via your own scripts; or via "Set Variable" steps added to the task sequence.  Regardless of how these values are set, the "Install Software" step that we have configured to look at the "PACKAGES" base variable name will see the entries in the list and install them all in the order specified.  Getting into all the pros and cons of one method versus another is a subject for a later day - for those of you who attended the "Part 4" session Tim and I gave at MMS 2008, you already heard this.

There is one other requirement to keep in mind (covered in the documentation at the link above, in case you didn't read that far):  Before ConfigMgr will allow a specific package:program to be installed, you have to enable it by checking the "Allow this program to be installed from a list of software packages in the "Install Software" task sequence step without being advertised" checkbox on the program.  This is a security feature in ConfigMgr: it wants your permission as an administrator before allowing this.

If you want to enable this option for all of your programs, consider running a script like this which will flip the required ProgramFlags bit for each program:

    sProviderServer = ""
    sSiteCode = "CEN"
    sNamespace = "root\sms\site_" & sSiteCode
    sUsername = ""
    sPassword = ""

    ' Connect to the SMS provider

    Set oLocator = CreateObject("WbemScripting.SWbemLocator")
    Set oSMS = oLocator.ConnectServer(sProviderServer, sNamespace, sUsername, sPassword)

    ' Build the query

    sQuery = "SELECT * FROM SMS_Program"

    ' Process the query

    iCount = 0
    Set oPrograms = oSMS.ExecQuery(sQuery)
    For each oProgram in oPrograms
        If (oProgram.ProgramFlags and 1) = 0 then
            oProgram.ProgramFlags = oProgram.ProgramFlags or 1
            WScript.Echo "Enabling: " & oProgram.PackageID & ":" & oProgram.ProgramName
            On Error Resume Next
            oProgram.Put_
            If Err then
                WScript.Echo "ERROR enabling " & oProgram.PackageID & ":" & oProgram.ProgramName & " possibly because of insufficient rights or because the package is not owned by this site.  " & Err.Description
            Else
                iCount = iCount + 1
            End if
        End if

    Next

    WScript.Echo "Total programs enabled: " & iCount

The script loops through each program, checking to see if the first bit (AUTHORIZED_DYNAMIC_INSTALL, described briefly in the ConfigMgr SDK) of the ProgramFlags field is enabled, and if it isn't the script enables it.  In most cases, you would want to run this program (using an account with sufficient rights) on your central primary site server, although if you have packages and programs defined at lower-level sites you would want to run it on them as well if you plan to use a task sequence to install any of those programs.

If you don't want to enable this on all programs, you can either modify the script above or you can manually enable the programs that you want.

Comments

• Anonymous
  January 01, 2003
  Hello Michael Good blog. I'm using the MDT SQL database to store the applciations, the customsettings.ini builds a list of apps to install. The process works correctly but is taking alot longer than SMS OSD. The logs show a 1 minute + time to check for policy...check log: Policy complied successfully in WMI 'rootccmpolicydefaultmachinerequestedconfig' namespace Get Install Directory for SMS Client waiting for local policy to take effect Policy evaluation initiated It is the task/step - waiting for local policy to take effect that takes the time. This happens for each appliation install. I have 40 apps to install... Has anyone else expericanced this? Does anyone know why this is happening? Thanks Peter

• Anonymous
  January 01, 2003
  I just wanted to blog this down real quick since it was fresh in memory. Troubleshooting a deployment

• Anonymous
  January 01, 2003
  This is an issue in ConfigMgr 2007 SP1.  Contact Microsoft Support to request a fix for this.

• Anonymous
  November 12, 2015
  Great post from your hands again. I loved the complete article.
  By the way nice writing style you have. I never felt like boring while reading this article.
  I will come back & read all your posts soon. Regards, Lucy.