jlc, A simple "echo N | gpupdate /force /target:whatever" will allow it to process what it can and forces a "N". But, if you do a "gpupdate /force " without a target you will get two prompts, and the simple "echo N |" isn't going to cut it.
Doing the /force and then a single reboot seems to work every time. Sometimes people would complain the "applying" process would take time, but not always. Now it always seems to take some time. Personally, I feel that the trade off of a guaranteed applied policy is worth it. Also, some settings *are* immediate. Some are 3 reboots away.. some are a reboot after a /force. I would *love* to see a detailed document of the policy settings and under what circumstance it would decide to apply it. Jason -----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 sttings 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/> ~
