Problem: Installing ISA Server on 64-bit versions of Microsoft Windows Server 2003 operating systems is not supported.

Cause: ISA Server services do not run on 64-bit versions of Windows Server 2003 operating systems.

Solution: No workaround.

Problem: ISA Server 2004 Enterprise Edition should only be installed on computers running Windows Server 2003.

Cause: Running ISA Server 2004 Enterprise Edition on computers running Windows 2000 Server is not supported.

Solution: No workaround.

Problem: ISA Server 2004 Enterprise Edition should not be installed as a domain member in a Windows NT Server 4.0 domain.

Cause: Running ISA Server 2004 Enterprise Edition in a Windows NT Server 4.0 domain is not supported.

Solution: No workaround.

Problem: Installing ISA Server Firewall Client software on a computer configured as an Active Directory domain controller is not supported.

Cause: If Firewall Client software is installed, the domain controller may not function as expected.

Solution: No workaround.

Installing other firewall products on an ISA Server computer is not supported.  Attempting to create a layered firewall deployment on a single server by adding additional firewall products will result in unpredictable behavior and may cause the server to fail.

Problem: ISA Server does not support multiple external connections to the Internet.

Cause: ISA Server does not support configuring multiple connections on the External network adapter.

Solution: No workaround. There are a number of third-party products that may provide a solution. For more information, see High Availability and Load Balancing at the Windows Server System Web site.

Problem: ISA Server does not support multiple default gateways configured on the same network adapter, or on different adapters.

Solution: Set a default gateway on only one of the ISA Server network adapters. Do not configure more than one default gateway on that adapter. The default gateway is usually set on the network adapter associated with the ISA Server default External network.

Problem: There cannot be two network adapters in the same subnet. This may manifest itself in a number of ways:

• Error 15108. ISA Server detected a spoof attack from Internet Protocol (IP) address IP_address, when trying to access a network resource. For more information, see the Microsoft Knowledge Base article 840681, "Attempts to access published resources are logged as spoof attacks with event ID 15108 in ISA Server 2000."
  
• Error 14147. ISA Server detected routes through adapter adapter_name that do not correlate with the network element to which this adapter belongs. For more information, see the Knowledge Base article 884496, "Client computers cannot access external resources, and event ID 14147 appears in the Application log in ISA Server 2004."
  

Cause: When you define IP address ranges for a network, ISA Server checks all network adapters. When ISA Server finds an adapter with an IP address in the network range, it associates the network with that adapter. When a network includes remote subnets accessible by ISA Server through routers, the IP address of the remote subnets should be included in the network definition. If you define a separate network object for a remote subnet (instead of including it in the network definition), ISA Server tries to locate an adapter with an IP address of the network object, and fails. ISA Server assumes that the adapter is not available (disconnected or disabled), and sets network status to disconnected.

Solution: For specific solutions to the errors described in the Problem section, see the linked Knowledge Base articles. For best practice when defining your network configuration in ISA Server, ensure the following when defining subnets:

• Include all network ranges for subnets in a network object’s properties (for example, include subnet IP addresses in the IP address range for the Internal network).
  
• To apply rules to specific subnets, create subnet objects in the Toolbox, and use these to specify source and destination in access rules.
  

Problem: ISA Server does not support intradomain communications between networks with a network address translation (NAT) relationship.

Cause: There may be some circumstances in which you want to allow communication within a domain through ISA Server from one network to another. Typical scenarios include:

• A Web server located in the perimeter network that is a member of the internal domain needs to contact the domain controller in the Internal network.
  
• Applications or servers located in the perimeter network need to be accessed by internal clients.
  

