«

Trevor Pott has been doing a series on the Windows Group Policy Objects
system, and how it compares to the way things are done on other systems. The
latest instalment is here
<http://www.theregister.co.uk/2010/07/06/sysadmin_using_group_policy/>:

To get right to it: GPOs are training wheels for sysadmins. GPOs are
able to modify a limited subset of configurations on a limited number of
operating systems and applications.

...

The first problem is that Microsoft’s various GPO elements need even
more flexibility than GPP already has. The critical bit is
extensibility; the ability to build true GPOs - not just scripting
through GPP - for non-Microsoft products.

Microsoft also needs to incorporate proper versioning, change control,
and the ability to revert an entire system to a “known good� set of
configurations through something other than system restore. Single-
button reversion of system-wide configuration, pushed from the active
directory, should not be optional. Are you listening Microsoft? Puppet
does all of this right.

The “Puppet� he’s referring to is here
<http://projects.puppetlabs.com/projects/puppet/wiki>. The problem with the
whole Windows GPO architecture is that it only works for applications
designed to work with it. Contrast that with Puppet, which is capable of
managing configuration for an entire system running all your usual common-
or-garden open-source software, without any special cooperation on the part
of the latter.

On Jul 7, 4:37*pm, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealand> wrote:
> Trevor Pott has been doing a series on the Windows Group Policy Objects
> system, and how it compares to the way things are done on other systems. The
> latest instalment is here
> <http://www.theregister.co.uk/2010/07/06/sysadmin_using_group_policy/>:
>
> * * To get right to it: GPOs are training wheels for sysadmins. GPOs are
> * * able to modify a limited subset of configurations on a limited number of
> * * operating systems and applications.
>
> * * ...
>
> * * The first problem is that Microsoft’s various GPO elements need even
> * * more flexibility than GPP already has. The critical bit is
> * * extensibility; the ability to build true GPOs - not just scripting
> * * through GPP - for non-Microsoft products.
>
> * * Microsoft also needs to incorporate proper versioning, change control,
> * * and the ability to revert an entire system to a “known good” set of
> * * configurations through something other than system restore. Single-
> * * button reversion of system-wide configuration, pushed from the active
> * * directory, should not be optional. Are you listening Microsoft? Puppet
> * * does all of this right.
>
> The “Puppet” he’s referring to is here
> <http://projects.puppetlabs.com/projects/puppet/wiki>. The problem with the
> whole Windows GPO architecture is that it only works for applications
> designed to work with it. Contrast that with Puppet, which is capable of
> managing configuration for an entire system running all your usual common-
> or-garden open-source software, without any special cooperation on the part
> of the latter.

Puppet is cool, but I'm not sure the author fully understands what
Puppet is. He keeps referring to it as "scripting", whereas I reckon
what Puppet does and how it works is closer to Group Policy than it is
to scripting.

ie with both Puppet and GP you are specifying the end result you want
(the 'what') - not the steps to get there like you do with scripting
(the 'how').

I haven't used it but from what I've heard Chef might be more like
what he describes - a bit more script like ie more Ruby oriented vs
DSL settings files like Puppet has.

The comparisons I've heard are that Puppet is best suited for
sysadmins wanting to make a bunch of heterogeneous systems at
arbitrary starting points fall into a standard config, while Chef is
best suited for deploying a standard config to a bunch of fresh
systems (eg rolling out new production servers).

--
Cheers
Anton

On Jul 7, 9:11*pm, "AD." <anton.l...@gmail.com> wrote:

> The comparisons I've heard are that Puppet is best suited for
> sysadmins wanting to make a bunch of heterogeneous systems at
> arbitrary starting points fall into a standard config, while Chef is
> best suited for deploying a standard config to a bunch of fresh
> systems (eg rolling out new production servers).

My current pet peeve is Microsoft's move away from using GP for
software distribution. As an example, the fiasco that was Office 2K7.
Yes there's an MSI in the package, yes you can add it to the software
distribution point in GP, but is it supported? Well, sort of.....

I haven't had a chance to look into the situation with O2K10 yet, but
we probably won't be moving to that platform anytime soon anyway.

On Jul 8, 8:27*pm, EMB <emb...@gmail.com> wrote:

