Hello all.
In your AD, there might be an OU tree for production purposes. There might be a second tree for testing purposes. Now you need a third tree for evaluation purposes. That means copying all OUs from one of the existing trees and re-linking all GPOs linked to the source.
I recently had this requirement for an OU structure 6 levels deep with more than 100 linked GPOs. Hard to believe I would do this manually, so I fired up my ISE and came out with this module:
CopyGPOLink
Since the description in the gallery is somewhat crispy, here's the full help:
Tuesday, July 25, 2017
Friday, June 23, 2017
Windows 10 Settings App - how to hide pages for user groups
Hi Readers :-)
With Win 10 1703, the settings app can be configured to hide or allow only certain pages. This is configured with http://gpsearch.azurewebsites.net/#13576. But there's a drawback: This is a computer setting, so it will affect ALL users - even local administrators. Hey, MS - what did you think about when implementing this?
How can we configure the settings app differently for different groups of users?
The solution for this - as often - is "Group Policy Preferences" (GPP). With GPP Registry, we can write HKLM in the user part of a policy. Lets try - we create a GPP Registry to write the value we found at gpsearch:
And voila - it turns out that this value is not evaluated at boot time or at logon, but each time you open the settings app.
This enables us to configure the settings app based on users, although "officially" it is a computer setting :-)
Be aware that results might be unexpected if you use fast user switching. Consider the following scenario:
Admin logs on, gets unrestricted settings app. Switch user, default user logs on, gets restricted settings app. If you now switch back to Admin, he also will have restricted settings app because switching users does not trigger gpupdate. You can circumvent this if you create a scheduled task that runs "gpupdate /target:user" and triggers on Session reconnect.
Note: The IDs for the pages (about, privacy and so on) are not listed in the policy help. They can be found at https://www.windowscentral.com/how-hide-settings-pages-windows-10-creators-update#mssettings_page_name_list or at https://blogs.technet.microsoft.com/mniehaus/2017/04/13/hiding-pages-in-settings-with-windows-10-1703/
With Win 10 1703, the settings app can be configured to hide or allow only certain pages. This is configured with http://gpsearch.azurewebsites.net/#13576. But there's a drawback: This is a computer setting, so it will affect ALL users - even local administrators. Hey, MS - what did you think about when implementing this?
How can we configure the settings app differently for different groups of users?
The solution for this - as often - is "Group Policy Preferences" (GPP). With GPP Registry, we can write HKLM in the user part of a policy. Lets try - we create a GPP Registry to write the value we found at gpsearch:
And voila - it turns out that this value is not evaluated at boot time or at logon, but each time you open the settings app.
This enables us to configure the settings app based on users, although "officially" it is a computer setting :-)
Be aware that results might be unexpected if you use fast user switching. Consider the following scenario:
Admin logs on, gets unrestricted settings app. Switch user, default user logs on, gets restricted settings app. If you now switch back to Admin, he also will have restricted settings app because switching users does not trigger gpupdate. You can circumvent this if you create a scheduled task that runs "gpupdate /target:user" and triggers on Session reconnect.
Note: The IDs for the pages (about, privacy and so on) are not listed in the policy help. They can be found at https://www.windowscentral.com/how-hide-settings-pages-windows-10-creators-update#mssettings_page_name_list or at https://blogs.technet.microsoft.com/mniehaus/2017/04/13/hiding-pages-in-settings-with-windows-10-1703/
Subscribe to:
Posts (Atom)