Lesson 1: Troubleshooting Exchange Server 2003 Server Migration and Interoperability | MCSA/MCSE Self-Paced Training Kit (Exam 70-284): Implementing and Managing MicrosoftВ® Exchange Server 2003 (Pro-Certification)

Clean installations of Exchange Server 2003 and migration from earlier Exchange systems are straightforward, well-defined processes. Nevertheless, they can fail if all the requirements are not in place. Removal of an Exchange Server 2003 server from an organization is more complex, particularly if private stores exist on the server. Coexistence and interoperability with foreign messaging systems requires careful configuration so that encoding problems can be avoided.

After this lesson, you will be able to

Troubleshoot installation and enumerate the reasons that a clean install of Exchange Server 2003 could fail
Remove an Exchange Server 2003 server from an Exchange Server 2003 organization, list the reasons that such an operation could fail, and explain the workaround in that situation
Check connectivity and Domain Name System (DNS) and Active Directory availability using the appropriate command-line tools
Troubleshoot migration and interoperability issues

Estimated lesson time: 60 minutes

Troubleshooting Installation

An Exchange Server 2003 organization may be created by migration from Exchange 2000 Server or Exchange Server 5.5. However, you may also need to install an Exchange Server 2003 server, or even an entire Exchange Server 2003 organization, from scratch. Installation was covered in Chapter 2, "Planning a Microsoft Exchange Server 2003 Infrastructure." Normally, Exchange Server 2003 installation is a straightforward process, but things can go wrong. A clean installation of Exchange Server 2003 can fail for a number of reasons:

The target server does not meet hardware requirements.
The target server does not meet software requirements.
You do not have the appropriate permissions.
The appropriate services are not running, or services are running that should not be.
Active Directory is not available.
ForestPrep and DomainPrep have not been run.
The DNS service is not available.

When you try to install Exchange Server 2003 and not all the conditions are met, the installation program typically responds with a list of all the required conditions. It is then up to you to determine what conditions you have failed to meet. It is therefore wise to go through a checklist before starting to install the software. The first page of the installation setup guidance that appears after you select New Exchange 2003 installation gives you this checklist. It also gives links to ForestPrep and DomainPrep.

Hardware and software requirements are listed in Chapter 2, "Planning a Microsoft Exchange 2003 Infrastructure." The information is repeated here deliberately so that it can be seen from a troubleshooting viewpoint and to save you from having to check back to obtain it.

Hardware Requirements

The minimum processor requirement is a Pentium 133. However, a Pentium III 500 processor is recommended for Exchange Server 2003, Standard Edition, and a Pentium III 733 for Exchange Server 2003, Enterprise Edition. It is unlikely that the processors on all but your most out-of-date servers fall below the minimum installation requirements, but severe performance problems will result in all but the smallest Exchange Server 2003 organizations if the recommendations are not followed.

The minimum memory requirement is 256 megabytes (MB). It is possible that this could be a source of failure if you are installing on a Windows 2000 Server machine. Windows 2000 Server will install on 128 MB. However, such an inadequate machine would be a strange choice for an Exchange Server 2003 server. What is more likely is that you will experience performance problems if your server memory is below the recommended 512 MB.

Installation will fail if you do not have 200 MB free space on your system drive and 500 MB free space on the partition where Exchange Server 2003 is installed. In practice, you will experience severe problems if your free disk space drops to anywhere near these limitations. An Exchange Server 2003 server will typically use disk arrays for performance and failover protection, and will store at least transaction logs, and possibly also Exchange binaries, on separate disks from the Exchange databases. Disk storage systems were discussed in Chapter 12.

It is unlikely that the machine chosen for Exchange Server 2003 installation will not have a CD-ROM drive or VGA graphics. It is, however, necessary to ensure that all disk partitions involving Exchange Server 2003 are NTFS. Typically, all partitions in Windows Server 2003 servers and Windows 2000 Server servers are NTFS unless the machines are dual boot.

Software and Service Requirements

Exchange Server 2003 will not install unless the target machine is running either Windows Server 2003 or Windows 2000 Server with Service Pack 3 (SP3) or later installed. If you want to use Windows clustering services for failover protection, then either Windows 2000 Advanced Server or Windows Server 2003, Enterprise Edition, is required. Network Load Balancing can be implemented on Windows 2000 Server or Windows Server 2003, Standard Edition. The SMTP, Network News Transport Protocol (NNTP) and World Wide Web (WWW) services must be installed and enabled on the server before you start Exchange Server 2003 installation, and the Post Office Protocol version 3 (POP3) service should not be installed. NNTP is required for installation, but you should subsequently disable it unless newsgroup functionality is required.

