One of the most challenging aspects of Windows NT/2000 networking is design. The conventional wisdom on the subject varies widely and often provides conflicting views on setting up and combining various network services. To help you sort through the diverse options, we’ll examine some common approaches to designing Windows networks and establish criteria to use in planning your network. We won’t go into depth on the vast subject of Windows domain topology. Rather, we’ll focus on balancing various network services and applications.

Network design involves three primary factors:

  • Performance optimization
  • Capacity planning
  • Security

These three factors play out very differently depending upon the size and the geographic spread of the network. Thus, generalized statements about topology should be regarded carefully.

Divide and conquer
In my opinion, one of the worst things to happen to Windows NT/2000 networking is Microsoft’s bundling of server products into the Back Office Server and Small Business Server packages. Don’t get me wrong; I love the price break. However, the bundles have given many people the false impression that they can safely run SQL Server, Exchange Server, Internet Information Server, Proxy Server, and any other Microsoft server products all on the same box. As a result, there are a lot of poorly designed NT/2000 network servers out there.

These all-in-one servers tend to have serious performance and stability problems and contribute to the myth of the NT kernel’s inherent instability. Unfortunately, Microsoft hasn’t really discouraged this kind of thinking. Its marketing efforts have focused on how Windows NT/2000 networks can provide more for less, and the promotion of the server bundles conveys a false sense of what an NT/2000 server can do.

On the other end of the spectrum are those analysts and commentators who insist that every server product and major network service on an NT/2000 network should be relegated to a dedicated server. While this may be true on huge Fortune 500 enterprise networks, most organizations will find that they can effectively consolidate some services and server products. The trick is to know which ones play well together so that you can make informed decisions when designing your network servers. Let’s take a closer look at the main factors that will help you make good design decisions.

Performance optimization and capacity planning
Performance optimization and capacity planning naturally go hand in hand, so we’ll examine many of their needs simultaneously. Performance optimization deals with enhancing the hardware and network infrastructure to support better performance, availability, and capacity. Capacity planning focuses on the number of users and computers accessing various network services and the resulting performance and availability of those services.

Although we’re not going to focus extensively on domain topology, when you’re designing and optimizing Windows NT/2000 networks, you always have to start with the domain controllers. When examining any services, you have to take into account the times when the services are most accessed by users. This is especially true for domain controllers because they tend to have peak periods of activity, such as mornings and/or the beginning of shifts, when many users will all be logging in at the same time. Generally, domain controllers are most active during the times when the most users are active on the network. Thus, you do not want to combine domain controllers with other services that are heavily accessed during peak user hours such as WINS servers, mail servers, and so on.

Server categories
Generally, we divide Windows NT/2000 servers into four network server categories:

  • Domain controllers
  • File and print servers
  • Application servers
  • Network services

The domain controllers category is self-explanatory. As we just mentioned, you want to combine domain controllers with few or no other services. The file and print servers category is also self-explanatory, and because these servers tend to be accessed frequently, it is also better not to combine them with other services.

Application servers include intensive network applications, such as database servers, mail servers, Web servers, terminal servers, and remote access servers. Balancing and combining these servers takes careful monitoring and planning based on how much each service is used.

Network services include WINS, DNS, DHCP, SNMP, and other network management services and programs. Network designers often combine these with services in the other three server categories. However, this requires regular monitoring and diligent planning in order to achieve the best performance. You can use Windows’ built-in Performance Monitor or a third-party tool such as HP OpenView to keep an eye on performance.

Optimization tips
In addition to your hardware and network infrastructure, the size of your network and its geographical spread will have the greatest impact on how you implement these four server categories in the design of your network. Enterprises with thousands of users and multiple locations will need to split up nearly all services onto dedicated machines. However, small and midsize businesses, branch offices, and self-contained departments will find that they can combine some of the services within these four server types. Deciding which ones to combine is where network engineers earn their money. The best practice is to forecast what your most resource-intensive services will be and when they will be accessed and then separate and combine services accordingly. Here are some general tips that can help with this process:

  • A RAS server may be a good candidate for combining with a busy daytime server such as WINS or an application server since most organizations have their heaviest RAS traffic during evening hours. However, this can also have some negative security implications.
  • Database servers should rarely be combined with any other services because they hog so much memory and processor time they will inevitably slow down other services.
  • As far as network services go, WINS and DNS (especially in a Windows 2000 environment) can use a lot of resources. However, DHCP is not very resource intensive.
  • If at all possible, always have at least two domain controllers so that if one of them goes berserk, you have a backup and won’t suffer any downtime.
  • In small environments of 30 or fewer users, you can run everything on one powerful server with moderate success. However, keep in mind that if you have problems with one service and have to restart or fiddle with the server, the problem could temporarily interrupt all of the other services on the machine as well. This configuration hinges on an accurate and regular backup strategy for disaster recovery.
  • Load your servers with as much RAM as you can afford. It’s okay to skimp in some of the other areas with your hardware but do not skimp on RAM. All four of the categories of NT/2000 servers can greatly benefit from an increase in RAM.

Don’t forget security
With network design (and nearly every other aspect of IT), you must consider the implications that any configurations will have on the security of the network and the organization as a whole. There are times when security considerations will limit what you can do in terms of network design. A good rule of thumb is to start your configuration with a more restrictive security policy. As you need to use more services and can better understand and compensate for the security risks, you can relax the restrictions.

Again, network design is not easy, and there aren’t a lot of general rules and tips that apply to all situations. Nevertheless, you can use the basic principles we’ve discussed here to make informed decisions in optimizing your current networks and designing future ones. As you’ve no doubt heard many times before, a network that is well designed from the beginning will save you a tremendous amount of time and energy down the road.
If you could design your own network from scratch, how would you approach it? Share your opinion in a discussion below or send the editor an e-mail.