4 ms·

Group policy "automation" is painful and inconsistent. Parts are only applied on user login. Parts only on reboot. Parts instantly. Hard to impossible to know w

by corty 5y ago

Group policy "automation" is painful and inconsistent. Parts are only applied on user login. Parts only on reboot. Parts instantly. Hard to impossible to know which is which. And no way to log off users or reboot machines via group policy, so you need remote logins anyways.

EvanAnderson 5y ago
I'd argue it's just being familiar with the tools. I'm biased, no doubt. Windows sysadmin work has paid the lion's share of my bills since the late 90s. I've been using Group Policy heavily since 1999 (during the Windows 2000 beta), so I'm used to knowing what applies when. Being familiar with which client-side extensions (CSEs) do which processing helps. The documentation for Microsoft's own functionality is reasonably good. Third-party software is a mixed bag. Remotely rebooting machines is easy. There has been a remote shutdown API in Windows NT since the at least Windows NT 4.0 (and probably going all the way back to the beginning). Since Windows 2003 there has been a command line tool included to actually use the API. Likewise, there are command line methods to remotely logoff users, refresh Group Policy, etc.
- kwdc 5y ago
  Re: rebooting is easy Full agreement. We were remotely powering on/off hundreds of machines with a single command line. Then just a web page because we needed non-IT people doing it on regular basis. We used to change wallpapers of certain groups of machines on a daily or even hourly basis due to special events. Do people really think we remotely logged into each one? Or manually remoted each one? Hmmm. Next someone will be saying its impossible to get the event logs from each machine... truly bizarre. (Yes you can, and we did, even from client machines if a machine had developed "quirks") Again, these complaints are just strange. Its as if they weren't using their infrastructure. None of this is any kind of wizardry. I'd expect any linux or windows admin to know the tools required.
  - corty 5y ago
    Depends, event forwarding is quite weird and broken. Default settings delay and buffer events for quite some time so that an attacker can easily suppress unsent event buffers. Crashes are also usually missed because buffered events have not been sent in time. That can be configured down, but all the provided defaults are useless. Also, encryption and authentication for log forwaring is bound to AD Kerberos credentials that frequently expire, leaving you without logs again. Any old syslog client and server is far superior in all the aspects mentioned.
    - kwdc 5y ago
      Reading your comments it seems like you have had a bad time. I hope you moved over to linux or similar instead. Otherwise there's a lot of optimisation required in your AD with clean up of multiple areas required. Likely issues with network infrastructure as well. Also, event forwarding isn’t the only way.
- corty 5y ago
  I didn't claim that rebooting a Windows box is impossible or hard. It is just that group policies are no complete solution for anything, they are just a small and imho weird part. Also, for a lot of things there is just no group policy you can set somewhere, so you are still in need of some "execute me that script that does the needful" in a lot of cases.
  - EvanAnderson 5y ago
    We have different experiences. Group Policy is a tool that I'm confident, in virtually any engagement, I can use to automate nearly all the goings-on of a Windows Server environment. Third-party software may not play well, but between the GPP CSEs and scripting, as necessary, I can get the job done. That's been my experience. I'm not sure what to say re: "execute me that script that does the needful". That's going to hold true in any environment, Windows or Linux or whatever. If you've got third-party software that uses unique configuration persistence mechanisms, or doesn't work-and-play with the OS-provided management interfaces (Service Control Manager on Windows, systemd on Linux, etc) then you're going to have to script one-offs. Most real sysadmin work, in my opinion, involves leveraging or creating code and infrastructure to handle automating assemblages of software. Scripting is often how that's done. Configuration management tools add some formalism to the process, but it's still "glue and tape"-- albeit fancy.
    - corty 5y ago
      I think Group Policies are a very incomplete, partial solution. As you said, you usually have to combine it with a few more things to get the job done, and that is how any sysadmin job works. But: You need not only a one-off-script to make things really work. You need a script that is idempotent, so you can execute it on all your machines and maybe do a retry or two if some are unreachable or an error happens. So the script should not only change things it is supposed to change (e.g. append a configuration line somewhere) but also check if that action is necessary or already done (e.g. that line has already been appended). Then you maybe need to restart the respective service to reread it's configuration. But of course you wouldn't want to unnecessarily restart it, since that might be disruptive or expensive, so you have to check if that configuration has been changed or not before restarting. Then handle automatic application for machines that are currently offline, have just been installed or need a refresh. Add in a some templateing and parameters, different groups, logging success/failure and you are at quite a complex script. Or rather, a script that no-one should write, because it is exactly what configuration management is supposed to do. If you are writing all that by hand for each one-off, you are doing it wrong because you are reinventing the wheel, and usually badly. If you aren't doing all that, you are missing important parts. So imho configuration management like puppet, salt, chef, … is table stakes for any kind of sysadmin work. I'm not familiar with Windows DSC, but I find it strange that you dismiss it as pandering to the Linux crowd.

