(图5)
Name:WPAD
Data Type:String
Code:252
完成后，单击OK，在252记录的String Value下输入， Http://ISA Server:80/wpad.dat，如图6。当然如果你已经配置好了DNS，也可以在这里输入 Http://WPAD:80/wpad.dat，但是如果这样设置就会带来一个问题，客户机多了一次对DNS解析WPAD名称的查询，其实，如果你的站点中只有1台ISA Server，你完全可以直接在String中给出ISA Server的IP地址，这样则会又减少一次DNS查询！做了预定义之后，你需要把这个252的Option应用到你的ScopeOption级别上，或许你的DHCP服务器负责多个Scope的IP地址分配工作，这时，把预定义的252 Option应用到Server Option级别上是比较高效的办法。此外，在建立252预定义条目时，Name字段不必为WPAD，这只是为了让你明确这个条目的作用的表示而已。DHCP的252记录通常用来支持自动发现打印机、Web代理服务器、时间服务器以及其他一些网络的服务器。
注意：在编辑String值的时候，文件名部分一定要使用小写，不能写成Wpad.dat或者WPAD.DAT等这种格式。唯一正确的格式是wpad.dat，因为ISA Server只响应“wpad.dat”。这是ISA Server的一个Bug，在Q307502这篇Kb中有说明！
3， 设置ISA Server 发布“自动发现”信息
打开ISA Server 管理器，右键ISA Server ，选择Properties，找到Auto Discovery选项卡，启用“Publish automatic discovery information”，如图5。一旦启用这这一项，ISA Server就会把用于配置Web代理客户端和FWC的配置文件发布，当客户机通过DNS和DHCP查询得到ISA Server的地址并连接ISA Server后，这个配置的脚本就会从ISA Server传输到客户机，配置相应的客户端成为ISA Server合法的客户端。

自动发现（AutoDiscovery）特性的机制讨论  —— 后续篇
起初，朗月繁星在设计这篇文章的结构时，是想把这部分内容和“机制讨论”写在一起的，但考虑到可能有一部分朋友还不是很了解“自动发现”的具体设置过程。所以，有些话题讨论起来会令一些读者有“不知所云”的感受，最终决定将这些讨论安排在“实施篇”的后边。于是，就有了机制讨论的后续篇。

话题一：关于配置文件的一些探讨
在上边的一些单元里，我们涉及了配置文件的概念，也讲了它是如何工作的。但是这个文件究竟存贮在什么位置？如果你在ISA Server上搜索这个文件，你是找不到的。如果使用 http://ISA Server/wpad.dat的方式，你可以得到这个文件。wpad.dat文件是由Web Proxy Service（W3proxy.Exe）组件临时生成的，而且配置文件不仅只有wpad.dat一个，详情请往下看。临时生成的原因是，ISA Server的计算机名、IP地址，以及响应的端口这些配置信息，在不同的公司设置可能会不同。此外，你可能会在设置DNS和DHCP服务器的时候有些疑惑，为什么在DHCP上的252记录要明确指出配置文件是wpad.dat，而在DNS上却只指明了ISA Server的IP地址？对于这个问题，朗月繁星起初也是疑惑不解，后经过大量的网络分析得到了结论。这是因为客户端在查找DHCP和DNS的WPAD条目后，所引用的信息不同。这里说的客户端包含Web代理客户端和FWC两方面内容。对于Web代理客户端，在查找DHCP的WPAD条目时，他要引用252记录（也就是WPAD条目）完整的String值，当Web代理客户端得到这个String值后，会使用HTTP的Get方式得到这个配置文件，即wpad.dat文件；在查找DNS的WPAD条目时，Web代理客户端要得到的信息只是ISA Server的IP地址，之后Web代理客户端会使用这个IP加上一个默认的“wpad.dat”字段以HTTP的get方式去访问位于这个IP地址上的wpad.dat文件。然而，对于FWC情况是如何呢？FWC无论是从DHCP还是DNS服务器上查找WPAD条目，对于FWC唯一有用的信息是ISA Server服务器的FQDN（或者是IP地址），尽管DHCP的252记录中给出了具体的配置文件的名称，但对于FWC来说是毫无意义的。当FWC得到这个FQDN后，会使用这个FQDN加上一个默认的“wspad.dat”字段以HTTP的get方式去访问这个文件，这一点与Web代理客户端从DNS服务器得到WPAD信息极为相似，唯一不同的是FWC加上的默认字段是“wspad.dat”而不是“wpad.dat”。
wspad.dat是FWC的配置文件，wpad.dat是Web代理客户端的配置文件。两者的格式是不一样的，wspad.dat的格式和Mspclnt.ini是一样的。我们知道Mspclnt.ini是安装FWC软件时存在于ISA Server上的一个用于传递配置信息给FWC的文件，并在安装之后复制给FWC的计算机。这个文件默认从ISA Server每6小时同步更新，以得到最新的配置信息。事实上wspad.dat就是Mspclnt.ini的副本，内容完全一样，如果您有兴趣可以做一下对比！配置文件中的信息包含对FWC上可以进行Winsock请求的应用程序的设置，例如您希望FWC不相响应QICQ的Winsock呼叫。同时包含配置文件的版本信息，ISA Server响应FWC请求的端口号（默认是UDP 1745），当然最重要的还包含ISA Server的计算机名或IP地址。我想，写道这里，您应该明白为什么配置IE浏览器和FWC使用的配置文件不一样了。我们知道，对于客户机上运行网络应用程序的设置（Application Setting）是FWC才具有的特性，Web代理客户不能在应用层上控制，所以对于IE浏览器来说，配置文件中关于应用程序的设置是无法辨认的。如果您对Web代理客户使用的配置文件的编写感兴趣，您可参考微软Knowledge Base中的“Using Automatic Configuration and Automatic Proxy” 一文。

