• Limited configuration options for download behavior (i.e. metadata only vs full content)
• Expired updates cannot be removed from the updates server easily
• Approval and publishing updates requires multiple steps to be taken

With SCUP 2011 you now have a so called ConfigMgr integration. This integration option can be used to regulate download behavior for an update. In general you probably want clients to download only metadata from SCCM/SCUP if only a few clients request an update. When the number of clients increase it would be better to download full content so that clients will use common distribution points instead of an internet location to download the update to avoid unnecessary bandwidth utilization. With the thresholds you can regulate this now.

Expiring and removing updates properly was a hell of a job if an update was removed from a vendor’s catalog. In SCUP 2011 you can use a new Software Update Cleanup Wizard for this. So now, expiring a software update that exists on the update server but is not in the SCUP repository is an easy job.

SCUP 2011 has a Publish tab where you can bundle updates that you want to deploy to your clients. This is a new feature that makes it somewhat easier to manage and administer the SCUP update repository.

What I like the most about SCUP is that you are able to deploy software with the WSUS functionality available. In large enterprise environments normal software distribution requires lots of steps to be taken by various departments for each individual software update. These steps include scripting, testing, configure SCCM packages, collections, advertisements, etc. New software updates like Adobe’s Flash Player are being released very rapidly. It requires that you’ll have to execute the same procedure over again to deploy it in your enterprise. Using SCUP and Adobe’s update catalog instead will save you a lot of time.

Installing drivers, BIOS, hardware utilities and firmware for instance on Dell systems is an easy job using SCUP. Minor disadvantage is that you will need the OpenManage client running on client systems to provide some necessary WMI classes. These extra classes will be used to identify the hardware peripherals. WSUS uses this information to compare with the catalog logic rules:

With SCUP you can use the logic which comes with the catalogs to deploy a software update bundle that include multiple updates at once. Compare the logic within the catalog with the queries you normally use in SCCM collections for grouping the client systems what you’ll need for targeting the software.

You can also create your own updates. As an example i’ve added the Google Chrome browser installer as a required update with Adobe Flash Player as a prerequisite .

Happy updating!!!

Douwe van de Ruit

So what happens when you enable the App-V/SCCM integration feature in the SCCM Management Console?

• Control of the App-V client is seized by the SCCM client. If you had App-V running on its own before you enabled the integration, you’ll notice that all App-V apps that are published through App-V’s Publishing Server are now rendered invalid. On launch you’ll get a “Unable to initialize package information (0×00000000)” error.
• You must now publish your App-V apps through SCCM as “Virtual Application Packages”. This works by importing the .XML file of the App-V package. SCCM will distribute the packages to its Distribution Points and you can enable those Distribution Points for HTTP(S) streaming.
• To get the App-V apps to your clients, you’ll have to create SCCM advertisements. Basically SCCM advertisements replace the App-V Publishing Server. The behavior of getting App-V apps to your desktop now becomes eerily similar to SCCM’s way of installing applications. No more getting your shortcuts immediately upon logon (like you get with App-V); you will have to go get a cup of coffee and hope that SCCM is willing to give you your apps today.
• If you created non-mandatory assignments, then you’ll have to go to Add/Remove Programs yourself and click “Run” for all the apps that you want. However clicking “Run” doesn’t actually run your app, it only registers the App-V app with the local App-V client. Don’t expect to see any progress bar or visual feedback that the registration actually happened; just keep scouring around in your Start Menu in hope of finding the shortcuts for your new app.
• If you created mandatory assignments, you’ll get one or more notifications from SCCM (after some time ofcourse) that SCCM has App-V apps for you that it would like to register with the local App-V client. It will do that on *every* desktop you logon to. Prepare to spend quite a bit of quality time with the SCCM Client…
• If you’re using either Windows Terminal Services or Fast User Switching in Vista, you’re SOL because the SCCM Client is allergic to terminal sessions. You’ll get a message telling you that “No programs are available to run from a Terminal Services session”. How nice. If you happen to be running the console session, you won’t notice this limitation because at the console session, everything works just fine. So make sure you also test your solution via a terminal session so you won’t get caught by surprise.

