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

  • Article

We discussed how applications are different in Part 1, so now we’ll move on to how application targeting, rules, and relationships change in ConfigMgr 2012’s user-centric universe.

#3: Application targeting will change dramatically in the future

There are really four “thesis statements” that represent how targeting fundamentally changes in user centric because of rules, available software, and approvals: 

  • You target applications to users, not machines. I think we’ve covered this ad nauseum. We know from our extensive research that every application request literally starts with “users X need application Y”. We want to get you to a world where your technology reflects your business processes!
  • You target at a business level and rely upon detection method, requirement rules, and dependencies to make sure that the application only tries to install on a system it can and should install. No more inventory collections based on whether the machine can install the application, or if it’s present. Requirement rules and dependencies make sure prerequisites are met, and even auto-deployed if need be.
  • You make software available to a broad group of users, and instead of scheduling the installs – you let them come install the software when they’re ready. We believe the world will move to an 80% “available” model for deployments. Required installs are great for machine updates, but for an application a user needs to use, required software and forced install based on scheduling will reduce dramatically. For you? Fewer collections to manage, fewer “deployments” to create/track.
  • You think in terms of targeting the software to “those that can see it – and who could have access to it if approved” instead of “only the users that need to install it.” You make software broadly visible, and create a way to show users what they can use if the business allows. What we learned early on with this is that targeting software long-term will look more like SharePoint permissions! Your software will evolve organically based on who needs it, and who has purchased/owns it.

How do you get ready for this? A few things to consider: First off, work with some of the teams/tools that do a really good job today of delivering applications to users. I’d talk to your RDS or Citrix administrator as a starting point. Next, you will want to really build a good fundamental process around user/device affinity to increase success at user targeting in general. Also, look at integrating a business approval tool and process on top of ConfigMgr. We have a basic approval in our admin console, but for some of you, that won’t be enough. Finally, Simulated Deployments will also be a great tool as it will show you how moving hardware elements from collections to requirement rules will behave so you can become skilled at it. 

#4: Rules evaluated dynamically on the client

Today in ConfigMgr, the vast majority of the things you do are evaluated on the server. Users X need application Y? I really translate that into, “send the installation policy to the machines that inventory tells me can install it correctly based on minimum system requirements and dependencies.” I create a collection, I hit refresh, and I see exactly what machines will be handed the policy to install that application. I know explicitly where it is going to go. The simple fact is that systems and users are too dynamic, too mobile, and too complex for a system that relies on 7-day-old inventory as a basis for what systems should get software. So, our approach now is to put all the information on the application that needs to be successfully installed. Requirement rules, dependencies, superseding applications, etc. All of this information is implicit in the application and how it should behave regardless of where it is evaluated for installation. Even the automation around dependent applications is just built in. And, it all happens on the client.

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

Immediate gratification vs. the unknown! Today, you build a collection and (after hitting refresh) you know the approximate scope of your change. You probably also know if you did something wrong because the results look way larger or smaller than you would have expected. In a world where rules/relationships are evaluated dynamically on systems, you have no visibility to the scope. What if you did some of the rules wrong, or want to know more of the details around “how many users will get the App-V deployment type vs. the MSI deployment type?” A great example of this is how we’ve watched hundreds of our customers and MVPs using the application model for the simplest rule of “minimum free disk space.” The most common mistake is to get the wrong operand and select “=” instead of “>=”. If you set a rule to only install this deployment type on a machine that has exactly 1GB of free disk space, you’ll probably not install it anywhere! 

How can you adapt? We’ve put some features in the product to help out. First of all, in the administrative console we have a feature called the “Relationship Viewer” (yes – don’t think it’s lost on us how many corny jokes you can tell about relationships and ConfigMgr! J). This is a graphical tool that allows you to look at full dependency or supersedence chains, as well as even see an application, its deployment types, and the global conditions related to it. The goal is to ensure that with all these deep/detailed relationships now, you can see exactly what you are deciding. You can graphically see the other objects tied to this particular object, and have a better understanding of what will be done. Secondly, I’ve mentioned the Simulated Deployment a few times, and this is the main reason we did this feature – so you can build trust in your ability to build rules and relationships in a predictable way. Finally, with rules in particular, we’ve created the ability to put groups of rules together into global expressions, so you can get great reuse of these without missing one or getting the wrong ones selected. 

#5: Relationships

In ConfigMgr 2007, there were a handful of what I would call “loose” relationships in the system, such as dependent programs or Task Sequences that called other applications. These weren’t really “relationships,” but more automation strings. And, they only really went one level deep. In ConfigMgr 2012, the relationships between applications are much richer and much more of a true “relationship”. They can go multiple levels deep, and they are honored by both objects – not just one. The two most prevalent relationships you’ll see are dependency and supersedence relationships on applications. Do NOT think of these as just “dependent programs” – the relationships are more than just installation automation. A dependency can be a rule (don’t install if this dependent application isn’t present) as well as install automation. And, relationships like supersedence have behaviors for them that tie to the end-user catalog experience (only show the superseding application in the catalog). Finally, with uninstall in ConfigMgr 2012, both of these relationships can be involved in uninstall automation as well. 

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

The first thing is how you interact with the objects in the administrator’s console. You can get SO deep into the details of rules and relationships, you forget just what you decided to do for the application. You may have this problem today with detailed task sequences! As I mentioned earlier, we’ve added the Relationship Viewer to help you visualize these. 

The second thing you’ll see in the administrative console is a rather “stringent” behavior when trying to do deletions on some related objects. Our BIGGEST fear was that you might accidentally delete an application that 25 applications depend upon. Why? Because these are RULES that the applications behave on live. If you cascaded the deletion to all of those objects, you may now have an application that cannot install correctly in the future, and other application administrators may not know about it. So, these relationships are stringently honored in our administrator console when it comes to deletion. You cannot delete an application that other applications depend on without breaking those relationships. 

The final thing is just the level of depth we allow these relationships to span or grow to. It’s possible to deploy a LOB application that depends on MS Office and Adobe 10, and MS Office depends on .Net Framework and IE7 or later – and now you kick off a chain of automated installations for 5-6 things you maybe didn’t know were detailed below those applications. Again, use simulated deployments to see what the system would have chosen to do in cases where you have applications with long relationship chains.

These are some of the biggest conceptual changes in the application delivery model in ConfigMgr 2012. The benefits these changes bring will be sizable for you in how you deliver software. And, if we can make sure you understand the biggest key fundamental conceptual shifts, it will make using the new system far more predictable and intuitive!

Bill Anderson

Principal Program Manager Lead

System Center Configuration Manager