话题二：使用DNS还是使用DHCP作为中心的服务器
在考虑选择DNS还是DHCP作为中心服务器的时候，我们主要考虑一下几点。第一，需要自动发现ISA Server的客户机是否为DHCP Client ，因为只有DHCP Client才有会向DHCP服务器发送特定DHCP会话的消息。所以需要自动发现ISA Server的这些客户机如果有某些不是DHCP Client，那么就必须另外配置DNS服务器支持这些非DHCP Client发现ISA Server。第二，我们知道默认情况下ISA Server会使用内部网卡的TCP 80端口发布自动发现的配置文件，这一点我们并不难理解，不知你是否还记得我们配置DHCP服务器的时候是如何填写252记录的String Value的？是的，客户机是利用Http的方式来请求这个配置文件的，而http协议的默认端口号是80。如果你的ISA Server由于某种原因不得不放弃使用TCP 80端口来发布自动发现的配置文件的时候，例如ISA Server要在内部网卡的TCP 80端口发布一个Web站点，你该如何？我们不妨假设ISA Server使用8000端口来发布自动发现的配置文件， 对于DHCP服务器的设置，我们可以直接的在服务器名称的后边加上“：8000”，也就是 http://ISA Server:8000/wpad.dat。但是对于DNS服务器应该如何设置？此时，单纯利用DNS服务器来支持客户机自动发现ISA Server的功能无法实现！我们知道非DHCP Client只能利用DNS来查询，但是DNS返回的结果只包含ISA Server（WPAD服务器）的IP地址，至于端口并没有告诉客户机，而客户机也只会使用DNS返回的IP地址加上一个预设置的80端口，用Http的get方式请求配置文件。而在使用非80端口的这种情况下，什么时候DNS会起一些作用呢？除非DHCP服务器设置252记录的String Value时写的不是ISA Server的计算机名，而是写WPAD，即 http://wpad/wapd.dat。这样DNS会负责将wpad解析成ISA Server的计算机名，再从ISA Server的计算机名解析成IP返回客户机，但是客户端“自动发现”ISA Server的关键不在DNS。换一句更言重、更直接的话来描述以上现象：使用非80端口发布自动发现时，非DHCP Client可以自动发现ISA Server的功能被取消了！但是，有没有可以解决的办法呢？ 答案是：有！其实你可以使用一种变通的办法来解决。在上一章节中，我们说过，您可以使用IE浏览器直接访问到那2个配置文件（wpda.dat和wspad.dat），而且也可以下载到你的计算机上。这一点就完全给我们提供了使用DNS配合在非80端口发布自动发现信息的方法。我想您不使用80端口发布自动发现信息的原因多数是因为您的ISA Server的内部IP要运行一个Web站点，那么这时您完全可以把这2个配置文件放到Web站点的主目录下，这样经DHCP发现的客户机会由ISA Server来提供配置文件的脚本，经DNS查询的客户机会由IIS（假设您的Web站点由IIS管理）提供配置文件的脚本。如果您不是因为发布Web站点而占用ISA Server内部IP的80端口，这种情况如何解决？我想这样朗月繁星也不必多说什么，有了上边的思路您应该可以解决！把配置文件放到网络内部的其他Web站点上就行，但是注意这时您的DNS的WPAD记录要指向这个Web站点的A记录，而且DHCP的252记录的String中不能使用 http://wpad:8080/wpad.dat，必须给出ISA Server的真实计算机名或FQDN，因为此时的Wpad对应的服务器（由DNS解析）不是ISA Server，而是您的Web Server，而Web Server没有在8080端口监听。换句话说漫游的用户有些是从ISA Server得到配置文件的，而有些是从Web Server上得到的。
话题三：不借助任何中心服务器支持ISA Server的“自动发现”功能
如果在你的站点中没有DNS和DHCP服务器，我们依然可以让客户机成功的发现ISA Server！
            在说这个话题前，请先来关注一下IE（Web代理客户端）和FWC默认的配置文件的URL。以下列出了他们的默认值
