Systems Management

Some points on group policy software distribution:

1) It does work, and it is quite easy to use and implement, so it has that going for it
2) Provided you don't have any remote site shenanigans going on, your server hardware should be more than sufficient to cover 1000 users under reasonable usage scenarios
3) You may run into max token size issues if you run an exchange server and have extremely large numbers of AD groups that users are a part of (I think the limit gets hit around 350) You'll see mysterious outlook failures if this happens. This mostly happens when administrators use granular group policy to deploy applications.
4) There is essentially no means of reporting on group policy applications. It's basically fire and forget, whether you like it or not.
5) Think long and hard before you want to go down the route of user-deployed applications, there are many pitfalls lurking in the shadows here.
6) Machine-based deployments are less resource intensive than user-targeted deployments.
7) Consider grouping applications by role rather than as individual applications, it's a fair amount of up front work, but it's well worth it later on.

Oh, and to answer your actual questions:

- I've used group policy to successfully deploy to pretty large environments (~2200 and ~4500.) Keep in mind that it's extremely limited in its function. You can deploy only MSI-based installations through it, so you'll either need a talented packager to shoehorn everything into an MSI format, or be okay with a lot of junk floating around your environment via MSI wrappers.
- Asides from the token size issue mentioned above, I've never run into any limit of actual installed applications. However, login times and network application search times will suffer greatly if you assign many applications to a user, rather than a machine. EDIT: I should clarify here, I've had several hundred applications resident in GPO's on a single domain with no problems. I would guess somewhere around ~450, with at least 300 being actively deployed.
- GPO can't handle anything other than install at logon. Other deployment apps can install with the system account at any time, so long as the target is powered on. I've personally used the Altiris console, BigFix, and SMS/SCCM, which all have their perks, but represent significant additional cost over simply using group policy.

Thanks for responding!
First, can you suggest any additional reading on GPO based installations?

ORIGINAL: Jsaylor
1) It does work, and it is quite easy to use and implement, so it has that going for it
<snip>
5) Think long and hard before you want to go down the route of user-deployed applications, there are many pitfalls lurking in the shadows here.

Mmm. What kinds of pitfalls? Is this the "resource intensive" side of things, or even something larger than that?

- I've used group policy to successfully deploy to pretty large environments (~2200 and ~4500.) Keep in mind that it's extremely limited in its function. You can deploy only MSI-based installations through it, so you'll either need a talented packager to shoehorn everything into an MSI format, or be okay with a lot of junk floating around your environment via MSI wrappers.


Apologies - what kinds of junk can we expect to see? I assume this is 'extra' stuff on the workstations in directories, tempfiles and the like? Something else?

Thanks for all of this.

Question: If we have a vendor delivered (or simplistic internally written) MSI file and the defaults are ok, what do you think of producing registry entries based on installation and configuration deltas and delivering them via group policy? Does this approach produce some of the 'shadow lurking' problems?

Thanks!

Rob

What kinds of pitfalls? Licensing, for one.

Most non-enterprise apps are licensed for a single machine. If a user logs in to a machine other than their normal one, you'll get a new installation on that new machine - instant license violation. Some vendors are pragmatic about that - if you, say, permission folders etc. for the deployment group - but most are not.

Licensing, for one.


Thanks for the response.

Licensing is not an area we thought about. If for performance reasons we need to associate installations with computers, this will be a problem.

ORIGINAL: RobW


Licensing, for one.


Thanks for the response.

Licensing is not an area we thought about.  If for performance reasons we need to associate installations with computers, this will be a problem.




It gets worse, actually. Not only will you get dinged on licensing simply for having users log into different machines, but you have to consider how to remove the applications. Once a user logs into a machine and has an application installed, that application can't be uninstalled in the traditional fashion until the user logs back into the same machine. You essentially end up with permanent installations that are... not quite legal, every single time a user logs into a new box.

Apologies - what kinds of junk can we expect to see? I assume this is 'extra' stuff on the workstations in directories, tempfiles and the like? Something else?

Regrettably, the most common method that I've seen people use to get an EXE installation working with group policy is to just stick it in an MSI wrapper. If that MSI wrapper isn't carefully written, you'll end up with installations that can be installed, but can't be removed via the MSI. Not only that, but as I mentioned before, group policy has just shy of absolutely 0 reporting ability, so once applications go out, you have no means of tracking them.