Hi all,
So, I suspect I know the answer to this question, but I'm going to ask it anyway, and maybe solicit some thoughts on the best approach to this.
It's not hugely relevant, but as some background, we've come from LANDesk, which has a very different approach to deploying software to computers. I favour many of the approaches in SCCM, notably user-based deployments, but I'm struggling to work out how to fit some of them in without causing myself, and my team, excessive administration.
Let's say Software X is freely, optionally installable by any user on any computer (it's freeware, or we have a company license). We have aUser-based Available deployment which puts it in the Application Catalog. They can install it on their own computer, or they can install it on a meeting room PC. Heck, IT can go all old-school, walk over to user's PC, log in and install it on the user's behalf (assuming it's a System install). Nice. Flexible.
A need is identified for an IT team to "push" (LANDesk term) that software to the primary computer of allUsers in AD Group Y. This will need to be free of user-interaction. To reiterate: in this scenario, it's not satisfactory for users to be told to go install it themselves from the catalog - it needs to be automatic.
If we create a User-based Required deployment, the software will end up on every computer they log into, not necessarily their primary computer.
I know the documented solution to that is to define user device affinitiesand then set a deployment type requirement for primary devices. However, the moment you do that, you prevent the Application from ever being used in adevice-based deployment, and you also prevent my first scenario, where users are free to install it wherever they like from the Catalog.
Microsoft seem to have designed the user-centric model around the notion that if software is assigned/deployed to a user, it absolutely has to be available to themwherever they are, and that simply isn't the case in our business, and I'd wager in others as well.
I've seen a few discussion here where the workaround is to create a second Applicationwithout the affinity requirement, but that doubles the amount of administrative work for any application we wish to deploy in this way (we have some apps with 6 deployment types!), and introduces the possibility of human error, where the wrong Application is deployed and it either doesn't work at all (affinity app to device deployment), or works too well and ends up on the wrong machines (no affinity app to user deployment).
So, has anyone encountered these requirements in their, or a client's environment and come up with a satisfactory solution to this conundrum? Are we just being really odd in approaching things this way?
I know what I'd change about SCCM to accommodate this: allow the user-device affinity requirement to be applied to thedeployment instance rather than (or as well as) the application deployment type and I may hit up a Connect suggestion to that end, but I've got to come up with something in the meantime!
Thanks for any input folks!
Richard