Deploying Applications and Software Updates on Microsoft System Center 2012 Configuration Manager

Brian Mason

September 2012

Creating applications and deployment types

When we deploy applications, we have significantly more granular control of how they are installed, as well as confirmation that the application is truly installed (instead of just a success or fail return code). However, with additional functionality, we sometimes encounter additional complexity. Follow this recipe to drive through the application creation process, as well as the There's more... sections to understand the power of the application. Applications in CM12 are state-based, meaning that CM12 will determine if an application is installed (or not) on a regular basis. In CM12, application state is verified on a weekly basis (and can be modified in the Client Agent Settings configuration). So before you can create an application, you should know how to determine if an application is installed. The following are a few examples of how you may determine application installation status:

  • File information (whether the file exists, the file version, the file date, and so on)
  • Folder information (whether folder exists)
  • Registry information (whether the registry key/value exists, the specific registry value)
  • Windows Installer product code
  • Script-based detection (run a custom VBScript, PowerShell, or JScript to determine whether an application is installed)

Once you have this information, you are ready to proceed to create an application.

Getting ready

The first application we create is one of the easiest. Start here and work your way towards more complex applications.

An application that uses an Application Virtualization (App-V) package is the easiest to import (as well as maintain) in CM12. Next, a Windows Installer (.msi) based application is preferred.

We are going to create and deploy a very simple application: 7-ZIP. This will show you how to make multiple deployment types for an application. Before proceeding, have both the x86 and x64 versions downloaded using the following links:

Copy them to a share where CM can access them like \\myCMServer\Source$\7-zip\MSI.

Note that either the service account CM is running under, or the machine account of the primary (or CAS if you have one) must have read access to that share.

How to do it...

The Create Application Wizard allows us to easily create a new application. When you select the .msi file, CM12 automatically uses the product code of the selected MSI for the application detection rule. Create a new application and a deployment type for a x86 install by performing the following steps:

  1. In the CM12 admin console, navigate to Software Library | Application Management | Applications and click on Create Application in the ribbon.
  2. Under General, click on Browse, and then select the application's x86 .msi (for our example, \\myCMServer\Source$\7-zip\MSI\7z920.msi). Click on Open and then on Next to begin the creation process. Ignore any warning about the publisher not being verified.
  3. Under Import Information, click on Next.
  4. Populate the General Information tab, the screenshot of which is as follows:
  5. Notice that the Installation program, contains the default command lines for a standard Windows Installer program. Modify the command line as required.

  6. Optionally, you can add Administrative categories by clicking on Select.
  7. Finally, click on Next twice and then click on Close to complete the Create Application Wizard.

How it works...

Although we successfully created an application, there are several more options that are available to us to improve the user experience, as well as define proper targeting of the application. This section will examine all the options that are available to us for the 7-Zip application we just created. Navigate to Software Library | Application Management | Applications. Then right-click and select Properties for the 7-Zip application. A discussion about the various tabs under 7-Zip properties is as follows:

  • The General tab:
  • This tab provides information for the administrator. Add information to this tab to share with CM colleagues. The field Optional reference can be used to capture trouble ticket or work order numbers, or anything else used in your organization.
  • None of the information on the General tab is available to the end-user in Software Center or Application Catalog.

  • The Application Catalog tab:
  • This tab contains all properties to enhance the user experience when software is available through either the Software Center (for machine-targeted software) or the Application Catalog (for user-targeted software).
    • Select Add/Remove to add local language (based on users regional settings)
    • Localized application name will be the name that appears to the user in Software Center and Application Catalog
    • User Categories define the categories that appear in Application Catalog
    • User documentation can be an uploaded file, or a link to a web page
    • Link Text offers a description of the link used in User Documentation
    • Localized Description and Keywords are searchable through both Application Catalog and Software Center
    • Icon is only used with the Application Catalog. Import an icon to help users locate familiar applications
  • The References tab is used to display applications that depend on this application, as well as any application that the current application needs.
  • The Distribution Settings tab handles how content is managed.
  • The Deployment Types tab shows one item by default when we run the wizard to import a Windows Installer application. With our example application (7-Zip), there are two Windows Installer applications available, one for x86 and one for x64 operating systems. But CM imported only the x86 version so far.

There's more...

Recall how CM07 required programs for packages and for packages to be sent to distribution points before you could advertise them, leave the console open where it is so that we can create some deployment types (DTs) and deliver their content to DPs.

Creating deployment types


