Configuring the Outlook 2000 Email
Client
The Outlook
2000 Email client can access a limited number of Internet mail protocols in
comparison to the Outlook Express, Outlook 2002 and Outlook 2003 clients.
Outlook 2000 supports secure and non-secure versions of the SMTP, POP3 and
Exchange MAPI/RPC protocols. These protocols meet the bulk of connectivity
requirements for most organization’s remote users.
The
following procedures to configure the Outlook 2000 client to connect to secure
Exchange Server services:
The
remainder of this ISA Server 2000
Exchange Server 2000/2003 Deployment Kit document discusses the details of
these procedures.
Install the Root CA Certificate on
the Outlook 2000 Client
The root CA
certificate must be in the user certificate store on the machine attempting to
make a secure connection to the Exchange Server or secure SMTP relay. While it
is possible to make a secure connection in some instances when the root CA
certificate is not installed on the OE client, the
user will be presented with error dialog boxes that may be confusing and
generate Help Desk support calls. You can circumvent this problem by installing
the root CA certificate on the OE client machine.
Please
refer to ISA Server 2000 Exchange Server
2000/2003 Deployment Kit document
How
to Import the Root CA Certificate into Email Client Certificate Stores
for details on how to import the root CA certificate into the OE client’s
certificate store.
Repair the SMTP Password Saving
Mechanism
Outlook
2000 can be configured to save the SMTP server
password so that you do not need to re-enter the password each time you start
Outlook 2000. The problem is that Outlook 2000 will not save this password if you
have not made a few changes in the Registry to support SMTP server password
saving.
Note:
You do not need to perform the following steps if the SMTP server does not
require SMTP authentication.
Perform the
following steps on either a Windows 2000 or Windows XP computer to save the
SMTP password in Outlook 2000:
Windows 2000
HKEY_CURRENT_USER\Software\Microsoft\Protected Storage System Provider
The user subkey folder looks similar to the following example:
S-1-5-21-124525095-708259637-1543119021-16701
NOTE: For every identity that you have,
there will be a subkey under the Protected Storage
System Provider key. To resolve this problem in all of your identities, you
must delete all of the user subkeys folders under the
Protected Storage System Provider key.
Windows XP
HKEY_CURRENT_USER\Software\Microsoft\Protected Storage System Provider
The user subkey folder looks similar to the following example:
S-1-5-21-124525095-708259637-1543119021-16701
NOTE: For every identity that you have,
there may be a subkey under the Protected Storage
System Provider key. To resolve this issue in all of your identities, you must
delete all of the user subkeys folders under the
Protected Storage System Provider key.
Configure the Outlook 2000 Client to
Use a Global Catalog Server
The Outlook
2000 client must be configured to use a specific
global catalog server. This allows you to create the appropriate public DNS
entries that allow the Outlook 2000 clients to resolve the name of the global
catalog server to the external IP address on the ISA Server that you’re using
in the secure Exchange RPC Publishing Rule. You need to make the following
changes in the Registry of the Outlook 2000 client if you wish it to access the
full range of Exchange Server services via a secure Exchange RPC Publishing
Rule.
Perform the
following steps to “hard code” a Global Catalog Server name on the Outlook 2000
client:
HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider
Note: You may have to create both the
Exchange key and the Exchange Provider key.
For
example, if the Global Catalog Server’s name is beexchange2003.internal.net, you would enter that same name in the Value name text box in the Registry
editor. Your private and public DNS
servers must be able to resolve this name appropriately so that when the client
is on the internal network, the address is resolve to the Global Catalog
server’s internal address and when the client is on an external network it
resolves the Global Catalog server’s name to the IP address used as the
external address on the ISA Server’s secure Exchange RPC Server Publishing
Rule.
Note:
It is critically important that the Outlook 2000 client be able to resolve the
name of the Global Catalog server to the IP address on the ISA Server firewall
on which the secure Exchange RPC Publishing Rule is configured.
Configure the Outlook 2000 Client
for Secure SMTP and POP3 Connections
Perform the
following steps to create an Outlook 2000 profile for an SMTP/POP3 connection:
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11
Type in the IP address or FQDN of
the POP3 server in the Incoming mail
(POP3) text box. Note that if you use the IP address the IP address must be the same as
the IP address used on the external interface of the ISA Server firewall that is used in the POP3 Server Publishing Rule. If you use a
FQDN, the name must resolve to the address on the external interface of the ISA
Server firewall that is used by the POP3 Server
Publishing Rule.
In the Outgoing mail
(SMTP) text box, type in the IP address or FQDN of the SMTP server. If you
use an IP address, the IP address can be either the address provided by the
ISP, or the address on the external interface of the ISA Server firewall that
you used in an SMTP Server Publishing Rule. Note that you do not need to
provide a secure, authenticating SMTP server for your remote clients. However,
if you do, you should enter the FQDN of your SMTP server, where the FQDN
resolves to the IP address on the external interface of the ISA Server firewall
that you used in the SMTP Server Publishing Rule.
Note:
If you publish a secure, authenticating SMTP server, you must use a FQDN in the
text box. The same is true for secure authenticating POP3 servers. The FQDN you
enter into these text boxes must match the common name on Web site certificate
bound to the secure POP3 and secure SMTP services.
If you require authentication with the SMTP server, put a
checkmark in the My server requires authentication
checkbox. Click the Settings button.
In the Outgoing Mail Server dialog
box, you have two options: Use same
settings as my incoming mail server and Log on using. You will typically use the same user name and
password you use for your POP3 server if you are publishing your own POP3 and
SMTP servers. However, if you are using an ISP SMTP server, you might want to
use alternate credentials to authenticate with the SMTP service if your ISP’s SMTP requires
authentication (which is not typical).
Figure 12
Put a checkmark in the Leave
a copy of messages checkbox if you do not want the messages to be removed from the Exchange Server after the Outlook 2000
POP3 client receives them. This is useful if you want to use the full MAPI
features included in Outlook when the Outlook 2000 client returns to the
office.
Click Apply and
then click OK.
Figure 13
Figure 14
Figure 15
Figure 16
Configure the Outlook 2000 Client
for Secure RPC Connections
Perform the
following steps on the Outlook 2000 client that accesses the Exchange Server
via a secure Exchange RPC Publishing Rule:
1.
Right click on the Outlook 2000 icon
on the desktop and click the Properties
command (figure 17).
Figure 17
2.
In the Select the information service(s) that you want to use with Microsoft
Outlook page (figure 18), select the Use
the following information services option and then put a checkmark in the Microsoft Exchange Server checkbox.
Click Next.
Figure 18
3.
On the Microsoft Exchange Server page, put in the FQDN that resolves to
the IP address that you are using in the Secure Exchange RPC Server Publishing
Rule on the external interface of the ISA Server firewall.
The FQDN you enter in the Microsoft Exchange server text box must resolve to the correct IP
address on the external interface of the ISA Server firewall. When the Outlook
2000 client is connected to an external network, this
address is the IP address on the external interface of the ISA Server firewall
used by the secure Exchange RPC Server Publishing Rule. When the client is connected to the internal network, this address must
resolve to the private address of the Exchange Server on the internal network.
In addition to the FQDN listed in this text box, you will
also need to create a DNS entry in your public DNS that resolves the name of
the Global Catalog Server that you’ve hard coded in the Outlook 2000 client’s
Registry. For example, if the name FQDN of the Global Catalog server on the
internal network is gc.internal.net,
then you should have a Host (A) record in your public DNS that resolves gc.internal.net to the IP address on the
external interface of the ISA Serve firewall that you are using in the secure
Exchange RPC Server Publishing Rule.
In order words, the Outlook 2000 client must be able to
resolve both the FQDN of the Exchange
Server and the FQDN of the Global
Catalog server to the external interface of the ISA Server firewall used in the
secure Exchange RPC Server Publishing Rule.
Click Next.
Note:
Please see
the DNS Notes for Remote Outlook 2000
MAPI Client Access at the end of this article for more information on
configuring a supporting DNS infrastructure for the Outlook 2000 MAPI client.
Figure 19
4.
Click Finish in the Done! dialog box (figure 20).
Figure 20
5.
Select the new profile in the list
on the Mail dialog box and click the
Properties button (figure 21).
Figure 21
6.
Click on the Services tab (figure 22) and then click on the Microsoft Exchange Server entry in the list of information
services. Click the Properties
button.
Figure 22
7.
On the Microsoft Exchange Server dialog box (figure 23), click the Check Name button.
Figure 23
8.
Notice that the name in the Microsoft Exchange server text box
changes and becomes underlined. This is the machine or NetBIOS name of the
Exchange Server on the internal network. Only after the Outlook 2000 client is
able to successfully communicate with the Exchange Server via the secure
Exchange RPC Server Publishing Rule is this name listed
in the Microsoft Exchange server
text box. This can be confusing because this name typically will have no
relationship to the FQDN you choose to use to allow inbound access to the site
for remote clients.
Note:
Please
review the information in the DNS Notes
for Remote Outlook 2000 MAPI Client Access section at the end of this ISA Server 2000 Exchange Server 2000/2003
Deployment Kit document for more information on how to configure a
supporting DNS infrastructure for remote MAPI client access.
Figure 24
9.
Click the Advanced tab (figure 25). Place checkmarks in the When using the network and When using dial-up networking
checkboxes in the Encrypt information
frame.
Figure 25
10. Click Apply and then click OK
in the Microsoft Exchange Settings
Properties dialog box (figure 26).
Figure 26
11. Click Close in the Mail dialog
box (figure 27).
Figure 27
Note that
if you enforce encrypted communications between the Outlook 2000 client and the
Exchange Server, you will need to click on a message or folder in Outlook 2000
to trigger new mail notifications.
DNS Notes for Remote Outlook 2000
MAPI Client Access
One of the
most difficult aspects of setting up remote access for the Outlook 2000 client
is configuring DNS support for the remote MAPI client access. The Outlook 2000
client must be able to do the following:
When
configuring the Outlook 2000 MAPI client, you must enter the name of the
Exchange Server into the Microsoft
Exchange server text box as seen in figure 28. Notice in this example that
I have entered mail.internal.net in
the text box. I entered this name because the POP3, IMAP and SMTP sites can all
be access via the name mail.internal.net.
So, to be consistent, I enter the same name for the Microsoft Exchange Server. The user name is
entered in the Mailbox text
box.
Figure 28
You might
have noticed that strange things happen after you click the Check Name button. In this example the mail.internal.net entry in the Microsoft Exchange server text box
changed to BEEXCHANGE2003 (figure
29). The name, BEEXCHANGE2003 is the
computer name (or NetBIOS) name, of the Exchange Server on the internal
network. When the Outlook 2000 MAPI client connects to the Exchange Server
(either while on the internal network or via the secure Exchange RPC filter),
the computer/NetBIOS name is returned to the client.
Figure 29
From this
point onward, the client must be able to resolve the computer/NetBIOS name of
the Exchange Server, regardless of the location of the Outlook 2000 MAPI
client. The reason is that the client will no longer use the original entry you
put into the Microsoft Exchange server
text box; it will use the name returned by the Exchange Server.
For
example, saw in the figure above that the original entry mail.internal.net was changed to BEEXCHANGE2003. From this point forward,
the Outlook 2000 MAPI client will not
be concerned with the name mail.internal.net,
the client will need to be able to correctly resolve the name BEEXCHANGE2003.
There is
where many ISA Server 2000 firewall administrators become frustrated. The
single label name BEEXCHANGE2003 is
not a fully qualified domain name. DNS servers can only resolve fully qualified
domain names and the remote Outlook 2000 MAPI client must be able to use DNS to
resolve BEEXHCANGE2003 (or whatever
the computer/NetBIOS name of your Exchange Server happens to be) to the
external IP address on the ISA firewall when the client is connected to a
remote network, and to the actual IP address of the Exchange Server on the
internal network when the client is directly connected to the internal network.
The
solution to this problem is to control how the client machine fully qualifies unqualified requests. The single label
name in this example BEEXCHANGE2003
must be fully qualified before it is sent to the DNS
server. The Windows 2000, Windows XP and Windows Server 2003 client operating
system can use several methods to fully qualify the request before sending it
to a DNS server:
Manually Configuring/Domain
Configuration of the Client Computer’s Primary Domain Name
Perform the
following steps to determine the primary DNS suffix of the machine:
Notice on the Network
Identification tab is shows the Domain
name as internal.net. This is the
name that will be appended to unqualified requests. In
our example above, BEEXCHANGE2003
would be fully qualified to BEEXCHANGE2003.internal.net
and then the request will be send to the DNS server for name resolution.
On the Identification
Changes dialog box, you have the option to add or remove the computer from
a Windows domain. The primary DNS name of the client is the same as the domain
the machine belongs to (by default). If the machine belongs to a workgroup,
there will be NO default primary
domain name assigned to the client.
Click the More button on the Identification
Changes dialog box (figure 30).
Figure 30
The entry in the Primary
DNS suffix of this computer text box contains primary domain name of this
machine. This is the name this machine
will append to unqualified requests. Therefore, in our example above, a
request for BEEXCHANGE2003 will be fully qualified by
appending the internal.net domain and
a request to resolve BEEXCHANGE2003.internal.net
will be sent to the DNS server for name resolution.
Note the Change
primary DNS suffix when domain membership changes checkbox is enabled by default. This allows the machine to fully
qualify unqualified names using the domain name of the domain the machine
belongs to. If the machine is a member of a workgroup, then there will be no
default entry in the Primary DNS suffix
of this computer text box.
If the computer is a member of a workgroup, you can manually
add the domain name you want the client to append to the unqualified request in
this Primary DNS suffix of this computer
text box. This will allow your client to append the correct domain name to the
computer/NetBIOS name of the Exchange Server.
Figure 31
Configuring an Adapter Specific DNS
Suffix or using DHCP to Assign an Adapter Specific Primary DNS Suffix
You can
simplify the assignment of a primary DNS suffix by configuring the DHCP server’s
scope to assign clients a primary DNS suffix. While this option isn’t available
to you when you don’t have control of the remote DNS server, it is very useful
when the Outlook 2000 client that is not a member of the correct domain needs
to connect to the Exchange Server on the internal network.
For
example, suppose the machine is a member of a workgroup called workgroup and no one has configure a Primary DNS Suffix for the computer. The machine
will not be able to fully qualify the Exchange Server’s computer/NetBIOS name
and the DNS name resolution request will fail.
You can
solve this problem for your internal network clients by configuring them to use
DHCP and configuring the DHCP server with the DHCP option to issue a primary
domain name to the DHCP clients. Now the Outlook client will be able to fully
resolve the computer/NetBIOS name of the Exchange Server, as well as now being
able to resolve the computer/NetBIOS name of the Global Catalog Server if you
entered only the computer/NetBIOS name (you do have the option of entering a
FQDN for the Global Catalog Server in the Registry).
Perform the
following steps to configure the network interface to support DNS suffix
assignment via DHCP:
Figure 32
Figure 33
Figure 34
The default setting on the network interface is Append primary and connection specific DNS
suffixes and Append parent suffixes
of the primary DNS suffix. The Append
primary and connection specific DNS suffixes option allows the machine to
fully qualify an unqualified name by appending the primary DNS suffix to the
unqualified name and appending a connection specific DNS suffix to the name.
This option allows the machine to be
assigned a connection specific DNS suffix via a DHCP server. Note that
if you do not have a DHCP server to assign a connection specific DNS suffix, or
if you want to override the DHCP server’s connection specific DNS suffix, you
can enter a DNS suffix in the DNS suffix
for this connection text box.
The Append parent
suffixes fo the primary DNS suffix checkbox
allows the client to append the primary DNS suffix and parent domains of the suffix. For example, suppose the Exchange
Server is named BEEXCHANGE2003
and the machine belongs to the dev.internal.net domain. The Exchange Server’s
name will be fully qualified in two ways: the first way using the complete
primary domain name BEEXCHANGE2003.dev.internal.net
and the second way using the parent of the primary DNS suffix BEEXCHANGE2003.internal.net. This
increases the probability of resolving the name of the Exchange Server because
the Exchange Server can belong to the parent domain without the client
belonging to the parent domain.
Figure 35
Appending an Adapter Specific Domain
Name or a List of DNS Suffixes
Another way
to fully qualify unqualified requests is to append a list DNS suffixes that the
client can use.
1.
Right click on the My Network Places icon on the desktop
and click the Properties command. In
the Network and Dial-up Connections
window, right click on the network connection and click the Properties command (figure 36).
Figure 36
2.
In the connection’s Properties dialog box, select the Internet Protocol (TCP/IP) entry in the
list of Components checked are used by this connection dialog box and click the Properties button (figure 37).
Figure 37
3.
Click the Advanced button in the Internet
Protocol (TCP/IP) Properties dialog box (figure 38).
Figure 38
4.
In the Advanced TCP/IP Settings dialog box, click on the DNS tab (figure 39).
Select the Append
these DNS suffixes (in order) option. You can enter a DNS suffix by
clicking the Add button and entering
it into the TCP/IP Domain Suffix dialog
box (not pictured). These DNS suffixes will override the primary DNS suffix
assigned to this computer, as well as any hard coded or DHCP assigned connection
specific DNS suffix.
Figure 39
5.
You will not need to restart the
machine after adding a DNS suffix search list. Just click OK in the dialog boxes and return to the Network and Dial-up Connections window. The changes take place
immediately.
Keep in
mind that the Outlook 2000 client must be able to resolve both the Exchange
Server’s actual computer/NetBIOS name and
the hard coded Global Catalog server you configured in the Registry. The
computer must be able to do this regardless of its location so that users have a “Outlook Just Works” experience.
You do this
with the help of a split DNS infrastructure. When the Outlook 2000 client is connected to the internal network, behind the ISA Server
firewall, the client will use an internal
DNS server that resolves the Exchange Server’s name to the machines internal IP address. On the other hand,
when the Outlook 2000 client is connected to an
external network, the Exchange Server and the Global Catalog server names must
resolve to the IP address on the ISA Server firewall that you used in your
secure Exchange RPC Server Publishing Rule.
The DNS
infrastructure is referred to a “split” DNS because
the same domain name is used on the internal and external network but the
contents of the zone files containing those domains differ. For example, you
can use the domain name domain.com on
the internal network and domain.com
to host Web and mail services accessible to hosts on remote networks and the
Internet. The internal and external network host both access the same server,
the only different is the path they take. The internal network client directly
connects to the resource located on the internal network, while the remote
client connected via the secure Exchange RPC Server Publishing Rule using the
public address on the ISA Server firewall.
The split
DNS makes movement between the remote and internal networks completely
transparent to users. On the other hand, if you use different domain names for
resources located on the internal network and resources accessible from an
external location, the probability of frustrating client application
reconfiguration issues increases geometrically.
Let’s take
one final look at the example we saw above. The Outlook 2000 client is configured with a new profile and we configure the client
to use the Global Catalog server GlobalCatalog in
the Registry. We then create a new Outlook 2000 profile and enter the name mail.internal.net in the Microsoft Exchange server text box and
a user name in the account text box. We click Check name and the computer/NetBIOS name of the Exchange Server
appears in the Microsoft Exchange server
text box, which is in this case is BEEXCHANGE2003.
The machine
is a laptop that one of our sales staff uses when connected to the corporate
network and when traveling around the country. While you want to join all the
machines to the corporate domain to enhance administrative control and network
security, you haven’t been able to do so yet. However, you have configured your
DHCP server to assign a primary domain name to DHCP clients. In addition, you
have hard coded the domain name internal.net
in the adapter’s DNS suffix for this
connections text box.
You have a
DNS server on the internal network on which you have created a zone that
contains the internal.net domain. In
the internal.net domain you have
created a Host (A) resource record for BEEXCHANGE2003
so that the name BEEXCHANGE2003.internal.net
resolves to the IP address 10.0.0.2.
You have also created a second Host (A) address record for GlobalCatalog so that the name GlobalCatalog.internal.net resolves to 10.0.0.3 (which is the IP address of
the Global Catalog server).
You have a
second physical DNS server that has a zone containing the internal.net domain. This DNS server can be located on your
internal network and be published by the ISA Server firewall so that its
accessible to Internet hosts, or you can allow a third party, such as your ISP,
host this external DNS zone
responsible for the internal.net
domain. In this externally accessible internal.net
domain you have created a Host (A) resource record for BEEXCHANGE2003 so that the name BEEXCHANGE2003.internal.net
resolves to the IP address 131.107.0.1.
You have also created a second Host (A) address record for GlobalCatalog so that the name GlobalCatalog.internal.net resolves to 131.107.0.1. This IP address, 131.107.0.1, is the IP address on the
external interface of the ISA Server firewall that you used in the secure
Exchange RPC Publishing Rule.
Now the
elements are all in place to support the Outlook 2000 clients regardless of
their location. If the Outlook 2000 client is on the internal network, it will
be able to query the internal DNS server for the names of the Exchange Server
and the Global Catalog server. When the Outlook 2000 client is connected to an
external network, it will be able to query the externally accessible DNS server
(either the DNS server you published with ISA Server firewall Server Publishing
Rules or one located on your ISP) and receive the public address on the
external interface of the ISA Server firewall that you used in your secure
Exchange RPC Server Publishing Rule.
As you can
see, the split DNS infrastructure creates an “Outlook Just Works” situation.
Your users just need to turn on their computers, open Outlook 2000, and connect
to their message store. It just works because you designed and configured your
DNS smartly.