If your server is running Windows Server 2003, then Active Service Pages (ASP.NET) must be installed. It must also be enabled using the Internet Information Services (IIS) Manager console. Windows Server 2003 has Microsoft .NET Framework built into the operating system and you do not need to install it.

Real World: An Installation Oddity

Some people who have successfully installed Exchange Server 2003 on Windows 2000 Server member servers have found that the installation failed on Windows Server 2003 member servers. Because ASP.NET and .NET Framework did not exist when Windows 2000 Server was introduced, Exchange Server 2003 installs them automatically during the Setup process on a Windows 2000 Server member server. However, it does not install ASP.NET on installation of an Exchange Server 2003 server on a Windows Server 2003 member server. Instead, you need to first install ASP.NET manually using Add/Remove Programs in Control Panel and enable it using IIS Manager. It seems to confuse people mightily that they need to perform additional steps when installing on the newer system.

Active Directory access is required. Notice that this does not mean that you need to install Exchange Server 2003 on a domain controller; indeed it would be most unwise to do this on a production network. However, the server you choose needs to be a member server in either a Windows 2000 or Windows 2003 Active Directory domain. Exchange Server 2003 requires DNS, but so does Active Directory. Therefore, the availability of Active Directory implies that the DNS service is also available.

Permission Requirements

You need to run ForestPrep when you install the first Exchange Server 2003 server in a forest and hence create an Exchange Server 2003 organization. ForestPrep can take some time—often an hour or more—to complete.

You need to run DomainPrep on the forest root domain, on all domains that will contain Exchange Server 2003 member servers, and on all domains that will contain Exchange Server 2003 mailbox-enabled objects. Most administrators remember that they need to run DomainPrep on child domains in their forests, but it is easy to forget that you also need to run it on the forest root domain directly after running ForestPrep.

To run ForestPrep for the first time in a forest, you need to be a member of the Schema Admins and Enterprise Admins groups. The Administrator account on the first domain on the first tree of a forest is by default a member of both groups, but it is good practice to use that account as seldom as possible. If you need to run ForestPrep again, then you can do so if you have Exchange Full Administrator permissions at the Exchange organizational level. The same level of permissions is also required to install the first Exchange Server 2003 server in a domain or to install an Exchange Server 2003 server with the Site Replication Service (SRS) enabled. To install additional services in a domain, you need to have Exchange Full Administrator permissions at the administrative group level. To run DomainPrep, you need to be a member of the Domain Admins group in the target domain. If you do not have sufficient permissions, then the installation will fail.

Important

It is tempting to do all your installation using the highest level of permissions that you have—typically the Administrator account for the forest root domain. Please resist this temptation. This practice is insecure. Also, if you are not familiar with the lower permission levels required for some of the tasks, then you will find it more difficult to delegate these tasks.

Removing an Exchange Server 2003 Server

The Exchange Server 2003 server installation wizard is also used to remove an Exchange Server 2003 server from an Exchange Server 2003 organization. You need the same level of permissions to remove a server that you do to add one. However, you can have problems that you need to troubleshoot when removing servers. For example, the wizard will not remove a server unless you have deleted or moved all the mailboxes on that server. In this case, the wizard stops with an error message, and you have two choices:

You can move or delete all the mailboxes.
You can forcibly remove the Exchange Server 2003 server from the organization.

The second process will result in the loss of any data held in public stores or mailboxes on the server. It is carried out using Exchange System Manager, and you need to power the server down or else an error will occur. This implies that the server you are removing cannot be the only machine on which Exchange System Manager is installed. (It would be very bad practice if it were.)

Forcible removal of an Exchange Server 2003 server is described in detail in Chapter 2, "Planning a Microsoft Exchange Server 2003 Infrastructure."

Troubleshooting Connectivity

Another possible reason for installation failure is that your target server is not connected to the services that you think it is. You can perform simple tests such as pinging a domain controller and a DNS server, or using the nslookup utility. However, more powerful tools are included in the Support/Tools folder on the Windows Server 2003 installation CD. The netdiag utility is used to test network connectivity, and the dcdiag utility can test both network connectivity and DNS resolution.

The netdiag command-line diagnostic utility is used to isolate networking and connectivity problems by performing a series of tests to determine the state of your server. This tool has a number of switches that let you specify specific tests, and to fix simple faults. However, a major advantage of the tool is that it can run without specifying any parameters or switches. You can therefore focus your efforts on analyzing the output rather than on training users how to use the tool.

The dcdiag command-line diagnostic utility analyzes the state of domain controllers in a forest and reports any problems. It is a powerful tool, with a large number of (optional) switches, which provides you with detailed information that lets you identify abnormal behavior in the system. The tool consists of a framework for executing tests, plus a series of tests that verify different functional areas of the system.