We will now modify the existing Deployment Type (DT) so that it will only install on x86 and create a new deployment type to support x64 installations. From the Deployment Types tab of the 7-Zip application's properties, select Edit to edit the DT. Review and modify the DT properties to confirm proper configuration. Commonly modified defaults are as follows:

  • Content: Modify distribution settings to all clients to fall back to unprotected distribution points, and changing the default of Do not download content for when a client is connected within a slow or unreliable network boundary to Download content from distribution point and run locally.
  • Programs: Modify the Windows Installer installation command line if necessary. Also notice the Uninstall Program option – by default this is available with a MSI deployment type, and will allow users to uninstall the (non-mandatory) application from Software Center. Verify that the uninstall command is functional, and modify as necessary, or remove the uninstall command line to prevent the uninstall functionality from Software Center.
  • Detection Method: This information is used to confirm the installation state of the application and (by default) will be checked weekly, according to client agent settings.
  • It is important to verify proper detection method. The detection method is used to verify whether the application is installed. Invalid methods may cause undesired results, such as automatic re-installations of a product or improper supersedence rules. Review more about supersedence rules later in this article.

  • Requirements: By default, you have no requirement rules defined. Since there are no requirements, this DT will install for any targeted system. For this example, you have a separate installation for x86 and x64 platforms, so add a requirement rule for x86 platforms by following these steps:
    1. From the Requirements tab, click on Add.
    2. Select Device> as the category, and then select Operating System as the condition.
    3. Check the boxes for all Windows 32-bit operating systems, for example, All Windows 7 (32-bit) and All Windows XP (32-bit).
    4. Click on OK to complete the deployment type.
  • Return Codes: If the installation returns any non-standard exit codes, add those codes here, as well as whether the code means success or failure.
  • Dependencies: We can add dependencies (such as .NET framework) if required – this provides a similar experience as "run another program first" with CM07, but with applications, the process is a bit smarter.
  • Switch to the General tab, and add x86 to the end of the Name to show admins that this DT is just for x86 systems. After all changes are completed, click on OK to save the Deployment Type configuration.
    1. Click on Add from the Deployment Types tab to start the Create Deployment Type Wizard.
    2. Click on Browse to select the x64 MSI (for example, \\mycmserver\source$\7-zip\MSI\7z920-x64.msi). Click on Open and then click on Next twice. Ignore any warning about the publisher not being verified.
    3. Under General | General Information, add x64 to the end of the name. Click on Next.
    4. For Requirements, click on Add. Choose Operating System for Condition.
    5. Check the boxes for all Windows 32-bit operating systems, for example, All Windows XP (64-bit) and All Windows 7 (64-bit). Click on OK, then Summary, then Next and Close to end the Create Deployment Type Wizard.
    6. Notice there are two deployment types (x86 and x64), Priority 1, and Priority 2. This is the order in which the deployment types will be evaluated. CM will execute using the first deployment type that qualifies for the system.
    7. Click on OK to close (and save) the modified application.
    8. Click on the Deployment Types tab in the bottom right-hand pane of the console to verify that 2 DTs show; one per OS type.
  • Perform the following steps to create a second deployment type (for x64 platform):


Specifying application settings


The process followed in this recipe so far has been for a simple Windows Installer-based installation (a .msi file). We also find a simple wizard for App Virtualization and Windows Mobile Cabinet (.cab) files. For all other applications, choose to Manually specify the application information in the Create Application Wizard. Many steps in the "Manual" process are the same, so you should be familiar with them after creating a Windows Installer based application. The manual process will walk you through to the Create Deployment Type Wizard, where you will specify the content source location, as well as install and uninstall command lines. The most challenging step to creating a manual configuration is the detection rule(s). As mentioned previously, applications are state-based, and will regularly verify if the application is installed. Spend time to ensure the detection rules are precise to avoid any surprises.

Classic package versus application
Now that we have walked through the process of creating an application, you may be wondering when to use classic package and program, compared to an application. As always, the answer is "It depends". Remember that when we deploy an application, it must be able to determine installation state based on detection rules. If we wanted to deploy something simple, like a netsh command to modify networking configuration, we would probably want to use a classic package/program. Most utility-type scripts will remain packages, while true applications should move to an application installation. You can continue to use classic package and programs for software installation, but you will not be able to take advantage of the granularity with deployment types and requirement rules offered by applications. Also, as shown with our 7-Zip installation, you deploy one application for x86 and x64, and at install time, CM12 determines the best DT to use.

Distribute an application to your DPs


Like CM07, creating a package or application doesn't get it to the DPs. We have to do that manually. Let's send 7-Zip to the DPs now by following these steps:

  1. From the CM12 admin console, navigate to Software Library | Application Management | Application and right-click on 7-Zip in the right-hand pane.
  2. Select Distribute Content. Click on Next twice.
  3. Under Content Distribution, click on Add and select either Distribution Point or Distribution Point Group.

    The former allows you to pick DPs one by one while the latter chooses a group. Groups have an advantage, in that, any new DPs added to them will get this application automatically.

  4. Assuming you have one DP, click on Add, select Distribution Point, check the box for your DP, and click on OK.
  5. Click on Next twice and then click on Close.

