Subscribe via Email

Subscribe via RSS/JSON


Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan


Restore-GPO : Value does not fall within the expected range

Once in a while you Google on some error and come across an old blog post of yours … and you smile. :) That’s what happened today. I was trying to Backup-GPO and Restore-GPO between two (trusted) domains and got the above error. Turns out this is expected when restoring GPOs between domains and I had encountered it previously. The workaround is to make a new GPO in the target domain and import the settings from the backed up GPO. 

You can either do this via PowerShell – use the Import-GPO cmdlet, or via GPO – right click the GPO and select “Import Settings”. 

Funny, the post I found was from 6 years ago … had forgotten I used to play with this stuff back then too. 

Asynchronous processing of Group Policy Preferences

My XenApp servers are set to process their GPOs synchronously (because I apply folder re-direction via GPO) and unless I do it synchronously there’s a chance that the user could login without folder redirection and only on the next login will folder redirection kick in.

However I have a bunch of registry keys I am setting via Group Policy Preferences (GPPs) and these take a long time. Eventually I decided to remove these from GPP and set in the default profile itself, and I have to figure out what to do later on when I need to make changes etc (I guess that’s still better as I only need to target the keys that need changing). But before I did that I was reading into how I can set GPPs to run asynchronously. I am ok with the registry keys being set after the user is logged in.

Well, turns out you can use Item Level Targeting (ILT) to have the GPP apply only in non-synchronous mode. I found this via this forum post.

If you want to do this en-masse for all your GPP registry keys you can edit the XML file itself where the GPP settings are stored. (Which is a cool thing about GPPs by the way – I hadn’t realized until now. All GPP settings, such as registry keys, shortcuts, etc. are stored in XML files in the policy. You can copy that XML file elsewhere, make changes, delete the GPP settings and copy paste the XML file into the GPP).

Anyhoo – in the XML file if your existing line for a setting is like this one (:

Add a new line like this after the above:

This adds a filter to that setting causing it to run only if the GPO mode is not synchronous.

This didn’t seem to make much of a difference in my case (in a very unscientific observation of staring at the screen while GPOs are being applied :)) so  I didn’t go down this route eventually.

On this topic, FYI to myself. By default GPPs are processed even if there is no change to the GPP. This is not the expected behavior. GPPs are called “preferences” so the impression one might get is that they set preferences, but let users change the settings. So I could have a GPP that sets an environment variable to something. The user could change it to something else. Since I haven’t changed the GPP after this, I wouldn’t expect GPO processing to look at the GPP again and re-set the environment variable. But that’s not what happens. Even if a GPP hasn’t changed, it is reconsidered during the asynchronous and background processing and re-applied. This can be turned off via GPO by the way. Lookie here: Computer Configuration\Administrative Templates\System\Group Policy\.

Totally unrelated, but came across as I was thinking of ways to apply a bunch of registry settings without resorting to GPPs: a nice article on the RunOnce process in Windows. Brief summary (copy pasted from the article):

  • The Windows registry contains these 4 keys:
  • HKLM\Software\Microsoft\Windows\CurrentVersion\Run
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run
  • HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
  • HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

HKCU keys will run the task when a specific user, while HKLM keys will run the task at first machine boot, regardless of the user logging in.

The Run registry keys will run the task every time there’s a login. The RunOnce registry keys will run the taks once and then delete that key. If you want to ensure that a RunOnce key is deleted only if its task is run successfully, you can prepend the key name value with an exclamation mark ‘!’.


[Aside] Group Policy Objects – VDA User Settings

An amazing post from Carl Stalhood (as a reference to myself for later):

Group Policy Objects – VDA User Settings

Importing Registry keys via GPP. Also, item-level targeting.

I wanted to do two things. 1) Import a bunch of registry keys for all users. And 2) Set some key values differently for users depending on their location.

Basically these were registry keys containing the details of all our WorkSite databases and I wanted to enable Auto Login to the local WorkSite DMS of each user. So basically import all the registry keys, and if a user’s location is XYZ (preferably identified via an LDAP query to the l attribute) set the DMS of that site to be AutoLogin.