Solution: Support for communication within a domain was not available in ISA Server 2000 (for information, see the Knowledge Base article 329807, "INFO: ISA Server Does Not Support Domain Members In Perimeter Network," which applied network address translation (NAT) on the address between the Internal and perimeter or External networks. ISA Server 2004 introduced the concept of multiple networks, and allows either route or NAT relationships to be defined between networks.

If networks have a NAT relationship, the limitation described in the Knowledge Base article 329807 still applies in ISA Server 2004. If networks have a route relationship, you can use either of the following methods to work around this issue:

• Create default routes on the local internal hosts for all remote internal subnets.
  
• Specify the local routers as the default gateway for computers located on the same subnet as the ISA Server internal interface. If you want to support requests from SecureNAT clients in the remote subnet or local subnet, specify the internal ISA Server interface as the default gateway of the router.
  

Problem: ISA Server uses the primary IP address of a network adapter when applying network address translation (NAT) to client requests. This may be an issue in Simple Mail Transfer Protocol (SMTP) scenarios.

Cause: When applying NAT to client requests to remote destinations, ISA Server calculates the IP address of the adapter to be used based on the TCP/IP routing mechanism (routing table). The address chosen is the same address as if ISA Server tried to create a connection (for example a TCP connection) with the server downstream. Generally this will be the primary IP address, where the primary IP address is the first address bound to the adapter interface (the default IP address). In a multiple IP address scenario, all other addresses are secondary. This is a problem in some scenarios. For example, all outgoing e-mail messages through ISA Server use the primary IP address of the ISA Server external adapter. Some receiving mail servers do a reverse lookup before accepting mail. If you have multiple mail servers with different Mail Exchanger (MX) records registered, and the primary IP address cannot be located in an MX record for your domain, e-mail messages may be rejected.

Note that this issue does not affect mail sent by Internet mail servers to your domain. In this case, a mail server doing a look up finds the MX record and the external IP address on which SMTP is publishing. The e-mail message arrives at ISA Server and is forwarded to the mail server.

Solution: In a NAT relationship there is no workaround. You cannot configure one-to-one NAT (as you can in server publishing). Instead, you must assign the IP address on the MX record as the primary IP address on the external network adapter. Alternatively, if appropriate you can configure a route relationship between the mail servers and the external network. Bear in mind that in a route relationship internal IP addresses are not hidden as they are in a NAT relationship.

Problem: There are a number of issues associated with the configuration of ISA Server on a computer with a single network adapter.

Cause: The causes include:

• Multi-network firewall policy. In single network adapter mode, ISA Server recognizes itself (the Local Host network). Everything else is recognized as the Internal network. There is no concept of an External network. The Microsoft Firewall service and application filters operate only in the context of the Local Host network. (ISA Server protects itself no matter what network template is applied.) Because the Firewall service and application filters operate in the context of the Local Host network, you can use access rules to allow non-Web protocols to the ISA Server computer. This has implications for running applications located on the ISA Server computer.
  
• Application layer inspection. Application level filtering does not function, except for Web Proxy Filter for Hypertext Transfer Protocol (HTTP), Secure HTTP (HTTPS), and File Transfer Protocol (FTP) over HTTP.
  
• Server publishing. Server publishing is not supported. Because there is no separation of Internal and External networks, ISA Server cannot provide the NAT functionality required in a server publishing scenario.
  
• Firewall clients. The Firewall Client application handles requests from Winsock applications that use the Firewall service. In a single network adapter environment, this service is only available in the context of the Local Host network (protecting the ISA Server computer), and Firewall Client requests are not supported.
  
• SecureNAT clients. SecureNAT clients use ISA Server as a router to the Internet, and SecureNAT client requests are handled by the Firewall service. In a single network adapter environment, this service is only available in the context of the Local Host network (protecting the ISA Server computer), and SecureNAT client requests are not supported.
  
• Virtual private networking. Site-to-site virtual private networks (VPNs) are not supported in a single network adapter scenario. Remote client VPN access is supported in a single network adapter scenario.
  

Solution: For a discussion of best practices, supported scenarios, and limitations, see Configuring ISA Server 2004 on a Computer with a Single Network Adapter at the Microsoft TechNet Web site. See also ISA Server online Help.

Problem: ISA Server supports dial-up connections to the Internet or a remote network using a modem connection or a virtual private network (VPN) connection. There are a number of limitations associated with a non-VPN connection.

Cause: This problem may occur because:

• You can only configure automatic dialing for a non-VPN dial-up connection on one network.
  
• ISA Server does not support customized routes. For example, if ISA Server dials a non-VPN connection to a remote network that is not the default gateway, this requires a custom route to the remote network. ISA Server 2004 overwrites Routing and Remote Access settings with its own settings. ISA Server creates and controls Point-to-Point Tunneling Protocol (PPTP) over Layer Two Tunneling Protocol (L2TP) interfaces, overwriting changes made in Routing and Remote Access. If modem connections are created in Routing and Remote Access, ISA Server deletes them.
  
• ISA Server uses the local domain table (LDT) to determine whether a request is to an internal computer (in the LDT) and whether dialing out is required. There may be an issue with connections being constantly dialed if clients make a dial-up request for a URL that is not defined in the LDT.
  

Solution: Several solutions are available:

• If automatic dialing is used to connect directly to the Internet, you should select the External network for the automatic dial-up connection. You can also configure automatic dialing to connect to a branch office, or to a specific location in your organization.
  
• In ISA Server 2000, you could use Routing and Remote Access to add a demand-dial interface for the connection and create a static route for the connection. This configuration is not available in ISA Server 2004.
  
• You can control whether the dial-up connection is dialed for DNS purposes. For more information, see the Knowledge Base article 901109, "The dial-up connection to a remote network is continually dialed when a client computer makes a request for a URL that is not defined in any LDT in ISA Server 2004."
  

Problem: Routing and Remote Access settings are overwritten by ISA Server. Demand-dial interfaces created with Routing and Remote Access are deleted.

Cause: Remote access settings must be specified using ISA Server Management. Any demand-dial interfaces created or modified using Routing and Remote Access that do not match networks in ISA Server are overwritten and deleted by ISA Server. Note the following limitations when creating demand-dial interfaces using the VPN Wizard:

• ISA Server does not support the assignment of a persistent connection, and persistent connections you assign in Routing and Remote Access are deleted. This may be an issue if you want a VPN connection to configure automatically when the server comes online, rather than waiting for traffic to trigger the interface to dial.
  
• ISA Server does not allow creation of multiple VPN connections to a particular network using different metrics. Such functionality allows more than one route to a particular network, so that if a primary route goes down, a backup route with different metrics is available.
  
• ISA Server does not allow you to disable or enable specific services or network components on a specific VPN interface.
  
• You cannot configure the number of redial attempts the VPN connection makes.
  
• ISA Server does not allow modem demand-dial interfaces.
  

Solution: For more information about solutions, see the following Knowledge Base articles:

• 837353, "Configuration changes that are made to Routing and Remote Access when you install ISA Server 2004"
  
• 842639, "Redial attempts and Average redial interval settings are reset in Routing and Remote Access service"
  

ISA Server default policy takes precedence in the ordering list of Routing and Remote Access policies. To put another remote access policy above the ISA Server policy, do the following:

1. At the command prompt, type net stop ISACTRL.
   
2. Change the policy order.
   
3. At the command prompt, type net start ISACTRL.
   

Problem: ISA Server 2004 Standard Edition does not support NLB. For more information, see the Knowledge Base article 884319, "ISA Server 2004 Standard Edition does not support NLB functionality."

Cause: Support for NLB is targeted at ISA Server 2004 Enterprise Edition, which addresses the concept of an array of ISA Server to share traffic and load.

Solution: To use NLB, install ISA Server 2004 Enterprise Edition.

Problem: When ISA Server 2004 Enterprise Edition is running on a computer with a single network adapter, there are limitations.

Cause: If ISA Server is running on a computer that does not have Windows Server 2003 with Service Pack 1 installed, more than one network adapter is required.

Solution: There are two possible solutions:

• If you are running ISA Server on a computer that does not have Windows Server 2003 with Service Pack 1 installed, you must install a second network adapter to be used for intra-array communication. NLB must be configured on an adapter with a static IP address. Ensure that you choose the IP address for the intra-array adapter from the intra-array network, and not the Internal network.
  
• If you are running ISA Server on a computer that has Windows Server 2003 Service Pack 1 installed, you do not need a second adapter for intra-array communications, because Service Pack 1 makes changes to the NLB stack.
  

Problem: ISA Server 2004 Standard Edition (without Service Pack 1) does not support Internet access requests from remote VPN clients through Web proxy on the ISA Server computer to which VPN remote clients are connecting. This issue is fixed in ISA Server 2004 Standard Edition Service Pack 1 and ISA Server 2004 Enterprise Edition.

Cause: Such client requests come from the VPN tunnel interface, and not from the Internal network interface. Web proxy NAT functionality cannot handle such requests.

Solution: Install ISA Server 2004 Standard Edition Service Pack 1.

Problem: In ISA Server 2004 Enterprise Edition, using a Dynamic Host Configuration Protocol (DHCP) server to assign IP addresses for VPN remote clients is only available in a single server ISA Server array.

Cause: This option is only available in ISA Server 2004 Standard Edition, or in ISA Server 2004 Enterprise Edition with a single array member. This limitation applies for the following reasons:

• When an array consists of more than one member and NLB is disabled, there are routing problems for DHCP address allocation.
  
• With NLB enabled, DHCP address assignment causes performance and scaling issues. This is because of the amount of routing rules and remote procedure call (RPC) communication required to deliver IP addresses to clients using DHCP.
  

Solution: Use static pool address assignment whenever there are multiple array members.

Problem: Do not enable user mapping when using Challenge Handshake Authentication Protocol (CHAP), Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), MS-CHAP version 2, or any type of Extensible Authentication Protocol (EAP) authentication if ISA Server and the Remote Authentication Dial-In User Service (RADIUS) server are in different domains, or one of them is in a workgroup. When you configure VPN remote client access, VPN client properties include the User Mapping tab. In these scenarios, user mapping is only supported for Password Authentication Protocol (PAP) and Shiva Password Authentication Protocol (SPAP) authentication methods.

