2003 RPCHTTP

ISA Server 2000 Exchange 2000/2003 Deployment Kit
Configuring ISA Server 2000 to Support Outlook 2003 RPC over HTTP
Exchange Server 2003 allows Outlook 2003 clients installed on Windows XP Service Pack 1 and
above full MAPI client access using the new RPC over HTTP protocol. RPC over HTTP allows
the RPC commands required for full Outlook 2003 MAPI client access to wrapped or
“encapsulated” in an HTTP header and passed through proxies that allow outbound HTTP.
In addition, you can secure RPC over HTTP communications using SSL. The RPC over HTTP
protocol solves the problem of remote access to the full suite of Exchange Server 2003 services
through firewalls that allow only HTTP and HTTPS (SSL) outbound to the Internet. Another
advantage of the RPC over HTTP protocol is that it can leverage the security and functionality
provided by the front-end/
Configuring ISA Server 2000 to Support Outlook 2003 RPC over HTTP 1
You need to carry out the following procedures to create a secure RPC over HTTP publishing
solution using ISA Server 2000:
• Install an enterprise CA
• Assign machine certificates to the front end and back end Exchange Servers
• Install the back end Exchange Server
• Install the RPC over HTTP service on the front end server
• Configure the front end Exchange Server to listen on a single address
• Request and install a Web site certificate for the front end Web site
• Export the Web site certificate to a file
• Force SSL and basic authentication on the RPC directory
• Configure the Registry entries on the front end server and restart
• Configure IPSec security between the front end and back end (optional)
• Install Windows Server 2003 on the firewall computer
• Install the ISA Server on the firewall computer
• Import the Web site certificate into the ISA Server firewall’s machine store
• Configure Web or Sever Publishing Rules on the ISA server firewall
• Install the URLScan Filter on the ISA Server 2000 Firewall Computer (optional)
• Warning regarding client certificate authentication between the ISA Server firewall and
the front end Exchange Server Web site
• Configure the Outlook 2003 client to use RPC over HTTP
2 Configuring ISA Server 2000 to Support Outlook 2003 RPC over HTTP
Install an Enterprise Certificate Authority
The Microsoft enterprise Certificate Authority (CA) allows you to issue certificates to all machines
in the Active Directory domain. You can install a Microsoft CA in either standalone or enterprise
mode. There are two primary advantages of using an enterprise CA over a standalone CA:
• You can use the Certificates MMC to obtain a certificate from an online enterprise CA
• You can use Active Directory Group Policy to automatically deploy user and machine
certificates to all domain members
You will use the Microsoft enterprise CA to install machine certificates on the front end and back
end Exchange Servers. These certificates will be used for authentication when you create the
IPSec Policy to secure the link between the front end and back end Exchange Servers.
Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document
Creating the enterprise CA for detailed information on how to install and configure a Microsoft
enterprise CA.
Assign Machine Certificates to the Front End and Back End Exchange Servers
You can use the enterprise CA to assign machine certificates to the front-end and back-end
Exchange Servers. You can use Group Policy to assign these machine certificates or you can
use the Certificates MMC standalone snap-in to assign the certificates.
Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit documents
Issuing certificates via autoenrollment and Issuing certificates via the MMC snap-in for
detailed information on how to issue machine certificates to the front-end and back-end Exchange
Servers
Install the Back End Exchange Server
There are no special requirements for the back-end Exchange Server in the RPC over HTTP
publishing scenario. In the example covered in this ISA Server 2000 Exchange Server
2000/2003 Deployment Kit document, we assume the back-end Exchange Server is a domain
controller for the domain that all Exchange Servers belong to. While we realize that it is not best
practice, this is the configuration we use on the lab network setup in this document.
Please refer to TechNet document Microsoft Exchange 2000 Server Front-End and Back-End
Topology for details on specific requirements for front-end and back-end Exchange Servers.
Install the Front End Exchange Server and the RPC over HTTP Service
The front-end Exchange Server acts as a “proxy” for RPC messages that are carried via the
HTTP protocol. This proxy function allows the front-end Exchange Server to receive the RPC
messages contained within the HTTP protocol headers and forward these messages to the back-
end Exchange Server.
The front-end Exchange Server is a proxy for these messages because the front-end Exchange
server is not the endpoint for these messages. The front-end Exchange Server only accepts
these messages, removes the HTTP header, and forwards them to the back end Exchange
Server. When the back-end sends its replies, the replies are accepted by the front-end Exchange
Server that’s acting as a RPC over HTTP proxy. The front-end Exchange Server encloses the
RPC reply it received from the back-end Exchange Server in an HTTP header and forwards this
reply to the Outlook 2003 client.
Install and configure the front-end Exchange Server according to the guidelines in Microsoft
Exchange 2000 Server Front-End and Back-End Topology. After the front-end Exchange
Server is installed, the next step is to install the RPC over HTTP Proxy networking service.
Perform the following steps to install the RPC over HTTP Proxy networking service on the front-
end Exchange Server:
1. Click Start, point to Control Panel and click on Add or Remove Programs. In the Add
or Remove Programs window, click on the Add/Remove Windows Components
button (figure 1).
Figure 1
2. In the Windows Components dialog box, click on the Networking Services entry in the
Components list and then click the Details button (figure 2).
Figure 2
3. In the Networking Services dialog box (figure 3), put a checkmark in the RPC over
HTTP Proxy checkbox and click OK.
Figure 3
4. Click Next in the Windows Components dialog box, click Next (figure 4).
Figure 4
5. An Insert Disk dialog box may appear asked you to insert the Windows CD-ROM (figure
5). Click OK.
Figure 5
6. Enter a path to the i386 folder in the Files Needed dialog box (figure 6). Click OK.
Figure 6
7. Click Finish on the Completing the Windows Components Wizard page (figure 7).
Figure 7
Close the Add or Remove Programs window.
Configure the Front End Exchange Server Web Service to Listen on a Single IP Address
You should configure the front-end Exchange Server’s Web site to listen on a specific IP address.
This helps facilitate the Web or Server Publishing Rules you create on the ISA Server firewall that
allow inbound access to the RPC over HTTP service on the front-end Exchange Server.
Perform the following steps to configure the front-end Exchange Server to listen on a specific IP
address:
1. Click Start, point to Administrative Tools and click on Internet Information Services
(IIS) Manager. In the Internet Information Services (IIS) Manager console, expand
your server name and then expand the Web Sites node. Right click on the Default Web
Site node and click Properties (figure 8).
Figure 8
2. In the Default Web Site Properties dialog box, click select your IP address from the list
of IP addresses in the IP address list (figure 9).
Figure 9
3. Click Apply and then click OK in the Default Web Site Properties dialog box and then
close the Internet Information Services (IIS) Manager console (figure 10).
Figure 10
Request and Install a Web Site Certificate on the Front End Exchange Server
The front-end Exchange Server’s Web site requires a certificate so that you can enforce SSL
connections between the ISA Server firewall and the front-end Exchange Server. In addition, the
front-end Exchange Server’s Web site requires a certificate so that the ISA Server firewall can
impersonate the site when external Outlook 2003 clients create an SSL link with the firewall’s
external interface.
You will then export the Web site certificate after the front-end Exchange Server obtains a
certificate. The exported file is copied to the ISA Server firewall and imported into the firewall’s
local machine certificate store and bound to the Incoming Web Requests listener.
Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document How
to Obtain a Web Site Certificate for details on how to obtain a Web site certificate for the front-
end server.
Export the Web Site Certificate to a File
The ISA Server 2000 firewall computer performs SSL to SSL bridging to protect the connection
from the remote OWA client to the front-end server, end to end. This end to end protection is
important because the implicit assumption made by the remote host is that if the initial connection
requires a secure link, then the entire transaction is protected by an encrypted link.
SSL to SSL bridging allows the external Web browser to create an encrypted SSL link with the
external interface of the ISA Server 2000 firewall. The ISA Server firewall decrypts the packets
and inspects them for validity and drops all invalid packets. The ISA Server firewall then
establishes a second SSL session between its own internal interface and the front-end Exchange
Server, re-encrypts the packets, and forwards them to the front-end Exchange server.
You can not use SSL to protect the communications between the front-end Exchange Server and
the back-end servers. However, you can use IPSec transport mode connections to protect all
data moving between the front-end and back-end Exchange Servers. This meets the implicit
requirement for an end to end encrypted link.
The ISA Server 2000 firewall impersonates the front-end OWA Web site by presenting the OWA
Web site’s certificate to the remote OWA client. The name of the OWA Web site is contained in
the certificate; this is the mechanism of impersonation.
Perform the following steps to export the Web site certificate from the OWA server:
1. Click Start, point to Administrative Tools and click on Internet Information Services.
In the Internet Information Services (IIS) Manager console (figure 11), expand the
Web Sites node and click on the Default Web Site entry. Right click on Default Web
Site and click Properties.
Figure 11
2. Click on the Directory Security tab in the Default Web Site Properties dialog box
(figure 12). Click on the View Certificate button.
Figure 12
3. In the Certificate dialog box, click on the Details tab (figure 13). Click on the Copy to
File button.
Figure 13
4. Click Next on the Welcome to the Certificate Export Wizard page (figure 14).
Figure 14
5. Select the Yes, export the private key option on the Export Private Key page (figure
15). Click Next.
Figure 15
6. On the Export File Format page (figure 16), select the Personal Information Exchange
– PKCS #12 (.PFX) option. Put a checkmark in the Include all certificate in the
certification path if possible checkbox. Remove the checkmarks from the Enable
strong protection (requires IE 5.0, NT 4.0 SP4 or above) and Delete the private key
if the export is successful checkboxes.
The enable strong protection option requires user intervention before the certificate can
be used to establish a connection. The server on which the certificate is installed cannot
perform the required actions. That is why you must not select that option. You do not
want to delete the private key from the OWA site, because you want to keep the key
there for backup.
Click Next.
Figure 16
7. On the Password page, type a password and then confirm the password. This password
protects the private key from being stolen by anyone who might be able to obtain the
exported file (figure 17).
Figure 17
8. On the File to Export page (figure 18), type in a path and file name for the certificate file.
Remember where you store the file because you need to copy it to the ISA Server
machine in the DMZ. Click Next.
Figure 18
9. Review your settings on the Completing the Certificate Export Wizard page (figure 19)
and click Finish.
Figure 19
10. Click OK on the Certificate Export Wizard dialog box that informs you the export was
successful (figure 20).
Figure 20
11. Close the Certificate dialog box (figure 21).