> > I haven't had a chance to look into the situation with O2K10 yet, but
> > we probably won't be moving to that platform anytime soon anyway.
>
> They both push just fine with Config Manager. *As do the other 127
> packages (apps and drivers) we distribute that way.

Yup, that's the solution we settled on too, however my peeve is that
you're expected to buy yet another piece of software. For the most
part, our software deployment requirements are rudimentary, GP worked
well for us until the recent changes.

On Jul 9, 9:25*pm, EMB <emb...@gmail.com> wrote:
> On 9/07/2010 4:36 p.m., Simon wrote:
>
> > On Jul 8, 8:27 pm, EMB<emb...@gmail.com> *wrote:
>
> >>> I haven't had a chance to look into the situation with O2K10 yet, but
> >>> we probably won't be moving to that platform anytime soon anyway.
>
> >> They both push just fine with Config Manager. *As do the other 127
> >> packages (apps and drivers) we distribute that way.
>
> > Yup, that's the solution we settled on too, however my peeve is that
> > you're expected to buy yet another piece of software. For the most
> > part, our software deployment requirements are rudimentary, GP worked
> > well for us until the recent changes.
>
> Ours are rather more complex, especially from a licensing compliance
> point of view. *ConfigMgr makes all that easy and uninstalls on demand
> too when we wish to move apps between machines.

We also looked into ZenWorks, but we managed to dump a lot of software
that wasn't pre-packaged as MSI's, or which would be complicated to
transform into an MSI.

> Don't however get me started on Operations Manager - I never wish to see
> the horrible piece of crap again.

My condolences - we suffered that afflictions ourselves for a while.
Luckily it disappeared with some decent antiseptic cream.

On Sat, 10 Jul 2010 15:13:56 +1200, EMB wrote:

>> We also looked into ZenWorks, but we managed to dump a lot of software
>> that wasn't pre-packaged as MSI's, or which would be complicated to
>> transform into an MSI.
>
> We haven't found anything yet that we can't package into an MSI. It
> helps that we have a staff member who is bloody good at doing that.

What if you have a heterogeneous environment and you want to have all
applications available for all platforms?

MSIs surely are limited to only working on the Microsoft platform?

whatever LDAP solution you use - Microsoft's "Active" Directory, or
Novell's eDirectory, or anything else - surely the tool should be both
platform agnostic from a user management perspective and also it should
have the smarts to figure out what version of an application it needs to
deploy onto the relevant OS.


--
"Filtering the Internet is like trying to boil the ocean"

On Jul 11, 12:00*am, Sweetpea <Herit...@Sweetpea.com> wrote:
> What if you have a heterogeneous environment and you want to have all
> applications available for all platforms?

Wouldn't having all apps available for all platforms mostly negate the
point of that heterogenous environment in the first place? Most of the
time a heterogenous environment only exists because different apps
require different platforms.

--
Cheers
Anton

On Sat, 10 Jul 2010 18:39:57 -0700, AD. wrote:

> Wouldn't having all apps available for all platforms mostly negate the
> point of that heterogenous environment in the first place? Most of the
> time a heterogenous environment only exists because different apps
> require different platforms.

What about user choice?

All good applications are available for multiple platforms.


--
"Filtering the Internet is like trying to boil the ocean"

On 11/07/10 14:22, Sweetpea wrote:
> On Sat, 10 Jul 2010 18:39:57 -0700, AD. wrote:
>
>> Wouldn't having all apps available for all platforms mostly negate the
>> point of that heterogenous environment in the first place? Most of the
>> time a heterogenous environment only exists because different apps
>> require different platforms.
>
> What about user choice?
>
User choice? Hehehehehehe! In a corporate environment there is no 'user
choice'.
>
> All good applications are available for multiple platforms.
>
Is Exchange available on Linux? There is nothing that can touch it so far.

Cheers,

Cliff

--

The ends justifies the means - Niccolò di Bernardo dei Machiavelli.

The end excuses any evil - Sophocles

On Sun, 11 Jul 2010 16:52:26 +1200, Enkidu wrote:

>> All good applications are available for multiple platforms.
>>
> Is Exchange available on Linux? There is nothing that can touch it so
> far.

QED!


--
"Filtering the Internet is like trying to boil the ocean"