Found this helpful post on how to export a registry key and convert it into an XML file you can copy paste in Group Policy Preferences. Damn! Nice one.

Next I created a copy of the key in question, set it to a higher number in the order (that happens by default when you do a copy) (we need it to be a higher number so that it overrides the other copy of that same key), and in its properties I enabled item-level targeting based on LDAP. Used a query like this: (&(objectClass=User)(sAMAccountName=%USERNAME%)(l=Dubai))

Some screenshots:

Here are the two keys I mentioned. The second one (with a higher order, 9) is set to a different value. The one with higher order will over-ride the one with lower order.

UPDATE: I was wrong. The lower number has higher precedence, so my screenshot above is wrong. I have hence swapped the order. The order is similar to that of GPOs. Lower number wins.

UPDATE 2: Maybe I wasn’t wrong after all. :) Even with the precedence change this didn’t work. I didn’t troubleshoot more (I suck, I know) – instead I just split these into separate GPOs. One to apply all the default settings, and one with higher precedence but scoped to the group I want to apply the different setting to. That did the trick.

I have set the higher order value to target specific users only though.

In this case, if the query searches for an User class object of matching login name and city (the l attribute) set to either Dubai or Abu Dhabi (the two offices for whom I want this key to be different).

[Aside] Configuring Windows Server 2012 R2/ 2016. Start Menu via GPO

Option 1: – export the layout, push it out via GPO to all users. Unfortunately, on Server 2012 R2 this means users can’t modify the Start Menu after this.

Option 2: – much better. You push out a default “template”, but users can customize it further on.

On a related note: – for customizing the Start menu colors (these are the colors of the background you get when pressing the Windows button on Server 2012 R2. I find it better to modify the colors first so the two registry keys mentioned in this link are created).

[Aside] Using GPP Item-Level targeting to set environment variables based on AD attributes

The subject says it all. Wanted to do this, found the following. Excellent!

Unrelated, but I was Googling on this and I want to put the links somewhere –

Msiexec /fu {ProductCode} : repairs all user-specific registry settings

Msiexec /fup {ProductCode}: repairs all user-specific registry settings and reinstalls missing files

GPO audit policies not applying

I didn’t realize my last post was the 500th one. Yay to me! :)

Had an issue at work today wherein someone had modified a server GPO to enable auditing but nothing was happening.

The GPO had the following.

And it looked like it was applying (output from gpresult /scope computer /h blah.html).

But checking the local policies showed that it wasn’t being applied.

Similarly the output of auditpol /get /category:* showed that nothing was happening.

This is because starting with Server 2008/ Vista Microsoft split the above audit categories to sub-categories, and starting with Server 2008 R2/ 7 allowed one to set these via GPO

My understanding from the above links is that both these sort of policies can mix (especially if the newer ones are not defined), so not entirely sure why the older audit policies were being ignored in my case. There’s even a GPO setting that explicitly let’s one choose either set over the other, but that didn’t have any effect in my case. (The policy is “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” and setting it to DISABLED gives the original policy categories precedence; by default this is ENABLED).

The newer audit policy categories & sub-categories can be found under the “Advanced Audit Policy Configuration” section in a GPO. In my case I defined the required audit policies here and they took effect.

Something else before I conclude (learnt from this official blog post).

By default GPOs applied to a computer can be found at %systemroot%\System32\GroupPolicy. Local audit policies are stored/ defined at %systemroot%\system32\GroupPolicy\machine\microsoft\windows nt\audit\audit.csv and then copied over to %systemroot%\security\audit\audit.csv. However, audit policies from domain GPOs are not stored there. This point is important to remember coz occasionally you might found forum posts that suggest checking the permissions of these files. They don’t matter for audit policies from domain GPOs.

In general it is better to use auditpol.exe /get /category:* to find the audit policy settings rather than an group policy tools.

Use PowerShell to get a list of GPOs without Authenticated Users in the delegation

Must have seen this recent Windows update that broke GPOs which were missing the Read permission for the “Authenticated Users” group. Solution is to get a list of these GPOs and add the “Authenticated Users” group to them. Here’s a one liner that gets you such a list –