Troubleshooting Migration

Migration is discussed in detail in Chapter 5, "Migrating from Microsoft Exchange Server and Other Mail Systems." Migration is designed to be straightforward and can be rolled back if problems occur. Problems, and hence troubleshooting requirements, are mainly associated with transferring user mailboxes. In Exchange 2000 Server, as in Exchange Server 2003, there is a one-to-one relationship between user accounts and mailboxes. However, Exchange Server 5.5 maintains its own directory independent of Windows, and a single Windows user account could be associated with multiple Exchange Server 5.5 mailboxes. This can cause problems when migrating Exchange Server 5.5 to Exchange Server 2003.

Exam Tip

Remember that the migration wizard and other migration tools move mailboxes from one organization to another. You should use the Active Directory Users And Computers console to move mailboxes within an organization.

If you use the Active Directory Connector to move mailboxes, it creates a new disabled user account when it cannot match a mailbox to an existing user account. The problem with this method is that the newly created user accounts have different security identifiers (SIDs) than the accounts currently in use in the source organization. As a result, they have no permissions configured, and they are not the mailbox owners for the corresponding mailboxes. To work around this problem, you need to enable each account manually and then grant that account permissions to the associated mailbox.

The preferred migration technique is to use the Active Directory Migration Tool, which is found in the \I386\ADMT folder of the Windows Server 2003 installation CD. This tool migrates the SID history of the user account, which enables accounts to retain their permissions after the migration. However, a problem can occur when using the Active Directory Migration Tool. If you find that the user passwords have not been migrated, and that as a result you need to set the passwords manually, then you may have used an old version of the tool. Version 2 on the Windows Server 2003 installation CD can migrate passwords. Previous versions cannot.

Troubleshooting Interoperability

When your Exchange Server 2003 organization is interoperating with other e-mail systems, problems can occur due to formatting incompatibility or to the use of Exchange-specific functions such as calendaring. For example, Exchange Server 2003 sends messages across an X.400 connection in native Exchange format. This works when the system at the other end of the connection is also running Exchange, but if the destination system is, for example, UNIX, then the message will be garbled. The solution to this problem is to clear the Allow Exchange Contents option on the X.400 connector and allow standard X.400 formatting to be used.

Sometimes an X.400 connector is the solution rather than the problem. By default, Exchange Server 2003 routing groups are connected by routing connectors. If, however, the connection is unreliable or non-persistent (a demand-dial connection, for example), then transfer reliability can be improved by using an X.400 connection, which uses message-based data transfer rather than remote procedure call (RPC).

You also need to take care how you specify encoding formats for your POP3 and Internet Message Protocol version 4 (IMAP4) clients on the relevant virtual servers. This was discussed in Chapter 9, "Virtual Servers." If your clients use UNIX to UNIX encoding (uuencode), then your virtual servers need to be set up appropriately. For Macintosh clients, you need to specify uuencode and then select BinHex for Macintosh.

Microsoft Outlook users tend to take calendaring for granted because it is a built-in Outlook function. However, the Calendar Connector's properties are set not to synchronize calendar data by default. Thus when Outlook users attempt to view the schedules of users on foreign systems, for example Lotus Notes, the information could be out of date.

Exam Tip

If you get a question about interaction with a foreign system, read it carefully to determine if you are getting no communication with the foreign system, in which case a connector is down or a virtual server has failed. If, on the other hand, you are getting a connection but the messages are garbled, then the encoding format may be specified incorrectly.

Practice: Using the Netdiag and Dcdiag Command-Line Utilities

The netdiag utility tests network connectivity. The tool lets you specify a number of optional parameters, such as /test: to run a specific test and /d: to specify a domain. However, it is typically run either with no parameters or with the /fix switch to repair minor errors and the /debug switch to give detailed output. The output from the tool can be redirected to a text file for analysis.

The dcdiag utility is mainly used to test domain controller operation, but it also tests DNS availability. If there is a problem with your Active Directory domain or your DNS server, then Exchange Server 2003 will not install and dcdiag can help troubleshoot the failure. The utility has a number of parameters, all of which are optional. You can use the /s: switch to specify a domain controller, the /u: switch to specify a user (by username and domain name), and the /p: switch to specify a password. If you do not supply any of these parameters, then the utility will test the host on which it is run in the context of the logged in user. The /fix switch fixes the Service Principal Names (SPNs) on the specified domain controller, and the /test: switch allows you to specify particular tests. All tests except DcPromo and RegisterInDNS must be run on a domain controller.

Exercise 1: Create Files to Hold the Test Output

To create files to hold the test output, perform the following steps:

On Server01, create a new folder named C:\Tests.