Cause: You select Enable User Mapping to map VPN remote users connecting with non-Active Directory directory service credentials (such as a RADIUS user) to Windows accounts. This feature enables you to apply access rules that use Windows groups and users to apply to other users. When RADIUS is authenticated with CHAP, MS-CHAP, MS-CHAP version 2, or any type of EAP, the domain specified in the user mapping is used to match the VPN client to a mirrored Active Directory account. When PAP or SPAP is used, the domain name is always ignored, and the VPN client can be matched to an Active Directory account in the local domain where ISA Server is a domain member, or to a local user account on the ISA Server computer in a workgroup configuration.

Solution: To use CHAP, MS-CHAP, MS-CHAP version 2, or EAP, make ISA Server a domain member.

Problem: Outbound L2TP connections without IPsec are not supported when ISA Server is configured as a VPN server that uses the L2TP/IPsec protocol.

Cause: By default the following settings apply:

• Network address translation (NAT) is applied to outbound traffic from the Internal, VPN Clients and Quarantine VPN Clients networks to the External network.
  
• When ISA Server is configured as a VPN server that uses the L2TP/IPsec protocol, traffic to and from the L2TP protocol port (UDP port 1701) is secured by IPsec.
  

With these default settings, the outbound L2TP client request is sent from the NAT address (usually the address of the ISA Server external network adapter) and the external VPN server responds to this address. ISA Server does not forward the L2TP traffic from the external VPN server to the client because no matching IPsec policy exists.