This puts it into a file called GPOs.txt in the current directory. Remove/ Modify that last re-direct as needed.

Get a list of OUs with inheritance blocked & GPOs not applied

To get a list of OUs and the status of GPO inheritance:

To get a list of OUs that have GPO inheritance blocked:

To get a list of OUs that have GPO inheritance blocked and a don’t have a particular GPO applied to them directly:

There’s probably a better way to do this, but this is the best I could come up with …

AD Domain Password policies

Password policies are set in the “Computer Configuration” section at Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy.

The policy applies to the computer as user objects are stored in the database of the computer. A Domain Controller is a special computer in that its database holds user objects for the entire domain, so it takes its password policy settings from whatever policy wins at the domain level. What this means is that you can have multiple policies in a domain – each containing different password policies – but the only one that matters for domain users is the policy that wins at the domain level. Any policy that applies to OUs will only apply to local user objects that reside in the SAM database of computers in that OU. 

A quick recap on how GPO precedence works: OU linked GPOs override Domain linked GPOs which override Site linked GPOs which override local GPOs (i.e. OU > Domain > Site > local). Within each of these there can be multiple GPOs. The link order matters here. The GPOs with lower link order win over GPOs with higher link order (i.e. link order 1 > link order 2 > …). Of course all these precedence order can be subverted if a GPO is set as enforced. In this case the parent GPO cannot be overridden by a child GPO. 

By default the Default Domain Policy is set at the Domain level and has link order 1. If you want to change the password policy for the domain you can either modify this GPO, or create a new GPO and apply it at the Domain level (but remember to set it at a lower link order than the Default Domain Policy – i.e. link order 1 for instance). 

For a list of the password policy settings check out this TechNet page. 

Since Windows Server 2008 it is possible to have Fine Grained Password Policies (FGPP) that can apply to OUs. These are not GPOs, so you can’t set them via GPMC. For Server 2008 this TechNet page has instructions (you have to use PowerShell or ADSI Edit), for Server 2012 check out this blog post (you can use ADAC; obviously Server 2012 makes it easier). Check out this article too for Server 2008 (it is better than the TechNet page which is … dense on details). 

Roaming profile permissions and versions

Ever noticed that when you moved from Windows XP to Windows 7 the profile name as a .V2 appended to it? That’s because the profile format changed with Windows Vista and to avoid mistakenly loading the older profile format, Vista and upwards add a .V2 (version 2) to the profile folder name. This way a user can login to both XP and Vista/ 7 machines at the same time and the profiles won’t get mashed. 

Windows 8/ 8.1 changes the format again to version 3. This time, however, they don’t change the folder name. When a Windows 7 user logs in to a Windows 8/ 8.1 machine the profile format is upgraded in-place but the folder name is not changed. Later, if they log in to a Windows 7 machine there will be trouble. Workarounds include this one from a member of the AD team or using GPOs on the computers to redirect roaming profiles to different locations (the “Set roaming profile path for all users logging onto this computer” GPO setting). More information is available in this KB article which seems to be missing. 

Speaking of GPOs and roaming profiles, by default roaming profiles are configured with very minimal permissions. Only the Creator/ Owner and the Local System have full permissions to the roaming profile on the server. Administrators don’t have any permissions, including being able to see the existing permissions. There is a GPO setting which can be used to grant the Administrator group access to roaming profiles. This is a Computer policy, found under Computer Configuration > Policies > Administrative Templates > System > User Profiles and is called “Add the Administrator security group to roaming users profiles”. 

Once this policy is applied to computers, when a user logs in the computer adds the Administrator group to the ACL of the roaming profile. However, this policy has a catch in that it only takes effect on roaming profiles created after the policy was deployed. If a user has a roaming profile from before the policy was deployed, the Administrator group will not be added to it. Even if the user logs in to a new machine the Administrator group will not be added (because in effect the machine is downloading the existing profile and leaving things as they are). Of course, if you delete the roaming profile of an existing user so it’s recreated afresh then the Administrator group will be added. 

admin group gpo


The only way to assign access to the Administrator group in such cases is to take ownership of the user’s roaming profile add the Administrator group to its ACLs. Best to create a PowerShell script or a batch file and automate the whole thing. 

