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:
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.
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!
Principal Program Manager Lead
System Center Configuration Manager