专栏作品
深入探讨ISA Server的自动发现特性
吕劼
ISA Server是Microsoft开发的用于替代Microsoft Proxy Server2.0的最新代理服务器和防火墙产品，其强大的功能及易用性给不同规模的企业带来的很多显而易见的好处。因此，ISA Server也正在逐步的成为很多企业，特别的基于Microsoft网络的企业的首选代理服务器和防火墙产品。今天，朗月繁星想和大家一起来深入的研究一下ISA Server中的自动发现（AutoDiscovery）特性。 在一个全球性的企业里，网络覆盖全球的很多城市，在每个城市里或者站点里有很多ISA Server或者是ISA Server的阵列（Array）。工作在这个企业的员工有很大一部分是使用笔记本电脑来访问位于公司其他站点或者是Internet上的资源，我们知道如果一台客户机要访问位于ISA Server外端的资源就必须成为ISA Server的三种客户端之一，要么是SNAT客户端，要么是Web代理客户端，要么是Firewall Client客户端（以下简称FWC）。三种客户端的共同之处是要明确自己的代理服务器的位置，也就是要知道代理服务器的IP地址。然而，当一个移动用户从一个城市或者站点出差（漫游）到另外一个城市或者站点的时候，你该如何配置这些客户机使他们无障碍地访问Internet的资源？换句话讲你将做什么样的配置使这些移动的客户机顺利的找到提供代理服务的ISA Server？ 我想读到这里的朋友可能已经猜到了，是的，没错！就是利用ISA Server的自动发现（AutoDiscovery）特性！这是一个令人振奋的功能，下面朗月繁星就来谈谈支持自动发现（AutoDiscovery）特性所涉及的一些技术要素。 如果您急于在网络中实现ISA Server的自动发现功能，你或许不需要了解过多的技术细节和讨论。这样，你可以直接参考设置“自动发现”之实施篇。 在此文中说的客户机和客户端是有区别的，客户机指用户使用的计算机，他可能使用Windows9x,Windows NT/2000或者其他Microsoft的操作系统，甚至是Linux；客户端指客户机操作系统上的某种应用程序或某种配置，例如，我们可以给Internet Explorer（以下简称IE）配置一个代理的信息，使之成为Web代理客户端；或者给用户的操作系统配置IP地址，网关以及DNS，这样这个操作系统就可以作为 SNAT客户端；如果您安装的ISA Server光盘中的Firewall Client，则运行在用户的操作系统上的网络应用程序的Winsock请求就会被FWC截获，从而做为ISA Server的FWC客户端。换句话说，客户机上可能存在多种客户端。此外，文中的domainsuffix.net指您的网络的DNS命名空间或者是您网络的域名称。在具体配置“自动发现”时，注意以您网络的所用的名称来代替domainsuffix.net。 自动发现（AutoDiscovery）特性的定义 自动发现是使ISA Server的客户端在不知道ISA Server的具体位置（IP地址）的情况下，通过网络上的其他网络服务来自动的发现ISA Server的IP地址及端口（Web代理客户需要知道提供Web代理服务的端口）的特性。 何种的客户端可以利用自动发现（AutoDiscovery）特性 我们知道ISA Server有三种客户端类型，在这3中客户端类型中，只有Web代理客户端和FWC可以利用自动发现（AutoDiscovery）特性，SNAT客户端不行！而且对于客户机使用的操作系统也有一定要求，客户机的OS必须是下面列表中的一种： Windows98 Windows ME Windows 2000 Windows XP 注意：不包含WinNT和Win95（Win95可以利用DHCP服务器发现ISA Server） 自动发现（AutoDiscovery）特性的机制讨论 之所以Microsoft称之为自动发现，足以证明ISA Server 的客户端在不经过“发现”这一过程前，是不知道代理服务器的具体位置的。那么，不难推断，在“发现”这一过程中，客户机肯定不是向ISA Server 来查询，所以就我的知识范围来讲，我想只有2种可以使用的方法来查找代理服务器ISA Server ：一个是通过发送广播，另外一个是向某个公共的中心服务器来查找这个信息。最终Microsoft采取了后者，我想这也是明智之选，因为以广播的方式查找，对于网络的利用极其不利。以太网中广播是任何网络管理员应该避免的问题，说广播是网络杀手，我想不会有人有异议！在一个LAN（或者VLAN）中，所有节点都处于一个广播域，所以，当其中一个节点发送广播数据帧时，任何处于这个广播域的所有其他节点都会处理这个帧，尽管这个帧对于很多节点都是毫无意义的。如果在一个包含一个非常的大的冲突域的基于CSMA/CD的以太网中，广播会导致处于这个冲突域的其他节点，无法“抢夺”到传输介质，而导致暂时无法发送和接受其他数据的情况，直到这个广播被所有节点处理完成。 现在我们就来谈谈ISA Server的客户端是如何向中心服务器来查找代理服务器ISA Server的。这个中心服务器的角色可以是DNS，也可以是DHCP，或者是其两者（请放心，两者同时利用不会产生任何冲突，而是会提高发现ISA Server的机率）。Web代理客户端和FWC都可以利用DHCP和DNS来发现ISA Server。没有FWC只能使用其中之一（指DNS和DHCP），或者Web代理客户只能使用其中之一这样的限制。正是由于没有这样的限制，所以最终Web代理客户和FWC究竟是从DNS还是从DHCP来“自动发现”ISA Server的始终是我们困惑的问题。所以，朗月繁星分以下几种情况分析说明。 如果客户机不是DHCP Client，那么不论的Web代理客户还是FWC都是不能通过DHCP服务器“自动发现”ISA Server的，那么就只能利用DNS服务器。向DNS查询的条件就是：客户机配置了DNS。如果DNS服务器上的WPAD记录配置正确，则查询成功；如果DNS服务器没有配置DNS或者错误配置了WPAD记录，则查询失败。如果客户机是DHCP Clinet，这种情况，客户机具备从DNS和DHCP“自动发现”ISA Server，但至于是否可以完成“自动发现”要看DHCP和DNS服务器的设置。执行的过程如下，DHCP Client在引发“发现”这个过程时，它会向自己的DHCP服务器发送Inform消息，当DHCP服务器收到这个信息后，会给客户机发送ACK信息，这个信息告诉客户机到什么位置去得到配置信息的文件，这个配置文件的作用就是把客户机配置成为Web代理客户端或者是FWC，配置成功后，客户机就可以通过ISA Server来访问特定的资源了。如果DHCP服务器上没有配置252记录（也就是用于支持自动发现特性的252记录），但客户机配置了DNS，则客户机就会向DNS服务器查询wpad.domainsuffix.net，如果DNS配置了WPAD记录，则“自动发现”成功，如果DNS服务器没有配置WPAD记录，则“自动发现”失败。若客户机根本没有配置DNS，那么也会失败。这里还有一点要注意，如果DHCP服务器虽然配置了252记录，但是配置有错误，那么客户机也不会在向DNS服务器查询，所以，结果还是会失败！有关上边的论述，我做了一张流程图，如图1，大家可以参考。
(图1) 现在，我们假设客户机成功的“发现”了ISA Server。您可以不用去想客户机是不是DHCP Client？从哪里发现的，DNS还是DHCP？因为这不是我们接下来要讨论的重点。刚才我说客户机成功地“发现”了ISA Server，实际上并不准确，因为客户机实际上不是发现了ISA Server，而是发现了配置文件的位置（存储这个配置文件的服务器叫做WPAD Server），而配置文件在ISA Server的自动发现体系里，其宿主恰巧正是ISA Server。DHCP和DNS只是告诉了这个文件的位置，而这个配置文件是否可以访问就要看ISA Server的设置了，换句话说ISA Server要将这个配置文件发布，这个设置的过程也就是发布“自动发现”信息（详见设置“自动发现”之实施篇）。写到这里可能有人要说话了，配置文件是干什么用的？DNS或者DHCP告诉客户机的不是包含ISA Server的IP地址了么，那不就等于发现ISA Server了吗？问的好，朗月繁星起初也有这样的疑问。因为要成为ISA Server的客户端我们就必须配置客户机，例如我们在IE中配置代理服务器和端口，或者在FWC程序中填写ISA Server的计算机名（或者IP）这一过程。这些都是我们人为配置的，如果启用了自动发现，那么这些类似的工作由谁来完成？就是由配置文件完成。唯一不同的就是你在IE，FWC等这样的客户端上看不到像用手工配置那样的痕迹，但是这些由配置文件自动配置的信息已经生效了！再说第二个问题，DHCP和DNS反馈的信息虽然包含了ISA Server的IP，但是这并不是告诉客户机谁是你的代理服务器。你可以想象你下你手动配置IE浏览器成为Web代理客户的情景，除了填写ISA Server的IP或者计算机名，是不是还要填写一个端口（默认是8080），如果DHCP和DNS告诉客户机的是代理服务器的信息，那么对于IE浏览器，代理的端口（就是上边谈到的8080）怎么办？要知道DNS和DHCP返回给客户机的唯一信息就是ISA Server的IP地址或者主机名（DHCP返回ISA Server的主机名或者FQDN；DNS最终会返回ISA Server的IP地址）。再一个可以说服你DHCP和DNS返回的信息是配置文件的位置而不是代理服务器信息的例子是：FWC配置时，只需要ISA Server的IP或者计算机名，而像IE浏览器这样的可以成为Web代理客户端的程序，除了要知道代理服务器的IP或者计算机名外，还要知道代理服务的端口。显然FWC从DNS和DHCP那里知道代理的端口没有任何用处，而IE不知道这个端口又不行！归根结蒂，明白下面一点是很重要的：ISA Server在“自动发现”这个功能里担任2种角色，其一是传递配置文件给客户端（IE或者FWC），也就是充当WPAD服务器；其二是作为客户端的代理服务器。 设置“自动发现”之实施篇 1， 设置客户机使用“自动发现”功能 A， 设置FWC使用“自动发现” 双击“My Computer”，打开“Control Panal”，双击Firewall Client,选中Automatically detect ISA Server ，如图2
(图2) B， 设置Web代理客户端，以IE为例 打开IE，单击Tools，选Internet Option，找到Connections选项卡，单击LAN Setting，选中Automatically Detect Settings，如图3。
(图3) 其他的就不要选择了，尤其是Proxy Server子设置一栏。如果你注意到这个对话框中那段提示文字就不难理解了，这段文字的意思是说：自动配置也许会覆盖手动的设置（Proxy Server子栏的设置），要明确使用手动设置，请禁止使用自动配置。 2， 设置中心服务器 A， 设置DNS服务器 打开DNS服务管理器，找到你的网络对应的Zone（DNS命名空间），请确认您的区域文件中包含ISA Server的A记录。之后，建立一个指向这个A记录的CNAME记录，名称为WPAD且必须是WPAD，因为不论Web代理客户还是FWC，都会使用wpad.domainsuffix.net这个FQDN向DNS服务器查找支持“自动发现”的信息。配置信息的填写参考如图4
(图4) B， 设置DHCP服务器 打开DHCP服务管理器，单击DHCP服务器，单击Action | Set Predefined Options，出现图显示的对话框，单击Add，输入如下信息：（如图5）
(图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），这些分析在微软的帮助站点中，您可能找不到相关的主题。所以笔者不能保证这里的描述完全正确无误，尽管这些分析使用不同的计算机（服务器，客户机）并多次进行网络分析完成。如果您在测试和实施的过程中，发现和此文中的描述有不符，希望您能和我联系。