[Aside] Couple of GPO notes

Figured something that had been bugging me for long. Got a couple of Win 8.1 machines in my test lab and startup scripts would take a while to launch on them. Initially I thought it must be security related or something, then I noticed that the Win 7 machines in the lab don’t have an issue. This got my checking for any Win 8.1 changes with startup scripts, and found this blog post. Turns out with Win 8.1 startup scripts are delayed for 5 mins! Good news is this setting can be turned off via a GPO – Computer Configuration\Policies\Administrative Templates\System\Group Policy\Configure Logon Script Delay.

Another thing I learnt today was regarding applying language settings via GPO preferences. By default they don’t get applied until you press the F5/F6 key to mark it as enabled. 

Lastly, just as a reminder to myself – to change the default Start Menu power button from Shutdown to anything else, use this GPO setting

Tip: Overriding a GPO setting via Registry

At work our Desktops team has put a policy in place that enables Outlook cached mode for every one. Which becomes a pain in the a$$ when you have to disable and enable cached mode for some users as part of fixing issues (OST file corruptions, no incoming emails, etc).

Thankfully this is a setting you can temporarily override via the registry. Just got to modify a key under HKCU.

But … if you open the registry as the affected user and try modifying the key, you can’t because of lack of permission. Expected, right? What’s the point of a policy if users can modify the registry directly to override it. Admin users can modify the key, but if you open the registry as an admin then HKCU points to the admin and not the user.

Here’s how you workaround though: open the registry by doing a “run as” as the admin. Then go to HKEY_USERS. One of the entries there will be for the user logged in. (There shouldn’t be many entries, but if there are then you can find the one you want in one of two ways: (1) Use psgetsid from the Sysnternals tools to find the SID of the logged in user. That’s the entry you want. Or (2) go to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. You will find entries there with the same names as under HKEY_USERS. Check the ProfileImagePath key in each – the one with the path to the logged in user is the key you want).

Once you find the key of the logged in user under HKEY_USERS that’s it. Everything under here is the HKCU of the logged in user so any changes you make here reflect HKCU. Go ahead and change whatever you want – the change will succeed because you are now using an admin account to make changes to the logged in user’s HKCU. Hah!

Hope this helps someone.

GPO errors due to SYSVOL replication issues

So the other day at my test lab I noticed many of my GPOs were giving errors. Ran gpupdate /force and it gave the following message:

User policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed. Windows attempted to read the file \\rakhesh.local\SysVol\rakhesh.local\Policies\{F28486EC-7C9D-40D6-A243-F1F733979D5C}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:
a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.
Computer Policy update has completed successfully.

To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.

Looked like a temporary thing so I didn’t give it much thought first. But when policies were still not being read after half an hour or so I figured something is broken.

Running gpresult /h didn’t have much to add. I noticed the there were errors similar to the one above. I also noticed that another policy had a version mismatch to the one on the server (this wasn’t highlighted anywhere, I just happened to notice).

I went to the path in the error message on each of my DCs (replace rakhesh.local with your DC name) to find out which DC had a missing file. As the message indicated, it was a replication issue. I had updated the GPO on one of the DCs but looks like it didn’t replicate to some of the other DCs; and my clients were trying to find the policy files on this DC where it didn’t replicate to, thus throwing errors.

Event Logs on the clients didn’t have much to add except for error messages similar to the above.

Event Logs on the DCs were more useful. “Applications and Services Logs” > “DFS Replication” is the place to look here. Interestingly, the DC where I couldn’t find the GPO above reported no errors. It had an entry like this:

The DFS Replication service successfully established an inbound connection with partner WIN-DC01 for replication group Domain System Volume.

Additional Information:
Connection Address Used: WIN-DC01.rakhesh.local
Connection ID: 11C8A7A0-F8A5-4867-B277-78DDC66E3ED3
Replication Group ID: 7C0BF99B-677B-4EDA-9B47-944D532DF7CB

This gives you the impression that all is fine. The other DC though had many errors. One of them was event ID 4012:

