You define static collections by manually adding a resource to a collection. An example of a static collection is a group of test workstations used to test software package deployments. As an example, the Test Workstations collection has TestWS1, TestWS2, and TestWS3 manually added to it. Static collections are useful when you need to define a limited number of systems or users to a collection and the membership in the collection does not change frequently. Membership is fixed (static) without manual changes.

You define dynamic collections by using a query-based membership in the collection. You can achieve the same result as with the Test Workstations static collection (see the previous section) by defining a rule to add any workstations to the collection using names starting with TestWS. This assumes that only test workstations are named with the test workstation naming convention (such as TestWS4). The benefit to a dynamic collection is it does not require manual changes to add resources to the collection. Let’s say you define a Test Workstations dynamic collection that adds all workstations starting with the name TestWS. If additional test workstations are created later, those new workstations will automatically become part of the Test Workstations collection.

Creating the ConfigMgr package for Operations Manager is straightforward and requires only a few steps:

Using an MSI file for the package definition greatly simplifies the process of creating the OpsMgr package, because the MSI supplies the information that otherwise would have to be manually specified to Configuration Manager.

With the package created, the next step is configuring the program the package will use. In the case of the OpsMgr agent, this is the Per-system unattended program. The Per-system unattended program deploys the OpsMgr package on a per-system basis and runs without user intervention. Right-click the program (located in the Configuration Manager console -> Site Database -> Software Distribution -> Packages -> <name of the package that was created> (in this case Microsoft Corporation System Center Operations Manager 2007 Agent)) and open the Properties page.

Properties for each program include the following tabs:

Each of these tabs defines how the program will function. Let’s review the content of each, using the OpsMgr package as an example.

The General tab (shown in Figure 13.9) has a variety of fields automatically populated with information, based on the package definition file used to create the OpsMgr package:

Figure 13.9. General tab for the per-system unattended installation program

You will want to make several changes to the program’s configuration on the General tab for the OpsMgr agent installation. First, add a comment explaining what the program will do. Next, change the properties on the Per-system attended command line, as follows:

This syntax will install the MOMAgent.msi in quiet mode, save the MSI log file to a log named MOMinstall.log, and provide no configuration information to the client (because the agent configuration is discovered from Active Directory). Run the program as hidden, keep the After Running setting of No action required, and specify a Category setting of OpsMgr. Figure 13.10 displays these settings.

Figure 13.10. Configuration changes on the General tab of the OpsMgr agent installation program

Now, move to the Requirements tab for the program. Figure 13.11 shows the default configuration for the OpsMgr program previously created using the package definition file.

Figure 13.11. Requirements tab for the Per-system unattended installation program

The Requirements tab tells Configuration Manager the requirements for running the program:

The Estimated disk space setting defaults to 86MB when the package definition file for the OpsMgr agent is used. Although the actual amount of disk space may vary from the amount defined with the package definition file, the default can provide a good starting point. As an example, installations of the OpsMgr agent can require at least 154MB of disk space based on the management packs monitored on the agent system, so the setting here will be 200MB. Although there is a large difference between an 86MB estimate and a 200MB estimate, it is better to overestimate the required disk space ConfigMgr will check for—so when applications are distributed they do not fill the remainder of the disk space on the system. The Estimated disk space setting can be in KB, MB, or GB, and it defaults to Unknown for program installations.

The Maximum allowed run time (minutes) setting defines how long the program is expected to run. There can be considerable variation in how a program will run; this depends on the speed of the system ConfigMgr is installing it on, the size of the program, and the network connectivity between the system and the source files used for the installation. In this example, the setting defaulted to Unknown. However, based on previous installations of the OpsMgr agent, it should complete within 10 minutes. This option has direct impacts to configurations on both the Environment tab and the MOM Maintenance Mode tab (discussed later in this section) due to the addition of maintenance windows within ConfigMgr 2007. This is used to determine whether a package has the time to install before the maintenance window closes.

Two options are available for platforms on which ConfigMgr can run the program:

For the OpsMgr agent, change the properties on the Requirements tab to set the estimated disk space to 200MB and the maximum allowed run time (in minutes) to 10. Also, specify that this program can only run on specified client platforms (that is, the x86 platforms this agent runs on), as shown in Figure 13.12.

Figure 13.12. Configuration changes on the Requirements tab of the OpsMgr agent installation program

The Environment tab for this program identifies when a program can run. Here are the options:

The conditions under which a program can run directly tie into the Run mode options:

Use the Allow users to interact with this program option in those situations where the user needs to interact with the program. The option Allow users to interact with the program is also an excellent troubleshooting method to use when packages are not installing correctly. With this option selected, the user interface is visible to the user logged in to the system, and the user can interact with the program. As an example, you will choose this option if the program requires the user to make a selection or click a button. If a program runs without this option selected and the program requires user intervention, it waits for the user interaction (which will never occur) and will eventually time out when the maximum allowed runtime has occurred (defined on the Requirements tab of the program; if undefined, the program times out after 12 hours).

