I am developing some group policies on a windows domain controller (Win Server 2016), but after testing a rule (R1) being applied for the first time on my client machine (Win 10), I modified it and it did not update anymore.
Even trying gpupdate /force did not work to update R1 on the client.
Thinking there was caching going on, I removed R1 on the domain controller and created a new one with a different name (R2). After a (long) while of gpupdate manually, my client found out that R1 was not there anymore, but now it won't get R2 at all.
The application scope for R2 is correct, and even broadening to something which necessarily has to include my machine and my user will not be sufficient for my client to get the new R2 group policy. Launching gpupdate /force to get R2 brings no joy, and gpresult /r confirms that R2 is not applied.
Am i missing something here? Can anybody suggest a way to force Windows to refresh the group policies from the domain controller, or force it to invalidate its cache? Please note I would try to avoid to leave the domain as this feels like not a solution, since every other machine here that encounters the same issue would need to leave the domain and join again, and I am somewhat reluctant accept that since Windows tells me the client machine will lose all the preferences for the domain user.
Additional information requested: from the gpsvc.log I found this regarding my R2 policy:
Found file system path of: <\\mydomain\SysVol\mydomain\Policies\{3890C0BE-2CD8-420C-92D8-83F279BC4EF6}>
GPSVC(588.5a8) 15:03:07:492 ProcessGPO(User): Couldn't find the group policy template file <\\mydomain\SysVol\mydomain\Policies\{3890C0BE-2CD8-420C-92D8-83F279BC4EF6}\gpt.ini>, error = 0x3. DC: <machine>.mydomain
I guess there is a problem with the replication of this rule then? I wish to add that yesterday it was just silently failing, while now it returns something along this error when I run gpupdate /force
My rule was in a OU composed by Users, and it applied just to myself (and since it was not working, I then also added my computer to the scope, without success). The setting was a user policy to copy some files in my user folder.
UPDATE: As suggested, I created a new rule, R3 and deleted R2. Windows would still complain about the missing files in Sysvol from R2. I turned off the machine as I had to leave for a while. When I was back, R2 was gone, no error would appear anymore, but R3 still would not be applied to my machine through gpupdate /force.
gpsvc.log reports, for R3: cannot be accessed/is disabled/or has no extensions
However I am in the security filter so I should have access.. right? Moreover, the rule is not empty and contains two settings to distribute two different files to users. Opening that path manually from Windows Explorer works, and I can read the files in there.
Thanks in advance for any help and suggestion!
UPDATE 2: On the day after, the client "just accepted" the policy R3 which yesterday refused to take. I am quite convinced there is caching involved now, or some kind of (long) replication delay. As of the reason why R3 may not have been applied in the beginning, I think this was the reason: https://blogs.technet.microsoft.com/askpfeplat/2016/07/05/who-broke-my-user-gpos/ . I have solved the issue nicely described by this article, but it took up to one day for my Win10 client to get the updated policy, independently of me running gpupdate /force.
Thanks to everybody for the suggestions and the great input.
