2

I have an OU named "Asia" wherein I've set regional settings via a GPO named "Asian Settings." This GPO is linked to the "Asia" OU and the link is enabled. However, when I run gpresult the log indicates that the "Asian Settings" GPO was NOT applied nor was it filtered out. I've tried gpupdate but that didn't resolve the problem. Can anyone explain why the GPO is not being applied to the OU and what I need to do in order to have it applied?

user9517
  • 115,471
  • 20
  • 215
  • 297
Ari
  • 189
  • 1
  • 9
  • Is there anything in the OU? What regional settings have you configured? – joeqwerty May 27 '11 at 15:27
  • @joeqwerty: There are `user` objects in the OU. Via an ADM file I configured settings for counrty name, datetime, currency, etc. – Ari May 27 '11 at 15:33
  • 1
    And the ADM file you created configures User settings and not Computer settings, right? Are you logging on as one of the users in the OU? – joeqwerty May 27 '11 at 15:34
  • @joeqwerty: Yes, the ADM file configures *user* settings (and not *computer* settings) Well, when I run the `gpresult` command I'm logged in as the administrator. But otherwise I do login as a member of the target OU. – Ari May 27 '11 at 15:40
  • 1
    Double check the linked GPO's and GPO inheritance for the Asia OU and run gpresults again for an Asia OU user and check both the Applied and Denied GPO's again. Also, is the security filtering of the GPO set to Authenticated Users? – joeqwerty May 27 '11 at 15:52
  • @joeqwerty: I double-checked and the **Asia OU** linked GPO includes *Asian Settings*, GPO inheritance includes *Asian Settings and Default Domain Policy*. Security filtering of the GPO is set to *Authenticated Users*. RSOP (applied GPO) includes *Local Group Policy, Default Domain Policy, and TS Policy*. – Ari May 27 '11 at 16:19
  • Ahh, TS policy. Is that for a Terminal Server? If so, you don't happen to have loopback policy processing configured in the TS policy do you? – joeqwerty May 27 '11 at 16:23
  • @joeqwerty: Yes, it's for a terminal server and yes the loopback policy is enabled in the TS Policy. Is that the problem? – Ari May 27 '11 at 16:28
  • More than likely. With loopback processing enabled (in replace mode) it tells the GPO CSE's to process the user settings defined in the GPO linked to the TS OU instead of processing the user settings defined in the GPO linked to the user OU (Asia). I suspect the setting is configured to replace the user settings and not merge the user settings. I'll create an answer from this comment so that you can accept it if this turns out to be right. – joeqwerty May 27 '11 at 16:35

2 Answers2

3

With loopback processing enabled (in replace mode) it tells the GPO CSE's to process and apply the user settings defined in the GPO linked to the TS OU instead of processing the user settings defined in the GPO linked to the user OU (Asia). I suspect the loopback setting is configured to replace the user settings and not merge the user settings.

In addition, setting the loopback policy to merge mode would process and apply the user settings from both the computer and the user OU's.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • 1
    Just from "TS Policy" - Good find. – Shane Madden May 27 '11 at 16:45
  • @joeqwerty: I re-configured the loopback policy to *merge* from *replace*, but it didn't resolve the issue. When I look in the applied GPO section of the user configuration summary I see that only the Default Domain Policy and TS Policy are applied. Could the problem be with the ADM file? – Ari May 27 '11 at 16:55
  • @joeqwerty: I also tried disabling the loopback all together, but that didn't solve the problem either. – Ari May 27 '11 at 17:06
  • 2
    Run gpupdate /force on the server. Even if the ADM is borked you should still see the GPO being applied. Also note that in replace mode the user GPO's don't get processed and won't be listed in gpresults but in merge mode they do get processed and should be listed in gpresults. Also, when using merge mode the user settings configured in the GPO linked to the computer OU take precedence, so if you have the same setting in both sets of user configurations (computer OU GPO and user OU GPO), the computer GPO settings would take precedence. – joeqwerty May 27 '11 at 17:11
  • @joeqwerty: I ran `gpupdate /force` on the target server and then ran `gpresult`. The resultant policy log shows that in user configurations only *TS Policy & Default Domain Policy* are applied. Oddly, when I run *Group Policy Modeling* the resultant applied policies includes *Asian Settings*. – Ari May 27 '11 at 17:52
  • Well I can't say that I think the ADM template in the policy is the problem, but as a test create an empty GPO and link it to the Asian OU and see if it gets applied. – joeqwerty May 27 '11 at 18:06
  • @joeqwerty: I added an empty GPO entitled *Test Policy* to the *Asian OU*. I ran `gpupdate /force` on the target server and then ran `gpresult`. The policy log once again showed that *TS Policy & Default Domain Policy* are the only GPOs applied. *Test policy* was not included in any section, not even in the denied/filtered-out section. I repeated the RSOP query from the AD server and got the same results. – Ari May 27 '11 at 18:17
  • OK, and just to be sure, you're running gpresult for a user from the Asian OU? If so, is that user logged on to the server or has that user logged on to the server? Also, if you look at the Settings tab in gpresults do you see any settings from your Asian OU GPO?... There's something I'm not thinking about I'm sure, but I can't think of it. – joeqwerty May 27 '11 at 18:41
  • @joeqwerty: Yes, I'm running `gpresult` for a user from the *Asian OU*. That user has previously logged into the server, but is not currently logged in. I do not see any settings from the *Asian OU GPO* within the *Settings* tab of the GP results. All *winning gpos* are either *Default Domain Policy or TS Policy*. The *TS Policy* GPO is linked to the *Terminal Server OU*. – Ari May 27 '11 at 18:57
  • I'm at a loss. I'm sure I'm missing something but looking at this in my own environment I can't think of anything else. The only thing I could suggest at this point is to enable User Environment Debug Logging and see if you can find the problem. http://support.microsoft.com/kb/221833 – joeqwerty May 27 '11 at 19:10
  • Also, take a look at the Denied GPO's and see if the Asian GPO's are listed and if so, why they're being denied (blocked SOM, etc). – joeqwerty May 27 '11 at 19:16
  • In the computer configuration section nothing is denied. In the user configuration section *Local Group Policy* is denied because it is *empty*. – Ari May 27 '11 at 19:20
  • @joeqwerty: Thanks for the help, I appreciate it. When I left last Friday the "Asian Settings" GPO was not being applied. When I checked on Tuesday morning after the long weekend, the GPO was applied. *Nothing was changed since I last touched it Friday night.* I checked the debug logs, but there were no signs of issues. I guess the main issue was the `loopback policy`, but I'm still dumbfounded as to why it took so long to take effect. In any event, the GPO since taking effect is properly and consistently being applied. – Ari Jun 05 '11 at 16:40
  • 1
    That's weird but I'm glad it's working for you now. – joeqwerty Jun 05 '11 at 17:24
0

Did you try gpupdate /force, or just gpupdate? If the latter, it may not happen right away. The default wait time on gpupdate is 600 seconds or 10 minutes.

KCotreau
  • 3,381
  • 3
  • 20
  • 24