Figure 21
12. Close the Default Web Site Properties dialog box (figure 22).
Figure 22
Force SSL and Basic Authentication on the RPC Directory
The external Outlook 2003 clients will use SSL to connect to the external interface of the ISA
Server firewall. The ISA Server firewall uses SSL to protect the connection between the internal
interface of the firewall and the front-end Exchange Server’s Web site. The Outlook 2003 client
will use basic authentication to authenticate with the ISA Server firewall’s Incoming Web
Requests listener and the firewall will forward these basic credentials to the front-end Exchange
Server’s Web site.
You need to force basic authentication on the front-end Exchange Server’s RPC directory to
insure the best performance and compatibility. The user credentials are protected by SSL
encryption so you do not need to worry about the clear text credentials being captured by an
intruder. In addition, we will force an SSL connection between the firewall and the RPC directory.
This presents any host, including the firewall, from using a non-secure connection to the front-end
server’s RPC directory.
Perform the following steps to force basic authentication and SSL encryption on the front-end
Exchange Server’s RPC directory:
1. Click Start, point to Administrative Tools and click on Internet Information Services
(IIS) Manager. In the Internet Information Services (IIS) Manager, expand your server
name and then expand the Web Sites node. Click the Rpc node in the left pane of the
console and right click an empty area in the right pane. Click on the Properties
command (figure 23).
Figure 23
2. Click on the Directory Security tab in the Rpc Properties dialog box (figure 24). Click
on the Edit button in the Secure communications frame.
Figure 24
3. In the Secure Communications dialog box, put a checkmark in the Require secure
channel (SSL) and Require 128-bit encryption checkboxes (figure 25). Click OK.
Figure 25
4. Click the Edit button in the Authentication and access control frame (figure 26).
Figure 26
5. In the Authentication Methods dialog box (figure 27), put a checkmark in the Basic
authentication (password is sent in clear text) checkbox.
Figure 27
6. An IIS Manager dialog box appears informing your that there are risks to using basic
authentication. That’s OK because we’re using SSL to protect the credentials and the
data. Click Yes (figure 28).
Figure 28
7. Remove the checkmarks from the Enable anonymous access and Integrated
Windows authentication checkboxes (figure 29). Click OK.
Figure 29
8. Click Apply and then click OK in the Rpc Properties dialog box (figure 30).
Figure 30
9. Close the Internet Information Services (IIS) Manager (figure 31).

Figure 31
Close the Internet Information Services (IIS) Manager console.
Configure the Registry Entries on the Front End Exchange Server
The front-end Exchange Server that is acting as an RPC over HTTP proxy server needs to know
the names of the back-end Exchange Servers and global catalog servers. You will need to
navigate to the Registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy and
change the value of the Valid Ports entry.
The change to the ValidPorts value is entered using the following format:
ExchangeServerFQDN:593;ExchangeServerFQDN:1024-
65535;GlobalCatalogServerFQDN:593;GlobalCatalogServerFQDN:1024-65535
Note:
These entries are entered as a single line in the Registry editor; the edit value dialog box
does not wrap line.
For example, if the back-end Exchange Server is named beexchange2003.internal.net and the
Global Catalog Server is named dc.internal.net, the entries would look like this:
beexchange2003.internal.net:593; beexchange2003.internal.net:1024-65535; dc.internal.net:593;