http://wpad.domainsuffix.net:80/wpad.dat      Web代理客户 http://wpad.domainsuffix.net:80/wspad.dat    FWC
什么时候客户端会使用这些默认值呢？非DHCP Client会直接引用默认值定位配置文件，也就是利用DNS上设置的WPAD记录。对于DHCP Client的Web代理客户端在发出Inform消息后，没有得到DHCP服务器包含252记录的响应时，就会使用 http://wpad.domainsuffix.net:80/wpad.dat 定位配置文件，这就必然需要进行DNS查询，这也就是图1中描述的为什么客户机配置了DNS才可能“发现”成功的原因。对于FWC就比较灵活了，在这个默认的URL的三个部分中：FQDN，Port，filename可以被分别引用，补充客户机得到的252记录的String中所缺少的部分。例如，DHCP服务器没有响应，或者252记录根本没有设置，又或者252记录根本没有设置String值，此时FWC会使用 http://wpad.domainsuffix.net:80/wpad.dat 定位配置文件；如果DHCP返回包含252记录String为 http://ISAServer.domainsuffix.net的消息，那么，FWC就会加上默认字段“wspad.dat”，使用 http://ISAServer.domainsuffix.net:80/wspad.dat定位配置文件。但特殊的情况是，即使DHCP返回String为 http://ISAServer.domainsuffix.net:80/wpad.dat的252信息时，FWC也会使用 http://ISAServer.domainsuffix.net:80/wspad.dat定位配置文件，你可以认为“wspad.dat”是固定的默认值！有关这些信息，您可以参考Q296591和Q260210这两篇Kb。
 了解上述内容后，在一个没有DNS和DHCP服务器的网络内支持“自动发现”就可以实现了。我们只要把ISA Server的计算机名修改为WPAD就可以了，这样客户机在定位配置文件时，就会利用NetBios的方式来解析ISA Server的计算机名WPAD，最终将可以读取到wpad.dat或wspad.dat文件。但是这种方法我并不建议。其一，一个健全的网络不应该没有DHCP和DNS服务器；其二，没有DHCP服务器就异味这你的客户机的IP地址是手动配置的，你如何保证当这台客户机从一个站点漫游到另一个站点时，这台客户机和当地的ISA Server的网络层是可以连通的？

Troubleshooting
如果你在配置自动发现后，客户机无法自动发现ISA Server，请从以下解决方法中找出故障原因。
1， ISA Server 是否成功发布了自动发现的信息？
您可以使用以下几种方法验证ISA Server 是否成功发布了自动发现的信息：
A， 使用netstat –na |find “80” 验证内部地址是否监听80端口
B，            使用ActivePort验证W3Proxy.exe是否监听80端口。ActivePort是一款免费软件，您可以从 http://www.ntutility.com得到
C，            直接在IE浏览器中访问WPAD或者WSPAD文件
如果您确认ISA Server没有正确发布自动发现的信息，您首先需要确定没有其他服务程序在80端口上监听，之后重新发布自动发现的信息，最后重新启动Web Proxy Server。在更改自动发现 配置信息后，您会收到一个是否启动相关服务的信息，我建议您选择手动重启动服务，这样您可以准确的知道您的配置生效的时间。
2， DNS和DHCP服务器以及配置了自动发现的客户机是否正常工作？
使用Sniffer或者Microsoft Network Monitor做网络分析。对于DHCP客户机您可以查看它是否发出DHCP Inform的消息，以及之后来自DHCP服务器的ACK消息中是否包含252记录的String值字段；为了验证DNS服务器是否工作正常，您可以使用上述的网络分析软件查看来自自动发现的客户机是否查询了wpad.domainsuffix.net，DNS服务器是否返回了正确的结果，您也可以使用NSLOOKUP wpad.domainsuffix.net命令验证。如果您发现客户机发出了响应的DHCP或DNS请求，那么发现失败的原因大多数因为你对DNS或DHCP做了不正确的配置，请按照上边的配置步骤重新配置DNS/DHCP服务器，之后重启动对应的服务；如果您发现客户机没有对相应的服务器发出正确的查询，请参考下面关于自动发现Bug的讨论。           