Solution: Use PPTP for outbound VPN connections, or do not use the L2TP/IPsec protocol when ISA Server is configured as a VPN server.

Problem: Customization of forms-based authentication pages is not supported in ISA Server 2004.

Cause: Forms-based authentication can be enabled on the Microsoft Office Outlook Web Access Web site, or on the ISA Server computer. When you enable this authentication method on ISA Server, the Logon.asp form runs on the ISA Server computer. It is possible to customize the form for specific requirements, but such customization is not supported on ISA Server 2004. Modifying pages on the Exchange server running Outlook Web Access will have no effect on forms-based authentication enabled on the ISA Server computer.

Solution: If problems arise as a result of such customization in ISA Server 2004, the original files should be restored. For more information, see the Knowledge Base article 327178, "Microsoft support policy for the customization of Outlook Web Access for Exchange." Customization is supported in ISA Server 2006.

Problem: There are a number of limitations to be aware of when enabling RSA SecurID authentication on ISA Server:

• When you configure RSA SecurID on a Web publishing rule, no other form of authentication can be enabled.
  
• Outlook Web Access cannot be configured to use SecurID credentials. ISA Server can forward the cookie to the Outlook Web Access server, but the server will not do anything with it.
  

Cause: When you publish an Outlook Web Access server and enable RSA SecurID on ISA Server, with forms-based authentication on the Exchange server, the following occurs:

