Publishing Exchange Server 2003 with ISA Server 2006

Note:
This document applies to Exchange Server 2003, Exchange 2000 Server, and Exchange Server version 5.5. This document does not cover the upcoming release of Exchange Server 2007. Because there are significant changes to Exchange 2007 from Exchange 2003, Exchange 2007 is discussed in a separate document.

Receiving and Sending Internet E-Mail Messages

The following sections discuss how to configure ISA Server so that you can receive and send Simple Mail Transfer Protocol (SMTP) e-mail messages.

Receiving Internet E-Mail Messages

This section describes how to configure ISA Server to allow Internet e-mail messages to reach your Exchange 2003 server or SMTP server through your ISA Server computer. To receive Internet e-mail through an ISA Server computer, you need to publish your SMTP mail server. When you publish your mail server, SMTP traffic on TCP port 25 from the Internet will be allowed directly to your SMTP server. Normally, you will configure one Exchange 2003 server in your Exchange 2003 organization to send and receive SMTP connections from the Internet. This is typically an Exchange 2003 server configured as a front-end server with the SMTP connector. A front-end server does not host the Exchange information store databases. A front-end server accepts incoming e-mail messages and forwards the e-mail messages to the appropriate back-end server for processing. The front-end server also accepts SMTP e-mail messages and then forwards the e-mail messages to the Internet according to the configured SMTP routing rules.

Requirements to Publish an SMTP Server

When someone on the Internet wants to send e-mail messages to an employee in your company, all the sender has is the employee's e-mail address, for example, mberg@contoso.com. When the e-mail message is sent to mberg@contoso.com, the sender's e-mail program or e-mail server needs to find out where to send the message for the requested domain, in this case, contoso.com. This is done by querying the Domain Name System (DNS) for the mail exchange (MX) record for contoso.com. The MX record is a special type of resource record in DNS specifying a host record of servers accepting incoming e-mail messages for the domain. To receive e-mail messages from the Internet, a domain should have at least one MX record, but may have multiple MX records to provide fault tolerance. The DNS server will return all listed MX records for a domain, and the e-mail client will attempt to establish an SMTP connection using the listed MX records, in preference order. The MX record points to the A record, which points to the IP address of the SMTP server.

The following requirements must be met before publishing your SMTP server:

Create an A record and point the A record to the external IP address of the ISA Server computer.
Create an MX record pointing to the A record.

Note the following:

These records need to be created on your public DNS servers.

If you are changing an existing DNS record, depending on the Time to Live setting for the DNS record, it may take time to for the changes to propagate across the Internet. Make sure to provide enough time for these changes to take effect before testing.

Important:
If you are running ISA Server Enterprise Edition and you have enabled Network Load Balancing (NLB) integration, you should create an MX record for each array member using the dedicated IP address for each array member instead of the virtual IP address of the NLB cluster. If you use the virtual IP address as the MX record, you can receive e-mail messages. However, e-mail messages sent to a server that performs a reverse DNS lookup on your domain will be rejected. For more information, see the section, Common E-Mail Validation Checks and Sending Internet E-Mail Messages with ISA Server.

Important:

If you are running ISA Server Enterprise Edition and you have enabled Network Load Balancing (NLB) integration, you should create an MX record for each array member using the dedicated IP address for each array member instead of the virtual IP address of the NLB cluster. If you use the virtual IP address as the MX record, you can receive e-mail messages. However, e-mail messages sent to a server that performs a reverse DNS lookup on your domain will be rejected. For more information, see the section, Common E-Mail Validation Checks and Sending Internet E-Mail Messages with ISA Server.

Before You Begin

Before running the New Mail Server Publishing Wizard, use the following worksheet to gather information.

Item	Description or value
Access type	Circle all that apply: SMTP Secure SMTP Newsgroups (NNTP)
Internal IP address of SMTP server (mail server IP address)	IP address: ___.___.___.___
External IP address that ISA Server will listen on	IP address: ___.___.___.___ Important: This address needs to match the address that the MX record resolves to.
Has public DNS been properly configured? Are A records configured? Are MX records configured?	Circle Yes or No: Yes or No Yes or No

Publish a Mail Server to Receive Internet E-Mail Messages

In this section, you will run the New Mail Server Publishing Wizard to publish an SMTP mail server. Perform the following procedure to publish the SMTP mail server.

To publish a mail server

In the console tree of ISA Server Management, click Firewall Policy:
- For ISA Server 2006 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Server_Name, and then click Firewall Policy.
- For ISA Server 2006 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Arrays, expand Array_Name, and then click Firewall Policy.

On the Tasks tab, click Publish Mail Servers. Use the wizard to create the rule as outlined in the following table.

Page	Field or property	Setting
Welcome	Mail Server Publishing rule name	Type a name for the rule, such as Inbound SMTP.
Select Access Type	Select the type of access this mail server will provide for clients	Select Server-to-server communication: SMTP, NNTP.
Select Services	Server-to-server communication	Select SMTP. If you need to publish secure SMTP or NNTP, select the appropriate service. For more information about secure SMTP and NNTP, see the Exchange 2003 product documentation.
Select Server	Server IP address	Type the IP address of the SMTP mail server.
Network Listener IP Addresses	Listen for requests from these networks	Select External and click Address to specify a specific IP address.
External Network Listener IP Selection	Listen for requests on Available IP Addresses	Select Specified IP addresses on the ISA Server computer in the selected network. Select the appropriate IP addresses and click Add. Important: The selected IP addresses must match the MX record IP addresses.
Completing the New Mail Server Publishing Rule Wizard	Completing the New Mail Server Publishing Rule Wizard	Review the selected settings and click Back to make changes and Finish to complete the wizard.

Click the Apply button in the details pane to save the changes and update the configuration.

Test inbound SMTP traffic

Mail servers on the Internet should now be able to connect on TCP port 25 to your inbound SMTP server to send e-mail messages to your organization. You should test that this connectivity is working. There are a few ways to test that inbound SMTP traffic is arriving. The easiest way is to send a test e-mail message to your domain from the Internet.

For additional information about testing SMTP traffic, see "XFOR: Telnet to Port 25 to Test SMTP Communication" at the Microsoft Support Web Site.

Sending Internet E-Mail Messages

After you configure inbound Internet e-mail, the next step is to configure outbound e-mail message traffic from your organization to be sent to the Internet through ISA Server. Typically, you have one Exchange 2003 server configured to send e-mail messages to the Internet via the SMTP protocol. This is typically an Exchange 2003 server configured as a front-end server. A front-end server does not host the Exchange information store databases. In this case, the front-end server accepts SMTP requests from the other Exchange 2003 servers in your organization and forwards the requests to the appropriate mail server on the Internet. This front-end server needs to be able to create SMTP sessions to mail servers on the Internet. Additionally, the front-end server must be able to perform DNS queries to find the MX record for the domain to which the e-mail message is being sent.

The following sections describe how to create an outbound SMTP access rule.

Confirm the SMTP Server Can Query DNS

Create a Computer Object for the SMTP Server

Create an Outbound SMTP Access Rule

Confirm the SMTP Server Can Query DNS

When the SMTP server has an e-mail message to deliver, it must resolve the MX record and corresponding A record of the recipient's domain. This resolution is done by means of DNS queries.

The first step is to confirm that the SMTP server can perform DNS queries. If the SMTP server cannot perform DNS queries, it will not send Internet e-mail messages. These messages accumulate in the SMTP server's queue, and eventually delivery will fail.

Perform the following procedure to confirm that the SMTP server can perform DNS queries.

To query an MX record for a domain from a command prompt

Open a Command Prompt window.
Type the following: nslookup.
Type the following: set q=mx.
This sets a filter to only collect MX records and related information.
Type the following: domain_name.com, where domain_name is the domain that you want to obtain the DNS records for, for example, microsoft.com or msn.com. An output similar to the following is displayed:

Server: [157.178.72.30]

Address: 157.178.72.30

microsoft.com MX preference = 10, mail exchanger = mail1.microsoft.com

microsoft.com MX preference = 10, mail exchanger = mail2.microsoft.com

microsoft.com MX preference = 10, mail exchanger = mail3.microsoft.com

microsoft.com MX preference = 10, mail exchanger = mail4.microsoft.com

microsoft.com MX preference = 10, mail exchanger = mail5.microsoft.com

mail1.microsoft.com internet address = 131.107.3.125

mail2.microsoft.com internet address = 131.107.3.124

mail3.microsoft.com internet address = 131.107.3.123

mail4.microsoft.com internet address = 131.107.3.122

mail5.microsoft.com internet address = 131.107.3.121

If the SMTP server cannot query DNS, check the server's TCP/IP settings. If the server is configured to use a public DNS server, check that you have an access rule allowing DNS traffic to the Internet from the SMTP server.