dc.internal.net:1024-65535
You will use fully qualified domain names in this Registry entry. The internal network DNS
infrastructure should already be in place because these machines all belong to an Active
Directory domain. The front-end Exchange Server must be able to resolve the FQDNs of the back
end Exchange and Global Catalog servers.
Note:
You do not need to configure specific ports to be used on the Global Catalog server because
the Global Catalog server and the Exchange Servers are ISA Server firewall LAT hosts. LAT
hosts have full access to each other and communications between them are not screened by
firewall policy. Never put a front-end Exchange Server on a DMZ segment.
Perform the following steps to configure the Registry on the front-end Exchange Server:
1. Click Start and then click the Run command. Type regedit in the Open text box and click
OK. In the Registry Editor, drill down to the following Registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy
Right click on the ValidPorts value and click Modify (figure 32)
Figure 32
2. Enter the information in the Value Data text box for the back-end Exchange Server and
the Global Catalog server using the format:
ExchangeServerFQDN:593;ExchangeServerFQDN:1024-
65535;GlobalCatalogServerFQDN:593;GlobalCatalogServerFQDN:1024-65535
Click OK after entering the information.
Figure 33
Restart the front-end Exchange Server computer.
Configure IPSec Policy to Secure All Communications Between the Front End and Back
End Servers (optional)
The link between the OWA client and the external interface of the ISA Server firewall is protected
by SSL encryption. In addition, the link between the internal interface of the ISA Server firewall
and the front-end Exchange Server is protected by SSL encryption. The problem is that the link
between the front-end and back-end Exchange Server is not protected by SSL encryption. You
can not use SSL between the front-end and back-end Exchange servers.
You can solve this problem by applying IPSec Policies to force a secure, encrypted link between
the front-end and back-end Exchange servers. The IPSec encrypted link protects messages
moving between the front-end and back-end, and provides the end to end encryption the OWA
client implicitly expects when it creates the secure link with the external interface of the ISA
Server.
There are several ways you can implement IPSec Policies. The two most popular methods are to
create a Group Policy-based security policy and deploy IPSec Policies via domain group policy.
Another method is to use local security policy on the front-end and back-end Exchange servers.
There are several ways to enforce authentication between the front-end and back-end Exchange
Servers when they establish their IPSec links. In this following example we assume that the front-
end and back-end Exchange Servers have received machine certificates from the same CA. We
will use certificate authentication as the preferred authentication method in the IPSec Policy.
Perform the following steps to create the IPSec transport mode secure connection between the
front-end and back-end Exchange Servers:
1. Go to the front-end Exchange Server, click Start, point to Administrative Tools and click
on Local Security Settings. In the Local Security Settings console, click on the IP
Security Policies on Local Computer node in the left pane of the console. Right click
on an empty area in the right pane of the console and click the Create IP Security
Policy command (figure 34).
Figure 34
2. Click Next on the Welcome to the IP Security Policy Wizard page (figure 35).
Figure 35
3. On the IP Security Policy Name page (figure 36), give the policy a name in the Name
text box. Enter an optional description for the policy in the Description text box. Click
Next.
Figure 36
4. On the Requests for Secure Communication page (figure 37), remove the checkmark
from the Activate the default response rule checkbox and click Next.
Figure 37
5. On the Completing the IP Security Policy Wizard page (figure 38), put a checkmark in
the Edit properties checkbox and click Finish.
Figure 38
6. The Properties dialog box for the policy appears (figure 39). Keep in mind that a security
policy consists of a set of rules. If any of the conditions we set in any of the rules matches
a connection, then the settings of the rule are triggered. The only rule included in the
policy at this point is the default response rule, but it is not selected and we will not select
it. Instead, we will add our own rule. Make sure that there is a checkmark in the Use Add
Wizard checkbox and click the Add button.
Figure 39
7. Click Next on the Welcome to the Create IP Security Rule Wizard page (figure 40).
Figure 40
8. We are creating a transport mode connection between the front-end and back-end
Exchange Servers. Therefore, on the Tunnel Endpoint page select the This rule does
not specify a tunnel option (figure 41).
Figure 41
9. Select the All network connections option on the Network Type page (figure 42). Click
Next.
Figure 42
10. An IP filter list contains IP addresses, computer names, or network IDs and protocol
information. When a connection matches a connection specified in the IP filter list, then a
filter action is applied. In this example we will create an IP filter list that contains the
source IP address being the back-end Exchange Server and the destination IP address
being the front-end Exchange Server. We will also configure the IP filter list to match all
protocol connections inbound from the back-end Exchange Server to the front-end
Exchange Server.
On the IP Filter List page, click the Add button (figure 43). In the IP Filter List dialog
box, type a name for the filter list in the Name text box. Type an optional description in
the Description text box. To add filters to the list, make sure there is a checkmark in the
Use Add Wizard checkbox and click the Add button.
Figure 43
11. Click Next on the Welcome to the IP Filter Wizard page (figure 44).
Figure 44
12. On the IP Filter Description and Mirrored property page (figure 45), type in a
description of the filter in the Description text box. You should enter information about
the nature of the filter, such as the source and destination addresses and the protocols.
In our example, we have a single front-end and back-end Exchange Server, so we’ll just
call it OWA.
Put a checkmark in the Mirrored. Match packets with the exact opposite source and
destination addresses option. This will allow the trigging of the filter action when
packets moving in the opposite direction as specified in the filter as detected by the
IPSec Policy Agent.
Figure 45
13. On the IP Traffic Source page (figure 46), select the A specific IP Address option in
the Source address drop down list. In the IP Address text box, type in the IP address of
the back-end Exchange Server. You will have to repeat the step if you have multiple
back-end Exchange Servers. Click Next.
Figure 46
14. On the IP Traffic Destination page (figure 47), select the My IP Address option from the
Destination address drop down list. Click Next.
Figure 47
15. On the IP Protocol Type page (figure 48), left the default setting of Any in the Select a
protocol type drop down list. We want to match all packets moving between the front-
end and back-end Exchange Servers, so we match all protocols with this filter list entry.
Click Next.
Figure 48
16. Do not put a checkmark in the Edit properties checkbox, then click Finish on the
Completing the IP Filter Wizard page (figure 49).
Figure 49
17. The IP filter that matches all protocols for communications between the front-end and
back-end Exchange Server. You have completed the configuration of the IP filter list that
matches the packets moving between the front-end and back-end Exchange Server.
Click OK to continue create the rule that secures the connection between the front-end
and back-end Exchange Servers.
Figure 50
18. On the IP Filter List page (figure 51), select the IP filter list you created in the IP Filter
lists box. Click Next.
Figure 51
19. On the Filter Action page (figure 52), select the Require Security option from the Filter
Actions list.
When a packet matches the source and destination, as well as protocol included in the
filter list, then a Filter Action is triggered. We are creating a rule that includes a filter list
we created that matches all protocol packets between the front-end and back-end
Exchange Servers. When packets match these conditions, then the Filter Action is
applied. The Require Security filter action will require that all packets moving between
the front-end and back-end Exchange Server are security with IPSec encryption.
Click Next.
Figure 52
20. On the Authentication Method page (figure 53), you can choose from Active Directory
default (Kerberos V5 protocol), Use a certificate from this certification authority
(CA) and Use this string to protect the key exchange (preshared key) options.
You and use the Active Directory default option if the front-end and back-end machines
belong to the same domain. You can enhance security by using the Use a certificate
from this certification authority (CA) option. The front-end and back-end Exchange
Server must have machine certificates from the same CA (or in a more complex
environment, trust the CAs that issued each other’s machine certificates).
In the current example, we have already deployed machine certificates to both the front-
end and back-end Exchange Servers, so select the Use a certificate form this
certification authority (CA) and click Browse.
Figure 53
21. On the Select Certificate dialog box (figure 54), find the CA certificate for your root CA
on the internal network and select it. Then click OK.
Figure 54
22. The CA information appears in the text box (figure 55). Click Next.
Figure 55
23. Put a checkmark in the Completing the Security Rule Wizard checkbox and click
Finish (figure 56).
Figure 56
24. Click OK on the New Rule Properties dialog box (figure 57).
Figure 57
25. On the Properties dialog box for the policy, click the General tab. You can change the
Name and the Description for this rule on this tab (figure 58). You can click the Settings
button and change core characteristic of the how key exchange is performed. Click OK.
Note:
Details of IPSec negotiation and policy as beyond the scope of this ISA Server 2000 Exchange
Server 2000/2003 Deployment Kit document. Please refer to Deploying IPSec on the Microsoft
TechNet site.
Figure 58
26. You will need to repeat the procedure on the back-end Exchange Servers. The only
difference between the policy you created on the front-end Exchange Sever and the
back-end Exchange Servers is few settings in the IP Filter. Figure 59 shows the IP
Traffic Source page of the IP Filter Wizard. On the back-end Exchange Servers, make
sure you use the back-end Exchange Server’s address in the source address text box.
Figure 59
27. The Destination address on the back-end Exchange Servers is set for My IP address
(figure 60).
Figure 60
28. The protocol type on the back-end Exchange Server’s is Any. Again, the same as what
we did with the front-end Exchange Servers (figure 61).
Figure 61
29. After the IPSec Policies are created on the front-end and back-end Exchange Servers,
right click on the policy you created to secure communications between the front-end and
back-end Exchange Servers and click the Assign command (figure 62).
Figure 62
30. When the policy is assigned, you will see a Yes entry in the Policy Assigned column
(figure 63).
Figure 63
31. You can test the policy by opening a command prompt and typing the command:
ping –t w.x.y.z
where w.x.y.z is the IP address of another Exchange Server included in the IP filter list.
You will see the ping command report that it is negotiating IP Security and then you will
see ping replies. You can see details of the IPSec negotiation and packet exchange by
using the IP Security Monitor standalone mmc console snap-in (figure 64).
Figure 64
Install Windows Server 2003 on the Firewall Computer
The computer that will become the ISA Server 2000 firewall must meet the following minimum
requirements:
• A personal computer with a 1.5 MHz or higher Intel/AMD-compatible CPU

