Migrating from Exchange 5.5 to Exchange 2000 requires a lot of preparation work to merge the two databases—Exchange 5.5 and Windows 2000 Active Directory (which is what Exchange 2000 uses). This article will look at the Active Directory elements that you must understand and modify as part of an Exchange 2000 upgrade. It will also provide some valuable tips for those preparing to roll out corporate Instant Messaging services as part of their Exchange 2000 deployment.
DNS is a critical part of Active Directory, so you need to ensure that DNS is working properly long before you begin the Exchange 2000 installation process. You can do this using the tools DCDiag and NetDiag on the Windows 2000 servers that will run Exchange 2000. Also, since Exchange 2000 will probably be the first program you’ll install in your Win2K Active Directory domain that requires dynamic DNS service records, it’s important to verify that your DNS servers are supporting that feature without a hitch. You’ll want to check this in a deployment on a test network.
You’ll also need to get your internal DNS system integrated with the external (Internet) DNS, verifying that all Exchange servers register with your internal DNS servers. External DNS servers (for example, your ISP’s Internet DNS servers) should be configured only as forwarders on your internal DNS servers. See Q300202 for an explanation of how this can be achieved simply (although for security reasons, many networks will incorporate a caching-only forwarding DNS server on the DMZ).
You’ll need to prepare for Instant Messenger if you’re going to take advantage of this new feature in Exchange 2000. This requires an _RVP Service record for Instant Messenger if you plan to have a unified namespace (with users having the same logon as their e-mail account). In addition, you must specify the fully qualified domain name (FQDN) of the IM router or IM home server.
The easiest way to create this record is to use the DNS console in Win2K. From the DNS console, right-click on your forward lookup zone and select Other New Records. From the drop-down list, select Service Location. Then, in the Service Location (SRV) dialog box, enter _rvp for the Service (it’s not available via the drop-down list) and change the Port Number to 80. Under Host Offering This Service, enter the FQDN of the IM router or IM home server. Make sure that you have an A record for that router/server. Figure A shows an example of an _RVP record.
|Creating an _RVP service record for Instant Messenger|
Once you’ve created the _RVP record, you should be able to see it under the _tcp folder in the DNS console, listed beside records for other services, such as Global Catalog servers, Kerberos servers, and LDAP servers. To verify that your clients can find this record, use the nslookup utility in interactive mode, set the query type to any (set q=any), and then type _rvp._tcp.<domain name>. For example:
You should see a response similar to the following:
_rvp._tcp.ad.com SRV service location:
priority = 0
weight = 0
port = 80
svr hostname = e2ksrv002.ad.com
You must specify these additional records on external DNS servers if you’re going to offer Instant Messenger services to your users over the Internet. You need this on internal DNS servers if you’re planning to offer Instant Messenger services to internal users (and/or VPN users).
Keep in mind that if you don’t plan to use a unified namespace with Instant Messenger, you don’t have to create an _RVP record. In that case, it’s optional; although if users are complaining of long logon times when using Instant Messenger, you should add one. If you are not using an _RVP record, you’ll have to make sure that the host name (A record or CNAME) of the IM server you are going to use is entered into your DNS. Microsoft recommends using the host name “im” as a suggested standard if you decide to use a nonunified namespace. This makes it easier for users to guess which name to use. An example Instant Messenger logon using a nonunified namespace for the ad.com domain would be email@example.com.
After installing Exchange 2000, you’ll need to enable users for Instant Messenger before they can connect to it (using Active Directory Users And Computers). Also, check the Instant Messaging Settings, Firewall Topology tab in Exchange System Manager if users connect over the Internet. For more on setting up instant messaging in Exchange 2000, see this article.
When preparing for Exchange 2000, many administrators get confused about configuring DNS correctly, or they neglect it. Don’t make that mistake.
Changing network authentication
Here’s something else to keep in mind if you roll out Instant Messenger: You will need to change the authentication method if users log on to Instant Messenger over the Internet using a proxy server, such as ISA Server. Instant Messenger uses IIS, and the default IIS authentication of Integrated Windows will not work with proxy servers. You’ll need to configure the Instant Messenger virtual server to use Digest authentication after installing Exchange 2000. Getting this to work requires a change on either the domain policy or the user account to store passwords using reversible encryption.
Once this change has been made, the user must reset his or her password, and the new password will be stored in the new format. It’s not until the new password is in effect that this will work, which is why it’s a good idea to change this setting well in advance.
Microsoft’s standard advice is to change this setting for reversible encryption as a domain Group Policy Object (Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy). However, it’s better from a security point of view if you can identify the users who will need this setting and configure it at the account level (see Figure B).
|Setting the Reversible Encryption option at the account level|
When you configure Instant Messenger later, remember to select Digest Authentication For Windows Domain Servers on the InstMsg virtual directory in IIS. You’ll also use this setting if you have remote non-Windows users logging on via RRAS, which requires CHAP authentication rather than MS-CHAP.
Global Catalog servers
Global Catalog servers play a key part in Exchange 2000, so you need to check their placement, quantity, and server resources. Unfortunately, this is not an exact science but more a matter of trial and error. You should have at least one Global Catalog server in the same site as your Exchange 2000 server; otherwise, Global Address List (GAL) lookups may go over WAN links, which is obviously less than ideal from the point of view of speed and bandwidth.
As well as performing GAL lookups, Global Catalog servers locate which server hosts the user mailboxes. Although you may want to factor in redundancy and scalability (some documentation recommends a minimum of two per site), don’t make the mistake of having too many Global Catalog servers. That will increase Active Directory replication traffic. An Exchange 2000 server will look to use a Global Catalog in its own Active Directory site first. If it doesn’t find one, it will look in its own domain, and if it doesn’t find one there, it will look in any site or domain.
Update domain controllers with service packs
Windows 2000 SP3 has been released for some time now and is considered stable by most administrators. Because of various fixes and security patches service packs contain, it’s a good idea to keep domain controllers up to date with them. However, it’s easy to forget some servers, especially if they’re on remote sites and are not considered to be a high security risk.
It’s well known that Exchange 2000 requires at least Windows 2000 Service Pack 1 and will fail to install on just the base version of the operating system. But it’s probably less well known that all domain controllers in your Active Directory forest should be on a minimum of Service Pack 1 to accommodate the new schema. If you haven’t already done so, do an inventory of the Win2K versions for your domain controllers and make sure that they are running at least Service Pack 1 without any problems before you install Exchange 2000.
Active Directory Native Mode
Microsoft suggests that you make the switch to Windows 2000 Native Mode as soon as possible to take advantage of some of the new features, such as universal groups, nested groups, and unlimited objects in a domain. However, especially for smaller networks, these benefits seem small in comparison with the risks and limitations of a one-way switch and being unable to integrate with Windows NT 4.0 Backup Domain Controllers.
Upgrading to Exchange 2000 may be the very incentive you need to switch to Native Mode. You risk losing access to public folders when you use the Exchange Active Directory Connector as part of the upgrade process (which you must do if you’re not in Native Mode) because this converts Exchange 5.5 Distribution Lists into universal groups.
I have provided a number of tips and suggestions that can help you get things in order with Active Directory and DNS in preparation for upgrading to Exchange 2000. I’ve also showed you some things you need to do to prepare to roll out Instant Messaging services, one of the exciting new features of Exchange 2000. My next article will cover the preparation needed for the Exchange servers themselves, including making changes to the Exchange 5.5 database, installing Exchange 2000 with the ForestPrep and DomainPrep switches, and installing the Active Directory Connector.