Create a Computer Object for the SMTP Server

In this section, you will create a computer object for the SMTP server. This object will be used when creating the access rule, allowing you to limit outbound SMTP access to the created computer object. If you have more than one SMTP server that needs to send SMTP messages to the Internet, create a computer set for all of your SMTP computer objects.

Perform the following procedure to create a computer object.

To create a computer object

In the console tree of ISA Server Management, click Firewall Policy:
- For ISA Server 2006 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Server_Name, and then click Firewall Policy.
- For ISA Server 2006 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Arrays, expand Array_Name, and then click Firewall Policy.
On the Toolbox tab, click Network Objects, click New, and then select Computer.
Type a name for the computer object, such as SMTP Server, in the Name field and type the computers IP address in the Computer IP Address field. If you do not know the IP address, you can use the Browse button.

Create an Outbound SMTP Access Rule

Perform the following procedure to create an outbound SMTP access rule.

To create an outbound SMTP access rule

In the console tree of ISA Server Management, click Firewall Policy:
- For ISA Server 2006 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Server_Name, and then click Firewall Policy.
- For ISA Server 2006 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Arrays, expand Array_Name, and then click Firewall Policy.

On the Tasks tab, click Create Access Rule. Use the wizard to create the rule as outlined in the following table.

Page	Field or property	Setting
Welcome	Access rule name	Type a name for the rule, such as Outbound SMTP.
Rule Action	Action to take when rule conditions are met	Select Allow.
Protocols	This rue applies to Protocols	Select Selected Protocols. Add the SMTP protocol to the list. To add the SMTP protocol to the list, click Add to open the Add Protocols dialog box. In the Add Protocols dialog box, expand Common Protocols, and select SMTP. Click Add and then click Close to close the Add Protocols dialog box.
Access Rule Sources	This rule applies to traffic from these sources	Add the computer object created in the previous section. For example, add SMTP Server. To add a computer object, click Add to open the Add Network Entities dialog box. In the Add Network Entities dialog box, expand Computers, and select the correct computer object. Click Add, and then click Close to close the Add Network Entities dialog box.
Access Rule Destinations	This rule applies to traffic sent to these destinations	Add the External network to the list. To add the External network, click Add to open the Add Network Entities dialog box. In the Add Network Entities dialog box, expand Networks, and select External. Click Add, and then click Close to close the Add Network Entities dialog box.
User Sets	This rule applies to requests from the following user sets	Leave the default of All Users.
Completing the New Access Rule Wizard	Completing the New Access Rule Wizard	Review the selected settings and click Back to make changes and Finish to complete the wizard.

Click the Apply button in the details pane to save the changes and update the configuration. It may take a few minutes for the rule to be applied.

Note:
Remember that access rules are ordered, so if a deny rule matching SMTP access requests exists ahead of this allow rule, access will be denied.
Send a test e-mail message to a user on the Internet and confirm that the user received the test e-mail message.

Note:
Remember that access rules are ordered, so if a deny rule matching SMTP access requests exists ahead of this allow rule, access will be denied.

Common E-Mail Validation Checks and Sending Internet E-Mail Messages with ISA Server

To reduce the amount of spam messages that companies receive, some administrators configure their SMTP servers to validate different pieces of information received during different stages of the e-mail delivery process. If the SMTP server is not able to properly validate the information as configured on the SMTP server, the e-mail message will be rejected. Because what information is validated and how the information is validated is determined by the administrator of the receiving SMTP server, it can be difficult to troubleshoot the reason why an e-mail message is rejected by one company but accepted by other companies. Typically, the rejected e-mail message will show a reason why the message was rejected. The reason why the message was rejected can either be included in the rejected message body or the Internet headers of the e-mail message.

The following information is sent by the sending SMTP server when attempting to send e-mail messages to another SMTP server:

Public IP address of the SMTP server. This is the source IP address of the IP packets.
HELO/EHLO host name.
Sender's domain.

The following sections describe some of the more common information that is validated by the receiving SMTP server.

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

Pointer (PTR) Record Validation

A DNS PTR record is used to map an IP address to a host name or host names depending on the version of DNS that is being used. The receiving SMTP server will perform a reverse DNS lookup on the IP address of the sending SMTP server. If a PTR record has been configured, the host name will be sent back as the information requested. Then, the SMTP server performs a forward lookup on the host name. If the IP address of the sending SMTP server and IP address of the forward lookup match, the e-mail message is assumed to have come from a valid SMTP server, and the e-mail message is allowed. If the two IP addresses do not match or there is no PTR record, the e-mail message is rejected.

To fix this scenario, confirm that you have a properly configured PTR record for the primary IP address for the External network adapter of the ISA Server computer. When applying network address translation (NAT), ISA Server uses the primary IP address of the network adapter that the traffic used when sent from the ISA Server computer. This IP address might be different from the IP address used when publishing your mail server.

Important:
If you do not control your public DNS records, contact your Internet service provider (ISP) to add the appropriate PTR records.

Note the following:

If you are running ISA Server Enterprise Edition and you have an NLB-enabled array, you need to create a PTR record for the external IP address for each array member.
To check that you have a properly configured PTR record, visit the following Web sites: http://www.dnsstuff.com or http://www.dnsreport.com.

HELO/EHLO Host Name Validation

HELO/EHLO is a required SMTP command that is used to initiate the transfer of e-mail messages from one SMTP server to another SMTP server. The HELO command is used to identify the sending SMTP server, in the form of a host name, to the receiving SMTP server. The host name should be a fully qualified domain name (FQDN) that can be resolved on the Internet.

Some SMTP servers validate the host name in the HELO command. The receiving SMTP server performs a forward lookup on the host name it received in the HELO command. If the IP address that is received back matches the sending SMTP server's IP address, the e-mail message is allowed. However, if the IP address does not match or no address is returned for the host name, the e-mail message is rejected.

To fix this scenario, confirm the following:

You have properly configured the HELO/EHLO command on your SMTP server. The host name should be an FQDN that is resolvable on the Internet. For more information about configuring the HELO command, see the Exchange Server product documentation.
The host name resolves to the primary IP address of the external network adapter. When applying network address translation (NAT), ISA Server uses the primary IP address of the network adapter that the traffic used when sent from the ISA Server computer. This IP address might be different from the IP address used when publishing your mail server.

Important:
If you do not control your public DNS records, contact your ISP to add the appropriate host records.

Note the following:

If you are running ISA Server Enterprise Edition and you have an NLB-enabled array, you need to create a host record that resolves to the primary IP address for each array member.
To check that you have a properly configured PTR record, visit the following Web sites: http://www.dnsstuff.com or http://www.dnsreport.com.

Domain MX Record Validation

Some receiving SMTP servers attempt to match the IP address that the e-mail message came from to the MX record of the sender's domain. In this case, the receiving SMTP server queries DNS for the MX record for the sender's domain. A forward lookup is performed on the host names and the receiving SMTP server attempts to match the IP address of the sending SMTP server to an IP address from a MX record. If there is a match, the e-mail message is allowed. However, if a match is not found, the e-mail message is rejected.

To fix this scenario, make sure that the address you are publishing your mail server on is the primary IP address of the external network adapter.

Important:
If you have multiple SMTP servers behind the ISA Server computer, only one SMTP server can be published with the primary IP address of the external network adapter. In this case, you install an SMTP gateway that will handle all SMTP traffic for all of your SMTP servers. You need to configure the following:

Configure the SMTP gateway to accept e-mail messages for all of your domains, and to properly route the SMTP messages to the appropriate internal Exchange server.
Configure the SMTP gateway to accept SMTP messages from the internal SMTP servers.
Configure your existing SMTP servers to send SMTP e-mail messages to the new SMTP gateway.

You can use Exchange Server or the SMTP service with Internet Information Services (IIS) to act as your SMTP gateway. For configuration information, see the Exchange or IIS product documentation.

Additional Action

If the proposed changes cannot be made, or if it cannot be determined why the e-mail messages have been rejected, you can call the e-mail administrator for the company you are trying to send the e-mail message to. Ask if the application they are using has a safe sender/recipient list, and to add your domain to this list. After your domain or IP address of your SMTP server has been added to the safe list, e-mail messages sent from your SMTP server will be accepted.

Client Access

Many companies need employees to have access to their mailboxes when they are not in the office. This access provides a company with a competitive business edge by ensuring that employees can respond to important e-mail messages, check their calendars, update their contacts, and send updates to their managers from a customer's site, hotel, airport, or home, all in a timely fashion. Also, this functionality can be used by the company to offer flexible work schedules for employees.

The following table lists the client access methods supported by ISA Server 2006.