• Users will be prompted for an RSA SecurID password and PIN by ISA Server.
  
• After being authenticated by ISA Server, users will be prompted by Exchange with the forms-based authentication page.
  
• You cannot configure a single sign-on, because RSA SecurID cannot pass credentials to the Outlook Web Access server. The Exchange server cannot identify the mailbox being accessed if SecurID credentials do not match an Exchange or Active Directory account.
  

Solution: There is no workaround for this limitation. Either users will be prompted multiple times for credentials, or you must use a different authentication scheme.

Problem: When a publishing configuration requires redirection to a different port number, ISA Server 2004 appends the port number to the host header. For example:

• If you listen for Web requests on port 81 and the Web publishing rule for www.contoso.com sends requests to domain.site.internal, which is listening on port 80, the host header sent to domain.site.internal will be www.contoso.com:81.
  
• In an HTTPS-to-HTTP bridging scenario, you publish a Web site over a Secure Sockets Layer (SSL) connection. The host header is forwarded to the back-end Web server as <hostheader>:443.
  

This behavior may be an issue where Web applications build links dynamically based on the host header. This behavior did not exist in ISA Server 2000.

Cause: This is by design for the link translation functionality of ISA Server 2004. In theory, the back-end server should place the external port (in the example, port 443) in dynamic links created on the Web server, because this is the port to which external clients connect.

Solution: There are two possible solutions:

• Add a mapping to the link translation dictionary to replace www.contoso.com:81 with www.contoso.com. In this case, the host header in the request will be changed to www.contoso.com. This is inefficient, because every time the client clicks a link, a redirect is required.
  
• Disable the option to forward the original host header to the server, and enable link translation (without making any addition to the dictionary). In this case, the server will build links according to the internal name. ISA Server will use link translation to translate all internal links to the external name (including the port number).
  

Problem: Only one SSL server certificate can be bound to a Web listener.

Cause: The name of the Web site specified in the external user request must use the name of the site listed on the common name of the certificate. For example, if users will access www.contoso.com, the common name on the certificate must be www.contoso.com. If you try to use the listener to publish another secure site, it will not succeed because the certificate name will not match the user request name.

Solution: To publish multiple SSL sites using the same IP address and port where all sites published use the same domain name, you can use a wildcard character certificate. For example, to publish sites OWA, WebSite1, and WebSite2 at contoso.com, you can acquire a wildcard character certificate (*.contoso.com) for the ISA Server computer. Note that ISA Server only supports wildcard character certificates on the ISA Server computer. In an HTTPS-to-HTTPS bridging scenario, you cannot use a wildcard character certificate to authenticate to the back-end Web server.

Problem: RPC over HTTP traffic encrypts the RPC data in HTTP. RPC over HTTP data is not inspected by ISA Server 2004.

Cause: In regular Web publishing scenarios, ISA Server can inspect the HTTP headers and body. However, the RPC filter designed to inspect RPC traffic cannot inspect RPC over HTTP requests, and does not protect against RPC exploits reaching the Exchange server. In outbound scenarios, RPC over HTTP requests over SSL are tunneled, and no inspection takes place of the HTTP headers or body following the initial connection.

Solution: Deploy RPC over HTTP with this limitation in mind. For configuration information for this scenario, see the Knowledge Base article 884506, "How to configure ISA Server 2004 to allow for RPC over HTTP client connections from Office Outlook 2003 to Exchange Server 2003, and see Using ISA Server 2004 Enterprise Edition with Exchange Server 2003 at the Microsoft TechNet Web site.

Problem: Running Live Communications Server on the ISA Server computer is not supported.

Cause: This is an untested scenario.

Solution: No workaround.

Problem: Not all Live Communications Server functionality works through ISA Server 2004.

Cause: The following limitations apply:

• Communication between two clients on the same side of the ISA Server computer should work in a simple internal network configuration.
  
