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:
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 AndersonPrincipal Program Manager LeadSystem Center Configuration Manager
Comments in this blog are open and monitored for each post for a period of two weeks after the posting date. If you have a specific question about a blog post that is older than two weeks, please submit your question via our Twitter handle @MSCloud