The Drive mode that the program runs under includes the following configurations:

For the OpsMgr agent, take the defaults, as displayed in Figure 13.13.

Figure 13.13. Environment tab for the Per-system unattended installation program

The Advanced tab for the program, shown in Figure 13.14, specifies a variety of configurations, such as whether other programs run prior to this one, whether this program is run once for the computer or for each user, where program notifications are suppressed, how disabled programs are handled on clients, and how the program integrates with install software task sequences.

Figure 13.14. Advanced tab for the Per-system unattended installation program

For the OpsMgr agent, accept the default configurations, shown in Figure 13.14.

The Windows Installer tab for the program provides installation source management. If the program requires repair or reinstallation, the MSI file automatically accesses the package files on a distribution point to reinstall or repair the program. This screen defaults to cleared, as displayed in Figure 13.15 for the OpsMgr package.

Figure 13.15. Windows Installer tab for the Per-system unattended installation program

The available fields on the screen shown in Figure 13.15 are the Windows Installer product code and the Windows Installer file. You can define these by clicking the Import button and specifying the MSI file used for the program. Choosing the MSI file populates both of these fields.

For the OpsMgr agent, accept the default configurations as displayed in Figure 13.15.

The final tab determines the MOM maintenance mode configurations for the program. Two options are available on this tab, as displayed in Figure 13.16:

Figure 13.16. MOM Maintenance Mode tab for the Per-system unattended installation program

Using a package definition file provides a solid configuration for building the program required to install the OpsMgr agent. This is just one of the configurations completed with the Create Package from Definition Wizard, which also created the package that includes the program(s) previously discussed in the “Using the Create Package From Definition Wizard” section of this chapter. To see the properties of this package, right-click the package (located in the Configuration Manager console -> Site Database -> Software Distribution -> Packages) and go to the Properties page.

The package’s General tab displays the default settings created. These include the name, version, manufacturer, language, and comment for the package. Figure 13.17 shows an example of the General tab with the information populated from the package definition file.

Figure 13.17. General tab of the package

Notice the other tabs that are part of the package properties. The Data Source tab in Figure 13.18 specifies where the files are located and shows their distribution method.

Figure 13.18. Data Source tab of the package

In this example, the OpsMgr package was created with uncompressed source files (see the option previously specified in Figure 13.5 to always obtain files from the source directory). You can change this setting after creating the package, and change the location of the source files using the Set button next to this field. Unchecking the option This package contains source files will gray out the remaining items on this tab. Alternatively, you can also choose to make this package use a compressed copy of the source directory, which grays out the option to update distribution points on a schedule.

If you check the option Always obtain files from the source directory, there is an option to update distribution points on a schedule. This option is useful for those software packages that you expect to update source files for on a regular basis. The option is configured by using the Schedule button and then configuring the start time (which defaults to the current date and time), the recurrence (none, weekly, monthly, custom interval) and how often it will recur (in days, hours or minutes). This option is seldom used, however.

Use the option Persist content in the client cache for recurring packages such as antivirus software. This option stores the program in the client cache for an indefinite period; however, this requires that the advertisement is configured to download and execute. The option is disabled by default. Use this option with care, because it decreases the amount of available client cache and could cause a package to fail to distribute if there is insufficient space to store that package.

The last option on this tab is Enable binary differential replication, which by default is disabled. If this option is checked, the package uses binary delta comparison for the source files. This means that ConfigMgr sends only the changed portions of the file, rather than the entire file.

Checking this option can significantly decrease bandwidth requirements when creating updates for large packages already sent to distribution points. However, using this option introduces additional complexity to replicating packages and debugging issues with package distribution. For more details on binary differential replication, refer to Chapter 5 and Chapter 14.

For the OpsMgr package, leave the defaults previously configured through the package definition file, displayed in Figure 13.18.

The Data Access tab (shown in Figure 13.19) specifies the shared folder location of the package when sent to a DP as well as the package update settings. The shared folder location section allows you to choose one of two options:

Figure 13.19. Data Access tab of the package

The Package update settings section of the Data Access tab specifies how ConfigMgr will handle access to distribution points when there are updates to the package data. If users are connected to the distribution points, there may be locked files or inconsistent results—some of the files may be updated but others not. By default, the option to disconnect users from distribution points is unchecked. If this option is checked, two additional configurations are required; these relate to the number of retries before users are disconnected and the interval between user notifications and disconnections. This option only affects standard distribution points (not branch distribution points).

For the OpsMgr package, keep the defaults configured through the package definition file, shown in Figure 13.19.