• Presence and instant message is essentially a client/server application, where the server mediates the communication between the two clients. This avoids NAT issues that arise when an external client needs the IP address of the internal client. Instant text messaging from an internal client to an external client can go out through Web proxy.
  
• Audio, video, and whiteboard features use SIP/SIMPLE. ISA Server does not have a SIP application filter at this time to handle such traffic. The only exception is if the session is initiated by an external Internet client that is not behind a NAT device.
  

Solution: There is no workaround for these limitations at this time.

Problem: The following limitations apply:

• ISA Server cannot publish secure File Transfer Protocol (FTP).
  
• ISA Server does not support outbound FTP over SSL/TLS (FTPS) connections.
  

Cause: The following causes apply:

• FTPS uses an encrypted control channel. For standard FTP traffic, ISA Server uses the FTP application filter to monitor FTP communications between the client and the server. Outbound SSL connections, such as FTPS, cannot be seen by ISA Server, and therefore ISA Server cannot adjust traffic policy in reaction to PASV and PORT FTP commands.
  
• Server publishing tunnels SSL traffic, and therefore such traffic is not inspected by ISA Server.
  

Solution: There is a specific workaround available that allows you to publish secure FTP. For more information, see Publishing Secure FTP Servers behind ISA Firewalls at the ISAserver.org Web site.

Problem: The following limitations apply:

• You cannot use FTP upload from a Web Proxy client. Remote directory and file management actions also fail.
  
• You cannot use third-party, non-browser FTP applications or command-line FTP tools. Web Proxy clients tunnel FTP requests over port 80. You require SecureNAT clients or Firewall clients to use these tools.
  
• To access FTP sites that are not anonymous, you will need to enable folder view in Internet Explorer. This causes Internet Explorer to prompt for credentials. Credentials should be specified in the following format: ftp//username:password@FTP_Server_Name.
  
• By default, ISA Server uses PASV mode for FTP requests. If this mode is not supported by the FTP server you want to reach, you will need to disable folder view in Internet Explorer. This allows Internet Explorer to send PORT commands.
  

Cause: FTP uploads are not supported for client computers configured as Web Proxy clients only.

Solution: There is no workaround for these limitations at this time. For more information about troubleshooting outgoing FTP access, see Troubleshooting Outbound FTP at the ISA Server TechCenter.

Problem: ISA Server is not a router and does not directly support routing protocols such as Routing Information Protocol (RIP) or Open Shortest Path First (OSPF).

Cause: ISA Server has no built-in support for these dynamic routing protocols.

Solution: You can install Routing and Remote Access on the ISA Server computer as a LAN router, to allow it to listen for OSPF announcements and handle routing protocols communications. You will need to create access rules to allow such traffic. Create a custom protocol object for the routing protocol, and then allow traffic for the protocols to and from neighboring routers, and the ISA Server computer. OSPF supports fragmented packets, and you should not filter IP fragments on ISA Server.

Problem: When ISA Server 2004 is installed, Remote Installation Services (RIS) takes an extreme length of time to deploy an image.

Cause: If this only occurs for clients on a remote subnet, you may need to change a registry entry. RIS uses Trivial File Transfer Protocol (TFTP). ISA Server has a predefined protocol for TFTP. The predefined protocol has a secondary connection defined as all User Datagram Protocol (UDP) ports, but this will only work when Firewall Client is installed on the client computer.

Solution: Use the following workaround:

• Open the complete range of UDP ports from the client to the TFTP server.
  
• Open the complete range of UDP ports from the TFTP server to the client.
  

Microsoft ISA Server and Forefront TMG are supported on hardware virtualization in accordance with the following programs:

• Microsoft Support Lifecycle
  
• Microsoft ISA Server system requirements
  
• Forefront TMG system requirements
  
• Microsoft Server Virtualization Validation Program (SVVP)
  
• Support Policy for Microsoft software running on non-Microsoft hardware virtualization software
  

For example, if a hardware virtualization platform is listed as ”validated” with the SVVP (not “under evaluation”), Microsoft ISA Server and Forefront TMG will be supported for production use on that platform within the limits prescribed in the Microsoft Product Support Lifecycle, Non-Microsoft hardware virtualization policies and the system requirements for that product version and edition.