Deploying an application to workstations


Now that you have your application with at least one deployment type and it has been distributed to your DPs, you can make a deployment. We're going to deploy 7-Zip to the All Workstations collection.

  1. From the CM12 admin console, navigate to Software Library | Application Management | Application and then right-click on 7-Zip in the right-hand pane.
  2. Select Deploy.
  3. Under General, click on the bottom Browse button, choose Device Collections in the left-hand pane and select All Workstations in the right-hand pane. Click on OK.
  4. If you skipped the previous step to distribute the 7-Zip msi files to the DPs, you can do so now. Otherwise, just click on Next.
  5. Under Deployment Settings, change Purpose to Required (for this exercise, we're assuming all machines in a lab must have 7-Zip). Feel free to leave it as Available instead if you wish, but users will have to go to Software Center to get it – read more under the Managing Software Center and Application Catalog recipe. Click on Next.
  6. Under Scheduling, select a time or just leave the defaults. Beware that if you set a time, it defaults to UTC instead of local time. You can select Client Local time instead under Time based on. Click on Next.
  7. Under User Experience, select Hide in Software Center and all notifications (unless you didn't make Purpose to Required in step 5). Click on Next.
  8. Under Alerts, you can optionally set up any alerts you wish to appear in the console. Click on Next.
  9. Under Summary, click on Next.
  10. Under Completion, click on Close.

You can monitor this deployment by clicking on the Deployments tab in the bottom-right-hand pane of the console.

See also

Managing Software Center and Application Catalog

A common question from admins is "What's the difference between Software Center and Application Catalog, and when should I use each one?" The short answer to this question is if you plan to target software to users, you will use the Application Catalog. If you plan to target software to devices (computers, mobile devices, and so on), you will use Software Center.

How to do it...

To determine whether an application should (or will) appear in Software Center or Application Catalog, ask the following questions:

  • Do I need to target users or user groups for software delivery?
  • Do I need to target systems for software delivery?
  • Will Operating System Deployment Task Sequences be available for the user to start the installation?
  • Will you allow optional software updates installation, and/or software updates with a deadline, but allow the user to install in advance?
  • Do you use Task Sequences for Non-Operating System Deployment software installations?

Use the following table to determine if you will need Software Center, Application Catalog, or both in your environment:

CM Feature Application Catalog Software Center
User targeting Yes No
Device targeting No Yes
Supports task sequence deployment No Yes
Supports SW Updates No Yes
Supports custom updates (SCUP) No Yes
Displays custom icons for available software Yes No
Supports software that requires admin approval Yes No
Displays all targeted software regardless of requirement rules Yes No

In addition to the features above, the following CM12 user-enabled configuration settings are available at the described location:

Configuration Item Application Catalog Software Center
Specify normal work hours   X
Opt out of power management   X
Software Center schedules for computer maintenance   X
Configure remote control   X
Configure user device affinity X  

There's more...

One key difference between Software Center and Application Catalog is when requirement rules are evaluated. For example, if we take the 7-Zip application, and configure a DT requirement rule to only run on Windows 7 x64 systems. Consider the following scenarios:

  1. We deploy the application as Available to All Systems collection.
    • Application Catalog will not display the deployment
    • Software Center will only display the deployment on systems that meet the requirement rule (in our example, Windows 7 x64 systems)
  2. We deploy the application as Available to All Users collection.
    • Application Catalog will display the deployment on for every user that connects to the Application Catalog. When a user elects to run the installation, CM will evaluate the requirements and then make a determination for installation. If no deployment types are available for the installation (meaning the requirement rules of the deployment type(s) do not match the running system), the user will receive an error stating that This computer does not meet the minimum requirements for this application and cannot be installed, as shown in the following screenshot:
    • Software Center will not display the deployment.
    • As we can see, there are positive reasons for leveraging Software Center, as well as Application Catalog. Depending on the desired user experience, we may find more value in one or the other, or decide to use both.

See also

Preparing for software updates

Painters will tell you that all the work goes into preparation; the painting itself is fast and easy. The same goes for CM12 software update management. It takes some work to get a proper setup in place before the easy work of day-to-day management can begin. We will now show you how to setup your Software Update Point (SUP) and sync it.

Getting ready

  1. In the CM12 admin console, navigate to Administration | Site Configuration | Servers and Site System Roles.
  2. Select the WSUS server in the right-hand pane (or right-click if the server is yet unknown and enter the FQDN and site code).
  3. Select the Software Update Point and complete the wizard until you get to Supersedence Rules.
  4. This is new to CM12. If you never deploy superseded updates, you can now set them to automatically expire upon syncing. Expired updates can never be deployed. They won't cause errors, but they won't install either. Alternatively, if your company has issues with updates and has a need to keep some of the older updates around for a while, select a timeframe for when to expire them instead.

  5. WSUS 3.0 SP2 does not know which newer classifications and products are available until it syncs once. So choose Security Updates as a classification and just one product you plan to send out. Complete the wizard and after a few minutes, watch the SUPSetup.log, and WSUSCtrl.log on the SUP, and the WCM.log on the primary site for errors.
  6. To sync, navigate to Software Library | Software Updates | All Software Updates. In the ribbon, click on the Synchronize Software Updates button. Watch the wsyncmgr.log for errors.
  7. After a complete sync, navigate to Site Configuration | Sites, select the primary site and select Configure Site Components | Software Update Point, and choose the classifications and products you plan to update.

How it works...

Admins do not log on to the WSUS console with CM. All configurations made inside the CM admin console are passed on to the WSUS server. Only after WSUS syncs will it know about all products Microsoft is making available for software updates.

There's more...

Once CM has been told where WSUS is, it can configure and operate it. But clients also need to be told to use it and where to find it.

The Active Software Update Point

Each primary site server and the CAS must have an Active Software Update Point designated. To set the Active Software Update point, navigate to Administration | Site Configuration | Sites and in the right-hand pane choose the Site server, then in the ribbon, click on Configure Site Components and select Software Update Point. Even if you make more than one SUP, only one can be selected as the active SUP. If you need more than one, you must cluster them using NLB and select the radio button for Use Network Load Balancing cluster for active software update point.

Servers under a Central Administrative Site (CAS) will have Sync Settings grayed out as that is set only on the CAS.

Enable software updates on clients

With the server side of things ready, clients need to be told to use the SUPs instead of Microsoft updates. Navigate to Administration | Site Configuration | Client Settings. You can either enable software updates for all machines (at this point, it just means scanning only) or you can create a custom client setting to apply to just a test collection. Inside the settings window, select Software Updates and enable software updates on clients. At the next policy refresh of the client, it will have a local policy generated to use the SUP. If any GPO is set to designate an old WSUS server, it must be removed or the client will fail to scan.

Creating and monitoring software updates

Software updates management has changed dramatically in CM12. Gone are the Update Repository, Update List and Update Template nodes. The change is a reflection of the entire task of managing updates being simplified.

Getting ready

Updates have to be downloaded to a source location before they can be pushed out to DPs. On a server of your choice (yes, the primary or CAS is OK for this too), create a share for the patches, for example, \\FileServer\Patches$. The share permissions will need your ID to write the patches and the primary site server's machine account to read them.

How to do it...

Now it's time to actually create a package of software updates that can be used to target clients. This can be done by following the given steps:

  1. Navigate to Software Library | Software Updates | All Software Updates. The right-hand side pane shows the first 1000 updates. It has a new search window which is what you will use to build saved searches of various types of updates.
  2. To the right-hand of the search pane is a drop-down column Add Criteria – use it to select Date Revised, Superseded, Title, Update Classification, and Vendor. Click on Add.
  3. Set Date Revised to is less than or equal to and Last 1 month.
  4. Set Superseded to No.
  5. Set Title to does not contain and then type Itanium in the text field to the right.
  6. Set Update Classification to Security Updates.
  7. Set Vendor to Microsoft and then click on the search button to the right of the search field above.
  8. In the ribbon, click on the Save Current Search button. From this point on, you can always get to this group of updates via the Saved Searches button in the ribbon instead of having to create it each time.
  9. Assuming you wish to deploy these patches from the past month, you now highlight them all in the right-hand pane with a shift click and then right-click to Create Software Update Group. Give it a meaningful name when prompted, like October Updates.
  10. In the admin console, right-click on your new software update group to Show members. This is where you can right-click on a patch and select Edit Membership. This is new to CM12, and it allows you to remove a patch from this software update group or add it to others.
  11. You can create another search and add it to this group as well.

Patches have yet to be downloaded. That can be done manually now as shown next, or chosen in the deployment wizard when you create a deployment targeting a collection.

  1. Once you're happy with the patches showing in the group, it's time to download them. Navigate to the Software Update Groups node and in the right-hand pane, right-click on your newly created group and choose Download.
  2. The wizard offers the option to download to an existing package or to create a new one. In this example, create a new one with the Package Source set to \\FileServer\Patches$\October. Although you could simply download all patches to the same folder, it might help in troubleshooting to break them out by package.
  3. Finally, the software update package has to be pushed to the DPs. To do that, simply click on the Deployment Packages node in the left-hand pane, and in the right-hand pane click on your new package. Click on Distribute Content in the ribbon to start the wizard, which will allow you to choose which DPs or DP groups you wish to send the updates to.
  4. Allow the server some time to copy the package to the DP and click on refresh in the ribbon. The status of the content will be shown in the bottom right with a success message when ready.

How it works...

A software update deployment can use several software update packages at once. It's also possible to create multiple deployments targeting one collection. Using the Windows Update Agent, clients scan against the SUP, the content from the SUP and pull patches from the DP (or each other if Windows 7 BranchCache is used). Keep the latest Windows Update Agent available installed on clients for best scanning results.

There's more...

With everything in place to patch machines, the final step is to deploy the software updates to a collection.

Creating a software update deployment

Navigate to Software Library | Software Updates | Software Update Groups. In the right-hand pane, select the group, then click on Deploy in the ribbon. Name your deployment then browse to the collection you wish to target. Complete the wizard using your personal preferences for showing or hiding updates, or suppressing or allowing reboots. If the updates were not previously downloaded, the wizard will allow you to do that now. If you do not set a deadline in the wizard, clients will not install the updates in the deployment (unless there is another deployment targeting them). Deployed updates without a deadline will appear in Software Center on the client, allowing the user to optionally install the update.

Monitoring the deployment

For a quick glance at how compliance of your update group stands throughout the company as a whole, the bottom pane of the software update group will show counts and percentages. For a quick glance at compliance of targeted machines from your deployment, navigate to Monitoring | Deployments and click on your deployment in the right-hand pane. The bottom pane will offer overall details, but you can click on the View Status to drill down for more detail. For detailed reports via SRS, navigate to Monitoring | Reporting | Reports and type updates in the search window to bring up a list of built-in reports related to software updates. States 1 – Enforcement states for a deployment is probably the first used to monitor a specific deployment.

See also

Leveraging Automatic Deployment Rules

New to CM12 are Automatic Deployment Rules(ADRs). It's a way to bring to CM12 what WSUS had natively; the ability to automatically approve updates and deploy them. We'll show an example of how to create one to update Endpoint Protection definitions, but the concept can be used for all software updates.

Getting ready

Have a target collection created for a group of machines, which will serve as a pilot for new definitions before sending them to the rest of the company. Updates have to be downloaded to a source location before they can be pushed out to DPs. On a server of your choice (yes, the primary or CAS is OK for this too), create a share for the patches, for example, \\FileServer\Patches$. The share permissions will need your ID to write the patches and the primary site server's machine account to read them.

How to do it...

  1. From the CM admin console, navigate to Software Library | Software Updates | Automatic Deployment Rules.
  2. In the ribbon, click on Create Automatic Deployment Rule and enter EP Definitions and then browse to your pilot collection.
  3. Under General, check the radio button for Add to an Existing Software Update Group so that updates can be automatically downloaded. Leave the box checked for Enable the deployment after this rule is run.
  4. Under Software Updates, select Definition Updates for Update Classification.
  5. Under Evaluation Schedule, set the schedule for as often as you plan to pilot. If setting the schedule for production, set it to occur at least daily.
  6. Under Deployment Schedule, set the installation deadline for As soon as possible.
  7. Under User Experience, set user notifications to Hide in Software Center and all notifications.
  8. Under Download Settings, set both radio buttons to Download software updates from distribution point and install.
  9. Under Deployment Package, you are given the option to download to an existing package or to create a new one. In this example, create a new one with the Package Source set to \\FileServer\Patches$\EPDefinitions. Although you could simply download all patches to the same folder, it might help in troubleshooting to break them out by package.
  10. Complete the wizard then open the created ADR and go over every setting for possible mistakes.
  11. 11. Test the ADR by clicking on Run Now in the ribbon. After enough time has passed for the ADR to run and updates to download, click on refresh in the ribbon to see the Last Error Description in the right-hand pane. Review ruleengine.log for additional information.

How it works...

The ADR runs automatically on schedule, downloading the updates selected and creating new deployments. Much of the manual work done in CM07 can now be done with the ADR instead.

There's more...

The ADR has also created a deployment. The status of that new deployment should be checked regularly by looking at Monitoring | Deployments.

Reducing collection dependencies with conditional rules and global conditions

The new application model in CM12 introduces the strategy of allowing clients to determine if they should run an application instead of carving out a specific collection for the distribution. Instead of waiting for inventory and collection of refresh cycles on the server, deployments of smart applications are evaluated in real time by each client.

Getting ready

We will create an application that will run cmd.exe /C if a machine has at least 4 GB of RAM on board. cmd.exe /C is a simple command used for testing software deployments. The command launched a command prompt window for an instant, and then exits. We will make use of global conditions and rules to make an application that is far smarter than the old style packages in CM07 ever were.

How to do it...

  1. In the CM admin console, navigate to Software Library | Applications. Click on Create Application in the ribbon to start the wizard.
  2. Under General, choose Manually specify the application information.
  3. Under General | General, enter Client 4GB Test for the name.
  4. Under General | Deployment Types, add a script (opens yet another wizard) deployment type and name it Close a cmd box if 4 GB or more.
  5. Under General | Content, type cmd.exe /C for the installation program.
  6. A detection rule must exist. MSI-based apps and their versions, registry keys, and files and folders can all be set as detection methods for an application. We'll set it to look for Windows | Fonts folder, which is always there.
  7. Under General | Detection Method, select Add Clause and then select File System with Folder type, path of %windir%, and Fonts for the folder name.
  8. Under General | User Experience, choose Install for system, Whether or not a user is logged, and Hidden.
  9. Under Requirements, change operator to Greater than or equal to and enter 4096 for a value.
  10. You have just chosen to use one of the 16 default global conditions that come with CM12. You can create your own and save them under Software Library | Application Management | Global Conditions. All that was offered in CM07 was the operating system.

  11. Finish the wizards with the defaults, which will show the new Client 4 GB Test application in the list of applications in CM.

How it works...

When deployed, clients will evaluate the conditions set on the application just like they evaluate the need for software updates on their own. Just like you don't create a collection for every possible software update, you won't have to make one for each application. The cmd.exe /c is used for demonstration purposes. You can add this global condition (and many others) to the 7-Zip application created earlier in this article.

There's more...

Before sending any application, it's vital to test it and pilot it first. CM12 offers an additional way to pilot that CM07 did not have; a Simulated Deployment.

Testing the application using a Simulated Deployment

A collection created in advance affords the admin the opportunity to see how many clients would be targeted. A Simulated Deployment can offer that same information with no risk of anything ever actually installing. With a Simulated Deployment, nothing ever really installs. Right-click on this application and choose Simulate Deployment to launch the Simulate Application Deployment Wizard. Choose any collection you wish to test against. Choosing All Systems is perfectly safe.

Because this application does nothing more than launch a command window and then exit, it's already safe to send to any system. But choosing a simulated deployment over a standard deployment means that clients will only report that they would launch a command box if they had 4 GB or more of RAM.

Leave the action as Install and finish the wizard. Clients will evaluate against this application upon their next policy check from the MP. The check is not unlike a configuration item test via Settings Management. All of the same console deployment status and SRS reports will work as if the simulation had been a normal deployment. Any application can be sent as a simulated deployment at any time. A simulated deployment might save you when you expected an application to install to 50 machines and your report shows 5000 machines would have. It offers another chance to go over settings and conditions on applications themselves.

Deploying custom updates

Deploy custom updates using Microsoft System Center Updates Publisher (SCUP) Once configured, custom updates are synchronized, downloaded, and deployed just like all other Microsoft updates with CM12. You will also find third-party catalogs from vendors like Adobe, HP, and Dell. You can leverage these catalogs with SCUP to easily detect and deploy hardware (firmware, BIOS, and so on) and software updates.

Getting ready

To install custom updates, you must have a valid Software Update Point, as well as SCUP installed on either the server or your workstation. Search for the latest SCUP (current version is SCUP 2011) and download at After installing SCUP, follow the integrated help for assistance in preparing the environment – a signing certificate is required to publish and deploy custom updates, as well as a group policy update to allow locally signed updates to be deployed through WSUS. You also need to deploy the certificate to clients so that they will trust the installation.

Use SCUP to import catalogs from Adobe, Dell, and Hewlett-Packard. Work with your application vendor for SCUP support.

How to do it...

Follow these steps to create a SCUP install of 7-Zip:

  1. Launch SCUP, and select Create Software Update.
  2. On the Package information tab, browse to the filename to install (7z920-x64.msi). Also, specify the download URL. This can be a local UNC path, or an HTTP path. Note that the download URL is used at publish time. You will also see in the following figure that no command-line arguments have been added. SCUP automatically adds /quiet /norestart to all Windows Installer-based packages, so adding these commands to the command-line property will result in duplicate command-line arguments, causing a Windows Installer error.
  3. On the Required Information tab, populate all available information.
  4. On the Optional information tab, populate all available information.
  5. On the Prerequisites tab, add the prerequisite named WSUS Detectoid – CPU Architecture: x64-based systems, and select Add Prerequisite.
  6. Skip the Superseded Updates tab.
  7. Use Installable Rules to determine if the application should be installed. In our case, we already have a WSUS Generated MSI Installable Rule (read only), as a result of browsing to the MSI in a previous step.
  8. On the Installed Rules tab, leave the default rule, and continue through the wizard.
  9. Now use the SCUP console to browse to the custom update we just created, right-click on the update, and select Publish.
  10. Select Full Content from the Publish Software Updates Wizard. Continue the wizard to complete the publishing process. View %temp%\SCUP.log for more information.
  11. Perform WSUS synchronization from CM, and then search Software Updates to locate new custom update.
  12. Refresh the All Software Updates node. Search the node for the 7-Zip update, and follow your standard process for deploying software updates. The client experience will show all targeted software updates, including the custom update, as shown in the following screenshot:
  13. Select to install one or all applicable updates.

How it works...

SCUP is a great way to deploy updates to applications, and can also be used to deploy core applications, if required. Also SCUP 2011 supports both CM07 and CM12.

Microsoft System Update Packages (files that end with .msu) are not supported through SCUP. Review more information on Microsoft System Update Packages at

There's more...

As far as knowing when to use SCUP versus CM12 application deployment, as always, it depends. If you have baseline applications that you want to "set and forget", you could consider using SCUP. If you want to take advantage of the familiar patching process to deploy an application, patch, or setting, consider using SCUP. If you don't want to manage an additional certificate and GPO to configure SCUP, stay with Application Model.

See also

Converting classic packages to applications

The Migration Wizard in CM12 is fairly straightforward, and will help us migrate almost all objects from CM07 to CM12. Now that we have migrated classic packages, it's time to take advantage of the new Application Model for deploying software. The Creating Applications and deployment types recipe walked through the process – we could simply follow that same process to recreate each of the classic packages into applications. This would be a bit of a time consuming manual process. To streamline this process, Microsoft created the Package Conversion Manager (PCM, a throw-back acronym to the Package Command Manager of SMS 1.2). We will walk through the analysis and conversion process in this recipe.

Getting ready

PCM is a separate installation. Download it from Microsoft, and install on the CM admin console to be used for package conversion.

How to do it...

Follow these steps to analyze and convert classic packages to the new Application Model:

  1. From the CM12 admin console, navigate to Software Library | Application Management | Packages and right-click on the title bar to add the Last Analyzed/Converted and Readiness columns.
  2. Select one or more packages, and click on Analyze Package from the ribbon. (the package analyzer will run for a few moments, and then refresh the display to show Readiness state).
  3. Selected packages will now show one of the following Readiness states:
    • Automatic: The package can be automatically converted to an application. Typically, Windows Installer-based applications with one program can be automatically converted. We can multi-select automatic packages and convert them without additional effort.
    • Fix and Convert: The package requires additional effort before it can be converted. We can only fix one package at a time.
    • Manual: This may imply the package should remain a package. Review the package properties, and walk through the manual wizard to understand the underlying problem.
    • Unknown: The package has not been analyzed.
  4. Select all with a Readiness state of Automatic, and select Convert Package from the ribbon to begin the conversion process. When the conversion has finished, review the converted package(s) in the root of the application node.
  5. From the Packages node, select a package with a Readiness state of Manual or Fix and Convert, and then select Fix and Convert from the ribbon.
  6. The first page of the Package Conversion Wizard describes the items required to fix. In our example, the classic program specified an executable (.exe) for installation. In order to convert to an application, we must specify the detection method for the product.
  7. Under Deployment Types, select the first one in the list, and select Edit Detection Method. This action opens the familiar detection method dialogs to allow you to specify how to detect if the application is installed (filename and version, registry name and value, and so on). Repeat for additional deployment types and/or delete any unnecessary deployment types.
  8. Continue to work through this process for all classic packages that can be migrated to a new application.

How it works...

PCM analyses the classic package by analyzing the programs for a package. If we only have one program, and that program executes a Windows Installer file, the conversion process is very simple, and automatic. If multiple programs are discovered, the PCM may not be able to programmatically determine the deployment types you desire to create for the application. PCM does a very good job of establishing a workflow to enable you to easily migrate packages to applications.

There's more...

After using the PCM a couple of times, you will get a good idea of how you may consider altering programs in CM07 to enable automatic conversion to an application. Generally speaking, Windows Installer is good, and easy to migrate, with a significant caveat related to repackaged applications. If you repackaged an application to an MSI, use care with detection rules. If you have detection rules based on the repackaged MSI, you may not be able to identify an existing install of the application that was installed without the wrapper. Also, with a repackaged application to MSI, ensure that the product GUID is unique for the application. Otherwise, we may detect an installation for product A, B, and C, instead of the only the desired product A.

Creating and deploying Virtual Applications (App-V)

Virtual Applications (APP-V) applications are by far the easiest applications to deploy. Also remember with applications, we can have multiple deployment types. For example, we may have an App-V deployment type for Microsoft Visio, as well as a Windows Installer deployment type. We can then create requirement rules.

Getting ready

Before we can create the application in CM12, we need to have an App-V sequenced application. Also with CM12, we can create a prerequisite on the application to install the App-V client, if it's not already installed.

How to do it...

Follow these steps to create and deploy an App-V application:

  1. From the CM12 admin console, navigate to Software Library | Application Management | Applications, then right-click and select New Application.
  2. For Application Type, select Microsoft Application Virtualization and then browse to the manifest file (.xml) for the application.
  3. Populate the General Information page of the wizard (Application name, version, and so on).
  4. Complete the Create Application Wizard.
  5. View properties of the new application, and edit the Deployment Type.
  6. Select the Dependencies tab, and then click on Add.
  7. Enter a friendly name, such as App-v client prerequisite and then click on the Add button.
  8. Navigate to your Microsoft Application Virtualization client application, and enable both the x86 and x64 deployment types. (note that you need to create an App-V client install for x86 and x64 before completing this step).
  9. On the Add Dependency dialog, ensure the Auto Install checkbox is enabled for each deployment type.
  10. Click on OK to save the Deployment Type settings, and then click on OK again to save the Application Settings.
  11. To deploy the application, right-click on the application and select Deploy.
  12. Complete the Deploy Software Wizard to deploy the application.

How it works...

Clients will use the App-V 4.6 SP1 client (or later) to install these applications instead of the Windows Installer engine. They'll send status back on their success or failure to do so just like other applications.

Superseding applications

Use application supersedence to upgrade applications from a previous version.

Getting ready

Most of the work for supersedence requires precise applications configured for both the old and new application. For example, you are currently deploying an application named "7-Zip 9.20". A new version of 7-Zip (version 9.22) has been released. Create a new application for version 9.22 with the appropriate deployment types and detection rules. Perform additional tests to confirm that each application (version 9.20 and 9.22) installs successfully, and have uninstall commands specified in each deployment type.

How to do it...

  1. View Properties for the application, and then select the Supersedence tab.
  2. Click on the Add button, and then browse to the appropriate application that is being superseded by the new application.
  3. In the Specify Supersedence Relationship dialog, map the existing deployment types to the deployment types for the new application version. Also enable the uninstall checkbox to use the uninstall commands of the previous version of the product. If the uninstall checkbox is not enabled, CM will launch the installation process to supersede the previous version, assuming that the installation code will handle the upgrade/uninstall of the pre-existing product.
  4. Deploy the new application. You have the deployment option to Automatically upgrade any superseded version of this application.

How it works...

Supersedence checks for the existence of previous application installations, based on detection rules and requirement rules. If a system is targeted with the new application, previous versions of the application may be upgraded (depending on how supersedence was configured), and if no previous version exists, the targeted application will simply install. When you configure supersedence, you have the option to uninstall the previous version prior to installing the new version. This option will be selected differently for each application, as some vendors may support an upgrade (which may or may not require a previous version already installed), while other applications may require previous versions are uninstalled prior to installing the latest version. Work with the application vendor as well as test every possible scenario and simulate deployment before actual deployment. If you select the Uninstall option for the previous version, you must have uninstall information populated in the DT of the old application. Also please note that supersedence of an application does not make the previous version obsolete. You can deploy version 9.20 to one collection, and 9.22 (with supersedence) to a different collection.

Monitoring content and deployment status

With Software Distribution, content is king. If content is not available for an application installation, software updates, or operating system deployment, installations (obviously) fail, generating trouble tickets, and probably causing you to work extra hours.

Getting ready...

To monitor content and deployment status, we must have proper visibility to this information in the CM console. Be advised that Roles Based Administration (RBA) may prevent you from seeing everything. Work with your CM admins to ensure you have access to the proper scope for supporting your end users (and computers).

How to do it...

  1. From the CM12 admin console, navigate to Monitoring | Distribution Status | Content Status.
  2. Right-click on the title bar, and select Group By | Type. This will create groups based on type to easily locate the desired content.
  3. Select the name of the desired content, and observe the bottom detail pane to view distribution statistics.
  4. If required, click on the View Status link to view additional issues related to CM.
  5. If content is corrupt or missing, navigate back to the Software Library tab, and then view Properties, and finally the Content Locations tab.
  6. From the Content Locations tab, select the appropriate action to validate content (hash check), redistribute content, or remove content from a DP.
  7. Review the Deployments node to view the status of a deployment. Selecting the View Status action will show the current content status information.

How it works...

CM monitors the content of all packages and applications on the DPs, keeping track of versions and verifying integrity of the files. CM can also be scheduled to check the integrity repeatedly. Only when CM sees content on the DP as expected, will it offer the DP to clients. All of this monitoring is presented to users in the Monitoring node of the console.

You've been reading an excerpt of:

Microsoft System Center 2012 Endpoint Protection Cookbook

Explore Title