Closed rmoreas closed 2 years ago
- Adding a separate editable file containing security group names and GPO names, and using those defaults unless overridden with non-mandatory parameters.
Actually we build and deploy the policies using a CI/CD pipelines and these settings are configured using pipeline variables.
If you prefer to have this configured within AaronLocker files, Support\Config.ps1
would be good candidate to hold these defaults.
- No "ShouldProcess" confirmation in the script - just do it if the script is executed. I'm pretty sure I don't have any other "are you sure" moments in here.
Clearing and setting GPOs is an operation with high impact. When running this scripts interactive, confirmation is desirable to avoid mistakes. In automated scripts (like in our CI/CD pipeline) -Confirm:$false
can be added to the parameter list to suppress the confirmation.
- Instead of going for the first DC in the returned list (which might be on the other side of the world, or off, or something), how about using $env:LOGONSERVER, which is probably closer? And how to deal with non-responsive DC - move to next?
Seems that there is also a Get-ADDomainController
cmdlet that allows to find the closest DC.
Files in the Support subdirectory are generally not designed to be edited. I think it'll go into CustomizationInputs or directly in the GPOConfiguration directory.
I just created a "GPOConfiguration-Draft" branch. See what you think of it. Probably going to move things around some more - I'd like to add support for AD GPO support in some of the other scripts.
I like this idea a lot, and I've been thinking about more automation around AD GPO management. I've got a script about ready to manage the AD groups, at least from a reporting perspective, including reporting when a computer is in more than one AD security group at a time. I wasn't sure where to put it, but I like your idea of a new GPOConfiguration subdirectory. A few changes I'd make: