I already saw this question asked but none as provided an answer so far
the problem is whith the set-gppermission command used to remove the authenticated users from the delegation that ask for confirmation even if -confirm:$false is used
the command is like
Set-GPPermissions -Name $GPOName -Replace -PermissionLevel None -TargetName ‘Authenticated Users’ -TargetType group -WarningAction Ignore -Confirm:$false
anyone has found a solution ?
Hey there and welcome!
Interesting. I’m seeing a lot of posts about this issue over the Internet, namely this one: c# - How to execute Set-GPPermissions command without confirmation prompt - Stack Overflow that seems very similar to your situation.
I’m not working until next Wednesday so I could probably test a bit then to see if I can replicate. I presume you’ve replicated this on multiple systems in your environment and/or multiple GPOs (like a test one)? It seems some folks are having luck from different systems, as if it’s something weird on that system.
If nothing from the above work - One quick workaround without being able to test is using the dsacls legacy command, which was suggested on the link I provided. I definitely understand this is nothing more than a workaround though and you may not want to use it.
<$.02>
I played with this a bit and have concluded the reason for the forced confirmation is that this is basically a bad idea. If you read the message, it clearly states removing “Authenticated Users” from the GPO will prevent the GPO from being applied.
I tested with other groups/users without issue and did not get prompted for confirmation.
</$.02>
That’s interesting - thanks for sharing! I had a feeling something like that may have been at play.
If this is the case, - I don’t think MS is right there to not listen to the confirm preference. You can remove Authenticated Users and apply other groups and it still work. I’m fairly certain i’ts common in some environments, this is done quite a bit as one tactic/approach to more easily apply a GPO a certain set of objects instead of something like item level targeting.
IMO if someone uses confirm:$false the cmdlet should follow it. If MS truly doesn’t want that for Authenticated Users, they need to add that to the docs, but IMO that’s a potential configuration that folks may want to automate in some situations and this sorta prevents that from being possible using that cmdlet anyway.
Hello,
I know that’s happening only with that policy and can be argued if this is a bad idea or not, I suppose we know what we are doing, the point is that it should obey to the -confirm option.
Even deleting an entire folder “might” be a bad idea but the option to answer yes is working.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.