The DFS Replication service stopped replication on the folder with the following local path: C:\Windows\SYSVOL\domain. This server has been disconnected from other partners for 118 days, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60). DFS Replication considers the data in this folder to be stale, and this server will not replicate the folder until this error is corrected.

To resume replication of this folder, use the DFS Management snap-in to remove this server from the replication group, and then add it back to the group. This causes the server to perform an initial synchronization task, which replaces the stale data with fresh data from other members of the replication group.

Additional Information:
Error: 9061 (The replicated folder has been offline for too long.)
Replicated Folder Name: SYSVOL Share
Replicated Folder ID: 0546D0D8-E779-4384-87CA-3D4ABCF1FA56
Replication Group Name: Domain System Volume
Replication Group ID: 7C0BF99B-677B-4EDA-9B47-944D532DF7CB
Member ID: 93D960C2-DE50-443F-B8A1-20B04C714E16

Good! So that explains it. Being a test lab, all my DCs aren’t usually online. In this case, WIN-DC01 is what I always have online but WIN-DC02 is only powered on when I want to test anything specific. Since the two weren’t in touch for more than 60 days, WIN-DC01 had stopped replicating with WIN-DC02. Makes sense – you wouldn’t want stale data from WIN-DC02 to overwrite fresh data on WIN-DC01 after all.

The steps in the Event Log entry didn’t work though. Being a SYSVOL folder there’s no option to remove a server from the replication group in DFS Management.

I searched online for any suggestions related to event ID 4012 and SYSVOL, adn found a Microsoft KB article. This article suggested running two commands which I’d like to post here as a reminder to myself as they are generally useful to quickly pinpoint the source of an error. Being a test lab I have just 2-3 DCs so I can go through them manually; but if I had many DCs it is useful to know how to find the faulty ones fast.

First command simply checks whether the SYSVOL folder is shared on each DC:

Next command uses WMIC to get the replication state of this folder on each DC.

A state of 5 indicates the group is in error. Interestingly, the “Access denied” message is one I had noticed earlier too when running dcdiag on the faulty DC.

I didn’t think much of it that time as there were no errors when running dcdiag from the working DC and also because I ran this command while I thought the error was a temporary thing. I still don’t think this is a permissions issue. My guess is that it is to do with the content freshness error I found in the Event Logs earlier. Possibly due to that the second DC is being denied access to replicate and that’s why I get the “access denied” error above.

