Realize greater efficiency and responsiveness for software deployments and updates.
Application virtualization is at the heart of Microsoft Application Virtualization (App-V). It decouples applications from the operating system and enables them to run as network services. Application virtualization can be layered on top of other virtualization technologies—network, storage, machine—to create a fully virtual IT environment where computing resources can be dynamically allocated in real-time based on real-time needs. App-V's patented application virtualization, dynamic streaming delivery, and centralized management technologies make everything from deployments and upgrades to migrations and business continuity initiatives easier and faster with better agility:
Application virtualization: Enable applications to run without the need to visit a desktop, laptop, or terminal server. Applications are no longer installed on the client—and there is minimal impact on the host operating system or other applications. The most extensive virtualization technology on the market, App-V virtualizes per user, per application instance, as well as key application components. As a result, application conflicts and the need for regression testing are dramatically reduced.
Dynamic streaming delivery: Applications are rapidly delivered, when needed, to laptops, desktops, and terminal servers. In most cases only a small percentage of the application is needed to launch the application. Additional components are delivered when transparently requested by the application. This results in faster delivery of the application when needed.
Centralized, policy-based management: Virtual Application deployments, patches, updates, and terminations are more easily managed via policies, and administered through the App-V console or via your ESD system. Use Microsoft App-V Application Virtualization to help reduce the complexities inherent in enterprise application management. With App-V you can reduce challenges and transform your computing environment into a dynamic, services-oriented infrastructure.
The diagram illustrates the key components of Microsoft App-V Application Virtualization.
How to integrate App-V with SCCM without losing the features you care about
- ◦ 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
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 ->
- ◦ Enable your SCCM Distribution Points for BITS, HTTP and HTTPS content transfer. To do this, go to the SCCM Console -> Site Database -> Site Management ->
- ◦ 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/
(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.
Virtual Apps – Configuring SCCM
The first thing we have to do in SCCM is make sure our distribution points are enabled to deliver a virtualized app. You do that by going to any site system that is a distribution point and selecting properties on the distribution point component. From there we need to ensure two settings are enabled. First, on the general tab, make sure the ‘Allow clients to transfer content from this distribution point using BITS, HTTP and HTTPS is enabledNext, on the ‘Virtual Applications’ tab, place a check mark to enabled the distribution point to serve virtual apps
Then, enabled the advertised programs client agent to accept virtual application distributions as follows
Now we are ready to create a virtual app package. In the SCCM console, navigate to Computer Management > Software Distribution > Packages. Right click on packages and select New > Virtual Application Package. On the first screen browse to the location of your virtual app package, specifically the XML manifest
click Next and the information on the General page will be supplied for you based on the XML details. Supply any additional information or change as needed. Click Next on the General page and you will see the Data Source page
click Next and the information on the General page will be supplied for you based on the XML details. Supply any additional information or change as needed. Click Next on the General page and you will see the Data Source page
On this page, supply the UNC path to the directory that will serve as the SCCM source directory for this virtualized app. SCCM will make appropriate modifications to the package and copy contents to this directory. This is done to ensure SCCM has it’s own version of the package source to which changes can safely be made without affecting the master source directory for the virtualized app.
The remaining screens of the wizard are standard so we won’t show screenshots. When the wizard is finished we will have a new virtualized app package noted by the unique icon.
If we look at the SCCM package source for our virtualized app we notice a couple of changes. Compare to the screenshot above when we first created the sequenced package – note that a few files have not been copied over. SCCM only pulls over the needed files. Also note that the .sft file has been renamed with the SCCM package ID instead of the original file name.
Like in normal software distribution, add your virtualized app package to a distribution point enabled for delivering virtual apps and then create an advertisement.
When you create the advertisement note that there is no unique option for sending a virtualized app – just choose the standard advertisement option. The pages of the wizard are standard until you get to the ‘distribution points’ tab. Here you noticed that SCCM detected the app is virtual and is presenting you options accordingly
OK, all done, we are ready to stream the app on our SCCM clients – right? Well, maybe – first we have to make sure the app-v client is installed on all of our SCCM clients that will receive the virtual app because the app-v client piece is the one that actually runs the app. So, lets pause here and look quickly at an SCCM client that has the app-v client installed and has received policy indicating it should run the virtual app we just advertised.
App-V Client
When we open the app-v client console we have several nodes available – application, file type association and publishing servers. If we right click on the op node, application virtualization [local] and go to properties we can see general information about the app-v client. A couple of tabs are worth pointing out here
The ‘general’ tab shows us information about where log files are located, allows us to increase the verbosity of our logs and shows us the default user data directory.
Remember the Q: drive? The ‘file system’ tab shows us the default drive letter that will be used to execute virtual apps. If you modified the drive letter from Q: to something else on your sequencing system you should modify it here too.
Looking at the applications node of the app-v client console we can see our word viewer package has arrived
Going to properties on the word viewer application we can see the details the app-v client will use to execute the application.
Notice the package URL points to my SCCM distribution point. In the case of my test app I’ve configured that streaming will occur from the distribution point. If I had selected to stream from the local cache the URL would point locally to my SCCM client cache folder.
App-V Package and SCCM Client
OK, now on to actually launching the virtual app. First, if we look in the ‘run advertised programs’ control panel applet we see that the virtual app is arrived and is available to run
Just like a normal advertisement you can choose whether to make the virtual app run with a mandatory schedule or make it optional. If the choice is mandatory you much choose the option to ‘allow user to run independent of assignment’ for the app to show up as it does above.
OK, now, finally, it’s ime to run the virtual app! When the app executed all it did was place a shortcut on my start menu so the user can see the available app.
When we click on the app for the first time there will likely be a slight delay to start the app. After that, it’s very quick. The only indication that the app is running virtual is a small progress bar in the right hand bottom corner of the screen when the app launches
Besides that, you can’t tell that word viewer is running virtually. It launches and works just like it would if it were installed locally.
Notice a Q: drive is listed, noting that the application is running virtually – the drive is actually accessible through my virtual app but if you try to access the Q: drive from a cmd prompt you will get an access denied message – and the drive doesn’t even show up in ‘my computer’
Thanks:
Habib