Microsoft has worked so long at releasing Windows Server 2003 that you might be tempted to think that it’s gotten rid of all the problems associated with connecting it to a network. But, like it or not, you’re going to run into problems with networking in Windows Server 2003. You need a little knowledge up front about which errors you’ll most likely face and a strategy to overcome them. Here are some of the problems you’ll encounter.

Adding protocols
By default, Windows Server 2003 installs only TCP/IP. You have to add additional protocols such as IPX/SPX manually. Some applications still require these protocols. To install IPX/SPX on Windows Server 2003, select Start | Control Panel | Network Connections. Open the connection you want to work with by double-clicking it. For this article, I’ll be describing the Local Area Connection on my lab server.

On the Properties page for the connection, click the Install button. From the Select Component Type window, choose Protocol and click Add. From the list of available protocols, choose IPX/SPX Compatible Transport and click OK.

Be default, IPX/SPX is configured to automatically detect the appropriate frame type. Also, the Windows server is assigned an internal network number of 00000000, which is perfectly adequate unless you plan to install Gateway Services for NetWare or File and Print Services for NetWare on the server, at which point it will need a unique IPX address.

If you’re having trouble with your server detecting the appropriate frame type, or if you use multiple frame types, you need to manually specify this information. Open the properties for the IPX/SPX transport and select the Manual Frame Type Detection radio button (see Figure A). Click the Add button to choose the appropriate frame type and to specify the network number for it.

Figure A
Choosing a frame type for IPX/SPX

If you’re unsure of the frame types in use on the network, use the config command at the NetWare server to see this information. On the Windows server, you can use ipxroute config to view this information. You’ll see a screen listing that looks similar to this:
C:\WINNT\Profiles\Administrator|ipxroute Config

NWLink IPX Routing and Source Routing Control Program v2.00

Num  Name                      Network    Node           Frame
1.  IpxLoopbackAdapter        1234cdef   000000000002   [802.2]
2.  Local Area Connection     00000000   0003ff484f06   [802.2]
3.  NDISWANIPX                00000000   500120524153   [EthII] –

– down wan line

Diagnose replication problems
Windows Server 2003 networks rely on a properly working replication scheme for a number of services, including Active Directory and Distributed File System. When this system breaks down, services are not supplied properly. Troubleshooting these types of problems can be difficult. To aid in diagnosing the cause of replication problems, Microsoft has provided a utility called DNSLint, which is available for download. Run the downloaded executable to extract two files. One is the dnslint.exe executable, and the second is documentation.

You can use DNSLint to troubleshoot three specific types of problems:

  • Diagnose problems potentially causing a lame delegation situation. Lame delegation is a situation in which a DNS server has been made responsible for a particular domain but either doesn’t exist or is not the authoritative DNS server for that domain.
  • Verify a specific set of DNS records on multiple DNS servers.
  • Verify the DNS records specifically needed for Active Directory replication.

DNSLint produces an HTML report after it completes its tests. To use DNSLint to verify Active Directory DNS records on the local server, use the following command from a command prompt:
dnslint /ad /s localhost /v

Windows Server 2003 network adapter drivers not available
Quite a few times in various newsgroups, I’ve come across messages from people who have indicated that they haven’t been able to find Windows Server 2003 drivers for their particular network adapter. Quite a few interesting workarounds have been tried, including using drivers from Windows XP and, in one case, from Windows NT.

While these are good short-term solutions, the appropriate long-term solution is to replace the NIC with one that has drivers for Windows Server 2003 available and preferably one that is on the Hardware Compatibility List. Using drivers from other versions of Windows can introduce instability to the system and even result in blue screen errors.

Network load balancing hardware problem
Network load balancing (NLB) can be a very useful tool for providing high availability and more reliable services to your users. However, some users who have enabled this feature under Windows Server 2003 have found that they are no longer able to ping the balanced adapters. This can result in the failure of monitoring systems, which rely on this information to determine whether the system is available.