From the KB article above I came across another one that has steps on how to force a of SYSVOL from one server to all the others. (In the linked article, the section ‘How to perform an authoritative synchronization of DFSR-replicated SYSVOL (like “D4” for FRS)’ is what I am talking about). Here’s what I did:

  1. I launched adsiedit.msc and connected with the default settings
  2. Then I opened CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=WIN-DC01,OU=Domain Controllers,DC=rakhesh,DC=local (replace the DC name and domain name with yours; in my case WIN-DC01 is the DC I want to set as authoritative) and …
  3. … I set msDFSR-Enabled=FALSE and msDFSR-options=1


  4. Next, I opened CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=WIN-DC02,OU=Domain Controllers,DC=rakhesh,DC=local – WIN-DC02 being the DC that is out of sync – and set msDFSR-Enabled=FALSE.
  5. For AD replication through out the domain:

  6. The result of the above steps will be that SYSVOL replication is disabled through out the domain. I confirmed that by going to the “DFS Replication” logs and noting an event with ID 4114:

    The replicated folder at local path C:\Windows\SYSVOL\domain has been disabled. The replicated folder will not participate in replication until it is enabled. All data in the replicated folder will be treated as pre-existing data when this replicated folder is enabled.

    Additional Information:
    Replicated Folder Name: SYSVOL Share
    Replicated Folder ID: 0546D0D8-E779-4384-87CA-3D4ABCF1FA56
    Replication Group Name: Domain System Volume
    Replication Group ID: 7C0BF99B-677B-4EDA-9B47-944D532DF7CB
    Member ID: 09E14860-47F6-49EE-820E-43F7ED015FEB

  7. Then I went back to CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=WIN-DC01,OU=Domain Controllers,DC=rakhesh,DC=local but this time I set msDFSR-Enabled=TRUE.
  8. Again, I forced AD replication through out the domain.
  9. Next, I ran dfsrdiag pollad on WIN-DC01 (the DC with the correct copy) to perform an initial sync with AD. (Note: My DC was a Server 2012 Core install. This didn’t have dfsrdiag by default. I installed it via Install-WindowsFeature RSAT-DFS-Mgmt-Con in PowerShell).
  10. I checked the Event Logs of WIN-DC01 to confirm SYSVOL is now replicating (event ID 4602 should be present):

    The DFS Replication service successfully initialized the SYSVOL replicated folder at local path C:\Windows\SYSVOL\domain. This member is the designated primary member for this replicated folder. No user action is required. To check for the presence of the SYSVOL share, open a command prompt window and then type “net share”.

    Additional Information:
    Replicated Folder Name: SYSVOL Share
    Replicated Folder ID: 0546D0D8-E779-4384-87CA-3D4ABCF1FA56
    Replication Group Name: Domain System Volume
    Replication Group ID: 7C0BF99B-677B-4EDA-9B47-944D532DF7CB
    Member ID: 93D960C2-DE50-443F-B8A1-20B04C714E16
    Read-Only: 0

  11. Finally, I went back to CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=WIN-DC01,OU=Domain Controllers,DC=rakhesh,DC=local and set msDFSR-Enabled=TRUE. You can see what’s happening, don’t you? First we disabled SYSVOL replication on all the DCs. Then we enabled it on the authoritative DC and got it to sync to AD. And now we are re-enabling it on all the other DCs so they get a fresh copy from the authoritative DC.
  12. Lastly, I did a dfsrdiag pollad on WIN-DC02 … and while it should have worked without any issues, I got the following error:

    C:\Users>dfsrdiag pollad
    [ERROR] Access is denied when connecting to WMI services on computer: WIN-DC02.r

    Operation Failed

However, Event Logs on WIN-DC02 showed that SYSVOL was now replicating successfully and clients are now able to download GPOs successfully. So it looks like the “access denied” error is something else altogether (as I suspected initially, yaay!). I’ll have to look into that later – I know in the past I’ve fiddled with the WMI settings on this machine so maybe I made some change that I forgot to reset.

Good stuff!

Loopback GPO processing

It’s been a while since I dabbled in GPOs so today I stumbled upon something I knew but had forgotten.

There are two sort of settings in a GPO (Group Policy Object): Computer settings & User settings. Computer settings apply to the computer itself, use settings apply to the user logging in to the computer.

You apply GPOs to OUs (Organization Units). Thing is, usually your user objects and computer objects will be in separate OUs – say you have an OU for all your desktops, an OU for all your servers, an OU for all your regular user accounts, and an OU for all your admin accounts. In such a scenario how would you go about applying a GPO to only admin accounts that login to a server.

You might link the GPO to the server accounts OU thinking that will cause it to apply to all users logging in to that servers. And it will, but there are two catches:

  1. It will apply to all users logging in to that server, not just the admin accounts (unless you separately disable non-admin accounts from logging in to that server – in which case you are covered); and
  2. More importantly, any user settings in the GPO will not be applied to users that login as the GPO is set to apply to computer objects (because that’s what the OU contains) and since user settings don’t matter to computers these will not be applied to users that login. By default, a user’s policy settings come from GPOs applied to the user object, not the computer object.

You could, of course, apply the GPO to the admin accounts OU but that has the side effect of applying the GPO when admin accounts login to a regular computer too. Not what you want.

The way to resolve this is via loopback GPO processing. Loopback GPO processing tells the computer to apply the user settings assigned to it to all users logging in to that computer. You can use loopback GPO processing to replace the policy settings applied to the user with the user policy settings on the computer. Or you can use loopback GPO processing to merge the two (with the user policy settings on the computer taking precedence).

To enable loopback GPO processing for a particular GPO, go to its Computer Configuration\Administrative Templates\System\Group Policy section using GPMC, open the Configure user Group Policy loopback processing mode policy setting, and change it from Not configured to Enabled and select one of Replace or Merge.