Systems Management

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.

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.

Cheers
Jeremy

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

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.