Access method	Exchange Server 2003	Exchange 2000 Server and Exchange Server 5.5
Outlook Web Access	Yes	Yes
RPC over HTTP	Yes	No
Outlook Mobile Access	Yes	No
Exchange ActiveSync	Yes	No

Note:
Using ISA Server 2006, you can publish all access methods with one publishing rule and one Web listener configured with forms-based authentication as the client authentication method. If an access method does not support forms-based authentication, such as RPC over HTTP, ISA Server will use Basic authentication. You can now create one Web listener and one publishing rule with Outlook Web Access and RPC over HTTP access methods selected together.

Note:

Using ISA Server 2006, you can publish all access methods with one publishing rule and one Web listener configured with forms-based authentication as the client authentication method. If an access method does not support forms-based authentication, such as RPC over HTTP, ISA Server will use Basic authentication. You can now create one Web listener and one publishing rule with Outlook Web Access and RPC over HTTP access methods selected together.

The following table lists the default paths configured after running the New Exchange Publishing Wizard.

Exchange Server version	Paths
Exchange Server 2003	/rpc/* /public/* /OMA/* /Microsoft-Server-ActiveSync/* /Exchweb/* /Exchange/*
Exchange 2000 Server	/public/* /Exchweb/* /Exchange/*
Exchange Server 5.5	/public/* /Exchweb/* /Exchange/*

Exchange Server version

Paths

Exchange Server 2003

/rpc/*

/public/*

/OMA/*

/Microsoft-Server-ActiveSync/*

/Exchweb/*

/Exchange/*

Exchange 2000 Server

/public/*

/Exchweb/*

/Exchange/*

Exchange Server 5.5

/public/*

/Exchweb/*

/Exchange/*

Note:
If you are using different paths, you will need to modify the default paths in the publishing rule.

When you publish Exchange client access with ISA Server 2006, communications from external clients to the ISA Server computer and from the ISA Server computer to the published server are encrypted using Secure Sockets Layer (SSL).

By publishing Exchange client access with ISA Server 2006, you have the following security benefits:

When you publish an application through ISA Server, you are protecting the server from direct external access because the name and IP address of the server are not accessible to the user. The user accesses the ISA Server computer, which then forwards the request to the server according to the conditions of the server publishing rule.

SSL bridging protects against attacks that are hidden in SSL-encrypted connections. For SSL-enabled Web applications, after receiving the client's request, ISA Server decrypts it, inspects it, and terminates the SSL connection with the client computer. The Web publishing rules determine how ISA Server communicates the request for the object to the published Web server. If the secure Web publishing rule is configured to forward the request using Secure HTTP (HTTPS), ISA Server initiates a new SSL connection with the published server. Because the ISA Server computer is now an SSL client, it requires that the published Web server responds with a server-side certificate.

Note:
The root certification authority (CA) certificate for a CA that issued the server certificate on the published Web server needs to be installed on the ISA Server computer.

You can configure forms-based authentication for supported applications. Using forms-based authentication, you can enforce required authentication methods, enable two-factor authentication, control e-mail attachment availability, and provide centralized logging. For more information about authentication, see "Authentication in ISA Server 2006" at the Microsoft TechNet Web site.

ISA Server 2006 also overcomes the difficulties of using client access VPN connections in the following ways:

Access to published applications is via a Web browser.
Applications are now more widely available and more accessible than remote access VPNs due to the use of SSL. Users can access published applications behind firewalls, from connections using NAT, and from other networking devices that might otherwise be blocking remote access VPN connections.
The reconnect process is easier and quicker, due to SSL. If your connection to the Internet is disconnected, you no longer need to reconnect with the remote access VPN dialer. After Internet access is reconnected, you can return to your published application.
Partners, vendors, and employees who are not in the office can easily access the required information in a secure way.

Publishing Exchange Web Client Access

The following sections provide the steps necessary to publish Exchange Web client access. The procedures describe a deployment of ISA Server in a production environment. We recommend that you thoroughly test ISA Server in a non-production, test environment before deploying ISA Server in production.

Network Topology

To deploy this solution, you will require the following computers, which are the minimal requirements for a laboratory configuration:

Computer to serve as the Exchange front-end server. This computer must run Microsoft Windows Server® 2003 or Windows® 2000 Server operating system, and Microsoft Exchange Server 2003. A front-end server does not host the Exchange information store databases. Front-end servers accept requests from clients and forward the requests to the appropriate back-end server for processing. For more information about system requirements for Exchange, see System Requirements for Exchange Server 2003.
Computer to serve as an Exchange back-end server. This computer must run Windows Server 2003 or Windows 2000 Server, and Exchange Server 2003. For more information about system requirements for Exchange, see System Requirements for Exchange Server 2003.
Computer to serve as a domain controller.
At least one internal client computer.
A server running ISA Server 2006 Standard Edition or an array of computers running ISA Server 2006 Enterprise Edition. An array of one computer will suffice running both ISA Server services and Configuration Storage server services. In a production environment, we recommend that the Configuration Storage server be hosted behind the ISA Server services computer, for enhanced security. The Configuration Storage server stores all of the ISA Server configuration data, including administrative roles.
At least one external client computer or appropriate mobile device.

Bb794845.7ff067f5-c338-4737-9b96-f72197a24add(en-us,TechNet.10).jpg

Authentication

You can configure forms-based authentication for supported applications, such as Outlook Web Access. Using forms-based authentication, you can enforce required authentication methods, enable two-factor authentication, control e-mail attachment availability, and provide centralized logging. You can publish an application that does not support forms-based authentication even with a Web listener that is configured with forms-based authentication. In this case, ISA Server uses Basic authentication for applications that do not support forms-based authentication.

For more information about authentication, see "Authentication in ISA Server 2006" at the Microsoft TechNet Web site.

Note the following:

If you do not limit access to authenticated users, as in the case when a rule allowing access is applied to all users, ISA Server will not validate the user's credentials. ISA Server will use the user's credentials to authenticate to the Web server according to the configured delegation method.
We recommend that you apply each publishing rule to all authenticated users or a specific user set, rather than selecting Require all users to authenticate on the Web listener, which requires any user connecting through the listener to authenticate.

Client certificate and Kerberos constrained delegation support

ISA Server 2006 introduces the use of Kerberos constrained delegation, which is described in the article Kerberos Protocol Transition and Constrained Delegation. Without Kerberos constrained delegation, ISA Server can delegate credentials only when client credentials are received using Basic or forms-based authentication. With Kerberos constrained delegation, ISA Server can accept other types of client credentials, such as client certificates. ISA Server must be enabled on the domain controller to use Kerberos constrained delegation (constrained to a specific service principal name).

If authentication fails, ISA Server provides the server's failure notice to the client. If the server requires a different type of credentials, an ISA Server alert is triggered.

Important:
The Exchange Server 2003 RPC over HTTP feature does not support Kerberos constrained delegation. Therefore, you cannot publish RPC over HTTP and use SSL Client Certificate Authentication as the Client Authentication Method in the Web listener.

LDAP authentication

ISA Server 2006 supports Lightweight Directory Access Protocol (LDAP) authentication. LDAP authentication is similar to Active Directory® directory service authentication, except that the ISA Server computer does not have to be a member of the domain. ISA Server connects to a configured LDAP server over the LDAP protocol to authenticate the user. Every Windows domain controller is also an LDAP server, by default, with no additional configuration changes required. By using LDAP authentication, you get the following benefits:

A server running ISA Server 2006 Standard Edition or ISA Server 2006 Enterprise Edition array members in workgroup mode. When ISA Server is installed in a perimeter network, you no longer need to open all of the ports required for domain membership.
Authentication of users in a domain with which there is no trust relationship.

For information about configuring ISA Server for LDAP authentication, see "Secure Application Publishing" at the Microsoft TechNet Web site

Exchange Configuration Requirements

This section describes the changes to the Exchange configuration that are required so that ISA Server Web client publishing works properly.

Confirm forms-based authentication not selected on the Exchange front-end server

Enable RPC over HTTP on the front-end Exchange server

Install a server certificate on the Exchange front-end server

Require secure channel (SSL) communications to the Web site

Confirm forms-based authentication not selected on the Exchange front-end server

Forms-based authentication can be configured on the Exchange front-end server when not using ISA Server to publish Exchange Web client access. When ISA Server is being used to publish Exchange Web client access, forms-based authentication should only be configured on the ISA Server computer.

Perform the following procedure to confirm that forms-based authentication is not selected on the Exchange front-end server.

To confirm forms-based authentication is not selected on an Exchange front-end server

Start Exchange System Manager.
If administrative groups are enabled, expand Administrative Groups.
Expand Servers, and then expand your front-end server.
Expand Protocols, expand HTTP, right-click Exchange Virtual Server, and then click Properties.
Click the Settings tab, and clear the check box Enable Forms Based Authentication.
Click OK.
If you receive a message that states that Internet Information Services (IIS) must be restarted, click OK. To restart IIS, type the following command at a command prompt: iisreset.

Note:
Perform this procedure on every Exchange front-end server in your environment that will be used for Outlook Web Access.

Enable RPC over HTTP on the front-end Exchange server

If you will be providing RPC over HTTP access to your users, you need to enable your Exchange front-end servers to be RPC proxy servers.

Perform the following procedure to make your Exchange front-end server an RPC proxy server.

To make your Exchange front-end server an RPC proxy server

Start Exchange System Manager.
If administrative groups are enabled, expand Administrative Groups.
Expand Servers, right-click your front-end server, and then click Properties.
Select the RPC-HTTP page, select RPC-HTTP front-end server, and click OK to close the properties dialog box for the selected server.

Note:
Perform this procedure on every Exchange front-end server in your environment.

Install a server certificate on the Exchange front-end server

To ensure the communications between the ISA Server computer and the Exchange front-end server are properly secured, you need to install a server certificate on the Exchange front-end server. This certificate can be from an internal CA and does not need to be purchased from a public CA.

This procedure is performed on the Exchange front-end server and assumes that an internal CA has already been installed. For information about how to install a Windows Server 2003 Enterprise CA, see "How to Install a Windows Server 2003 Enterprise CA" at the Microsoft TechNet Web site.

Before you begin, you should decide on a fully qualified domain name (FQDN) (also referred to as a common name).

Important:
ISA Server needs to resolve the FQDN that is used to create the certificate. The connection between the ISA Server computer and the Exchange front-end server will not be successful if ISA Server uses a different FQDN than the FQDN used to create the certificate.

Perform the following procedure to install a server certificate on the Exchange front-end server.

To obtain a new server certificate using the Web Server Certificate Wizard

In IIS Manager, expand the local computer, and then expand the Web Sites folder.
Right-click the Web site for the Exchange front-end services, by default, the Default Web Site, and click Properties.
On the Directory Security tab, under Secure communications, click Server Certificate. Use the wizard to request and install the Web server certificate.
In the Web Server Certificate Wizard, select Create a new certificate.
On the Delayed or Immediate Request page, select Send the request immediately to an online certification authority.
Enter the required information on the Name and Security Settings and the Organization Information pages.

Type the FQDN on the Your Site's Common Name page.

Important:
ISA Server must resolve this name to the Exchange front-end server. The FQDN entered will be used when publishing the Exchange Web client access.

Enter the required information on the Geographical Information page.
Accept the default port of 443 on the SSL Port page.
From the list under Certification authorities, select the correct internal CA.

Note:
This will only be available if you are running a Windows Server enterprise CA.
Review your request on the Certificate Request Submission page and click Next to submit your request. This will also install the certificate for your Web site.
Click Finish on the Completing the Web Server Certificate Wizard page to close the wizard.

Note:
This will only be available if you are running a Windows Server enterprise CA.

Note the following:

If you have multiple Exchange front-end servers providing Exchange Web client access, you need to perform this procedure on each front-end server using the same common name or FQDN for each server. Alternatively, you can export the certificate along with its private key and import the certificate to the additional front-end servers.
In addition, you can configure SSL client authentication between the Exchange front-end server and the ISA Server computer. For more information, see ISA Server product Help.

Require secure channel (SSL) communications to the Web site

After a certificate is installed for the Web site, you need to require the Web site to only accept secure channel communications (SSL only communications).

Perform the following procedure to enable Require secure channel (SSL).

To enable secure communications

In IIS Manager, expand the local computer, and then expand the Web Sites folder.
Right-click the Web site where the Exchange front-end services have been installed, by default, the Default Web Site, and click Properties.
On the Directory Security tab, under Secure communications, click Edit.
Select Require secure channel (SSL) on the Secure Communication page and then click OK. Click OK again to close the Web site properties dialog box.

Note:
If you have multiple Exchange front-end servers providing Exchange Web client access, you need to perform this procedure on each front-end server.

For more information about certificates and CAs, see Windows Server 2003 product documentation.

ISA Server Requirements

Before you start to run the Publish Exchange Client Web Access Wizard, you should complete the following procedures.

Install server certificate on the ISA Server computer

Update public DNS

Install server certificate on the ISA Server computer

To enable a secure connection between the client computer and the ISA Server computer, you need to install a server certificate on the ISA Server computer. This certificate should be issued by a public CA because it will be accessed by users on the Internet. If a private CA is used, the root CA certificate from the private CA will need to be installed on any computer that will need to create a secure connection (an HTTPS connection) to the ISA Server computer.

In most cases, the ISA Server computer does not have IIS installed. The following procedures assume that IIS is installed. Use the following procedures to import a certificate on the ISA Server computer.

Request and install a server certificate from a public CA

Export the server certificate to a file

Import the server certificate on the ISA Server computer

Request and install a server certificate from a public CA

Perform the following procedure to request and install a server certificate on a computer with IIS installed.

To request and install a server certificate from a public CA

In IIS, create a new Web site, pointing the Web site to a new empty directory.
In IIS Manager, expand the local computer, right-click the Web Sites folder, click New, and then click Web Site to start the Web Site Creation Wizard.
Click Next on the Welcome page.
Type a name for the Web site in the Description field. For example, type ISA Cert Site, and click Next.
Accept the default settings on the IP Address and Port Settings page.
Enter a path for the Web site on the Web Site Home Directory page. For example, enter c:\temp.
Accept the default settings on the Web Site Access Permissions page and click Next.

Click Finish to complete the Web Site Creation Wizard.

Important:
By default, the new Web site is stopped. You should leave this Web site in the stopped state. There is no reason to start this Web site.

Note:
For more information about creating a new Web site, see IIS product documentation.

Follow the steps provided by the public CA to create and install a server certificate using the Web site you created in Step 1.

Important:
The important information in the certificate is the common name or FQDN. Enter the FQDN that will be used by users on the Internet to connect to the Exchange Outlook Web Access site. For example, enter mail.contoso.com.

Note:
Confirm that the private key for the certificate that you will install is exportable.

Export the server certificate to a file

After the certificate is installed on the Web site that you just created, you will export the certificate to a file. This file will then be copied and imported to the ISA Server computer.

Perform the following procedure to export the server certificate that you just installed.

To export the server certificate to a .pfx file

In IIS Manager, expand the local computer, and then expand the Web Sites folder.
Right-click the Web site for the Exchange front-end services, by default, the Default Web Site, and click Properties.
On the Directory Security tab, under Secure communications, click Server Certificate to start the Web Server Certificate Wizard.
Click Next on the Welcome page.
Select Export the current certificate to a .pfx file on the Modify the Current Certificate Assignment page.
Type the path and file name on the Export Certificate page. For example, type c:\certificates\mail_isa.pfx, and then click Next.

Enter a password for the .pfx file. This password will be requested when a user is importing the .pfx file. We recommend that a strong password be used because the .pfx file also has the private key.

Important:
The .pfx file should be transferred to the ISA Server computer in a secure fashion because it contains the private key for the certificate to be installed on the ISA Server computer.

Import the server certificate on the ISA Server computer

Perform the following procedure on the ISA Server computer to import the server certificate to the local computer store.

To import a server certificate on the ISA Server computer

Copy the .pfx file created in the previous section to the ISA Server computer in a secure fashion.
Click Start, and then click Run. In Open, type MMC, and then click OK.
Click File, click Add/Remove Snap-in, and in the Add/Remove Snap-in dialog box, click Add to open the Add Standalone Snap-in dialog box.
Select Certificates, click Add, select Computer account, and then click Next.
Select Local Computer, and then click Finish. In the Add Standalone Snap-in dialog box, click Close, and in the Add/Remove Snap-in dialog box, click OK.
Expand the Certificates node, and right-click the Personal folder.
Select All Tasks, and then click Import. This starts the Certificate Import Wizard.
On the Welcome page, click Next.
On the File to Import page, browse to the file that you created previously and copied to the ISA Server computer, and then click Next.

On the Password page, type the password for this file, and then click Next.

Note:
The Password page provides the option Mark this key as exportable. If you want to prevent the exporting of the key from the ISA Server computer, do not select this option.

On the Certificate Store page, verify that the selections Place all certificates in the following store is selected and Certificate Store is set to Personal (the default settings), and then click Next.
On the wizard completion page, click Finish.
Verify that the server certificate was properly installed. Click Certificates, and double-click the new server certificate. On the General tab, there should be a note that shows You have a private key that corresponds to this certificate. On the Certification Path tab, you should see a hierarchical relationship between your certificate and the CA, and a note that shows This certificate is OK.

Update public DNS

Create a new DNS host record in your domain's public DNS servers. Users will initiate a connection using the name of the Web site. This name needs to match the common name or FQDN used in the certificate installed on the ISA Server computer. For example, a user might browse to https://mail.contoso.com/exchange. In this case, the following conditions need to be met for the user to successfully initiate a connection:

FQDN used in the server certificate installed on the ISA Server computer needs to be mail.contoso.com.
User needs to resolve mail.contoso.com to an IP address.

IP address that mail.contoso.com resolves to needs to be configured on the External network of the ISA Server computer.

Note:
For ISA Server Enterprise Edition, if you are working with an NLB-enabled array, the IP address should be a virtual IP address configured for the array. For more information about NLB, see ISA Server product Help.

Exchange Publishing

Now that the Exchange front-end server and the ISA Server computer have been properly configured and have the proper server certificates installed, you can start the procedures to publish the Exchange front-end server. Using the Exchange Publishing Wizard, you can provide secure access to your Exchange front-end server.

The following procedures are used to publish your Exchange front-end server.

Create a server farm (optional)

Create a Web listener

Create an Exchange Web client access publishing rule

Create a server farm (optional)

When you have more than one Exchange front-end server, you can use ISA Server to provide load balancing for these servers. This will enable you to publish the Web site once, instead of having to run the wizard multiple times. Also, this eliminates the need for a third-party product to load balance a Web site. If one of the servers is unavailable, ISA Server detects that the server is not available and directs users to servers that are working. ISA Server verifies on regular intervals that the servers that are members of the server farm are functioning. The server farm properties determine the following:

Servers included in the farm
Connectivity verification method that ISA Server will use to verify that the servers are functioning

Perform the following procedure to create a server farm.

To create a server farm

In the console tree of ISA Server Management, click Firewall Policy:
- For ISA Server 2006 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Server_Name, and then click Firewall Policy.
- For ISA Server 2006 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Arrays, expand Array_Name, and then click Firewall Policy.

On the Toolbox tab, click Network Objects, click New, and select Server Farm. Use the wizard to create the server farm as outlined in the following table.

Page	Field or property	Setting
Welcome	Server farm name	Type a name for the server farm. For example, type Exchange front end servers.
Servers	Servers included in this farm	Select Add and enter either the IP addresses or names of your Exchange front-end servers.
Server Farm Connectivity Monitoring	Method used to monitor server farm connectivity	Select Send an HTTP/HTTPS GET request.
Completing the New Server Farm Wizard	Completing the New Server Farm Wizard	Review the selected settings, and click Back to make changes and Finish to complete the wizard.

When the wizard completes, click Yes in the Enable HTTP Connectivity Verification dialog box.
Click the Apply button in the details pane to save the changes and update the configuration.

For more information about connectivity verifiers, see ISA Server product Help.

Create a Web listener

When you create a Web publishing rule, you must specify a Web listener to be used. The Web listener properties determine the following:

IP addresses and ports on the specified networks that the ISA Server computer uses to listen for Web requests (HTTP or HTTPS).
Server certificates to use with IP addresses.
Authentication method to use.
Number of concurrent connections that are allowed.
Single sign on (SSO) settings.

Update the following table with information that will be used when you use the New Web Listener Wizard.

Property	Value
Web listener name	Name: ________________________
Client connection security Note the following: If HTTP is selected, information between the ISA Server computer and the client will be transferred in plaintext. If HTTPS is selected, a server certificate needs to be installed on the ISA Server computer.	HTTPS or HTTP (circle one)
Web listener IP address	Network: ___________________ Optional Specific IP address: ___.___.___.___ Note: If this specific IP address is not the primary network adapter IP address, a secondary IP address needs to be configured on the ISA Server computer before creating the Web listener.
Authentication settings Web listener SSL certificate Note: This is only required if HTTPS has been selected for client connectivity security.	___Use a single certificate for this Web listener. Certificate issued to: _______________________ ___Assign a certificate for each IP address. (This option will only be available if a specific IP address has been assigned to the Web listener.) Certificate issued to: _______________________
Authentication For forms-based authentication, you have options to authenticate your users to ISA Server.	For more information about authentication, see Authentication.
Single sign on settings	___Enable single sign on. Single sign on domain name: ___________________________

Use the information on the worksheet that you filled in previously, and perform the following procedure to create a Web listener.

To create a Web listener

In the console tree of ISA Server Management, click Firewall Policy:
- For ISA Server 2006 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Server_Name, and then click Firewall Policy.
- For ISA Server 2006 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Arrays, expand Array_Name, and then click Firewall Policy.

On the Toolbox tab, click Network Objects, click New, and then select Web Listener. Use the wizard to create the Web listener as outlined in the following table.

Page	Field or property	Setting
Welcome	Web listener name	Type a name for the Web listener. For example, type Exchange FBA.
Client Connection Security	Select what type of connections this Web Listener will establish with clients	Select Require SSL secured connections with clients.
Web Listener IP Addresses	Listen for incoming Web requests on these networks ISA Server will compress content sent to clients	Select the External network. Check box should be selected (default). Click Select IP Addresses.
External Network Listener IP Selection	Listen for requests on Available IP Addresses	Select Specified IP addresses on the ISA Server computer in the selected network. Select the correct IP address and click Add. Note: For ISA Server Enterprise Edition with an NLB-enabled array, you should select a virtual IP address.
Listener SSL Certificates	Select a certificate for each IP address, or specify a single certificate for this Web listener	Select Assign a certificate for each IP address. Select the IP address you just selected and click Select Certificate.
Select Certificate	Select a certificate from the list of available certificates	Select the certificate that you just installed on the ISA Server computer. For example, select mail.contoso.com, and click Select. The certificate must be installed before running the wizard.
Authentication Settings	Select how clients will provide credentials to ISA Server Select how ISA Server will validate client credentials	Select HTML Form Authentication for forms-based authentication and select the appropriate method that ISA Server will use to validate the client's credentials. For example, select Windows (Active Directory) if your ISA Server computer is in a domain configuration.
Single Sign On Settings	Enable SSO for Web sites published with this Web listener SSO domain name	Leave the default setting to enable SSO. To enable SSO between two published sites `portal.contoso.com` and `mail.contoso.com,` type .contoso.com.
Completing the New Web Listener Wizard	Completing the New Web Listener Wizard	Review the selected settings, and click Back to make changes or Finish to complete the wizard.

Create an Exchange Web client access publishing rule

When you publish an internal Exchange front-end server through ISA Server 2006, you are protecting the Web server from direct external access because the name and IP address of the server are not accessible to the user. The user accesses the ISA Server computer, which then forwards the request to the internal Web server according to the conditions of your Web server publishing rule. An Exchange Web client access publishing rule is a Web publishing rule that contains default settings appropriate to Exchange Web client access.

Update the following table with information that will be used when you use the New Exchange Publishing Rule Wizard.

Property	Value
Exchange publishing rule name	Name: ________________________
Services Note: You can publish all services in a single rule using the same Web listener configured with forms-based authentication. ISA Server 2006 will use Basic authentication for services that do not support forms-based authentication.	Exchange version: ____________ __Outlook Web Access __Outlook RPC over HTTP __Outlook Mobile Access __Exchange ActiveSync
Publishing type	__Publish a single Web site or __Publish a server farm of load balanced servers and Server farm name:_____________
Server connection security	HTTPS or HTTP (circle one) Note the following: If HTTP is selected, information between the ISA Server computer and the Web server will be transferred in plaintext. If HTTPS is selected, a server certificate needs to be installed on the Exchange front-end server.
Internal publishing details	Internal site name (FQDN): ______________________ If the FQDN is not resolvable by the ISA Server computer: Computer name or IP address:_____________________
Public name details	Accept request for: __This domain name:______________ or __Any domain name
Select Web listener	Web listener:________________
User set	List user sets that will have access to this rule: _________________ __________________

Use the information on the worksheet that you filled in previously, and perform the following procedure to create an Exchange Web client access publishing rule.

To create an Exchange Web client access publishing rule

In the console tree of ISA Server Management, click Firewall Policy:
- For ISA Server 2006 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Server_Name, and then click Firewall Policy.
- For ISA Server 2006 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Arrays, expand Array_Name, and then click Firewall Policy.
On the Tasks tab, click Publish Exchange Web Client Access. Use the wizard to create the rule as outlined in the following tables.

For a single Web server, use the table in New Exchange Publishing Rule Wizard for a single Web site.

If you are using a server farm, use the table in New Exchange Server Publishing Rule Wizard for a server farm.

New Exchange Publishing Rule Wizard for a single Web site

Page	Field or property	Setting
Welcome	Exchange Publishing rule name	Type a name for the rule. For example, type Exchange Web Client Publishing.
Select Services	Exchange version Web client mail services	Select the proper version of Exchange. For example, select Exchange Server 2003. Select the desired access methods.
Publishing Type	Select if this rule will publish a single Web site or external load balancer, a Web server farm, or multiple Web sites	Select Publish a single Web site or load balancer.
Server Connection Security	Choose the type of connections ISA Server will establish with the published Web server or server farm	Select Use SSL to connect to the published Web server or server farm. Note: A server certificate must be installed on the published Exchange front-end server, and the root CA certificate of the CA that issued the server certificate on the Exchange front-end server must be installed on the ISA Server computer.
Internal Publishing Details	Internal site name	Type the internal FQDN of the Exchange front-end server. For example, type exchfe.corp.contoso.com. Important: The internal site name must match the name of the server certificate that is installed on the internal Exchange front-end server. Note: If you cannot properly resolve the internal site name, you can select Use a computer name or IP address to connect to the published server, and then type the required IP address or name that is resolvable by the ISA Server computer.
Public Name Details	Accept requests for Public name	This domain name (type below) Type the domain name that you want ISA Server to accept the connection for. For example, type mail.contoso.com.
Select Web Listener	Web listener	Select the Web listener you created previously. For example, select Exchange FBA.
Authentication Delegation	Select the method used by ISA Server to authenticate to the published Web server	Select Basic authentication.
User Sets	This rule applies to requests from the following user sets	Select the user set approved to access this rule.
Completing the New Exchange Publishing Rule Wizard	Completing the New Exchange Publishing Rule Wizard	Review the selected settings, and click Back to make changes and Finish to complete the wizard.

New Exchange Server Publishing Rule Wizard for a server farm

Page	Field or property	Setting
Welcome	Exchange Publishing rule name	Type Exchange Web Client Publishing.
Select Services	Exchange version Web client mail services	Select the proper version of Exchange server. For example, select Exchange Server 2003. Select the desired access methods.
Publishing Type	Select if this rule will publish a single Web site or external load balancer, a Web server farm, or multiple Web sites	Select Publish a server farm of load balanced Web servers.
Server Connection Security	Choose the type of connections ISA Server will establish with the published Web server or server farm	Select Use SSL to connect to the published Web server or server farm. Note: A server certificate must be installed on the published Exchange front-end servers, and the root CA certificate must be installed on the ISA Server computer.
Internal Publishing Details	Internal site name	Type exchfe.corp.contoso.com.
Specify Server Farm	Select the Exchange server farm you want to publish	Select the name of the server farm previously created. For example, select Exchange front end servers.
Public Name Details	Accept requests for Public name	This domain name (type below) Type mail.contoso.com.
Select Web Listener	Web listener	Select Exchange FBA.
Authentication Delegation	Select the method used by ISA Server to authenticate to the published Web server	Select Basic authentication.
User Sets	This rule applies to requests from the following user sets	Select the user set approved to access this rule.
Completing the New Exchange Publishing Rule Wizard	Completing the New Exchange Publishing Rule Wizard	Review the selected settings, and click Back to make changes and Finish to complete the wizard.

SSL bridging

SSL bridging is used when ISA Server terminates or initiates an SSL connection. In ISA Server 2006, SSL bridging is automatically configured when the specified Web listener is configured to listen for HTTPS traffic.

Specifically, SSL bridging works in the following scenarios:

A client requests an SSL object. ISA Server decrypts the request, and then encrypts it again and forwards it to the Web server. The Web server returns the encrypted object to ISA Server. ISA Server decrypts the object, and then encrypts it again and sends it to the client. SSL requests are forwarded as SSL requests.
A client requests an SSL object. ISA Server decrypts the request and forwards it without encryption to the Web server. The Web server returns the HTTP object to ISA Server. ISA Server encrypts the object and sends it to the client. SSL requests are forwarded as HTTP requests.

For incoming Web requests, an external client uses HTTPS to request an object from a Web server located on your Internal network. The client connects to ISA Server on the SSL port specified in the Web listener properties—by default, port 443.

After receiving the client's request, ISA Server decrypts it, terminating the SSL connection. The Web publishing rules determine how ISA Server communicates the request for the object to the published Web server (FTP, HTTP, or HTTPS).

If the secure Web publishing rule is configured to forward the request using HTTPS, ISA Server initiates a new SSL connection with the publishing server, sending a request to the listening port (by default, port 443). Because the ISA Server computer is now an SSL client, it requires that the publishing Web server responds with a server-side certificate.

Test Exchange Publishing Rule

In this section, you will test the new Exchange publishing rule that you just created.

Test Outlook Web Access

From a computer on the Internet, use the following procedure to test Outlook Web Access.

Note:
Make sure that you have the root CA of the issuing CA of the mail.contoso.com certificate installed.

To test the Outlook Web Access publishing rule

Open Microsoft Internet Explorer.
Browse to the Outlook Web Access Web site, such as the URL https://mail.contoso.com/exchange, and enter your user credentials to log on.
You can now read and send e-mail messages.

Test Outlook Mobile Access

From a computer on the Internet, use the following procedure to test Outlook Mobile Access.

To test the Outlook Mobile Access publishing rule

Open Microsoft Internet Explorer.
Browse to the Outlook Web Access Web site, such as the following URL: https://mail.contoso.com/oma.
Enter your user credentials to log on.

Note:
Although Microsoft Internet Explorer® is not a supported client for Outlook Mobile Access, it is useful to test whether you can communicate with your Exchange front-end server.

Important:
When a Microsoft Windows Mobile® user tries to access a published Outlook Web Access or Outlook Mobile Access Web site published with the Exchange Publishing Wizard, the user receives error 401 instead of the Exchange logon forms. The required HTML form directories for Outlook Mobile Access are missing from the Exchange HTML form set directory, which is causing this error. The solution is to manually create the following two directories cHTML and xHTML in the %programfiles%\Microsoft ISA Server\CookieAuthTemplate\Exchange folder. Then, copy the contents of the %programfiles%\Microsoft ISA Server\CookieAuthTemplate\Exchange\HTML folder to the cHTML and xHTML folders.

Important:

When a Microsoft Windows Mobile® user tries to access a published Outlook Web Access or Outlook Mobile Access Web site published with the Exchange Publishing Wizard, the user receives error 401 instead of the Exchange logon forms.
The required HTML form directories for Outlook Mobile Access are missing from the Exchange HTML form set directory, which is causing this error.
The solution is to manually create the following two directories cHTML and xHTML in the %programfiles%\Microsoft ISA Server\CookieAuthTemplate\Exchange folder. Then, copy the contents of the %programfiles%\Microsoft ISA Server\CookieAuthTemplate\Exchange\HTML folder to the cHTML and xHTML folders.

Test Exchange ActiveSync

Configure a mobile device to connect to your Exchange server using Microsoft Exchange ActiveSync, and make sure that ISA Server and Exchange ActiveSync are working properly. When configuring your mobile device and you are prompted to enter a name for the server name field, type the name of the Exchange ActiveSync server that was just published, such as https://mail.contoso.com/oma.

Note:
You can also test Exchange ActiveSync using Internet Explorer. Open Internet Explorer, and in Address, type the URL https://published_server_name/Microsoft-Server-Activesync, where published_server_name is the published name of the Outlook Web Access server (the name a user would use to access Outlook Web Access). After you authenticate yourself, if you receive an Error 501/505 – Not implemented or not supported, ISA Server and Exchange ActiveSync are working together properly.

Note:

You can also test Exchange ActiveSync using Internet Explorer. Open Internet Explorer, and in Address, type the URL https://published_server_name/Microsoft-Server-Activesync, where published_server_name is the published name of the Outlook Web Access server (the name a user would use to access Outlook Web Access). After you authenticate yourself, if you receive an Error 501/505 – Not implemented or not supported, ISA Server and Exchange ActiveSync are working together properly.

Test RPC over HTTP

This procedure must be performed from a client on the Internal network. We recommend configuring Outlook 2003 without RPC over HTTP. Confirm that Outlook is working properly on the Internal network before configuring RPC over HTTP.

To test RPC over HTTP from Outlook 2003

Change the following account setting in Outlook 2003:
1. On the Outlook 2003 Tools menu, select E-mail Accounts.
2. Select View or change existing e-mail accounts, and then click Next.
3. Select your Microsoft Exchange account and click Change.
4. Click More Settings.
5. If you receive an error from Outlook that it could not connect to Exchange, click Cancel and continue to step H.
6. Click the Connection tab, select Connect to my Exchange mailbox using HTTP, and then click Exchange Proxy Settings.
7. Type mail.contoso.com in Use this URL to connect to my proxy server for Exchange in Connection settings.
8. Select Mutually authenticate the session when connecting with SSL and, for example, type msstd:mail.contoso.com in Principal name for proxy server.
9. Select Basic Authentication for Proxy authentication settings.
10. Click OK to close the Exchange Proxy Settings dialog box.
11. Click OK to close the Microsoft Exchange Server dialog box.
Click Next and then click Finish to close the E-mail Accounts dialog box.
Restart Outlook.
When you restart Outlook, you will be presented with a logon dialog box. Enter the user name and password and click OK.

Note:
For RPC over HTTP to work, both when the user is out of the office and when the user is in the office, the FQDN mail.contoso.com must resolve to the external address when users are in the office and when connected to the Internet.

Appendix A: Additional Publishing Features

In this section, the following additional features are discussed, which you can configure to ease your deployments:

Redirect HTTP to HTTPS
Password Management
Attachment Blocking

Redirecting HTTP to HTTPS

When publishing a Web site, we recommend that users open an HTTPS connection between them and the ISA Server computer to protect the sensitive information that is being transferred over the Internet. This requires that users enter a URL such as https://mail.contoso.com/exchange. If the user just enters http://mail.contoso.com/exchange, the user will receive the following error.

Bb794845.30acd38d-c5b5-49f5-8281-6eb2b55a5542(en-us,TechNet.10).bmp

Users have a tendency not to enter the HTTPS portion of the URL even when going to a secured Web site. This behavior has been reinforced by Web administrators who have scripted their Web sites to redirect users to an HTTPS page, even when they enter HTTP. This is done to reduce the number of Help desk calls by users when they cannot open the URL they are trying to open.

To enable HTTP to HTTPS redirection, perform the following procedure.

To enable HTTP to HTTPS redirection

In the console tree of ISA Server Management, click Firewall Policy:
- For ISA Server 2006 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Server_Name, and then click Firewall Policy.
- For ISA Server 2006 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Arrays, expand Array_Name, and then click Firewall Policy.
On the Toolbox tab, click Network Objects, expand Web Listeners, right-click the Web listener, and then select Properties.
Select the Connections tab.
Select Enable HTTP connections on port and confirm that the listening port for HTTP is 80.
Confirm that Enable SSL (HTTPS) connections on port is selected and is listening on port 443.
Select Redirect all traffic from HTTP to HTTPS.
Click OK to close the properties of the Web listener.
Click the Apply button in the details pane to save the changes and update the configuration.

Password Management

It is good security policy to require your users to change their passwords on a regular basis. Users who are not in the office on a regular basis need a method to change their passwords when they are not in the office.

When using forms-based authentication, you can inform users that their passwords are going to expire in a specific number of days, and you can enable users to change their passwords so they do not expire. Users will also be able to change an expired password.

To enable the change password functionality for forms-based authentication

In the console tree of ISA Server Management, click Firewall Policy:
- For ISA Server 2006 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Server_Name, and then click Firewall Policy.
- For ISA Server 2006 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Arrays, expand Array_Name, and then click Firewall Policy.
On the Toolbox tab, click Network Objects, expand Web Listeners, right-click the desired Web listener, and then select Properties.
Select the Forms tab.
Select Allow users to change their passwords and Remind users that their password will expire in this number of days. The default number of days is 15.
Click OK to close the properties of the Web listener.
Click the Apply button in the details pane to save the changes and update the configuration.
The users will now see the following logon screen. Notice the option I want to change my password after logging on.

To configure the Change Password option when using LDAP authentication, LDAP needs to be configured with the following settings:

Connection to the LDAP servers must be over a secured connection. This requires an SSL certificate to be installed on the Active Directory servers. For more information about enabling LDAP over SSL, see "How to Enable LDAP over SSL with a third-party certification authority" at the Microsoft Support Web site.
The ISA Server computer needs to have the root certificate for the CA that issued the SSL certificate installed on the Active Directory servers.
Connection to the LDAP servers cannot be via a global catalog.
A user name and password that are used for verifying user account status and changing passwords are required.

Attachment Blocking

Because Outlook Web Access is often used from public computers, you may want to control the user's ability to view and save attachments, so that private corporate information is not cached or saved to a public computer. ISA Server provides a mechanism for blocking e-mail attachments for users on public (shared) computers or users on private computers (or both). This prevents users from opening or saving attachments, although the attachments can be seen by the users.

Important:
If you are using Exchange Server 2003, we recommend you configure attachment blocking on the Exchange 2003 server and not on ISA Server. For more information about configuring attachment blocking on Exchange Server 2003, see "How to Manage Outlook Web Access features in Exchange Server 2003" at the Microsoft Support Web site.

To configure attachment blocking in ISA Server 2006, perform the following procedure.

To configure attachment blocking in ISA Server 2006

In the console tree of ISA Server Management, click Firewall Policy:
- For ISA Server 2006 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Server_Name, and then click Firewall Policy.
- For ISA Server 2006 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Arrays, expand Array_Name, and then click Firewall Policy.
- Right-click the publishing rule for Outlook Web Access and select Properties.
- Select the Application Settings tab.
- Select Public computers or Private computers (or select both options) in the Exchange Publishing Attachment Blocking section and click OK.

Appendix B: Troubleshooting

In this section, troubleshooting issues are discussed.

ISA Server Best Practices Analyzer

To determine the overall health and diagnose common configuration errors, download and run the Microsoft ISA Server Best Practices Analyzer Tool at the Microsoft Download Center.

Double Authentication Required after Upgrading from ISA Server 2004

After upgrading from ISA Server 2004, when an Exchange publishing rule was defined with forms-based authentication, users are prompted twice for their credentials. In ISA Server 2004, when you create a rule with the New Mail Server Publishing Rule Wizard, authentication delegation is not required, because it is handled by ISA Server itself. When this rule is upgraded to ISA Server 2006, authentication delegation for the rule is set to No delegation.

The solution is to manually configure authentication delegation for the affected rule to Basic Authentication.

Log Off when the User Leaves Site Feature Removed

The Log off when the user leaves site setting has been removed from ISA Server 2006. Users should always use the log off button to properly log off from Outlook Web Access.

Windows Mobile Users Receive Error 401 Unauthorized

When a Windows Mobile user tries to access a published Outlook Web Access or Windows Mobile Access Web site published with the New Exchange Publishing Rule Wizard, the user receives error 401 instead of the Exchange logon forms.

The required HTML form directories for Windows Mobile access are missing from the Exchange HTML form set directory, which is causing this error.

The solution is to manually create the two directories, cHTML and xHTML, in the %programfiles%\Microsoft ISA Server\CookieAuthTemplate\Exchange folder. Then, copy the contents of the %programfiles%\Microsoft ISA Server\CookieAuthTemplate\Exchange\HTML folder to the cHTML and xHTML folders.

Users Receive Access Denied Error Message

When a user attempts to connect to a published Outlook Web Access site and does not add the /exchange suffix to the end of the URL, such as https://mail.contoso.com, instead of receiving the forms-based authentication logon screen, the user receives an "Access denied" error message. This error can be difficult to troubleshoot because ISA Server is behaving as expected.

A workaround is to publish the root of the Exchange front-end server, with an action of Deny, and redirect users to the proper URL, such as https://mail.contoso.com/exchange.

Perform the following procedure to automatically redirect users to the proper Outlook Web Access URL.

To create an Exchange Web client access publishing rule

In the console tree of ISA Server Management, click Firewall Policy:
- For ISA Server 2006 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Server_Name, and then click Firewall Policy.
- For ISA Server 2006 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Arrays, expand Array_Name, and then click Firewall Policy.

On the Tasks tab, click Publish Web Sites. Use the wizard to create the rule as outlined in the following table.

Page	Field or property	Setting
Welcome	Web publishing rule name	Type a name for the rule, such as Exchange Redirect.
Select Rule Action	Action to take when rule conditions are met	Select Deny.
Publishing Type	Select if this rule will publish a single Web site or external load balancer, a Web server farm, or multiple Web sites	Select Publish a single Web site or load balancer.
Server Connection Security	Choose the type of connections ISA Server will establish with the published Web server or server farm	Select Use SSL to connect to the published Web server or server farm. Note A server certificate must be installed on the published Exchange front-end servers, and the root CA certificate must be installed on the ISA Server computer.
Internal Publishing Details	Internal site name	Type the internal FQDN of the Exchange front-end server. For example: exchfe.corp.contoso.com. Important: The internal site name must match the name of the server certificate that is installed on the internal Exchange front-end server. Note: If you cannot properly resolve the internal site name, you can select Use a computer name or IP address to connect to the published server, and then type the required IP address or name that is resolvable by the ISA Server computer.
Internal Publishing Details	Path (optional)	Type / in the Path box.
Public Name Details	Accept requests for Public name	This domain name (type below) Type the domain name that you want ISA Server to accept connections for. For example, type mail.contoso.com.
Select Web Listener	Web listener	Select the Web listener you created previously, such as Exchange FBA.
Authentication Delegation	Select the method used by ISA Server to authenticate to the published Web server	Select Basic authentication.
User Sets	This rule applies to requests from the following user sets	Select the user set approved to access this rule. This should be the same user set that you used in the Exchange publishing rule.
Completing the New Web Publishing Rule Wizard	Completing the New Web Publishing Rule Wizard	Review the selected settings, and click Back to make changes and Finish to complete the wizard.

Right-click the rule you just created and click Properties.
Select the Action tab, select Redirect HTTP requests to this Web page, and type the correct URL, such as https://mail.contoso.com/exchange, in the Redirect requests to an alternate Web page box.
Select the Application Settings tab, select Use customized HTML forms instead of the default, type Exchange in the Type the custom HTML form set directory box, and then click OK.
Click the Apply button in the details pane to save the changes and update the configuration.

Important:
This rule should be placed before the Exchange publishing rule to have the expected results.

Appendix C: Configuring Certificate-Based Authentication with Exchange ActiveSync through ISA Server

Exchange ActiveSync in Exchange Server 2003 allows Windows Mobile-based devices and Exchange ActiveSync-enabled third-party devices to synchronize e-mail, calendar, contact, and task information that is stored on the user's Exchange server, and to retain access to this information when the mobile device is online or offline.

Exchange Server 2003 Service Pack 2 (SP2), adds the ability to authenticate an ActiveSync connection using certificate-based authentication. Prior to ISA Server 2006, to publish ActiveSync with certificate-based authentication, you had to publish ActiveSync in tunnel mode. When you publish a site in tunnel mode, you lose the benefit of ISA Server being able to inspect the SSL traffic.

ISA Server 2006 supports Kerberos constrained delegation, which allows ISA Server to authenticate client connections with a client certificate and issues a Kerberos ticket to the published Web server. When Kerberos constrained delegation is configured properly, the published Web server accepts the Kerberos ticket instead of client credentials.

This appendix provides information about the configuration changes to the Exchange front-end server, to the back-end servers, and to the ISA Server computer, which are required to successfully publish ActiveSync with client certificate-based authentication through ISA Server 2006. This appendix does not cover deploying Exchange Server 2003 SP2 or how to configure certificate deployment for mobile devices.

Note the following:

Certificate-based authentication for ActiveSync is a feature of Exchange Server 2003 SP2. For more information about deploying Exchange Server 2003 SP2, see the Microsoft Exchange Server Web site.
For more information about deploying certificates to mobile devices, see Appendix A in the "Step-by-Step Guide to Deploying Windows Mobile-based Devices with Microsoft Exchange Server 2003 SP2" at the Microsoft TechNet Web site.

The following are required to configure certificate-based authentication with ActiveSync through ISA Server 2006:

Raise the domain functional level to Windows Server 2003.
Configure Kerberos constrained delegation and protocol transitioning for:
ISA Server
Exchange front-end servers
Configure Integrated Windows authentication for the Exchange front-end servers.
Create a Web listener with client authentication set to client certificate authentication.
Create an Exchange publishing rule, setting the authentication delegation to Kerberos constrained delegation.
Test the new configuration.

Raising the Domain Functional Level to Windows Server 2003

For Kerberos constrained delegation to work properly, you need to confirm that the Active Directory domain is working at a Windows Server 2003 level.

To raise the domain functional level to Windows Server 2003

Click Start, point to Program Files, point to Administrative Tools, and then click Active Directory Users and Computers.

Important:
The change in steps 2, 3, and 4 are permanent. You cannot undo these actions.
Right-click the domain, and then select Raise Domain Functional Level.
In the Raise Domain Functional Level box, select Windows Server 2003 from the list, and then click Raise.
Click OK.

Important:
The change in steps 2, 3, and 4 are permanent. You cannot undo these actions.

Configuring Constrained Delegation and Protocol Transitioning

Kerberos is a network authentication protocol that authenticates the identity of users who are trying to log on to a network, and encrypts their communications through secret key cryptography.

You must configure Kerberos constrained delegation when ISA Server is configured to authenticate the user through a client certificate and then impersonate that user to the Exchange front-end server. The Exchange front-end ActiveSync server will then impersonate the user when you access the user's e-mail, calendar, contact, and task information in the Exchange back-end server where the user's mailbox is located. This is required because ISA Server cannot delegate the client certificate presented to it by the client.

When you want to configure Kerberos constrained delegation, so that the Exchange front-end server trusts the Kerberos ticket from the ISA Server computer, the configuration is done on the ISA Server computer account. To configure Kerberos constrained delegation, so that the Exchange back-end servers trust the Kerberos ticket issued from the Exchange front-end servers, the configuration is done on the Exchange front-end servers computer account.

For more information, see Kerberos Authentication in Windows Server 2003.

Active Directory Users and Computers is an MMC snap-in that is a standard part of Microsoft Windows Server operating systems. However, when you install Exchange Server 2003, the Setup wizard automatically extends the functionality of Active Directory Users and Computers to include Exchange-specific tasks.

You start Active Directory Users and Computers from either an Exchange server or from a workstation that has the Exchange management tools installed.

Note:
If the Active Directory Users and Computers snap-in is installed on a computer that does not have Exchange Server or the Exchange Server management tools installed, you cannot perform Exchange Server tasks from that computer.

The Delegation tab that is referenced in the following procedures lets you configure delegation in three ways:

Not allowed Select the Do not trust this computer for delegation option.
Allowed for all services Select the Trust this computer for deletion to any service (Kerberos only) option. Refers to the Windows 2000 Server delegation method.
Allowed for only a limited set of services Select the Trust this computer for delegation to specified services only option. Refers to the constrained delegation method available with Windows Server 2003.

To configure Kerberos constrained delegation on the ISA Server computers, perform the following procedure.

To use Active Directory Users and Computers to configure constrained delegation and protocol transitioning

Click Start, point to Program Files, point to Administrative Tools, and then click Active Directory Users and Computers.
In the console tree, click your Domain and expand the tree view.
Click Computers and expand the tree view. From the list of computers, right-click the ISA Server computer, click Properties, and then click the Delegation tab.
On the Delegation tab, select Trust the computer for designation of specified services only, and then click Add.
Select Use any authentication protocol to enable protocol transitioning, and then click Add.
Click Users or Computers, type the name of the front-end Exchange server, and then click OK.
Select HTTP and W3SVC, and then click OK two times.

Note:
Perform this procedure for each ISA Server computer that will be publishing Exchange ActiveSync.

To configure Kerberos constrained delegation for the Exchange front-end servers, perform the following procedure.

To use Active Directory Users and Computers to configure constrained delegation and protocol transitioning, follow these steps from the front-end server

Click Start, point to Program Files, point to Administrative Tools, and then click Active Directory Users and Computers.
In the console tree, click your Domain and expand the tree view.
Click Computers and expand the tree view. From the list of computers, right-click the Exchange front-end server, click Properties, and then click the Delegation tab.
On the Delegation tab, select Trust the computer for designation of specified services only, and then click Add.
Select Use any authentication protocol to enable protocol transitioning, and then click Add.
Click Users or Computers, type the name of the back-end Exchange server or servers, and then click OK.
Select HTTP and W3SRV, and then click OK two times.
Right-click the back-end Exchange computer, click Properties, and then click Delegation.
On the Delegation tab, select Trust the computer for designation of specified services only. If the back-end server is a domain controller, it is already configured to trust the computer for designation of specified services only.

Note:
Perform this procedure for each Exchange front-end server in your environment that is providing Exchange ActiveSync services.

Configuring Integrated Windows Authentication on the Exchange Front-End Servers

For the Exchange front-end servers to accept the Kerberos ticket, the ActiveSync directory needs to be configured to accept Integrated Windows authentication in IIS Manager.

Perform the following procedure to configure Integrated Windows authentication on the Exchange front-end servers.

To configure Integrated Windows authentication for the ActiveSync directory in IIS Manager

In IIS Manager, double-click the local computer, right-click the ActiveSync directory you want to configure, and then click Properties.
Click the Directory Security tab.
In the Authentication and access control section, click Edit.
In the Authenticated access section, select Integrated Windows Authentication.
Click OK twice.

Creating a New Web Listener

You need to create a new Web listener with client authentication configured with client certificate authentication.

Follow the instructions in the topic Create a Web listener, with the following change:

On the Authentication Settings page, select SSL Client Certificate Authentication.

Creating a New Exchange Publishing Rule

To create a new Exchange publishing rule, follow the instructions in the topic Create an Exchange Web client access publishing rule, with the following changes:

On the Select Services page, select Exchange ActiveSync only.
On the Authentication Delegation page, select Kerberos constrained delegation. The service principle name will be automatically entered, based on the information you entered in the Internal site name box on the Internal Publishing Details page.