As a result of the findings described above, we were pretty disappointed with the solution and decided to reverse our decision to integrate App-V with SCCM. However we did like the idea of using SCCM Distribution Points to stream App-V apps from. So we had a go at doing a manual integration of App-V with SCCM so that we could use just the SCCM parts we wanted. The idea was inspired by Tim Mangan’s article which included this diagram:

In his article he never got around to actually testing if it was possible to stream an application that was published by App-V’s Publishing Server from an SCCM Distribution Point. He only verified that is was possible to install the App-V app through an MSI with SCCM. So we ventured to get HTTP streaming working against SCCM Distribution Points, with the shortcuts still being provided by an App-V Publishing Server. In a nutshell: it works! You do have to setup a few mechanisms to get load balancing working though.

Here is how it works:

• First and foremost: disable the App-V integration with SCCM. To do this, go to the SCCM Console -> Site Database -> Site Management -> <Site> -> Site Settings -> Client Agents -> Advertised Programs Client Agent -> Properties and make sure “Allow virtual application package advertisement” is NOT selected.
• Enable your SCCM Distribution Points for BITS, HTTP and HTTPS content transfer. To do this, go to the SCCM Console -> Site Database -> Site Management -> <Site> -> Site Settings -> Site Systems -> <your DP> -> ConfigMgr distribution point -> Properties and select “Allow clients to transfer content from this distribution point using BITS, HTTP and HTTPS”.
• We found that (at least in the RTM version of SCCM 2007 R2) you don’t have to enable “virtual application streaming” on the “Virtual Applications” tab of the distribution point to be able to stream from a SCCM DP when using our manual integration. The added benefit of this is that you can now also use Secondary Site DP’s as streaming servers!
• Set up an App-V Management Server on any server you like. You can even set it up on a SCCM server, it doesn’t matter. Use the default installation settings for the entire installation. After installation, set the Default Content Path to the following: http://%SFT_SOFTGRIDSERVER%
• Add an App-V package to SCCM for distribution and streaming:
  • Go to the SCCM Console -> Site Database -> Computer Management -> Software Distribution -> Packages -> New -> Package. Enter the information about your package and click Next. Select “This package contains source files” and set the Source Directory to the location of your App-V package and click Finish. Note that you import the App-V package as a normal SCCM package and NOT as a Virtual Application Package. Importing it as a Virtual Application Package will cause the .SFT file in the App-V package to be renamed and cause the .SFT file to be added to not 1 but 2 locations on each SCCM Distribution Point, doubling storage requirements.
  • When the package is added to SCCM, find the Package ID and use it to update the streaming location in the App-V OSD files. For each OSD file in your App-V package, update the HREF statement to HTTP://%SFT_SOFTGRIDSERVER%/SMS_DP$/SMSPKG/<your SCCM Package ID>/<name of your SFT file>
    (If you are using a File Share Distribution Point, the IIS vdir may be different than SMS_DP$. Verify the vdir name in IIS Manager and ensure that all DP’s are either standard DP’s or File Share DP’s.)
  • Now add some SCCM Distribution Points to your package so that SCCM can distribute the App-V content
• Import the same App-V package into the App-V Management Server so that you can distribute the shortcuts and set permissions:
  • On the App-V Management Server, go to the App-V Management Console, go to Applications
    -> Import Application and go to the same App-V package folder. Select the .SPRJ file and click Open. Perform your regular App-V import steps and finish the import.
  • The imported applications in the App-V Management Console should now show the correct http:// paths to both the OSD file(s) and the SFT file(s).
• That’s it! Now just configure your App-V Clients on the desktops to use your newly setup App-V Management Server by configuring a Publishing Server and use Group Policy to set the %SFT_SOFTGRIDSERVER% to the name of a SCCM Distribution Point nearby. We set this variable to DNS name that uses DNS Round Robin to distribute the load to multiple DP’s.