by corty 5y ago

EvanAnderson 5y ago

I'd argue it's just being familiar with the tools. I'm biased, no doubt. Windows sysadmin work has paid the lion's share of my bills since the late 90s. I've been using Group Policy heavily since 1999 (during the Windows 2000 beta), so I'm used to knowing what applies when. Being familiar with which client-side extensions (CSEs) do which processing helps. The documentation for Microsoft's own functionality is reasonably good. Third-party software is a mixed bag. Remotely rebooting machines is easy. There has been a remote shutdown API in Windows NT since the at least Windows NT 4.0 (and probably going all the way back to the beginning). Since Windows 2003 there has been a command line tool included to actually use the API. Likewise, there are command line methods to remotely logoff users, refresh Group Policy, etc.

kwdc 5y ago
Re: rebooting is easy Full agreement. We were remotely powering on/off hundreds of machines with a single command line. Then just a web page because we needed non-IT people doing it on regular basis. We used to change wallpapers of certain groups of machines on a daily or even hourly basis due to special events. Do people really think we remotely logged into each one? Or manually remoted each one? Hmmm. Next someone will be saying its impossible to get the event logs from each machine... truly bizarre. (Yes you can, and we did, even from client machines if a machine had developed "quirks") Again, these complaints are just strange. Its as if they weren't using their infrastructure. None of this is any kind of wizardry. I'd expect any linux or windows admin to know the tools required.
- corty 5y ago
  Depends, event forwarding is quite weird and broken. Default settings delay and buffer events for quite some time so that an attacker can easily suppress unsent event buffers. Crashes are also usually missed because buffered events have not been sent in time. That can be configured down, but all the provided defaults are useless. Also, encryption and authentication for log forwaring is bound to AD Kerberos credentials that frequently expire, leaving you without logs again. Any old syslog client and server is far superior in all the aspects mentioned.
  - kwdc 5y ago
    Reading your comments it seems like you have had a bad time. I hope you moved over to linux or similar instead. Otherwise there's a lot of optimisation required in your AD with clean up of multiple areas required. Likely issues with network infrastructure as well. Also, event forwarding isn’t the only way.
corty 5y ago
I didn't claim that rebooting a Windows box is impossible or hard. It is just that group policies are no complete solution for anything, they are just a small and imho weird part. Also, for a lot of things there is just no group policy you can set somewhere, so you are still in need of some "execute me that script that does the needful" in a lot of cases.
- EvanAnderson 5y ago
  We have different experiences. Group Policy is a tool that I'm confident, in virtually any engagement, I can use to automate nearly all the goings-on of a Windows Server environment. Third-party software may not play well, but between the GPP CSEs and scripting, as necessary, I can get the job done. That's been my experience. I'm not sure what to say re: "execute me that script that does the needful". That's going to hold true in any environment, Windows or Linux or whatever. If you've got third-party software that uses unique configuration persistence mechanisms, or doesn't work-and-play with the OS-provided management interfaces (Service Control Manager on Windows, systemd on Linux, etc) then you're going to have to script one-offs. Most real sysadmin work, in my opinion, involves leveraging or creating code and infrastructure to handle automating assemblages of software. Scripting is often how that's done. Configuration management tools add some formalism to the process, but it's still "glue and tape"-- albeit fancy.
  - corty 5y ago
    I think Group Policies are a very incomplete, partial solution. As you said, you usually have to combine it with a few more things to get the job done, and that is how any sysadmin job works. But: You need not only a one-off-script to make things really work. You need a script that is idempotent, so you can execute it on all your machines and maybe do a retry or two if some are unreachable or an error happens. So the script should not only change things it is supposed to change (e.g. append a configuration line somewhere) but also check if that action is necessary or already done (e.g. that line has already been appended). Then you maybe need to restart the respective service to reread it's configuration. But of course you wouldn't want to unnecessarily restart it, since that might be disruptive or expensive, so you have to check if that configuration has been changed or not before restarting. Then handle automatic application for machines that are currently offline, have just been installed or need a refresh. Add in a some templateing and parameters, different groups, logging success/failure and you are at quite a complex script. Or rather, a script that no-one should write, because it is exactly what configuration management is supposed to do. If you are writing all that by hand for each one-off, you are doing it wrong because you are reinventing the wheel, and usually badly. If you aren't doing all that, you are missing important parts. So imho configuration management like puppet, salt, chef, … is table stakes for any kind of sysadmin work. I'm not familiar with Windows DSC, but I find it strange that you dismiss it as pandering to the Linux crowd.