To be able to ping load-balanced network adapters in Windows Server 2003, the adapters must support multipacket receive indications. Only a few adapters currently support this feature. To see if your NICs are supported under NLB, use the chknic utility from the Windows Server 2003 Resource Kit. You can download the Resource Kit tools from Microsoft’s Web site. The following is sample output from this command on my lab server:

Device : Intel 21140-Based PCI Fast Ethernet Adapter (Generic)
Physical address : 00-03-FF-48-4F-06
Device is supported by NLB

Keep up with hot fixes
Within two weeks of the Windows Server 2003 release, Microsoft started releasing hot fixes for it to correct specific networking problems. For example, on May 2, 2003, Microsoft released a hot fix (Knowledge Base Article 817689) to correct a problem in which disconnecting a network adapter from the network caused associated routing entries with that adapter to not be removed from the routing table.

A more serious related problem has also been corrected via hot fix. If you have two network adapters in a Windows Server 2003 system, and both are configured with static IP addresses and connected to the same network, on disconnecting and reconnecting the primary adapter, the secondary adapter also loses its connection. Because both adapters point to the same destination, when the primary is reconnected, its route is recreated, but the secondary one never is. This is corrected via a hot fix that you’ll find in Knowledge Base Article 817690.

As time goes on, the number of hot fixes will grow. Keeping up to date with them will help you keep your problems to a minimum.

Get your IP address without using the command line
When troubleshooting network problems, you often need to use the command-line tool ipconfig on Windows machines, especially for those machines that get their IP addresses from DHCP. You’ve probably used the commands ipconfig /release and ipconfig /renew more than once to release and renew DHCP addressing information. I’m also willing to bet that you’ve used ipconfig more than a few times to get networking information such as MAC address, system IP address, etc.

While these steps aren’t that difficult, if you’re troubleshooting a network problem, it’s more than likely that you’re already viewing the network connection from the GUI. Just do the DHCP release/renew there and also get DHCP information for the network adapter. On the adapter status screen, click the Support tab. As you can see in Figure B, this particular adapter is manually configured since this server is a domain controller.

Figure B
Network adapter status

Notice the Repair button at the lower left-hand corner of the window. This button will refresh the DHCP lease, clear the ARP, NetBIOS, and DNS caches, and reregister the adapter with WINS and DNS services.

Determine which process is using a port
Only a single program at a time is allowed to use a particular TCP port. There may come a time when you need to determine which program is using a particular port or which port a particular process is using. A new feature of the netstat command makes this easy in Windows Server 2003.

To get a list of the current TCP information on your server, issue the command netstat –o from your server’s command line. The –o parameter indicates that netstat should also display the process identifier (PID) associated with each connection. Locate the service in the netstat list for which you need more information and take note of the number in the PID column. As an example, I want to determine what is using TCP port 1041 on my lab server. Issuing netstat –o yields the following partial results:
Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP    nt4-2:ldap       ESTABLISHED     396
  TCP    nt4-2:ldap       ESTABLISHED     396
  TCP    nt4-2:ldap       ESTABLISHED     396
  TCP    nt4-2:ldap       ESTABLISHED     396
  TCP    nt4-2:1041       ESTABLISHED    1320
  TCP    nt4-2:1043       ESTABLISHED     1320

Note that the process associated with port 1041 is PID 1320.

Open Task Manager. By default, Task Manager doesn’t show the PID. To add this column, click View | Select Columns, add the PID column, and click OK, as shown in Figure C.

Figure C
Add the PID column to the list.

Sort the Task Manager by PID by clicking on the PID column. In Figure D, you can see that PID 1320 is associated with ismserv.exe, which is the Intersite Messaging service.

Figure D
The Task Manager can help you track down troublesome services.

Slowly getting better
While it adds a lot of new and improved features, Windows Server 2003 is still confounding people at times. But Microsoft has made it easier to troubleshoot and diagnose some of these problems by adding new features and improving existing ones.