We were looking for a more permanent solution so we didn't test just running it one time and rebooting again and again to see if it stuck.
The only Y/N I've seen with gpupdate /force is the reboot and in a script it defaults to no. Otherwise, we'd have a lot of unhappy people around here once an hour. It just catches whatever changes it synchronized on the next reboot, as you saw. I'm not sure what's up with your delays without the gpupdate /force being something that is ran constantly. I don't have an environment to help you validate those right now or I certainly would! I'd reboot a lot more and see how far it sticks. It seems that the systems synchronize and apply computer settings on their own schedule and if you did a force prior to the reboot that would have updated them anyway then maybe you are a victim of happenstance. Good luck and good night. -----Original Message----- From: Joseph L. Casale [mailto:jcas...@activenetwerx.com] Sent: Thursday, January 08, 2009 6:19 PM To: NT System Admin Issues Subject: RE: WPAD Proxy Config Priceless, I just got off the phone with someone regarding increased boot and loading times with the computers displaying 'Applying Computer Settings...' :) I noticed the /force target:computer got the settings in immediately but never waited a full 3 reboots to see. Did you *only* notice the lengthy times once you applied the script changes? How does that work as a /force has an interactive prompt for a "y/n"? Is that the reason for the timeout? I don't have any of that in my login/startup scripts. Yet I still have these delays now... jlc -----Original Message----- From: Joe Tinney [mailto:jtin...@lastar.com] Sent: Thursday, January 08, 2009 4:02 PM To: NT System Admin Issues Subject: RE: WPAD Proxy Config We use WPAD, also. We've found that it takes at least 3 reboots for the GPO to take over in IE7. See thread gpupdate/GPO from Jason Gauthier (jgauth...@lastar.com) regarding the issues we were seeing with that. We had found that when we manually changed our proxy settings that it was not resetting itself in a timely fashion. After some testing it was found that it was taking (for us) at least 3 reboots for them to kick in. There were many possible reasons given as to why. We ended up putting a "gpupdate /force /target:computer" in an hourly script that runs on all of our workstations and "gpupdate /force /target:user" in the login script. The changes to the proxy settings required a reboot to take effect, but only one this time and not 3. The downside, we've discovered, is increased boot and loading times with the computers displaying 'Applying Computer Settings...' for several minutes on every boot now. HTH. -----Original Message----- From: Joseph L. Casale [mailto:jcas...@activenetwerx.com] Sent: Thursday, January 08, 2009 5:51 PM To: NT System Admin Issues Subject: RE: WPAD Proxy Config Ok, Theoretically I have covered both since my dns has the cname "wpad" redirecting to my webserver which dishes out wpad.dat from its root and my dhcp server has option 252 referencing that complete url.:) My wpad file looks similar to yours as well. I see some issues searching the net on ie7 though, I just found that the GPO setting for it is rather flaky, sigh... Thanks! jlc -----Original Message----- From: Ben Scott [mailto:mailvor...@gmail.com] Sent: Thursday, January 08, 2009 3:37 PM To: NT System Admin Issues Subject: Re: WPAD Proxy Config On Thu, Jan 8, 2009 at 4:45 PM, Joseph L. Casale <jcas...@activenetwerx.com> wrote: > Well, my firefox clients pick up the settings but not ie7. > I am using the dns (cname) / dhcp option 252 method. > > How are you doing it, and do you have it working with ie7? We haven't deployed MSIE 7 here yet. I'll see if I can get a sandbox VM running with it to test. MSIE 6 and Firefox 3.x on Win XP Pro SP2 both work fine. Here's what we did: We implemented the DNS method of WPAD. We didn't even bother with DHCP; the DNS method has worked fine for us for everything. I seem to recall reading that the DHCP method isn't as widely implemented in clients, but I could be wrong on that. We created a CNAME record named <wpad.corp.example.com.>, where <corp.example.com.> is our Active Directory domain name, and the default DNS suffix for our LAN. Thus, clients attempting to do WPAD via DNS end up requesting <http://wpad.corp.example.com/wpad.dat>. The right-hand-side of the CNAME record specifies <foo.corp.example.com.>, where <foo> is our proxy server. Our proxy server also runs an Apache web server, which is configured with an alias such that </wpad.dat> redirects to </proxy.pac>. That's our proxy auto-config script. Apache also knows that a *.pac file is of MIME type <application/x-ns-proxy-autoconfig>. To do that, the following was added to the Apache config file: AddType application/x-ns-proxy-autoconfig .pac Redirect /wpad.dat http://foo/proxy.pac Our proxy auto-config script looks like this: function FindProxyForURL(url, host) { if ( isPlainHostName(host) || dnsDomainIs(host, ".corp.example.com") || shExpMatch(url, "http://10.*") || shExpMatch(url, "http://127.*") ) return "DIRECT"; else return "PROXY proxy:8080"; } We also have a CNAME <proxy.corp.example.com.> that yields our proxy server. (I'm big on using generic aliases for specific hosts, so when things change you don't have to reconfigure a bunch of things, just the alias.) The script causes browsers to bypass our proxy for internal systems, and use our proxy for everything else. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~