For hardware virtualization platforms not listed with the SVVP, Microsoft ISA Server and Forefront TMG are supported in accordance with remaining Microsoft support policies, limited as follows:

• Desktop virtualization, such as Microsoft Virtual PC or similar 3rd-party product: supported for demonstration and educational use only
  
• Server Virtualization, such as Microsoft Virtual Server or similar 3rd-party product: supported, but not recommended for production use
  

Important: As stated in KB 897615, Microsoft support engineers may request that a customer reproduce a reported problem on real hardware or within an SVVP-listed hardware virtualization platform before continuing with the case. If the problem cannot be reproduced in hardware or on SVVP-listed server virtualization product of similar class, the case may be deferred to the 3rd-party vendor product support.

Problem: The ISA Server SMTP Message Screener component may interfere with Exchange Server 2003 functionality.

Cause: The ISA Server SMTP Message Screener component is designed for filtering e-mail messages based on keywords or attachments, or blocking e-mail messages from specific senders or domains. It works together with the SMTP filter to intercept all SMTP traffic arriving on TCP port 25 of the ISA Server computer. We do not recommend that you use the Message Screener component with Exchange Server 2003. Message Screener may interfere with the functioning of the Exchange Server 2003 Connection and Recipient Filtering function.

Solution: The SMTP filter can be used with Exchange Server 2003. For more information, see Installation and configuration of the SMTP filter and Message Screener are described in the document Using the ISA Server 2004 Enterprise Edition SMTP Filter and Message Screener.

Problem: IPv6 traffic passes through ISA Server firewall regardless of firewall policy.

Cause: Filtering of IPv6 traffic is not supported.

Solution: We recommend that you not enable IPv6 traffic on the ISA Server computer or array members. If you have enabled IPv6 traffic, we recommend that you disable it. To disable the IPv6 stack on the ISA Server computer or array member, type the following at a command prompt:

netsh interface ipv6 uninstall

Alternatively, you can disable the IPv6 stack in the Windows user interface:

1. On the ISA Server computer or array member, from the Start menu, point to Settings, and click Control Panel.
   
2. In the Control Panel, double-click Network Connections.
   
3. Double-click a network connection that is associated with a network adapter, and click Properties.
   
4. On the General tab, from the list box, select Microsoft TCP/IP version 6, and then click Uninstall. In the Warning dialog box, click Yes to process.
   
5. Click OK to close the Network Connection Properties.
   
6. Restart the ISA Server computer or array member.
   

Problem: The Web Cache Communication Protocol (WCCP) and the Internet Cache Protocol (ICP) are not supported in ISA Server.

Cause: Unsupported.

Solution: No workaround.

Problem: You may experience problems such as unexpected delays, incomplete pages, or random authentication warning messages, when you browse the Web in a chained configuration. This can occur when the following conditions are true:

• The downstream ISA Server computer is configured to require integrated (NTLM) authentication.
  
• No authentication is required (anonymous) on the upstream Web proxy server.
  
• Internet Explorer is the client browser.
  

This behavior does not occur if the upstream proxy requires NTLM authentication and the routing rule on the downstream server is configured to provide NTLM credentials to the upstream Web proxy server.

Cause: Internet Explorer may send an extraneous NTLM authentication header on a connection that has already been authenticated with the downstream ISA Server computer using integrated authentication. This may cause the downstream ISA Server computer to pass those credentials to the upstream Web proxy server. These credentials are not intended for the upstream proxy, and it may cause delays and responses because it is unable to process the NTLM credentials. The downstream ISA Server computer passes this response to the Web browser, which may cause symptoms such as delays and authentication warning messages.

Solution: For workarounds, see the Knowledge Base articles 883285, "Users are repeatedly prompted for their credentials when they try to access the Internet after you configure a firewall chain between ISA Server computers" and 810561, "RemoveAllProxyAuthorization Not Applied to SSL Tunneling (CONNECT) Requests."

Problem: A Web Proxy client browser cannot connect to the Web listener over an SSL connection.

