Why group policy management works They give me a certain flexibility in writing the desktop management blog. The next six articles are marked in my calendar as “something to do with Group Policy Objects (GPOs).” The topics I write tend to line up with the research I am doing for my day job, and lo and behold, the next couple of weeks I will be deep into GPOs. I …
Very interesting article, and I look forward to read the rest of the series!
I see what you mean about new people having to learn the ropes 'somehow' and you're right of course, nobody is born an admin.
First, let me tell you what my situation is: I am employed by a large multi-national company with tens of thousands of people around the world all using computers, part of a massive AD and administered through Group policies like you talked about. The problems we are facing are badly installed software, network drives disappearing or being wrongly connected, roaming user-profiles you can only use on one PC properly, unpatched PC's which get infected with virusses, wrongly set file access rights, etc, etc... The list is endless.
So, in our case, it would be helpfull to have a couple more decent administrators and less people learning how to be one.
The vanishing of network drives got so bad that I wrote a program that my colleagues and me can use to make a personalised vbscript that we can run when needed and that will just remove badly attached drives and re-attach the ones we actually need.
Of course, the IT-services got outsourced some years ago, and since then, the situation has gradually gotten worse. People with no clue about IT inside the company making insane rules, and fresh out of school (or never having got there) outsourced admins badly implementing them.
Sorry, I feel better now. Think I'll have a drink of water and get back to work...
As useful as any program or style of management is, /nothing/ truly replaces good, well trained admins.
But...I can delegate GPO management to the little nublets. Let them tinker with the areas that can't cause TOO much trouble, and gradually let them play with more. A good admin fresh out of school should know a lot about the basics. I shouldn't have to explain what formatting a drive is, or what 255.255.255.224 means.
I however do not expect him to know that VI will behave completely differently in Ubuntu than it does in Red Hat. Not would I expect him to know the different places ClamAV can hide it's files, depending on if it is installed via RPM, DEB or TAR. (or if it is .95 or older.)
If I am managing entirely by script, I sure as heck would need to know all the different places the variants of ClamAV would hide it’s configs, and all the ins and outs of every version of everything that I used.
I agree GPOs aren’t perfect; gods know I’ve had enough problems with them, but they do seem to be a good way to keep someone gainfully employed doing useful work why they learn the ropes.
As to understaffing and outsourcing...sir, you have my condolances.
As to admin levels, had a discussion elsewhere about that long ago. The thing to realise is that there are levels. Perhaps we need different names, or if you will, titles, for various levels, next to positions. SAGE does define something of that sort.
But all too often I see things like adverts for a ``network administrator'' who is expected to take care of ``the network'', which then turns out to mean ``the sack of assorted unmaintained windows boxes making up our office''. Like users complaining about something wrong with ``the CPU'', which much later turns out to be luser slang for ``that noisy box under my desk''. Regardless of actual presence of such a thing. So it's not entirely surprising other people take the other extreme view. I don't think they're right either. But I do think that having the power ought to require to either know what you're doing or to have the good sense not to meddle.
Someone said that ``rights'' and ``permissions'' are misnomers, and that ``responsibilities'' would have been a better choice.
On to group policy objects. Seeing how this approach is very vendor specific, it would be nice to see if there aren't (obviously prefferably open source and with command line version for scriptability) tools available to manipulate these objects remotely and from other-vendor systems.
After all, why should automation stop at the GUI the vendor gives you?
"Most importantly, they are cheap. GPO management of a network is the entry level position in systems administration. Along with tasks like patch management, user object maintenance and end-user support it is a way of keeping these junior admins gainfully employed while they are shown the ropes of the more difficult parts of systems administration."
Bad patch management can monumentally f*ck up a corporate desktop. I agree with the AC above that to wield the power there should also be some knowledge backing it up - Windows admins are ridiculed enough by their *nix brethren for their point-click interface use and seeming lack of comparative knowledge without fuelling the fire with comments like that.
I'm not the purist you talk about in your article. I don't compile other people's programs, I like to be as hands off as possible and work at as a high a level of abstraction as possible.
I run a small Windows network and a small Linux network (about 100 machines in total.)
With Puppet on the Linux machines, I can control every aspect of the machine that is necessary - what the configuration files are, which packages are installed, etc. I use the same tool (Puppet) to maintain the state of the machines as I do to get them up and running from a minimal installation. But the key, the real money maker, is that the entire configuration is stored in a version control system. So if I goof up the Kerberos config file, and the users can't login to their workstations... I can just revert back to the previous version, apply the change, and we're done. And of course, the manifests (Puppets answer to GPO's) are in version control too.
With Windows in general, but especially with the Group Policy Management Console, you do the wrong thing, and you have no way of getting an answer to "What changed yesterday?" or "How do I get back to the state where everything was working?" And then, one GPO is easy to test. But when you have 5, things get confusing as to what is being applied and what is being overridden.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
