Hi everyone

The company I am currently working for is just setting up and would like to do their deployments via AD Group Policy - "assigning to USERS". Their reasoning for this - if a user is assigned an application it will install and be available for that particular user on a given machine. In addition a user who needs to move computers often will get the appropriate apps automatically without the helpdesk having to amend computer membership as the user moves around.
The setting of "remove application when it falls out of scope of management" is also enabled.

I am quite familiar with assigning Apps to COMPUTERS, however assigning to USERS is new territory for me, so hoping those of you who have been down this road before can provide me with answers to the following questions:

Is this likely to cause a big mess with many users logging in and out and moving computers?
I'm thinking of situations where 2 users assigned the same app logon to the same PC.
Or when one of those users has the app uninstalled... yikes!

Would you recommend in general using this deployment option in a production environment?
My gut feeling is that this option may be more trouble than it's worth.

Any over real world experience related info you could share with me.

Thanks for any help in advance, I'd prefer not to find out if this is a bad choice when it's too late!

0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


We've been using Group Policy assigned apps for 3 years now, and of our 300 assigned applications roughly 200 of those are user-assigned.

Overall we've seen very few issues, except for those packages that require some additional manual configuration beyond the installation. People log on to other machines that have the same application installed with no problem. However part of that lack of issues could be because we didn't have users log on to different machines anywhere near as often as anticipated. We made the decision for most of the same reasons you did, and ultimately we discovered that very few users log in to other machines, and when they do, the most critical things like email settings (lotus notes) don't travel with their profile.

I wasn't here for the initial setup of group policy assigned installs. If I were I would have recommended going with machine-assigned installs, mainly for license compliance and standardization reasons, and because it makes the transition to SMS (which we are currently doing) much easier.

Bottom line - User assigned installs do what they're supposed to do, but I'd recommend against it.
Answered 01/10/2007 by: Bladerun
Green Belt

Please log in to comment
Hi Bladerun

Thanks a lot for the comprehensive comments. It's great to get some feedback from someone who has been down this road before.
I'm going to recommend per machine installs, however if this doesn't go ahead its nice to know per user installs aren't as messy as they may sound.

Answered 01/11/2007 by: jboyes
Senior Yellow Belt

Please log in to comment
Hi Bladerun,
can understand your comment on better use machine installs.
But why are you switching from GPO installs to SMS? That looks like a backlash to me. Have you considered products like 'Specops Deploy' ?
Where do you see the advantages?
Regards, Nick
Answered 01/13/2007 by: nheim
Tenth Degree Black Belt

Please log in to comment
nheim -

We're going from GP deployment to SMS for quite a few reasons. SMS was brought in originally solely for it's patch management capabilities, and the following was the rational behind transitioning to SMS for our application deployments as well:

- Ability to deploy more than just MSI's. This is the single most important reason. Most applications now come with some kind of support for mass deployment. In nearly every case, it is preferable to use the native installer rather than recapturing the application into an MSI. Plus it gives us the ability to deploy scripts easily without having to wrap them in an MSI or build them into the already lengthy logon script.

- Keep recapturing to a minimum.
I'm quite experienced in the art of repackaging, but the bottom line is that a package is nearly always more reliable if you're using the native installer. More and more apps are coming from the vendor with some kind of self-sensing install procedure that checks for the existance of other applications and reacts accordingly. Preserving that logic saves many a headache. It also tends to decrease the time needed for packaging.

- Flexibility in scheduling. Simply put, being able to deploy software without a reboot or relog is important as our booting process is quite long as it is.

- Query-based collection deployment. There are numerous advantages here, but primarly the ability to target machines with specific configurations on a query-basis is a huge advantage. As an example, we deploy wireless software to all laptops that have wireless NIC's. With the query based collection, the enterprise is constantly checked for new machines that may need the software, no manual steps are required.

- Problems with Group Policy deployments. We've had a number of spordic problems with Group Policy assigned apps, including applications randomly uninstalling and reinstalling, as well as machines not receiving policy in a timely fashion.
Answered 01/15/2007 by: Bladerun
Green Belt

Please log in to comment