In the C:\Tests folder, create the following empty text files:

Netdiag1.txt
Netdiag2.txt
Dcdiag1.txt
Dcdiag2.txt

Note

Some administrators do not create the required folder and files before using command-line utilities such as netdiag and dcdiag, because the utilities create them automatically. However, not all command-line utilities do this. Arguably, it is good practice to create files before you run any utility that uses them.

Exercise 2: Use Netdiag to Check Network Connectivity

To use netdiag to test network connectivity on Server01, perform the following steps:

On Server01, open the Command console.
Enter netdiag /debug /fix > c:\tests\netdiag1.txt.
Open the Netdiag1.txt file using Microsoft Notepad.
Read the test output. Use the search function to find "Errors," "Warning," or "Failed." A section of the test output is shown in Figure 14-1.

Figure 14-1: Netdiag output

Exercise 3: Use Netdiag to Find a Connection Fault

To create a connection fault on Server01 and use netdiag to diagnose the fault, perform the following steps:

On Server01, unplug the connector from Local Area Connection.
Open the Command console.
Enter netdiag /debug /fix > c:\tests\netdiag2.txt.
Open the Netdiag2.txt file using Notepad.
Read the test output. Use the search function to find "Fatal." The relevant section of the test output is shown in Figure 14-2.

Figure 14-2: Netdiag output showing a fatal error
Replace the network connector for Local Area Connection. Test the connection by pinging Server02.

Exercise 4: Use Dcdiag to Test Server02

In this exercise, you run dcdiag from Server01 to test Server02. If Server02 is not a domain controller on your test network, then test Server01 instead. To test Server02 using dcdiag, perform the following steps:

On Server01, open the Command console.
Enter dcdiag /s:server02 /n:contoso.com /u:contoso.com\administrator /p:* /v /f:c:\tests\dcdiag1.txt /fix.
Enter the password for the contoso.com administrator when prompted. The test completes as shown in Figure 14-3.

Figure 14-3: Running dcdiag on Server02
Open the Dcdiag1.txt file using Notepad and read the results. A section of the test output is shown in Figure 14-4.

Figure 14-4: Output of dcdiag test on Server02

Exercise 5: Use Dcdiag to Detect a Fault on Server02

In this exercise, you stop the DNS service on Server02 and then run dcdiag from Server01 to test Server02. To use dcdiag to detect a fault on Server02, perform the following steps:

On Server02, open the DNS console, right-click SERVER02, and then click Stop.
On Server01, open the Command console.
Enter dcdiag /s:server02 /n:contoso.com /u:contoso.com\administrator /p:* /v /f:c:\tests\dcdiag2.txt /fix.
Enter the password for the contoso.com administrator when prompted.
Open the Dcdiag2.txt file using Notepad and read the results. The relevant section of the test output is shown in Figure 14-5.

Figure 14-5: Dcdiag failure notification on Server02
Start the DNS service on Server02.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and then try the question again. You can find answers to the questions in the "Questions and Answers" section at the end of this chapter.

You are installing Exchange Server 2003, Enterprise Edition, on a standalone server. The server meets the recommended hardware requirements and Windows Server 2003, Enterprise Edition, is installed. You have installed and enabled SMTP, NNTP, the World Wide Web service, and ASP.NET. The server is a standard primary DNS server. Will the installation succeed? If not, why not?
You migrate an Exchange Server 5.5 organization to Exchange Server 2003. You use the Active Directory Migration Tool to migrate the mailboxes. You find that the mailboxes have migrated with all the user permissions intact, but user passwords have not migrated. What is the probable reason?
Your Exchange Server 2003 organization connects to a UNIX e-mail system over an X.400 connector. You establish connectivity with the system, but e-mail messages are garbled. How do you solve the problem?

Lesson Summary

Exchange Server 2003 will fail to install if your hardware resources are inadequate, if your member server does not have the appropriate operating system, or if Active Directory or DNS are not accessible.
Other reasons for installation failure are that SMTP, NNTP, and the World Wide Web service are not installed and running and that POP3 is installed. When installing on a Windows Server 2003 member server, you also need to install and enable ASP.NET.
Migration from Exchange systems requires that mailboxes be migrated. When migrating to Exchange Server 2003 you should use version 2 of the Active Directory Migration Tool, which will migrate mailboxes that are associated with user accounts and will also migrate passwords. You need to configure an SMTP virtual server to replace the Internet Mail connector used by Exchange Server 5.5 and configure DNS accordingly.
When you need to coexist with foreign e-mail systems, it is important to check your encoding. Exchange Server 2003 defaults are not always suitable for this coexistence.
You can use support tools such as netdiag and dcdiag to check network connectivity and DNS and Active Directory operation.