You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a problem with FindandFixADObjectswithStaleAdminSDHolder.ps1 that results in ALL users...even those with current membership in protected groups...having adminCount=1 cleared.
When I run FindandFixADObjectswithStaleAdminSDHolder.ps1 on Windows Server 2019 standard in an AD environment that has fewer than 10 users, the script finds and "fixes" 52 users.
Additionally, in AD there were a half dozen or so users that were a member of Administrators (a protected group) and the script detects these as "stale" and "fixes" them by clearing adminCount even though they should remain protected.
Within the hour when SDPROP runs the adminCount of these users is automatically set back to 1 (as it should be, as far as I can tell), so no harm done.
But the behavior I saw is that the script essentially clears adminCount for ALL users...and then the next run of SDPROP sets adminCount=1 for the users that should have it. This is still useful...but is not what I expected the script to do.
The text was updated successfully, but these errors were encountered:
There is a problem with FindandFixADObjectswithStaleAdminSDHolder.ps1 that results in ALL users...even those with current membership in protected groups...having adminCount=1 cleared.
When I run FindandFixADObjectswithStaleAdminSDHolder.ps1 on Windows Server 2019 standard in an AD environment that has fewer than 10 users, the script finds and "fixes" 52 users.
Additionally, in AD there were a half dozen or so users that were a member of Administrators (a protected group) and the script detects these as "stale" and "fixes" them by clearing adminCount even though they should remain protected.
Within the hour when SDPROP runs the adminCount of these users is automatically set back to 1 (as it should be, as far as I can tell), so no harm done.
But the behavior I saw is that the script essentially clears adminCount for ALL users...and then the next run of SDPROP sets adminCount=1 for the users that should have it. This is still useful...but is not what I expected the script to do.
The text was updated successfully, but these errors were encountered: