User Centric App Deployment Part 2: User/Device Affinity

  • Article

In its simplest form, the User/Device Affinity feature in ConfigMgr 2012 is just about saying, "this user uses this device as a primary place of work". Knowing this is a place you frequently do work, we can optimize delivery. Knowing another device is NOT a place you normally do work, we can control resource delivery. 

Here's how it works.  You have the ability to set the relationship for a primary user on a device, or a primary device for a user. Now, it's not REALLY primary, as primary insinuates "only." We allow a user to have multiple primary devices (my laptop and my mobile phone) or a device to have multiple primary users (shift workers). As stated above, it's a statement of "a place where I frequently do work and want resource delivery optimized as such". Now, how do you set this?  Well, in true ConfigMgr form, we've given you 6 different ways! Not to make it complicated, but to give you enough flexibility to embed this into a series of your business processes where it may make sense to do this. Here's a summary:

  • Device Usage, with thresholds. You can use user login information and frequencies to set this relationship automatically.
  • End-user can set. Yes, in true user centric form, you can allow your end-users to set this in the Software Catalog.
  • CSV file import. If you have a purchasing process whereby you know who you are buying PCs for, you can export this data out into a CSV and then import it.
  • OS Deployment. We provide functionality in a prestart command that your deployment technicians can set UDA when they build a machine for a user.
  • Manually. You as an admin can go set this for a device or a user. You can just assign it, or you can see what users have used a device and decide.
  • Mobile Devices. You set this at device enrollment time.

Now, once you have this relationship set, how can you use it to solve the problems of user roaming or coordinating application delivery? For user roaming problems, we've created a requirement rule in the application model for Primary Device. So, in targeting software to a user, you can use the Primary Device rule to indicate if the software should be delivered or not. For example, say I have an MSI, with a long install process. When I create the deployment type in the application model, I can set a requirement rule of "Primary Device must be true." So, if a user logs into a device that is not a primary device for them, the software will not install. With this in place, there's now a class of applications that will not interrupt the user login experience or possibly corrupt a system. In the application model, you can have multiple deployment types in the same application, and still use this rule. For example, I have an application like Office that I have an MSI install for, and I want to make it available via Citrix XenApp for roaming situations. On the Office MSI deployment type, I set "Primary Device must be true." I do not set that rule on my XenApp deployment type, and I set my application install priority order for the MSI first, the XenApp deployment type second. The result?  On any primary device, it will install the MSI deployment type, and on a non-primary device it will get me Office via XenApp. Users can still roam, and administrators can safely deliver software to them. Pretty cool, huh?

OK, what about the coordinated deployments with no user present? ConfigMgr 2012 can use the relationship to deliver resources to a group of users and push-deploy the software to their primary devices. This way, if you do need to coordinate the delivery in off hours, you can still accomplish it. For mobile devices, we automatically take all required deployments for a user/group and do this on mobile phones where you have a mobile deployment type for that application. Now, you can target software to users on mobile devices, even though there is no user login on that device. The other cool place for this is during OS provisioning. If you set the relationship as part of the prestart command mentioned above, we'll take all applications that you've set to “Deploy automatically according to schedule with or without user login” and install all of them directly after the OS provisioning process. You can now have user required applications in one place in ConfigMgr, and not have to explicitly call them out in a task sequencer ever again.

The new ConfigMgr 2012 application model and user device affinity features truly allow you to think "user first,” where “user X gets app Y” with ease!

Bill Anderson
Principal Program Manager Lead
System Center Configuration Manager