The Distribution Settings tab displayed in Figure 13.20 specifies the priority, preferred sender, and configurations for branch distribution points for the package.

Figure 13.20. Distribution Settings tab of the package

The Branch distribution point content settings section has two options:

For the OpsMgr package, keep the defaults configured with the package definition file, shown in Figure 13.20.

The Reporting tab of the software package, displayed in Figure 13.21, specifies the configurations for the Management Information Format (MIF) configured for the package. The package’s MIF file is placed in the Windows folder; ConfigMgr can find the file and use the information in it to provide package success and failure information. Two options are available on this tab:

Figure 13.21. Reporting tab of the package

The last tab on the package properties is the Security tab. This tab defines the class and instance security for this package object. The top section shows the class security rights for the object and the bottom section shows the instance security rights. Each section has three buttons used to maintain entries in that section:

Figure 13.22 shows the default security rights generated from the package definition file. Chapter 20, “Security and Delegation in Configuration Manager 2007,” discusses security.

Figure 13.22. Security tab of the package

After completing the program configuration, your next step is to distribute the package, which is discussed in Chapter 14.

Packaging the Operations Manager agent with a package definition file demonstrates many of the configurations used when manually creating a package and a program. Although using a package definition file (an MSI, PDF, or MIF file) is the recommended approach, what takes place when a package definition file is not available? Drawing on the information just used to create the OpsMgr package, the next section discusses the process for creating packages and programs manually, using the Forefront client as an example.

Similar to when you created a package using a package definition file, open the Configuration Manager console and navigate to System Center Configuration Manager -> Site Database -> Computer Management -> Software Distribution -> Packages. Right-click Packages, and this time choose New -> Package. This starts the New Package Wizard. On the first page of the wizard (the General page), specify a variety of fields, each of which is your personal preference for the package. As long as the fields properly explain what the package is, the actual content is not critical. These fields include the following:

• Name— The name of the package. This example used Forefront Client Security Agent. To determine each of the fields for this package, right-click the program you are installing (clientsetup.exe, in this case) and work using the fields shown as program properties. For the name, you can choose a shortened version of the Description field shown in Figure 13.23.

Figure 13.23. Version information on the Forefront Client Security client installation program

• Version— The version of the software package. For this example, the version is 1.0.1703.0 which is available on the Details tab for the Properties of the Forefront Client Security client. The General tab for this is shown in Figure 13.23.

• Manufacturer— Who created the software package. Specify Microsoft, shortened from the Company field shown in Figure 13.23.

• Language— The language of the package (English, in this case), which is a shortened version of the language information provided as a value for the Language item.

• Comment— Additional information on the package. For consistency with the existing OpsMgr package, specify the comment shown in Figure 13.24.

Figure 13.24. Packaging the Forefront client on the General screen

Figure 13.24 shows the full set of information specified for the package. Note that the manufacturer name is automatically prepended to the name, with the version and language added at the end, thus giving the full name of the program: Microsoft Forefront Client Security Agent 1.0.1703.0 English, as shown at the top of Figure 13.24 in the field next to the package icon.

Click Next to continue and now configure the data source for this package. Specify the source folder created earlier, which is the d:sourceForefront folder. Anticipating there will be regular updates to this package, configure the package to update distribution points on a schedule (daily in this case). Figure 13.25 displays this configuration.

Figure 13.25. Packaging the Forefront client on the Data Source screen

There are no additional fields in the wizard you need to alter from the defaults (Data Access, Distribution Settings, Reporting, Security, Summary) so click the Finish button on Figure 13.25 to bypass the remaining configuration pages. Click Next on the Summary page and click Close after creating the package.

The package is created, but without any programs for the package to run. To specify the program you want to create, open the Configuration Manager console and then navigate to System Center Configuration Manager -> Site Database -> Computer Management -> Software Distribution -> Packages -> Microsoft Forefront Client Security Agent 1.0.1703.0 English -> Programs. Right-click Programs and choose New -> Program to start the New Program Wizard. On the General screen, specify a name, comment, command line, and how the program will run. For this example, configure settings for the Forefront client as displayed in Figure 13.26.

Figure 13.26. Creating the program for the Forefront client on the General screen

The Name and Comment fields can contain whatever text is appropriate, and do not require a specific set of text as long as they properly describe the program and its function.

However, the command line needs a very specific set of information. How do you know what to put into the command line field? There are two primary methods for determining the appropriate command-line information:

• The easiest method is opening the folder containing the installation program and running the program with /? after the command. As an example, Figure 13.27 shows the output from running clientsetup /?. The parameters shown here indicate the parameters necessary to specify when running the program. The command line shown in Figure 13.27 uses both the /CG and /MS parameters to install the Forefront client.

Figure 13.27. Output from running the clientsetup /? command