• For the operating system, Windows 2000 Service Pack 4 or Windows Server 2003
• 256 MB of memory (RAM)
• 20 MB of available hard disk space for program files
• Two network adapters that is compatible with Windows 2000 or Windows Server 2003 ,
for communication with the internal and external networks
• One local hard disk partition that is formatted with the NTFS file system for log files and
Web caching (if you wish to run the ISA Server firewall’s Web caching facilities)
The ISA Server firewall and Web caching components work very well on modest hardware. This
is true even when the SMTP filter is enabled and protecting the published SMTP servers.
However, if you run decide to use the SMTP Message Screener on the firewall, or if you use SSL
to protect Web Published Web site, or if you use the ISA Server firewall as a VPN server, you
need to increase the minimum requirements to support encryption services.
Install ISA Server 2000 on the Firewall Computer
Install ISA Server 2000 after installing Windows Server 2003 onto the firewall computers. You
must go through some specific procedures outside of the standard ISA Server 2000 installation
when installing the firewall software onto a Windows Server 2003 computer. Please refer to ISA
Server 2000 Exchange Server 2000/2003 Deployment Kit document Installing ISA Server
2000 on Windows Server 2003.
Import the Web Site Certificate into the ISA Server Firewall’s Machine Certificate Store
Now that the ISA Server software is installed, you’re ready to copy the Web site certificate file
from the front-end Exchange server to the ISA Server computer. This certificate is imported into
the ISA Server’s machine certificate store and then bound to the Incoming Web Requests
listener.
Perform the following steps to import the OWA server’s Web site certificate into the ISA Server’s
machine certificate store:
1. Click Start and click on the Run command. Type mmc in the Open text box and click
OK. In the Console 1 console, click the File menu and click the Add/Remove Snap-in
Figure 65
2. Click the Add button in the Add/Remove Snap-in dialog box (figure 66).
Figure 66
3. Click on the Certificates entry in the Available Standalone Snap-in list on the Add
Standalone Snap-in dialog box (figure 67). Click Add.
Figure 67
4. Select the Computer account option on the Certificates snap-in page (figure 68). Click
Next.
Figure 68
5. On the Select Computer page, select the Local computer: (the computer this
console is running on) option and click Finish (figure 69).
Figure 69
6. Click Close on the Add Standalone Snap-in page (figure 70).

Figure 70
7. Click OK on the Add/Remove Snap-in dialog box (figure 71).

