Open Borgquite opened 2 years ago
Sorry about the huge code dump but hope it helps. If the regexes are impenetrable I can recommend https://regex101.com/
Hi @Borgquite ! Thank you very much for testing the module so thoroughly - it helps a lot! Yes, this is a known bug, I just haven't filed it here yet. I planned to fix it on this week, before giving you a new release.
Would you be interested in adding your code directly into the repository? If yes, please create a PR into the CSE branch.
@exchange12rocks I'll leave that to you as not sure the best place for it to go! I think this covers all the issues I've found so far (unless you're near to writing the WMI filter code, which I'd also be interested in!)
I'll look forward to the new release :)
Hi @Borgquite ! I am sorry - I haven't managed to implement this yet. I published a version 0.3.0, which includes all fixes so far, and continue to work on this one
Hi @exchange12rocks - no worries, appreciate you putting out the existing stuff in the new release! If you can point me where the best place for the code above to go is I can try to implement it myself. It would need to be somewhere that runs every time after a setting is added or removed. It should then be possible to check if the Groups.xml file exists (or is empty/nonexistent) and add/remove gPCMachineExtensionNames value (as appropriate)
Hey @Borgquite , I finally managed to push some work for this bug: https://github.com/exchange12rocks/PSGPPreferences/tree/CSE
I am looking to complete this by tomorrow
@borgquite The version 0.3.2 is in the gallery - please check it out
@exchange12rocks Thank you so much! I am in a really busy period at work at the moment but will look forward to giving it a spin when things calm down :) I'll send you some feedback when I have.
Hey @exchange12rocks, managed to have a play today. It seems to work OK on a 'fresh' GPO, but it messes up if other Group Policy extensions are already applied to an existing object:
For example:
$GPO = New-GPO "TEST GPO 2"
Set-GPRegistryValue -Name "TEST GPO 2" -Key "HKLM\Software\Policies\Microsoft\Windows\Personalization" -ValueName "NoLockScreen" -Type DWORD -Value 1 # Create a registry-based policy GPO setting (as used by Administrative Templates)
$GPOADObject = Get-ADObject -Identity $GPO.Path -Properties gPCMachineExtensionNames
$GPOADObject.gPCMachineExtensionNames # Returns [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{D02B1F72-3407-48AE-BA88-E8213C6761F1}]
New-GPPGroup -GPOName "TEST GPO 2" -Name "Administrators" -Create
$GPOADObject = Get-ADObject -Identity $GPO.Path -Properties gPCMachineExtensionNames # Returns [{00000000-0000-0000-0000-000000000000}{79f92669-4224-476c-9c5c-6efb4d87df4a}][{17d89fec-5c44-4972-b12d-241caef74509}{79f92669-4224-476c-9c5c-6efb4d87df4a}]
$GPOADObject.gPCMachineExtensionNames
Please note that gPCMachineExtensionNames has the CSE IDs and Tools IDs for Group Policy Preferences, but the existing ones for Computer Policy Settings (documented under https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-gpreg/f0dba6b8-704f-45d5-999f-1a0a694a6df9) have been removed. The code I mentioned above will retain all existing CSEs and Tools (meaning existing policy settings still work) whereas the current deployed code wipes them out. It is at least partly down to your trying to match the all-zeroes CSE specifically in Get-GPOCSE whereas you should probably be treating all CSE/Tool pairs identically, leaving any existing ones in place and just adding or removing the ones you specifically need.
I would also note that the code appears to be writing out GUIDs with lower case a-f instead of upper case A-F (and the regex matches are the same). Accepting lowercase input is a good idea (I've updated my sample code above to do this), but I would change your output to upper case only to avoid any compatibility issues (in my testing the GUI tools always wrote out gPCMachineExtensionNames GUIDs in upper case, so it's possible lower case GUIDs might unexpectedly break other Group Policy extensions. It's a relatively undocumented ecosystem so best to be conservative in what your code does, I'd suggest.)
Also having other issues where existing GP Preferences are being changed & no longer working I'm afraid. Ran out of time today and am off on holiday for a couple of days but will be back next week. Thanks for all your work!
Hmm it should preserve all existing ones and sort them accordingly 🤔
Thank you!
Oh, of course: it does not work because Set-GPRegistryValue (and the GUI) sets the attribute without the leading zero GUID. So it just does not match the regular expression. I thought the zero GUID is always there
Ah, OK, the zero GUID is needed only for GPP 🤦♂️ Why did I miss that?
Fixed in the release 0.3.3 - available in the gallery
Thank you! :) Will take a look once I get another moment free!
Just been looking through the code - suggest a change to the regex to do case insensitivity using a flag rather than [A-f] (which also matches G-Z). Pull request #41
Based on my understanding of GP extensions I hope it's OK for me to say there are still a couple of worries I'd have about how it's implemented at present:
I'm not sure if I've made this clear or not, but if you're free sometime between 10:00-17:00 GMT one day perhaps we could discuss over a video/audio call? But basically what you want to be able to cope with is more like this, which I don't think is quite what you've got yet:
[{00000000-GPP CSE GUID}{GPP Tools GUID 1}{GPP Tools GUID 2}][{GPP CSE GUID 1}{GPP Tools GUID 1}][{GPP CSE GUID 2}{GPP Tools GUID 2}][{Another CSE GUID 1}{Another Tools GUID 1}][{Another CSE GUID 2}{Another Tools GUID 2}]
Let me know if I can explain better!
Hey,
Just to give you a couple of reproduction scenarios for those issues:
The issue with removing the setting (at present I think there may be another bug where Groups.xml isn't deleted even when there is no setting inside), but I think even if the XML file was empty, it might still return [{00000000-0000-0000-0000-000000000000}] - making the change via the GUI will return blank)
$GPO = New-GPO "TEST GPO"
New-GPPGroup -GPOName "TEST GPO" -Name "Administrators" -Create
Remove-GPPGroup -GPOName "TEST GPO" -Name "Administrators"
$GPOADObject = Get-ADObject -Identity $GPO.Path -Properties gPCMachineExtensionNames
$GPOADObject.gPCMachineExtensionNames # Returns [{00000000-0000-0000-0000-000000000000}{79F92669-4224-476C-9C5C-6EFB4D87DF4A}][{17D89FEC-5C44-4972-B12D-241CAEF74509}{79F92669-4224-476C-9C5C-6EFB4D87DF4A}]
# Should instead return blank
The other issue:
$GPO = Get-GPO -Name "TEST GPO"
$GPOADObject = Get-ADObject -Identity $GPO.Path -Properties gPCMachineExtensionNames
$GPOADObject.gPCMachineExtensionNames # Returns [{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B6664F-4972-11D1-A7CA-0000F87571E3}]
New-GPPGroup -GPOName "TEST GPO" -Name "Administrators" -Create
$GPOADObject = Get-ADObject -Identity $GPO.Path -Properties gPCMachineExtensionNames
$GPOADObject.gPCMachineExtensionNames # Returns [{00000000-0000-0000-0000-000000000000}{40B6664F-4972-11D1-A7CA-0000F87571E3}{79F92669-4224-476C-9C5C-6EFB4D87DF4A}][{17D89FEC-5C44-4972-B12D-241CAEF74509}{79F92669-4224-476C-9C5C-6EFB4D87DF4A}][{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B6664F-4972-11D1-A7CA-0000F87571E3}]
# Should instead be returning [{00000000-0000-0000-0000-000000000000}{79F92669-4224-476C-9C5C-6EFB4D87DF4A}][{17D89FEC-5C44-4972-B12D-241CAEF74509}{79F92669-4224-476C-9C5C-6EFB4D87DF4A}][{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B6664F-4972-11D1-A7CA-0000F87571E3}]
I could try to fix this if you want, but not sure whether it might require some rearchitecting of code!
Hi @Borgquite ! Sorry for the delay, I was moving to the Netherlands. The second issue existed because of my laziness in filtering out CSE tools - I've implemented that properly now.
I'll continue working on the first issue.
Thanks @exchange12rocks - I'll take a look when you're done & try to test it then!
OK, so this one may take a little longer to explain:
When setting up a brand new 'clean' Group Policy object ONLY using PSGPPreferences, without using the GPP GUI in any way, the applied Preferences settings are not visible in the Settings report under the Group Policy Management Console, and are not applied.
To reproduce:
Then start the Group Policy Management Console, and open 'TEST GPO' / 'Settings'. It shows 'No settings defined'.
The cause is described and discussed in a similar bug for a similar project here: https://github.com/hashicorp/terraform-provider-ad/issues/39 but boils down to:
[{00000000-0000-0000-0000-000000000000}{Tool Extension GUID 1}][{CSE GUID 1}{Tool Extension GUID 1}]
e.g. for Local Groups and Settings:
[{00000000-0000-0000-0000-000000000000}{79F92669-4224-476C-9C5C-6EFB4D87DF4A}][{17D89FEC-5C44-4972-B12D-241CAEF74509}{79F92669-4224-476C-9C5C-6EFB4D87DF4A}]
A few notes regarding this though:
Having played around with modifying this the following PowerShell should do the job (please feel free to use this as you see fit - released as public domain):
I guess it would be good if this could be added before and after each 'Add', 'Set' or 'Remove' operation. Adding them will make the reporting & application work in the first place. Removing them when unnecessary will speed up client-side application of the relevant GPO.
Again after testing it seems the GUI generates these values if any relevant items are 'created' or 'set', and removes them after any 'remove' operations if no items of the given type are left. I think the code is good but please do review and test as well :). Happy to explain anything if you want to know my reasoning.