Standardize on TCPIP

Whatever the size of your network, you need to plan a wholesale conversion to TCP/IP in everything that you do. Windows 2003 without TCP/IP is like an eagle in a cage. As long as you maintain a hodge-podge of network protocols, such as IPX/SPX, NetBEUI, NWLink, AppleTalk, and the like, you cannot convert to a native-mode domain.

Besides the features of the native domain, maintaining several protocols results in more network management, slower applications (the overhead of supporting more multiple protocols on the network), more opportunities to breach security, and the introduction of viruses, bugs, and so on.

Not only should TCP/IP be the network protocol of choice, but your applications should also be supporting it from one end of its stack to the other. Begin binding the TCP/IP protocol to all network interfaces and start planning the logical design of a TCP/IP network if you have not already started doing so.

Take inventory of software and hardware that does not function on a TCP/IP network and devise the necessary plans to begin phasing them out. In other words, standardize on TCP/IP and make it policy.

If you still need legacy applications that require support of the NetBIOS API, SNA, IPX, and so on, you obviously still need to support protocols, at least at the network topological level — that is, on routers, interface cards, and so on. That does not, however, mean that you are required to support these protocols on the Windows network infrastructure, unless you still have a huge investment in legacy Windows operating systems and applications or in operating systems such as NetWare (prior to version 5.0).

We have small clients (four PCs) to large clients (1,000+ computers) beginning wholesale conversion to TCP/IP. The smaller the clients, the easier their conversions are to Windows 2003 on TCP/IP.

As for NetBIOS support, just use common sense. As soon as all NetBIOS-dependant applications and operating systems are shut down, you can end your reliance on the API and begin to plot the end of life for your WINS services. The writing is on the wall for NetBIOS, so if you are planning development that perpetuates the API on your systems, you are placing your bets on the wrong horse.

Deploy DHCP

The larger the network, the more important it is to deploy dynamic IP address assignment, so if you have not yet deployed DHCP, now is the time to start. Rather than invest in Windows NT DHCP, consider a Windows 2003 role DHCP server. Not only is it easier to manage than Windows NT DHCP, but it also gets you started using the Microsoft Management Console (MMC), which is pervasive in Windows 2003. You really get to use MMC in Windows NT only with BackOffice products such as SNA Server and IIS.

Deploy WINS .NET

If you are dropping NetBEUI, you need to deploy WINS so that NetBIOS clients can resolve IP addresses to NetBIOS host names. If you already have a WINS presence, consider deploying a role Windows 2003 WINS server. It is not only easier to manage than the older versions, but it also has a lot of new features that make management a lot less troublesome.

Deploy DNS

Many companies do not use DNS, but they must do so whenever they start thinking about Windows 2003. If you are in such a position, deploy Windows 2003 Dynamic DNS (DDNS) on a role server (discussed in Chapter 15). If you support intranet-based Web and FTP servers, that is all the more reason to begin converting these servers to Windows 2003 role servers.

Was this article helpful?

0 0

Post a comment