Figure 71
8. Right click on the Personal node in the left pane of the console, point to All Tasks and
click Import (figure 72).
Figure 72
9. Click Next on the Welcome to the Certificate Import Wizard (figure 73).
Figure 73
10. Click the Browse button and locate the certificate file. Click Next after the file path and
name appear in the File name text box (figure 74).
Figure 74
11. On the Password page, type in the password for the file (figure 75). Do not put a
checkmark in the Mark this key as exportable. This will allow you to back up or
transport you keys at a late time checkbox. The reason is that this machine is a bastion
host with an interface in a DMZ or on the Internet and may be compromised. The
compromiser may be able to steal the private key from this machine if it is marked as
exportable.
Click Next.
Figure 75
12. On the Certificate Store page (figure 76), confirm that the Place all certificate in the
follow store option is select and that is says Personal in the Certificate store box. Click
Next.
Figure 76
13. Review the settings on the Completing the Certificate Import page and click Finish
(figure 77).
Figure 77
14. Click OK on the Certificate Import Wizard dialog box informing you the import was
successful (figure 78).
Figure 78
15. You will see the Web site certificate an the CA certificate in the right pane of the console.
The Web site certificate has the FQDN that is assigned to the Web site. This is the name
external users will use to access the OWA site. The CA certificate must be placed into
the Trusted Root Certification Authorities\Certificates store so that this machine will
trust the Web site certificate installed on it.
Double click on the Web site certificate in the right pane of the console (figure 79).
Figure 79
16. Click on the Certification Path tab on the Certificate dialog box (figure 80). You may
notice a red “x” on the CA certificate node. This indicates that this machine does not trust
the CA that issued the Web site certificate. In order to use this certificate to perform SSL
to SSL bridging, this machine must trust the CA that issued the Web site certificate.
Close the Certificate dialog box.
Note:
If you do not see a red “x” then you do not need to carry out the following steps. The absence of
the red “x” indicates that you already have the Root CA certificate in your Trusted Root
Certification Authorities certificate store.
Figure 80
17. Right click on the CA certificate in the right pane of the console and click the Copy
Figure 81
18. Expand the Trusted Root Certification Authorities node and click the Certificates
node (figure 82). Right click on the Certificates node and click the Paste command. This
pastes the CA certificate into the Trusted Root Certificate Authorities\Certificates
store and allows this machine to trust certificates issued by this CA.
Figure 82
19. Press F5 to refresh the display. You should see the certificate appear in the right pane of
the console (figure 83). If you do not see the CA certificate in the right pane of the
console, repeat the procedure
Figure 83
20. Return to the Personal\Certificates node in the left pane of the console and double click
on the Web site certificate. In the Web site certificate’s Certificate dialog box, click on the
Certification Path tab (figure 84). Notice that the red “x” no longer appears on the CA
certificate. Click OK on the Certificate dialog box.
Figure 84
21. Close the mmc console (figure 85). You may want to save this console with the name of
certificates and store it in the Administrative Tools menu.
Figure 85
Create the Web or Server Publishing Rules on the ISA Server Firewall
Now you’re ready to create the publishing rule that allows inbound access to the front-end
Exchange server. There are two methods you can use to allow inbound access:
• Server Publishing Rules

• Web Publishing Rules
Server Publishing Rules perform a “reverse NAT” function and merely forward the inbound SSL
messages to the front-end Exchange Server. The ISA Server firewall is not able to inspect the
contents of the SSL communication when you use Server Publishing Rules because the data is
protected within an SSL tunnel.
Web Publishing Rules are much more secure. The ISA Server firewall is able to inspect the
contents of the SSL stream because of ISA Server’s ability to perform SSL bridging. The ISA
Server firewall can apply the rules enforced by the urlscan.ini file, as well enforcing the correct
URL and delegating basic authentication, so that the OWA client must authenticate with the
firewall before a single packet is passed back to the front-end Exchange Server.
I highly recommend that you use Web Publishing Rules to publish the front-end Exchange Server
that is acting as an RPC over HTTP proxy computer. However, in some cases, you are forced to
use Server Publishing Rules, so we will cover both procedures in this ISA Server 2000
Exchange Server 2000/2003 Deployment Kit document.
Let’s look at how to create a Server Publishing Rule to allow inbound access to the front-end
Exchange Server. The first step is to confirm that the incoming Web Requests listening is not
listening on TCP port 443.
Perform the following steps to confirm that the incoming Web Requests listener is not listening on
TCP port 443:
1. Open the ISA Management console, expand the Servers and Arrays node and right
click on your server name. Click on the Properties command (figure 86)
Figure 86
2. On the server Properties dialog box (figure 87), click on the Incoming Web Request
tab. Notice that there are two options in the Identification frame:
Use the same listener configuration for all IP addresses This setting allows the ISA
Server firewall to listen on all IP addresses bound to the external interface and use the
same security settings for all inbound requests intercepted by the Incoming Web
Requests listener
Configure listeners individually per IP address This setting allow you to configure a
listener separate. For example, if you have three IP addresses bound to the external
interface of the ISA Server firewall, then you can commit a single address to listening for
inbound connections to Web sites published via Web publishing Rules.
You want to prevent the Incoming Web Requests listener from use TCP port 443. First,
you should always configure listeners on a per listener basis. This gives you control over
the IP addresses used by listeners. Second, you will need to remove the checkmark from
the Enable SSL listeners checkbox.
Note:
When you remove the checkmark from the Enable SSL listeners checkbox, none of your
listeners will be able to listen on TCP 443. This checkbox represents a global setting and you
cannot control it on a per listener basis.
Figure 87
3. Click Apply after removing the checkmark. You will be asked to restart the services. All
the service to restart automatically (figure 88).
Figure 88
4. Click OK in the server Properties dialog box (figure 89).

Figure 89
Removing the SSL listeners allows the Server Publishing Rule to bind TCP port 443. No two
services can use the same IP address and port. This is sometimes referred to as socket
contention.
Creating a Server Publishing Rule
Perform the following steps to create a Server Publishing Rule to allow inbound access to the
inbound RPC over HTTP connection:
1. Open the ISA Management console (figure 90) and expand the Servers and Arrays
node. Expand your server name and then expand the Publishing node. Right click on
the Server Publishing Rules node, point to New and click on Rule.
Figure 90
2. Enter a name for the RPC over HTTP Server Publishing Rule in the Server publishing
rule name text box on the Welcome to the New Server Publishing Rule Wizard page
(figure 91). Click Next.
Figure 91
3. Type in the IP address of the front-end Exchange Server in the IP address of internal
server text box (figure 92). Click the Browse button and select the IP address on the
external interface you want to use in the Server Publishing Rule. Click OK in the New
Server Publishing Rule Wizard dialog box.
Figure 92
4. Click Next on the Address Mapping page (figure 93).

