I’ve heard tales about customers running in to difficulties when configuring automatic discovery. This is one of those tricky ISA Server configuration issues, since there’s so much interaction with other products. This interaction makes it difficult sometimes to understand the source of the problem. (Incidentally, a common cause of auto-discovery issues is DNS mis-configuration…always check that your DNS is properly configured when troubleshooting automatic discovery issues).
One thing that I’ve found useful is using the FwcTool to troubleshoot autodetection from a client box. You can download the tool here.
Another useful tool is a document that gives you more details and background on ISA Server’s automatic discovery mechanism…you can read it here.
But all this got me thinking…I’m pretty sure that a document on troubleshooting automatic discovery would also prove very useful. Stay tuned!
Some concerns on the WPAD feature on ISA 2004 SP1 on SBS 2003 SP1.
Everytime when the CEICW is performed, the WPAD is automatically turned off.
Should the ISA settings be maintained in the CEICW ?
I want to make it easy for other admins in the organization to configure the server should there be a need.
It is not very pleasant to see that things stopped working especially after CEICW and inexperienced admins will have to look high and low for the problem.
For SBS you'll need to use the WPAD script that Jim developed. I beleive that the link if my blog is still good.
When IIS is housed on the same system, you can get unusual results. Using the script works and no problems when you run the CEIW afterwards.
I think a doc on troubleshooting WPAD entries is a great idea! Rumor has it that DHCP WPAD suffers from significant performance issues. Another important issue is designing a WPAD support for distributed organizations. Many companies want to use DNS instead of DHCP, because they don't have WinXP SP2 and don't run as local admin. Thanks!
DHCP-based WPAD has been problematic.
Between Admin- or Power-Uner-only functioanlity and the dreaded 8-second wait at the cllient for a response from WinInet, it's been less than ideal.
In general, I recommend DNS- (or WINS, if you're still chained to it)-based WPAD. It's faster and more configurable.
Any plans on improving the response time issue for DHCP/WinInet? DHCP seems like a more scalable solution and much more simple for branch office deployments. Thanks! --Tom
The DHCP/WinInet problem is described at
As far as I know it should be solved with KB907455 Internet Explorer may delay up to 10 seconds before it starts for the first time in Windows XP (http://support.microsoft.com/default.aspx?scid=kb;en-us;907455).
Kind of frustrating when the link it p