• Alternatively, you can find command-line information using the Internet to check commonly used sites, such as myITforum.com and AppDeploy.com, or just search for command-line parameters.

Figure 13.26 also shows the Run parameter set to Hidden, so the user will not see the program installing on his or her system. Keep the default “After running” selection of No action required. Click Next, and continue on to the Requirements screen.

On this page, set the estimated disk space to 350MB (based on the client requirements available at http://www.microsoft.com/forefront/clientsecurity/en/us/system-requirements.aspx). You will also want to specify the x86 platforms (this is further restricted, because for the XP platforms only Windows XP SP 2 is supported, and for the Windows 2000 platforms only Windows 2000 SP 4 is supported). Figure 13.28 displays this configuration. Click Next.

Figure 13.28. Creating the program for the Forefront client on the Requirements screen

On the Environment screen, change the default configuration to run whether or not a user is logged on. Take the default configurations on the Advanced, Windows Installer, and MOM Maintenance screens. Click Finish to move to the Summary page and click Next to finish creating the program, then close the wizard.

At this point, you have created a package for the Forefront client and a program that runs an unattended installation of the program. The next step would be to specify the distribution points to use to distribute the software, but that discussion takes place in Chapter 14.

Software repackaging takes an existing application installation and converts it to an MSI package. You would take a snapshot of a system before and after installing the software on a system and then convert the results into the MSI package. Several tools are available to help with repackaging:

However, there may be software you cannot even effectively repackage to create an MSI. Although this is not common, it can happen.

A coworker had a situation where OSD was being used to deploy a large number of operating system upgrades. The client had a Wireless Configured Privacy–based wireless configuration that needed to be deployed to all systems being upgraded. Testing determined no method existed that allowed either installing the WEP configuration or repackaging the WEP configuration. Faced with that situation, the best option was to use a scripted installation.

A scripted installation uses a tool such as AutoIT (available for download at http://www.autoitscript.com), which uses a simulated set of keystrokes, mouse movements, and Windows manipulation to automate tasks. These tasks are tested on a client workstation until they reliably perform the process they were designed to perform. The tasks are compiled into an executable that ConfigMgr can deploy as a software package. The software package requires the user be logged on and can interact with the package, because the scripted installation actually performs the installation through the user interface. Although it is not recommended as an approach for providing software installation, this is a good trick for those cases where no other software packaging approaches are viable.

Consider an environment that needs to run Microsoft Word 2003 and 2007 on the same client system. There are several ways to accomplish this:

SoftGrid runs applications in a siloed environment using virtualized versions of the operating system components, including the Registry, files, fonts, INI settings, COM configurations, embedded services, and environment variables. This siloed approach means that applications do not install directly into the client system. If the user were to open up the Registry on his or her workstation, there would not be any Registry settings for Microsoft Word, even though there is an icon for Word on the desktop and Word runs as if it was a locally installed application.

SoftGrid provides this functionality through a client- and server-based configuration. The SoftGrid architecture uses a SoftGrid Virtual Application Server for delivering applications, and it uses a client that installs on those systems that will have applications deployed.

SoftGrid-defined applications use a process called sequencing. Sequencing defines how a standard application will install and function as a virtualized application.

When using virtual applications with ConfigMgr, you must deploy both the ConfigMgr client and the App-V client to those client systems for the virtual applications to work on these systems.

Microsoft released the first Microsoft-branded version of the product formerly known as SoftGrid in 2008, naming it Microsoft Application Virtualization 4.5 (App-V 4.5 for short).

You can get App-V 4.5 several ways:

You can take applications sequenced using App-V 4.5 and deploy them as virtual applications with ConfigMgr 2007. Additional information on App-V 4.5 is available at http://www.microsoft.com/systemcenter/appv/default.mspx, and the App-V 4.5 FAQ is located at http://technet.microsoft.com/en-us/appvirtualization/cc664494.aspx.

When Microsoft added SoftGrid to its product line, the functionality crossings between SMS and SoftGrid were significant:

Configuration Manager 2007 Release 2 (R2) provides integration between these two programs such that you can manage App-V virtualized applications from Configuration Manager 2007.

Before creating the package, place the sequenced application on the site server. Perform the following steps:

When sequencing your next application, create a new folder under the SoftGrid folder for the new application (say, Microsoft Office) and then create a new folder under VirtualApps for the new application as well. This approach provides a consistent way to locate the various shared folders under the VirtualApps top-level folder.

After storing the sequenced application in one folder, and creating and sharing a destination folder, you are ready to start the wizard to create the virtual application! Perform the following steps:

Figure 13.36. ConfigMgr console with a virtual application created

The integration of virtual application packaging into ConfigMgr 2007 R2 is a large step forward in providing a single platform to package and deploy software, regardless of whether it is deployed as a software package or a virtual application.