Key Concepts of User Centric Application Delivery in Configuration Manager 2012: Part 1

At its core, our highest-level definition of user-centric management is:

The centralized policies for and delivery of all resources needed for corporate end-users to do their jobs anywhere on any device in a safe and compliant manner.

There are a lot of pieces to user-centric (see User-centric Management Part 1), but what I want to talk about in this two part blog series are five key conceptual changes in ConfigMgr 2012 that will fundamentally change the way that you think about delivering applications in the future. Do you HAVE to change? No - we know you TOO well to force you to change! But Consumerization of IT is driving a change in how end users want to access applications on any device, and this cannot be achieved by the traditional method of targeting software to user objects. It requires a fundamental shift in the how applications are delivered so they can be easily accessed by any device. Here are the first two concepts we’re introducing:

#1: Applications are very different

In ConfigMgr 2012 – we have an application! In ConfigMgr 2007, we never really had an application. We had a content object (package) and execution objects (programs). You could mix and match them to come up with about anything you wanted. In ConfigMgr 2012, we have an "application." If you want a fun exercise, you and your peers should get in a room and argue about whether MS Office is the application, or if Excel is the application – I know we did! :-) But, the questions above will allow you to answer that. Do I deploy Office? Do I measure compliance of Office? Do my users look for Office? Do I version manage Office? As you're deciding what an application is, those will be the key litmus questions you'll want to ask.

An application is not just an MSI or EXE anymore. We virtualize applications now. Applications can be server hosted with technologies like Citrix XenApp or Remote Desktop Services. Applications install on different form factors and platforms. Applications can now be cloud services delivered via the web. We even have tens of application "stores" now that can deliver applications more easily without us doing so. There are some applications that can even span all of these different technical representations. I like to pick on Microsoft software, specifically MS Office. Imagine a world in the future (you decide how distant) where you just want your users to be able to use MS Office. That same version of MS Office may be locally installed, virtualized with MS AppV, server-hosted via XenApp or RDS, on a CAB file for your mobile device, on a Macintosh, or from the cloud. Users X need app Y gets WAY harder in this world! In ConfigMgr 2012, we're not solving all of these – but we have built our application model in a way that a single application can represent multiple technological forms like local delivery (scripted, MSI), MS AppV, or mobile formats.

So, how does this change the way you deliver applications?

First of all, this is a lot of new technology to understand. I would bet most ConfigMgr admins don't also own RDS, and in many cases may not know or work with the team that does. Same is true as we look beyond just Windows PCs and look at mobile devices. You need to definitely broaden your thinking and knowledge to include all of these application technologies and other teams so you can understand how to leverage them to better deliver resources to your end-users. The other change to keep in mind is that users have higher expectations for applications. Businesses and end-users expect more software to do their jobs, and they will expect you to deliver it to them. The old days of "give me a few weeks/months to test this application out on our standard build, then I'll get it to you" will not survive a new world. Really look to virtualization and server-hosting technologies to speed up delivery of applications where possible.

#2: An application is state-based

OK - more geeky jargon. What does it mean for an application to be state-based? In simple terms – the application knows its own identity. This means it knows not to install where it's already present, and if the application is required for a system, it knows to check periodically that it is installed (and reinstall if it is missing). Because of this state-based approach, we now track compliance separately from installation. For example, you can be compliant if we didn't install the software, but we detected it was already on the system. Now, we don't manage the entire state of the application (aka track every MSI table entry!) as that's frankly like killing a squirrel with a canon. We just check that the application is present. This "identity" is what we call a detection method. If you've used DCM today in ConfigMgr 2007, or System Center Updates Publisher, you're a bit more used to this concept. We'll try to help automatically create a detection method with something like an MSI by using the MSI Product ID. And, for MS App-V, we know the ID in the manifest so you don't have to do anything for the detection method. But there be many cases where you need to create a detection method for an application to correctly identify it on a system.

So, how does this change the way you deliver applications?

Well, you'll never have to go build extra collections around, "if the app isn't present, go reinstall it" using DCM or inventory. And, you won't have to target "systems that don't already have the app" by using things like difficult inventory queries or collections where the advertisement hasn't previously already run. So, it should save you some time and a bunch of extra collections. The biggest thing will be in how the application behaves. If you get the detection method incorrect, you may see applications that install where already present - making for a bad user experience. Or, if you get it incorrect the other way - you may have applications not installing, and showing compliant - when the application wasn't there.

How do you get successful with the detection method? First of all, work closer with your application experts, repackaging staff, or application developers. They typically know this information already. In fact, every application setup/install in the world is designed to check for, "don't install if the app is already present". Secondly, use existing features in ConfigMgr today that leverage this. Use DCM to create Application CIs for your existing applications. Use SCUP to create updates for things today. Finally, we've put a new feature in the Release Candidate called Simulated Deployment. This feature allows you to take an application and target it to real users/systems, and then run the application detection method, rules, and relationships to tell you what we would have done. That way you can see the results of the actions before you deploy the application.

To find out about the remaining three key changes in the ConfigMgr 2012 application delivery model, continue reading Key Concepts of User-centric Application Delivery Part 2.

Bill Anderson

Principal Program Manager Lead

System Center Configuration Manager