/build/static/layout/Breadcrumb_cap_w.png

Advice on Max Applications distributed via GPO?

We're a long time Zenworks shop continuing the move away from Novel technologies. GPO delivered applications are a possible NAL replacement.

For a particular Kiosk type user, we have ~55 applications available to the user via Zenworks and NAL. Most of these are 'snapshot' delivered applications, meaning they are placed on a workstation and launched without the use of any other installation technologies. Many are custom applications with older (sometimes 16 bit) dll's, and extensive registry changes. We recognize that we will be repackaging most or all of these apps for use by a GPO.

We have 4 beefy dc's 2k3 servers (4x3g processor, 2g mem, 1g net), and ~1000 users. 24x7 operation - max logins at any particular time is 400.

So,
  • Anyone else do something like this? How did it go?
  • Is there a practical maximum to the number of applications distributed via GPO? What happens if you have too many?
  • Can push installations be done at a time other than at logon?Cost is an issue - What might be a good replacement for the Application distribution piece of Zenworks?Anything we should be thinking about that I didnt mention in my above post?
Thanks!

Rob

0 Comments   [ + ] Show comments

Answers (5)

Posted by: Jsaylor 13 years ago
Second Degree Blue Belt
0
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.
Posted by: RobW 13 years ago
Yellow Belt
0
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
Posted by: anonymous_9363 13 years ago
Red Belt
0
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.
Posted by: RobW 13 years ago
Yellow Belt
0

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.
Posted by: Jsaylor 13 years ago
Second Degree Blue Belt
0
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.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