Figure 93
5. On the Protocol Settings page (figure 94), select the HTTPS Server protocol from the
Apply the rule to this protocol list. Click Next.
Figure 94
6. Select the Any request option on the Client Type page (figure 95). Click Next.
Figure 95
7. Review your settings and click Finish on the Complete the New Server Publishing
Rule Wizard page (figure 96).
Figure 96
The Server Publishing Rule will starting working without requiring you to restart the computer or
any services.
Creating a Web Publishing Rule
Web Publishing Rules are a more secure alternative to Server Publishing Rules. They can be a
bit more complex to put together than Server Publishing Rules, but your reward is a much higher
level of security. Creating a Web Publishing Rule to make your front-end Exchange Server’s
HTTP proxy service available can be made a lot easier by leveraging the automation provided by
the OWA Web Publishing Wizard. The OWA Web publishing Wizard is a feature provided by ISA
Server 2000 Feature Pack 1.
The OWA Web Publishing Wizard will do most of the work for you. There are just a couple of
tweaks you have to make to optimize the rule for security and customize it to support RPC over
HTTP publishing.
Perform the following steps to create the Web Publishing Rule that will allow remote access to
both your OWA site and RPC over HTTP:
1. Open the ISA Management console (figure 97). Expand the Server and Arrays node
and then expand your server name. Expand the Publishing node and click on the Web
Publishing Rules node. Right click on the Web Publishing Rules node, point to New
and click Publish Outlook Web Access Server.
Figure 97
2. Type in a name for the rule in the Outlook Web Access Server rule name text box on
the Welcome to the Outlook Web Access Publishing Wizard page (figure 98). Click
Next.
Figure 98
3. On the Name of Published Server page (figure 99), type in the FQDN of the OWA site
in the Internal name or IP address of the Outlook Web Access Server. This
information is used to forward the incoming request to the internal OWA server. You can
use the IP address of the internal server, or the IP address of the external interface of the
firewall protecting the internal OWA server if you are using reverse NAT to publish the
OWA server.
I prefer to use the actual FQDN that the external user uses to connect to the site. This
makes the Web Proxy logs easier to interpret. You can create a HOSTS file entry on the
ISA Server that resolves this name to the IP address you want the incoming request
forwarded to.
Put a checkmark in the Use an SSL connection from the ISA Server to the Outlook
Web Access Server checkbox. This forces the ISA Server to establish an SSL link
between itself and the OWA server. All communications between the ISA Server and the
OWA server are protected by SSL.
Click Next.
Figure 99
4. On the Listeners page (figure 100), enter the URL that the external users will use to
connect to the OWA site. Because we are forcing an SSL connection between the
external client and the ISA Server, we use the URL https://owa.internal.net.
Click Next.
Figure 100
5. On the Secure Connection from Client page (figure 101), put a checkmark in the
Enable SSL. Client must use SSL to connect to the ISA Server checkbox. Click the
Select button.
Select the Web site certificate in the Select Certificate dialog box. Click OK.
Figure 101
6. The Web site certificate appears in the Certificate frame (figure 102). Click Next.
Figure 102
7. Review the settings on the Completing the Outlook Web page and click Finish (figure
103).
Figure 103
8. Select the Save the changes and restart the service(s) option on the ISA Server
Warning dialog box (figure 104), and click Finish.
Figure 104
Review the Settings on the Incoming Web Requests Listener and the OWA Web Publishing
Rule
Let’s now examine the changes the OWA Web Publishing Rule Wizard made to the Incoming
Web Requests listener and the details of the Web Publishing Rule.
Perform the following steps to review the changes to the Incoming Web Requests listener:
1. Open the ISA Management console and expand the Servers and Arrays node (figure
105). Right click on your server name and click the Properties command.
Figure 105
2. In the server’s Properties dialog box (figure 106), click on the Incoming Web Requests
tab. Notice that the Configure listeners individually per IP address has been selected.
This option allows the Incoming Web Requests listener to listen on a specific IP
address instead of all addresses bound to the external interface of the ISA Server.
The Enable SSL listeners checkbox has been enabled. This allows the Incoming Web
Requests listener to accept inbound SSL connection requests. The SSL port is set for
TCP port 443.
Select the listener entry and click the Edit button.
Figure 106
3. The Outlook Web Access Publishing Wizard has configured the listener to use the
primary address bound to the external interface on the ISA Server. Integrated
authentication is enabled by default. The Use a server certificate to authenticate to
web clients option is selected and the OWA Web site’s certificate is bound to the
listener.
The remote OWA client will use only basic authentication when communicating with the
ISA Server. Put a checkmark in the Basic with this domain checkbox (figure 107).
Figure 107
4. Click Yes on the ISA Server Configuration dialog box warning you that basic
credentials are sent in the clear (figure 108).
Figure 108
5. Enter the name of your domain in the Domain Name text box on the Select Domain
dialog box (figure 109) and click OK.
Figure 109
6. Remove the checkmark from the Integrated checkbox. You want the remote OWA
clients to use only basic authentication and not try to negotiate integrated authentication
(figure 110). Click OK.
Figure 110
7. Select the Save the changes and restart the service(s) option and click OK (figure
111).
Figure 111
8. Click OK in the server’s Properties dialog box (figure 112).

Figure 112
The Outlook Web Access Web Publishing Wizard created the Web Publishing Rule that allows
the ISA Server to forward the incoming requests to owa.internal.net to the OWA server on the
internal network. Note that the FQDN in the request is critical. This FQDN must match exactly the
name on the Web site certificate. The client will not be able to establish an SSL link to the
Incoming Web Requests listener if there is a mismatch between the FQDN the client uses to
access the OWA server, the FQDN of the server in the Destination Set and the name of the OWA
server on the certificate.
Let’s look at some of the details of the Web Publishing Rule created by the Wizard and tune it up
a bit:
1. In the ISA Management console (figure 113), expand your Servers and Arrays node
and expand your server name. Expand the Publishing node and click on the Web
Publishing Rules node. Double click on the OWA Web publishing rule you created.
Figure 113
2. Click on the Destinations tab (figure 114). Notice that the This rule applies to option is
set to Selected destination set. The name of the Destination Set is listed in the Name
drop down list. The specific destinations included in this Destination Set are seen in the
Destinations included in set list.
These destinations include the FQDN of the OWA server and the directories that external
users are allowed to access. These path entries are:
/exchweb*
/public*
/exchange*
The wildcard entry at the end of the path indicates that the external client can access all
files and folders under the exchweb, public and exchange folders.
Figure 114
3. Click on the Action tab. Notice that the Redirect the request to this internal Web
server (name or IP address) option is selected (figure 115). The FQDN of the OWA site
is entered into the text box under this option. This FQDN must resolve to an IP address
that can accept incoming requests to the OWA site. We will create a HOSTS file entry
later that insures that the requests are forwarded correctly.
The Send the original host header to the publishing server instead of the actual
one (specified above) check is enabled. Do not disable this checkbox.
Put a checkmark in the Allow delegation of basic authentication credentials