致微软公司――关于ISA Server 2000 自动发现机制的Bug
在测试自动发现的过程中，我也发现了一些Bug。具体的描述如下：
Bug1：客户机在查询wpad.domainsuffix.net后，会做缓存记录存储配置文件的服务器的FQDN，这个缓存的有效期并非结束于客户机重新引导计算机，而是结束于计算机（操作系统）认为自己处于的网络环境发生变化。计算机认为自己处于的网络环境改变由以下方面决定。客户机从与上次不同DHCP服务器得到IP地址（可能是用户的计算机漫游到另外一个站点）；客户机由IP自动获得变为IP手动设置或者反之。由此产生的问题如下：由于某种原因，您修改了ISA Server的计算机名称，或者您的ISA Server出现故障而迁移到另外一台服务器上，或者您希望为漫游的用户新增一台ISA Server 2000作为漫游用户的代理服务器。当然您会在DNS服务器上对相应的A记录和WPAD记录做修改。但是，即使这样，由于漫游的用户的操作系统缓存了wpad.domainsuffix.net对应的FQDN，所以这个用户（计算机）不会在查询wpad.domainsuffix.net得到新的ISA Server 2000的FQDN，故客户机就会发现失败或者无法使用您为漫游用户配置的新的ISA Server。如果客户端缓存的wpad.domainsuffix.net对用的主机已经不是ISA Server了，那么FWC会向DNS查询wpad.domainsuffix.net得到新的ISA Server的IP地址；然而Web 代理客户端不会向DNS查询wpad.domainsuffix.net，所以发现失败。
解决方法：使这些用户先漫游到另一个站点，由于客户机会从另一个DHCP服务器获得IP地址，也就是说客户机感知到自己的网络环境变化了，这时客户机会查询wpad.domainsuffix.net。之后，在迁移回原来的站点，这时客户机所处的网络环境又改变了，所以客户机会查询wpad.domainsuffix.net，从而您对网络内ISA Server设置和部署的一些改变会应用到客户机；另一种可行的办法是，修改客户机的IP设置变为手动，生效后再改变为自动获得IP地址，这样客户机很认为网络环境改变，从而查询wpad.domainsuffix.net，应用您网络的新设置！这里的解决方法实际上都是让客户端感知到网络环境改变，但是这两种办法都是比较低效率的。问题的症结就出在客户机会缓存对wpad.domainsuffix.net的查询，只要禁止这种缓存就可以解决。
Bug2：配置了自动发现的DHCP客户机在成功发现某站点的ISA Server后，当这个客户机漫游到其他的站点中时，如果这个站点没有配置DNS的WPAD条目（指利用DHCP的252记录），则客户机不能自动发现ISA Server，客户机必须重新引发“自动发现”。这里说的引发自动发现是指在IE浏览器失败后，点击Detect Network Settings（图8），或者在禁用FWC的Automatically detect ISA Server并再次启用。发生此错误的原因是，客户机漫游到另一站点时，它并不发送DHCP Infom消息给DHCP服务器，而是发出一个wpad.domainsuffix.net的DNS查询，由于这个站点中的DNS服务器上没有WPAD条目，所以查询失败。当客户机重新引发“自动发现”时，客户机才发出DHCP Inform的消息，故当DHCP服务器返回252记录的配置信息给客户机后，客户机发现成功。笔者认为这个Bug比较严重，因为漫游的计算机在不同的站点间漫游的时候，所有的站点中必须同时配置DNS和DHCP包含WPAD记录才能更好的支持“自动发现”特性，否则必须指导用户当无法浏览资源时（也就是自动发现失败），手动重新引发“自动发现”。
有关这些问题的说明，笔者从微软的支持站点中没有发现更好解决方案，所以希望微软公司能尽快解决这些问题。
声明：本文对于“自动发现”的分析，很多来源于笔者的网络分析（使用Microsoft Network Monitor和Sniffer Pro），这些分析在微软的帮助站点中，您可能找不到相关的主题。所以笔者不能保证这里的描述完全正确无误，尽管这些分析使用不同的计算机（服务器，客户机）并多次进行网络分析完成。如果您在测试和实施的过程中，发现和此文中的描述有不符，希望您能和我联系。