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/>  ~

Reply via email to