Cause: This is a browser limitation. Internet Explorer does not support certificate authentication to a Web proxy. On the Web Proxy tab of a network’s properties page, there is an option to Enable SSL. This option is only for use in a Web Proxy chaining scenario. In this case, you can configure a downstream ISA Server computer to forward Web requests to an upstream proxy over an SSL connection. This allows you to bridge HTTP traffic as HTTPS to the upstream server.

Solution: Do not use an SSL connection.

Problem: Web Proxy client requests cannot be authenticated using a client certificate.

Cause: The Web Proxy client browser does not establish the SSL connection with ISA Server 2004. Rather, the Web browser establishes an end-to-end SSL connection with the Web server computer, and ISA Server does not examine the packets inside the encrypted tunnel.

Solution: No workaround. Note that ISA Server can use a client certificate to authenticate against an upstream ISA Server computer. In this scenario, you can bridge an SSL connection between a downstream ISA Server computer and an upstream ISA Server computer.

Problem: ISA Server access rules cannot authenticate based on computer account. For example, to allow a specific user working from home full access from a corporate laptop, but limited access from a home computer.

Cause: ISA Server can only use a computer account for rule authentication in very specific circumstances. ISA Server evaluates authentication conditions for a rule from the settings on the User tab of the rule, and identifies the computer from which a request originates from the From tab. A rule is evaluated and applied if all the rule's conditions are met. Within a particular tab, a rule is applied if any of the conditions are met. For example, if the Users tab indicates that authentication applied to 3 groups, then a user only needs to belong to one of the groups in order for the rule to be applicable.

On the Users tab, ISA Server allows you to specify users, groups, and security principals to be authenticated on a rule. However, if you specify a computer account on the User tab, only applications running under the Local System or Network Service account on the specified computer will be authenticated - when the specified computer authenticates to a domain controller using Kerberos. This can occur when the Web proxy listener of the ISA Server is enabled for Windows Integrated authentication, and the client supports Kerberos authentication (for example Internet Explorer 7.0).

You specify a computer account (DomainName\ComputerName$) on the User tab. With this setting, any service (running under the Local System account or the Network Service account) that runs a Kerberos-enabled client will be authenticated, and access allowed or denied in accordance with the rule settings. Note that the source network object on the From tab of the rule must include the IP address of specified computer. If only a domain users group is specified on the Users tab, then authentication of the client browser using the computer account is not applicable for the rule. If a rule has both a domain user group and a computer accounts group specified, then at least one of the User conditions must be met. The request must be able to succesfully authenticate using the user account or the computer account.

Solution: One workaround to differentiate remote clients by computer might be to use a VPN solution, as follows:

1. Create an access rule from the VPN Quarantine Clients network to the destination network. The VPN Quarantine Clients network will include the home computer. Specify a more limited access policy in this rule, and optionally, add a user account to the Users tab. The VPN Quarantine network must be enabled, and ensure that the disconnection time is not specified (this is the default setting) .
   
2. Create an access from the VPN Clients network to the destination network. The VPN Clients network will include the corporate laptop. Specify a more permissive policy on this rule, and user accounts as required.
   

For this solution to work you must include the Quarantine solution on each of the corporate computers.

Problem: LDAP authentication is not supported in outbound Web access scenarios.

Cause: In ISA Server 2006, LDAP authentication is available only as an authentication method in reverse proxy Web publishing scenarios. LDAP authentication is not available in ISA Server 2004.

Solution: No workaround.

Problem: There are a number of limitations when running the Microsoft Management Console (MMC) snap-in console, ISA Server Management.

Cause: The causes include:

• You cannot run ISA Server 2000 ISA Server Management snap-in console and ISA Server 2004 ISA Server Management snap-in console on the same computer.
  
• You can install ISA Server 2004 ISA Server Management snap-in console on the same computer as ISA Server 2000 Firewall Client.
  
• You cannot install ISA Server 2004 Firewall Client together with ISA Server 2000 ISA Server Management snap-in console.
  
• You cannot run ISA Server Management snap-in console for ISA Server 2004 Standard Edition on the same computer as ISA Server Management snap-in console for ISA Server 2004 Enterprise Edition.
  

Solution: There is no workaround at this time.