SolutionBase: Fix Exchange 2003 Netdiag/Kerberos glitch

by Guest Contributor | Jul 02, 2004 7:00:00 AM

Takeaway: Resolve the "[FATAL] Kerberos does not have a ticket for host" Exchange Server 2003 installation error. There are a couple techniques available for overcoming the Netdiag glitch, which can prevent critical services from starting.

I recently received an interesting e-mail about a bug in Exchange Server 2003. What makes it interesting is that Microsoft has no mention of the bug in its Knowledge Base. The message I received read:

"I found an issue with the Netdiag tool that Microsoft uses in a standard deploy of Exchange 2003. The error is '[FATAL] Kerberos does not have a ticket for host'. What gives?"

Error details

The person who sent me the message was installing Exchange Server 2003 onto a Windows 2003 server. During the installation process, Exchange uses the Netdiag utility to verify network connectivity. While trying to verify Exchange�s ability to communicate with Active Directory, Netdiag detects a Kerberos problem and reports the error. It's possible to ignore the error and complete the Exchange installation. But if you take this route, some of the critical Exchange services will not start after installation completes.

Note

To learn more about Netdiag, download it from the Windows 2000 Technical Resources Web site.

There is very little information on the Internet regarding this glitch. It seems to be one of those problems that everyone is having, but nobody seems to have a solution. Because of this, I spent some time going over the message boards trying to look for commonality among the installations. The common thread seems to be that, although Exchange is being installed onto a Windows 2003 server, the server is functioning as a member server within a Windows 2000 domain in each case.

Alternative solution

It would seem the simple solution would be to bring a Windows server 2003 domain controller online within the same domain as the failed Exchange installation. Of course, budget constraints and other logistical issues may make doing so impossible. However, there's another possible solution. I ran into a series of posts on the Internet from someone who was having this exact Kerberos problem. The first time he installed Exchange, he received the error that I mentioned earlier. He went as far into the installation as possible and then ran Setup again just for kicks. This time, the error message went away, and he was able to install a fully functional copy of Exchange.

Troubleshoot with ping first

Essentially, the Kerberos issue occurs if servers can�t resolve the fully qualified domain name of a domain controller or of the member server. The user who discovered the solution recommends beginning the troubleshooting process by pinging between the various servers in the organization by fully qualified domain name (i.e., PING server.domain.com) to ensure that all of the servers have a functional communications path and that the DNS server is able to resolve the fully qualified domain name.

While you're at it, you'll also need to make sure that Exchange Server can ping a global catalog server. If any of the pings fail, try pinging by IP address. If the pings still fail, then you have a communications issue. If you're able to ping by IP address, but not by fully qualified domain name, something is incorrectly configured within your DNS server, which points to another issue.

Multiple SPNs

If all of the ping tests yield satisfactory results, and you're able to run Netdiag on the failing Exchange Server without getting any other strange errors, the problem could be that the server principal name (SPN) for either Exchange Server or for a domain controller is registered in Active Directory more than once. To find out if this is the case, you'll have to install the Windows Support Tools.

To install the tools, insert the Windows installation CD and run the SETUP.EXE file located in the \support\tools folder. Once the support tools have been installed, run the LDP.EXE utility. When this utility opens, select the Connect command from the resulting shortcut menu to open the Connect dialog box. Enter the name of one of your domain controllers into the Server field. Verify that the port number is set to 389 and that the Connectionless check box is cleared. Click OK, and LDP will connect to the domain controller.

Next, select the Bind command from LDP�s Connection menu to open the Bind dialog box. Enter the username and password of the domain administrator into the space provided. Make sure the Domain check box is selected, and then enter the domain name in DNS format. Click OK, and you should see a message indicating that you're authenticated as Administrator.

Now that you're connected and authenticated, it�s time to begin searching for duplicate SPN registrations. To do so, select the Search command on LDP�s Browse menu to reveal the Search dialog box. Then enter the Base Dn�the Active Directory location from which the search will begin. Enter the following for your Base Dn:

CN=Schema,CN=Configuration,dc=My_Domain,dc=com

In the Filter box, enter the following text:

(serverPrincipalName=HOST\<YourComputerName> )

Of course, you would replace My_Domain with the name of your domain, and replace YourComputerName with the name of the computer you're searching for in Active Directory. The Search dialog box also contains radio buttons that you can use to specify the scope of the search. Select the Subtree option for the search scope, and click Run. LDP should display every registered SPN for the name you've provided. There should be exactly one listing returned. If no entries are returned, clear the Base Dn field and run your search again. However, if multiple entries are returned, you'll have to delete all but one entry.

Final thoughts

If you're experiencing the Exchange Server 2003/Kerberos problem, I hope that one of the techniques I've shared will help you get past the error and install Exchange. If not, however, keep in mind that you can always resolve the issue by upgrading one of your domain controllers to Windows Server 2003.

If you're thinking about upgrading your domain, you must remember that simply running DCPROMO on your troubled Exchange Server to promote it to a domain controller is a bad idea. Sure, it will solve the problem; but having an Exchange Server that is also acting as a domain controller is a huge security risk.

0 comment(s)