checkbox. This allows the ISA Server to forward the basic authentication credentials to
the OWA site on the internal network. This allows only authenticated connections to be
made to the OWA site. If the client is not authenticated, no packets are forwarded to the
internal site.
Figure 115
4. Click on the Bridging tab (figure 116). In the Redirect HTTP requests as frame has the
SSL requests (establish a secure channel to the site) option select. This setting will
be ignored because all connections must be SSL; no non-SSL connections will be
accepted.
The SSL requests (establish a new secure channel to this site) option is select in the
Redirect SSL requests as) frame. This setting insures that SSL requests are bridged as
SSL requests (SSL to SSL bridging). The external client establishes an SSL connection
with the ISA Server, then the ISA Server establishes a new SSL connection with the
OWA site on the internal network.
Put a checkmark in the Require secure channel (SSL) for published site checkbox.
This setting forces the external client to successfully negotiate an SSL connection. If the
client cannot negotiate an SSL link, the connection is dropped. Put a checkmark in the
Require 128-bit encryption checkbox if you know that all your OWA clients support 128-
bit (almost all Microsoft clients now support 128-bit encryption).
You do not need to select the Use a certificate to authenticate to the SSL Web server
checkbox. This is only required if you want to require the ISA Server to use a client
certificate to authenticate to the OWA web site. This feature increases security by forcing
the ISA Server to present a client certificate to the OWA server before it can connect to it.
We will not cover this procedure in this ISA Server 2000 Exchange Server 2000/2003
Deployment Kit document.
Figure 116
5. In the ISA Management console, expand the Policy Elements node and click on the
Destination Sets node. Right click on the Destination Set created by the OWA Wizard
and click the Properties command (figure 117).
Figure 117
6. Click the Destinations tab in the Destination Properties dialog box (figure 118). Click
Add.
Figure 118
7. In the Add/Edit Destination dialog box, select the Destination option and put the FQDN
of the OWA/RPC site in the text box (figure 119). In the Path text box, type /rpc*
Click OK.
Figure 119
8. Click Apply and then click OK in the Destination Set Properties dialog box (figure 120).
Figure 120
9. Close the ISA Management console (figure 121).

Figure 121
Note:
You can remove the OWA related from the Destination Set created by the OWA Publishing
Wizard if you do not want to make OWA available to external network hosts. Open the
Destination Set created by the Wizard and remove the /exchange*, /exchweb* and /public*
entries from the list.
Close the ISA Management console.
Notice that the Web Publishing Rule uses the name of the OWA server, owa.internal.net, in the
redirect. This FQDN must resolve to an IP address that can reach the OWA server on the internal
network. If you are routing between the DMZ and the internal network, the FQDN must resolve to
the actual IP address of the OWA server. If you are performing reverse NAT between the OWA
server and the DMZ (such as a Server Publishing Rule in ISA Server 2000), then the FQDN must
resolve to the address of the external interface of the firewall on the edge of the private network.
You can configure a DNS server to support DMZ hosts, or you can use a HOSTS file on the Web
ISA Server to forward the requests to the correct IP address.
Perform the following steps to create the HOSTS file on the ISA Server:
1. Open Windows Explorer and navigate to \WINDOWS\system32\drivers\etc directory

and open the hosts file.
2. In the Open With dialog box, select the Notepad entry and click OK.
3. The hosts file is opened in Notepad. Put a line at the end of the hosts file that resolves
the name in the redirect to the IP address that can reach the OWA server on the internal
network. For example, if the firewall in front of the OWA server on the internal network is
performing reverse NAT to publish the internal OWA site, and the redirect is
owa.internal.net, then you would put in the following entry:
10.0.0.2 owa.internal.net
Where “10.0.0.2” is the IP address on the external interface of the internal network
firewall that is publishing the internal network OWA site, and owa.internal.net is the entry
in the Web Publishing Rule for the redirection. Make sure you press ENTER after you put
this line into the hosts file so that there is an empty line at the end of the file.
4. Close Notepad and click OK to save the changes made to the file.
Install the URLScan Filter on the ISA Server 2000 Firewall Computer (optional)
The URLScan filter is an optional component of the ISA Server 2000 Feature Pack 1. This
version of URLScan installs directly on the ISA Server 2000 firewall computer. Like the version of
URLScan that installs on the Web server, the Feature Pack 1 version of URLScan examines
incoming HTTP connections for invalid commands and requests. Validity is determined by the
settings in the urlscan.ini file.
You can download the ISA Server 2000 Feature Pack 1 version of URLScan from the ISA Server
2000 Feature Pack 1 Web site. Download the isafp1ur.exe file from the site and run the
installation program. Follow the onscreen instructions. If you are not familiar with the URLScan
tool, review the readme file before installing.
You will be asked what version of urlscan.ini you want to use when installing URLScan. Choose
the Outlook Web Access version of the file. However, this version of urlscan.ini does not contain
all the required settings to allow RPC over HTTP to work properly. You will need to open the
urlscan.ini file in the \Program Files\Microsoft ISA Server directory and add the following
entries:
[RequestLimits]
; The entries in this section impose limits on the length
; of allowed parts of requests reaching the server.
MaxAllowedContentLength=2000000000
MaxUrl=16384
MaxQueryString=4096
In addition, you need to add the following verbs to the Allow Verbs:
RPC_IN_DATA
RPC_OUT_DATA
(thanks go to Jim Harrison for discovering these required settings)
Be sure to install URLScan on the ISA Server 2000 firewall using the OWA template. The
installation Wizard will ask you to make this decision during the course of installation.
Warning Regarding Client Certificate Authentication between the ISA Server Firewall and
the Front End Exchange Server Web Site
You can install a client certificate on the ISA Server firewall and configure the OWA site
directories to require a client certificate to authenticate to these directories. This increases the
level of security afforded to the OWA publishing scenario. However, if you require client certificate
authentication on the \Rpc directory, the connection will fail and the external RPC over HTTP
client will not be able to connect to the Exchange Server.
If you decide to publish both OWA and RPC over HTTP directories, you can force client certificate
authentication on the OWA directories and not require client certificate authentication on the \Rpc
directory. Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit
document Increasing OWA Security by Configuring the ISA Server to Present a Client
Certificate to an OWA Web site for more information on how to configure client certificate
authentication to the OWA site directories.
Configure the Outlook 2003 Client to use RPC over HTTP
You must use Outlook 2003 running on Windows XP Service Pack 1 to connect using the RPC
over HTTP connection method. In addition, you must install the hotfix mentioned in Microsoft KB
article Outlook 11 Performs Slowly or Stops Responding When Connected to Exchange
Server 2003 Through HTTP. Download and install the hotfix before configuring a profile that
allows the user to connect to the Exchange Server.
It is important to note that you must create the profile while the Outlook 2003 computer is on the
internal network, or while the Outlook 2003 computer is on the Internet and can access the
Exchange Server using RPC (TCP 135). You will not be able to create a new profile or change an
existing profile to use RPC over HTTP if is does not have access to the Exchange Server via
RPC (TCP 135).
This bears repeating: you will not be able to create a new Outlook profile when the Outlook client
is not on the internal network and can access the Exchange Server using RPC via TCP 135. In
addition, a user with an existing profile will not be able to alter the existing profile so that it can
use RPC over HTTP if that client is not located on the internal network and can access the
Exchange Server using TCP 135. The Outlook 2003 profile must be configured to use RPC over
HTTP while that machine is connected to the internal network and can access the Exchange
Server via TCP port 135.
NOTE:
The above assessment was made based on the pre-release version of Outlook 2003. With
the final version of Outlook 2003, you can create the HTTP over RPC connection while not
connected to the corporate network and without RPC access. Please check
www.isaserver.org for updates on this issue. –Tom.
Perform the following steps to create the Outlook 2003 profile:
1. Click Start and then right click on the Outlook 2003 icon in the menu. Click on the
Properties command (figure 122).
Figure 122
2. Click the Add button in the Mail dialog box (figure 123).
Figure 123
3. Type in a name for the profile in the Profile Name text box (figure 124). Click OK.
Figure 124
4. Select the Add a new e-mail account option in the This wizard will allowyou to
change the e-mail accounts the direction that Outlook uses page (figure 125). Click
Next.
Figure 125
5. On the Server Type page (figure 126), select the Microsoft Exchange Server option
and click Next.
Figure 126
6. On the Exchange Server Settings page (figure 127), type in the FQDN of the front-end
Exchange Server. This must be the same name used on the Web site certificate you
have assigned to the front-end Exchange Server’s Web site. For example, we obtained a
Web site certificate for the front-end Exchange Server’s Web site. The Common Name
(CN) on the Web site certificate is owa.internal.net. Therefore we enter owa.internal.net
in the Microsoft Exchange Server text box.
Type a user account name in the User Name text box. Click the Check Name button to
confirm that the Outlook 2003 client machine can communicate with the front-end
Exchange Server.
Put a checkmark in the Use local copy of Mailbox checkbox.
Click the More Settings button.
Figure 127
7. You can change how Outlook detects the connection state on the General tab of the
Microsoft Exchange Server dialog box (figure 128). Do not make any changes here
unless you have an explicit reason to do so.
Figure 128
8. Click on the Advanced tab (figure 129). Confirm that there is a checkmark in the Use
local copy of Mailbox checkbox. The default selection is Download headers followed
by full item.
Figure 129
9. Click on the Security tab (figure 130). Put a checkmark in the Encrypt information
checkbox. I’m not sure this does anything when you use RPC over HTTP, but encryption
is a good thing, so we’ll enable this checkbox anyhow.
Figure 130
10. Click on the Connection tab (figure 131). Select the Connect using my Local Area
Network (LAN) option. Put a checkmark in the Connect to my Exchange mailbox
using HTTP, then click the Exchange Proxy Settings button.
Figure 131
11. You configure the specifics of the RPC over HTTP session in the Exchange Proxy
Settings dialog box (figure 132). Type in the FQDN to your front-end Exchange Server in
the Use this URL to connect to my proxy server for Exchange text box. This is same
name listed as the Common Name on the Web site certificate.
Put a checkmark in the Mutually authenticate the session when connecting with SSL
checkbox. Put in the FQDN of the front-end Exchange Server (the same name listed on
the Web site certificate) in the Principal name for proxy server text box. Use the
format:
Msstd:FQDN
For example, we use msstd:owa.internal.net for our published front-end Exchange

