Local group policy has this here in Windows 10:
Computer Configuration, Administrative Templates, Windows Components, Data Collection and Preview Builds
We may disable “Allow Telemetry” and enable “Do not show feedback notifications” for excellent effect.
Domain group policy will only have the above, if it has been upgraded (or installed) with the appropriate very recent version of Group Policy templates.
It’s very possible, per user or per computer:
www.mustbegeek.com/block-usb-or-removable-devices-using-group-policy/
It’s done in Policies, Administrative Templates, System, Removable Storage Access. There are quite a few granulations available.
User Configuration, Preferences (not Policies!), Control Panel Settings, Folder Options. Create a new item. Choose “Launch folder windows in a separate process”.
It is often helpful to update the Group Policy templates for a domain. The most current set can be found quite easily via a Google search:
Windows 10 has some sort of automatic thing built in which is pretended to read our minds and decide for us which of our printers should be the default at any time. Needless to say this makes no sense at all, and causes lots of user frustration. To turn this off with Group Policy, browse to:
User Configuration -> Administrative Templates -> Control Panel -> Printers
and set “Turn off Windows default printer management” to Enabled.
Normally, if a GPO is linked to an OU containing only computers, the user portion does not run. Loopback Mode makes it run. In GPMC, look here:
Computer Configuration, Policies, Administrative Templates, System, Group Policy, “Configure user Group Policy loopback processing mode”
There is a strong tendency to want to use %username% as a macro in GPOs, to get the user’s name in. However, this doesn’t work in GPO. One has to use %LogonUser%. To get the whole list of macros, press F3 while the cursor is in the GPO setup field.
First in a series on improving Windows Group Policy. This apply to the whole Group Policy milieu on a network, all domain controllers.
Third in a series on improving Windows Group Policy.
Group Policy can and sometimes needs to copy files. If it fails, when you run this command:
GPRESULT /H gpresult.html /F
and look at gpresult.html in a web browser, you may see a permissions error, 0×80070005. This is commonly because your source file is not readable. To make this right, working advice appears to be to give read-only access to the source location, to “Authenticated Users”. Obviously this is not secure enough for some applications of this, but at the moment it is not clear what will work. “NETWORK” does not work, “SYSTEM” does not work.
But this page is a work in progress, the above permissions are clearly not satisfactory for many circumstances.
Reportedly, for user-level group policy items, the group policy engine runs with the permissions of the particular user logging in. But this does not make sense with the above, because any user logging in will be a member of “Authenticated Users”. So the engine must run as some other authenticated user, given that the user is apparently not counted as “logged in” while the engine is doing the above.
For computer-level items, the group policy engine runs with the permissions of the computer itself. This means that file copying may be quite a lot more reliable if it can be done without user information, e.g., to the public desktop et cetera. This should work by adding the security group “Domain Computers” as read-only to the source share.
Second in a series on improving Windows Group Policy.
One very common Group Policy strangulator shows up in Windows event logs as SceCli, event ID 1202. When Group Policy processing encounters this, it can prevent many things from occurring.
The error, specifically, is a nonexistent user or group present in a GP configuration item. For instance, most recently there was a Group Policy including a security item which included “Domain Uers”, a typo of “Domain Users”, deep in computer-level security items, and this prevented the policy from doing anything, even though there were other, equivalent, items in the same area. I’ll repeat, the typo item had to be removed, before the entire policy would do anything; group policy processing is apparently not able to treat a nonexistent referent as irrelevant.
Finding the item is interesting too. It requires a file of this name and location:
%SYSTEMROOT%\Security\Logs\winlogon.log
It may not exist. If not, or if it’s not up to date, browse to this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}
and set DWORD ExtensionDebugLevel to 2. Then run gpupdate, and the file will be created. Then in administrative CMD, run:
FIND /I "Cannot find" %SYSTEMROOT%\Security\Logs\winlogon.log
The above will produce one or more invalid security group names or login names, included somewhere as a configuration item within a group policy. Once you have the name(s), run:
rsop.msc
and examine all of its tree carefully, to find the error. That will lead you to the spot in GPMC where you will find the bad entry, to fix. Once you have fixed, try your gpupdate again, and your policy will apply, unless something else is wrong!