Okey dokey. I figured this out after a bit of repro in my lab. Its kinda interesting. So, basically the duplicate GPO processing is a function of using Loopback policy in merge mode only (replace mode doesn't cause this). And, when I looked at the userenv log, it made total sense why it was doing this, even though I hadn't really thought about it until now, mostly because I don't' often see merge mode loopback used. What is going on is, with replace mode, Windows basically says, don't do any user-specific policy processing for the user logging into a loopback machine. So basically any GPOs that would normally be processed by the user, including local, site, domain and OU- linked ones, are just not processed in replace mode. Instead, all user settings come from any GPOs that apply to the loopback computer, including those linked at the local, site,domain and OU level. Makes sense. Now enter merge mode...
Merge mode says, first process all user GPOs that the user account would normally get. Then, process all user GPOs that the loopback computer would normally get. So, what that means is that policies that are higher in the hierarchy, like site and domain-linked GPOs that are processed both by the computer and the user, get processed twice. Since the computer-based loopback user settings process last, the result would normally be that any conflicting user-specific settings (like Admin. Template registry settings) would be overriden by the loopback computer settings. And that happens, however, certain policy extensions, like scripts or software installation, don't exhibit override behavior. If two scripts are in the path to be processed, they will process cumulatively rather than one overriding the other. Same with software. Hence the reason you see logon scripts running twice. So, bottom line here is that if you want to use merge mode, you're probably going to need to play with it a bit. For example, you might want to set block inheritance on the OU containing the loopback machines, and then if there are any, non-script-based GPOs higher up that you need to apply to those computers, you can set them to Enforced. Even in this case, RSOP will still report that some GPOs run twice, so that won't go away at all in merge mode. In any case, very interesting. Thanks for bringing it up. Good fodder for a new FAQ on my website :) Darren -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Rochford Sent: Thursday, January 05, 2006 9:55 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Duplicate application of group policy I'm glad that you say loopback shouldn't cause this - I was sure I'd used something like this successfully before! I've now put a copy of the complete results of gpresult /v and userenv.log on http://195.194.12.22/data/gp.htm (they're a bit big to email to the list!) I've tried looking at userenv.log files before and while I can understand some of what's going on, I can't really see what's going wrong! I've loaded the syspro Policy Log Viewer (http://www.sysprosoft.com/policyreporter.shtml) which you mention on your website. On the Performance History tab it says "Via Loopback" next to the policies which are being duplicated. Not sure where this gets me but it's now time for me to go home (and brave the snow which has just started falling in London!) Steve -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: 04 January 2006 18:14 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Duplicate application of group policy John- I don't doubt this is the behavior you're seeing, but loopback *should* not cause this. At least not given the way its *supposed* to work. So, that is why a userenv log would be very interesting here. My guess is that even though Gpresult is showing it as running twice, the given GPO is really only being processed once. I will also try to test this on my end to see if I can discover what's up. Darren -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, January 04, 2006 9:57 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Duplicate application of group policy Not to doubt your expertise Darren, but we use a worksation loopback here for the screen saver. Not my idea, but in our situation, it is easier to figure out machines that need to be exempt, rather than users. They could run a certain test for weeks on one pc, but on their administrative pc, the screen saver is OK, and required. RSOP certainly shows the domain policies being run twice. Might be because of "merge" mode, never really bothered into looking into the mechanics. I also fool around with my local policy to test a setting here and there, and it also shows that as being run twice in certain situations. We even use site policies, and they show being run twice, and that's done before the domain. Certainly he should turn on the logging as you say, but Steve's situation sounds very familiar to me. Thanks, John "Darren Mar-Elia" <[EMAIL PROTECTED] uest.com> To Sent by: <ActiveDir@mail.activedir.org> [EMAIL PROTECTED] cc ail.activedir.org Subject RE: [ActiveDir] Duplicate 01/04/2006 11:09 application of group policy AM Please respond to [EMAIL PROTECTED] tivedir.org Steve- In this situation, I would enable verbose userenv logging and see if you can track down what is actually happening during the processing cycle. I am kinda doubting that loopback would cause things like the local GPO or Default Domain Policy from processing twice, because these should be processing well before you OU-based loopback policies kick in. Darren -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, January 04, 2006 7:50 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Duplicate application of group policy Hi Steve... That's about the only way to apply user settings to computers, using the loopback. Not sure of your OU structure, if you had your users seperated, you could apply the actual user policies (loginscripts etc.) at the "user OU" level. As long as that was a different "scope" it would eliminate them trying to run the scripts twice, which is where I would expect these things to hang some. Or even generate errors, if trying to remap an already mapped drive. Not sure if I"m explaining it clearly enough? John "Steve Rochford" <[EMAIL PROTECTED] nwl.ac.uk> To Sent by: <ActiveDir@mail.activedir.org> [EMAIL PROTECTED] cc ail.activedir.org Subject RE: [ActiveDir] Duplicate 01/04/2006 09:12 application of group policy AM Please respond to [EMAIL PROTECTED] tivedir.org Thanks; I spotted that proxy_isa was only once but John's other message about loopback makes me start thinking that this is very relevant. The proxy_isa just sets a particular OU to use an ISA server as proxy (rather than Squid - we have some software which won't work with ISA so a couple of OUs link to a GPO called ISA_Squid which points them at the Squid proxy server). The policy is applied to a group of machines (because it's particular rooms which need the proxy set like this rather than particular people) but loopback processing is set because the proxy settings themselves are user specific rather than machine specific. I'm sure I've used loopback processing for actually this sort of thing before but I'd guess I'm doing something wrong! I've tried to copy the settings screen from the proxy_isa GPO below - is this where I should be looking or could something else be wrong? If necessary, I can remove the GPO and just use the login script to set proxy settings - there was just a "nice" feel to doing things with the GPO Steve Computer Configuration (Enabled) Administrative Templates System/Group Policy Policy Setting Enabled Mode: Merge User Configuration (Enabled) Windows Settings Internet Explorer Maintenance Connection/Proxy Settings Enable proxy settings Protocol Server Port HTTP witproxy 8080 Secure witproxy 8080 FTP witproxy 8080 Gopher witproxy 8080 Socks witproxy 8080 Exceptions: Do not use proxy server for addresses beginning with www.student.cnwl.ac.uk, moodle.student.cnwl.ac.uk, learnwise.student.cnwl.ac.uk, wstud3.student.cnwl.ac.uk, mail.student.cnwl.ac.uk, Do not use proxy server for local (intranet) addresses Enabled ________________________________ From: [EMAIL PROTECTED] on behalf of Al Mulnick Sent: Wed 04/01/2006 14:16 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Duplicate application of group policy Steve, it looks like, from that list that you're not applying all GPO's twice. Some are and some aren't. That seems to me like it would be a configuration issue. allpcs Proxy_ISA <-----applied once Default Domain Policy <----- applied twice LogonLogoffScripts Local Group Policy Default Domain Policy LogonLogoffScripts Local Group Policy Some things to look for: Check to see what the GPO's are linked to. Look over recent changes to see if any of them could have affected this behavior. Verify that the slow logon is due to the application of group policy. You may have something else going on. Al On 1/4/06, Steve Rochford <[EMAIL PROTECTED]> wrote: Most group policy objects are being applied twice - what do I need to look for to fix this? Running gpresult /v shows that they're being picked up twice - eg the the start of the user section is shown below. There is only one link for each policy object but there's obviously something I'm missing. All the policies are working but it's causing problems because logging on takes twice as long and the user login script (set in the "logonlogoffscripts" group policy) runs twice. Steve USER SETTINGS -------------- CN=Administrator,CN=Users,DC=student,DC=cnwl,DC=ac,DC=uk Last time Group Policy was applied: 04/01/2006 at 08:23:52 Group Policy was applied from: pstud1.student.cnwl.ac.uk Group Policy slow link threshold: 500 kbps Applied Group Policy Objects ----------------------------- allpcs Proxy_ISA Default Domain Policy LogonLogoffScripts Local Group Policy Default Domain Policy LogonLogoffScripts Local Group Policy List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ [attachment "winmail.dat" deleted by John P Salemi/CedarRapids/RockwellCollins] List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
