SCCM 2012 Beta 2 with App-V First Look

Microsoft made Beta 2 of SCCM 2012 available last week. Because I do a lot with App-V, I needed to get this up and running in my lab. This is a “first look” report. SCCM 2012, which is anticipated to be released in the 4th quarter of 2011, is a major overhaul of the product.

I’m not much of an SCCM guy; I’m more of an App-V guy but I work with SCCM because the SP2 release of the 2007 version added support for deploying App-V applications. Looking from the perspective of customers that were using the App-V Management Server to deploy virtual applications, even if they were already using SCCM to deploy traditional installed applications, using SCCM 2007 SP2 to deploy virtual applications was a step back. Especially for all of the customers deploying App-V on Terminal Servers and Citrix XenApp/Presentation Server, the implementation was too limiting. Most important was the inability to target and deploy to only certain users on a machine, and not have all users receive access to the virtual application. For those considering Migrating for desktops, the difference in deployment time for a virtual application was also a show stopper, although this was truly an emotional issue rather than a practical one. So I opened up the 2012 beta and played with it will suspicion.

So far, I am impressed. One immediate change, SCCM 2012 will only work on an x64 OS, and it requires 2GB ram minimum. Now I know the old SCCM had high memory minimums, but this one means it. Being a lab test machine, my OS also included the Sql database on the same VM, but the machine pretty much uses the full 2GB ram. I have been running it on the new Hyper-V, which allows it to grab more memory as it needs to, but with only a few machines to be managed it peaked at nearly 3GB. So don’t skimp on RAM. Oh, and you need the new App-V 4.6 SP1 release to work with SCCM 2012. I’m guessing that Microsoft had to make a couple small changes in the App-V client to support this release.

The UI for 2012 has been revamped in this version. In the old version, there was always a lot of clutter to scroll through to find what you needed for an operation. And it seemed that for any operation you wanted to do, there were always two or three ways to do it. The new UI is more organized and much easier to use. Some of the terminology changes, but once you get the hang of it, it seems much easier. I won’t go into details, but here is a typical screen shot.

For me, most important in this release is that SCCM now treats User identities as first class citizens. Much like device (system) discovery, users and user groups can be discovered from Active Directory. As applications are defined, these applications can be assigned to either a user or device group. And while you could assign SCCM packages to users in the old version, with this new version when you assign to the user you have a choice of deploying to all users on the OS or only that specific user. In the screenshot below, we can see that the WinZip App-V package has been assigned to a user group collection. The compliance field has a value of 20% because only one of the five users in that AD User Group has his system turned on. SCCM will naturally learn from the Client SCCM client when someone logs onto a device, just like always. SCCM 2012 also supports associating users with devices in the database, so that user based deployments can happen overnight even if the user isn’t logged in (as long as the device is powered on and available).

I tested the per user deployment on a Windows 7 machine.  I can’t test against a terminal server because Microsoft still hasn’t released the required App-V 4.6 SP1 RDS client yet.  But with WinZip deployed to the user group above, I logged into the Windows 7 machine using the credentials of a user in that group and verified that the virtual WinZip package was deployed and worked.  I then logged out of the machine and back in as a different user that was not in the user group.  I verified that the virtual application was not available to that user.  Exactly what we wanted! 

The application itself can contain many means to deploy it, depending on the situation. So with a single application definition, you can include a deployment type for a traditional install and a second deployment type for an App-V deployment. In the example below, I have configured three different deployments.

If it is a Win7 operating system and the client has the App-V dependency installed, the first App-V package is used. If it is an XP system with App-V, then a second App-V package is used. If there is no App-V dependency on the system, then a traditional silent MSI install is used instead.

This creates a great amount of flexibility in this single application definition. In fact, although it is called an application in the UI, it really is more like a set of deployment rules. I could have easily added a deployment type to put WinRAR on the box instead of 7-Zip for some of these deployments (such as if 7-Zip didn’t work on terminal servers, for example). Or maybe an RDP/ICA file to launch a remote session application if the user is out of the office.

In addition to the per-user deployment issue of the old SCCM, another issue was that App-V packages typically include multiple application shortcuts and file associations. With the traditional App-V Management server, we could assign individual shortcuts of a package on a per-user basis. With the old SCCM, it was all the shortcuts or nothing. This also is improved in the SCCM 2012 version. Below is a screen from an App-V deployment type record of an application, where we can define which of the shortcuts should be published. We don’t have access to the file type associations, so we still need to be careful with these while sequencing.

And, let’s talk speed. In our training classes, today we show an App-V deployment of a virtual application and updating it, but we don’t have time to wait for SCCM to test all of the sequenced applications. Over the course of three days, the average student will sequence and test at least a dozen different applications. Waiting for the SCCM agent to poll, messing with the control panel applet to beg it to poll, parsing the log files to figure out why it didn’t poll would take way too long. They might only get half as many apps completed. So we test those apps without SCCM. I still haven’t pushed out many apps, but so far this is looking much faster. It’s never going to be as fast – or provide the direct feedback of success – of testing using the App-V Management Server, or better yet the stand-alone App-V client using the AppV_DeployApp tool, but it isn’t bad!

There is a lot more one can talk about SCCM 2012. More about the UI, more about how the Database changes eliminate a lot of file copying and redundant processing to scale better. More about how you can define logic to detect the presense of applications and conditions that affect deployments, and logic to uninstall (why who would ever want to do that centrally?)  Also pre-deployment and mobile devices, and a smarter deployment server model, and a whole lot more. But I’m not an SCCM guy so you’ll want to read about that elsewhere.

From my perspective, if you are into this kind of thing, SCCM 2012 looks like a real winner to centrally management your application deployments.  Microsoft has indicated that it intends to move forward with App-V using both the App-V Management Server and SCCM deployment options for App-V customers.  Their intent is that the App-V Management Server, which is a no cost option (in terms of license cost for the App-V Management Server software, you still need an OS and Database Server) is the “good” while SCCM is the “better” option.  Until I started playing with this Beta, I didn’t think the reality would meet that intent.  It will take much more than this “first look” to determine if customers will want to deploy their App-V packages using SCCM 2012, but so far it looks promising.