Server because the Common Name on the certificate is owa.internal.net.
Put a checkmark in the Connect using HTTP first, then connect using my Local Area
Network (LAN). This is an interesting setting, as its unclear what a “LAN” protocol is in
contrast to an “HTTP” protocol. I assume it means to use unencapsulated RPC
messages, but I can’t say that for sure.
In the Use this authentication when connecting to my proxy server for Exchange
drop down box, select the Basic Authentication option. This forces you to use SSL,
which is OK, because we are using SSL for our links.
Click OK on the Exchange Proxy Settings dialog box.
Figure 132
12. Click Apply and OK on the Microsoft Exchange Server dialog box (figure 133).
Figure 133
13. Click Next on the Exchange Server Settings page (figure 134).
Figure 134
14. Click Finish on the Congratulations! Page (figure 135).

Figure 135
15. Click OK on the Mail dialog box (figure 136).

Figure 136
16. Open Outlook 2003. You will be able to use HTTPS for the connection, as confirm in the
Exchange Server Connection Status window (figure 137). You can access the
connection status window by right clicking on the Outlook 2003 icon in the system tray
and selecting the connection status command right after you start up Outlook 2003.
Figure 137

2003 RPCHTTP

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

2003 RPCHTTP

Hochgeladen von

Copyright:

Verfügbare Formate

ISA Server 2000 Exchange 2000/2003 Deployment Kit

Install an Enterprise Certificate Authority

Install the Back End Exchange Server

Close the Add or Remove Programs window.

Export the Web Site Certificate to a File

11. Close the Certificate dialog box (figure 21).

Force SSL and Basic Authentication on the RPC Directory

9. Close the Internet Information Services (IIS) Manager (figure 31).

Close the Internet Information Services (IIS) Manager console.

Configure the Registry Entries on the Front End Exchange Server

beexchange2003.internal.net:593; beexchange2003.internal.net:1024-65535; dc.internal.net:593;

Click OK after entering the information.

Restart the front-end Exchange Server computer.

Install Windows Server 2003 on the Firewall Computer

• A personal computer with a 1.5 MHz or higher Intel/AMD-compatible CPU

Install ISA Server 2000 on the Firewall Computer

6. Click Close on the Add Standalone Snap-in page (figure 70).

7. Click OK on the Add/Remove Snap-in dialog box (figure 71).

Close the Certificate dialog box.

• Server Publishing Rules

4. Click OK in the server Properties dialog box (figure 89).

Creating a Server Publishing Rule

4. Click Next on the Address Mapping page (figure 93).

Creating a Web Publishing Rule

Select the listener entry and click the Edit button.

8. Click OK in the server’s Properties dialog box (figure 112).

Put a checkmark in the Allow delegation of basic authentication credentials

9. Close the ISA Management console (figure 121).

Close the ISA Management console.

1. Open Windows Explorer and navigate to \WINDOWS\system32\drivers\etc directory

(thanks go to Jim Harrison for discovering these required settings)

Configure the Outlook 2003 Client to use RPC over HTTP

Perform the following steps to create the Outlook 2003 profile:

Put a checkmark in the Use local copy of Mailbox checkbox.

Click the More Settings button.

For example, we use msstd:owa.internal.net for our published front-end Exchange

Click OK on the Exchange Proxy Settings dialog box.

14. Click Finish on the Congratulations! Page (figure 135).

15. Click OK on the Mail dialog box (figure 136).

Das könnte Ihnen auch gefallen