Before you can determine the path to your new network environment, you must determine where you are right now in terms of your existing network infrastructure. This requires determining a baseline for network and system hardware, software installation and configuration, operations, management, and security. Don't rely on what you think is the case; actually verify what is in place.
You should get an idea of what the current network looks like before moving to a new operating system. You will require configuration information while designing the modifications to the network and deploying the servers. In addition, some aspects of Windows Server 2003, such as the sites used in Active Directory replication, are based upon your physical network configuration. (A site is a segment of the network with good connectivity, consisting of one or more Internet Protocol [IP] subnets.)
For reasons such as this, you'll want to assess a number of aspects related to your physical network environment. Consider such characteristics as the following:
Network topology Document the systems and devices on your network, including link speeds, wide area network (WAN) connections, sites using dial-up connections, and so on. Include devices such as routers, switches, servers, and clients, noting all forms of addressing, such as both NetBIOS names and IP addresses for Windows systems.
Network addressing Are you currently employing Transmission Control Protocol/Internet Protocol (TCP/IP)? Is the address space private or public? Which TCP/IP subnets are in use at each location?
Remote locations How many physical locations does the organization have? Are they all using broadband connections, or are there remote offices that connect sporadically by dial-up? What is the speed of those links?
Traffic patterns Monitoring network traffic can provide insights into current performance, as well as help you to identify potential bottlenecks and other problems before they occur. Examine utilization statistics, paying attention to both regularly occurring patterns and anomalous spikes or lulls, which might indicate a problem.
Special cases Are there any portions of the network that have out-of-theordinary configuration needs, such as test labs that are isolated from the rest of the network?
Inside Out: Mapping the territory
Create a network map illustrating the location of all your current resources—this is easier by using tools such as Microsoft Visio. Collect as much detailed information as possible about those resources, starting with basics, such as what is installed on each server, the services it's providing, and so on. Additional information, such as critical workflow processes and traffic patterns between servers, can also be very useful when it comes time to consolidate servers or deploy new ones. The easier it is to cross-reference all of this information, the better.
As part of planning, you should inventory the existing network servers, identifying each system's operating system version, IP address, Domain Name System (DNS) names, as well as the services provided by that system. Collect such information by performing the following tasks:
Inventory hardware Conduct a hardware inventory of the servers on your network, noting central processing unit (CPU), random access memory (RAM), disk space, and so on. Pay particular attention to older machines that might present compatibility issues if upgraded.
Identify network operating systems Determine the current operating system on each computer, including the entire version number (even if it runs to many digits), as well as service packs, hot fixes, and other postrelease additions.
Assess your current Microsoft Windows domains Do you have Windows domains on the network? Microsoft Windows NT 4 or Active Directory? If multiple, detail the trust relationships. List the name of each domain, what it contains (users, resources, or both), and which servers are acting as domain controllers.
Identify localization factors If your organization crosses international and/or language boundaries, identify the localized versions in use and the locations in which they are used. This is critical when upgrading to Windows Server 2003, because attempting an upgrade using a different localized version of Windows Server 2003 might fail.
Assess software licenses Evaluate licenses for servers and client access. This will help you select the most appropriate licensing program.
Identify file storage Review the contents and configuration of existing file servers, identifying partitions and volumes on each system. Identify existing distributed file system (DFS) servers and the contents of DFS shares. Don't forget shares used to store user data.
Inside Out: Where is the data?
Locating file shares that are maintained at a departmental, team, or even individual level can take a little bit of investigation, but it can well be worth it to allow you to centralize the management of data that is important to individual groups, while providing valuable services, such as ensuring that regular data backups are performed.
You can gather hardware and software inventories of computers that run the Windows operating system by using tools such as Microsoft Systems Management Server or HP OpenView. Review the types of clients that must be supported, so that you can configure servers appropriately. This is also a good time to determine any client systems that must be upgraded (or replaced) to use Windows Server 2003 functionality.
Look at your current network services, noting which services are running on which servers, and the dependencies of these services. Do this for all domain controllers and member servers that you'll be upgrading. You'll use this information later to plan for server placement and service hosting on the upgraded network configuration. Some examples of services to document are as follows:
DNS services You must assess your current DNS configuration, especially if you're moving from Windows NT 4 to Windows Server 2003 and implementing Active Directory, which depends upon a bit of proprietary configuration. If you're currently using a non-Microsoft DNS server, you'll want to carefully plan DNS support because Active Directory relies on Windows Server 2003 DNS.
WINS services You should assess the use of NetBIOS by legacy applications and computers running earlier versions of the Windows operating system to determine what type of NetBIOS support (such as Windows Internet Naming Service [WINS]) will be needed in the new network configuration.
Print services List printers and the print server assigned to each one. Consider who is assigned to the various administrative tasks and whether the printer will be published in Active Directory. Also determine whether all of the print servers will be upgraded in place or whether some will be consolidated.
Network applications Inventory your applications, creating a list of the applications that are currently on the network, including version number (as well as postrelease patches and such), which server hosts it, and how important each application is to your business. Use this information to determine whether upgrades or modifications are needed. Also watch for software that is never used and thus need not be purchased or supported—every unneeded application you can remove represents savings of both time and money.
This list is only the beginning. Your network will undoubtedly have many more services that you must take into account.
Caution
Make sure that you determine any dependencies in your network configuration. Discovering after the fact that a critical process relied upon the server that you just decommissioned is not going to make your job any easier. You can find out which Microsoft and third-party applications are certified to be compatible with Windows Server 2003 at http://www.microsoft.com/windowsserver2003/evaluation/suppapps/default.mspx.
When you document your network infrastructure, you will need to review many aspects of your network security. In addition to security concerns that are specific to your network environment, the following factors should be addressed:
Consider exactly who has access to what and why. Identify network resources, security groups, and assignment of access permissions.
Determine which security protocols and services are in place. Are adequate virus protection, firewall protection, e-mail filtering, and so on in place? Is Kerberos or NTLM authentication being used? Have you implemented a public key infrastructure (PKI) on your network?
Examine auditing methods and identify the range of tracked access and objects.
Determine which staff members have access to the Internet and which sorts of access they have. Look at the business case for access that crosses the corporate firewall—does everyone that has Internet access actually need it, or has it been provided across the board because it was easier to provide blanket access than to provide access selectively? Such access might be simpler to implement, but when you look at Internet access from the security perspective, it presents many potential problems.
Consider inbound access as well; for example, can employees access their information from home? If so, examine the security that is in place for this access.
Note
Security is one area in which well-established methods matter—pay particular attention to all established policies and procedures, what has been officially documented, and what isn't documented as well.
Depending upon your existing network security mechanisms, the underlying security methods can change upon deployment of Windows Server 2003. The Windows NT 4 security model (using NTLM authentication), for instance, is initially supported upon upgrade to Windows Server 2003, but is no longer supported when the forest and domain functional levels are raised to Windows Server 2003 level.
Inside Out: Thinking about Internet access
From an IT perspective, the fewer employees that have Internet access, the better. When employees have access to the Internet, their activities can open the business to potential liability. You must balance the needs of employees who require Internet access to do their jobs with the potential risks to the company of an employee doing something irresponsible or, worse, illegal.
Employee Internet access also means more work for both IT staff and management, requiring that policies be defined and enforced, requiring auditing and constant vigilance against the various problems that are introduced. When you add in lost productivity caused by Web surfing, chat, online shopping, and so on, it becomes clear that allowing Internet access is more complicated than just reconfiguring a firewall.
Examining the administrative methods currently in use on your network provides you with a lot of information about what you are doing right, as well as identifying those areas that could use some improvement. Using this information, you can tweak network procedures where needed to optimize the administration of the new environment.
Each company has its own sort of approach to network administration—some are very centralized, with even the smallest changes being made by the IT department, while others are partially managed by the business units, which control aspects such as user management. Administrative models fit into these categories:
Centralized Administration of the entire network is handled by one group, perhaps in one location, although not necessarily. This provides a high degree of control at the cost of requiring IT staff for every change to the network, no matter how small.
Decentralized This administrative model delegates more of the control of day-to-day operations to local administrators of some sort, often departmental. Certain aspects of network management might still be managed by a central IT department, in that a network with decentralized administration often has well-defined procedures controlling exactly how each administrative task is performed.
Hybrid On many networks, a blend of these two methods is used: A centralized IT department performs many tasks (generally, the more difficult, delicate operations, and those with the broadest impact on the network), while delegating simpler tasks (such as user management) to departmental or group administrators.
The costs of downtime caused by service interruption or data loss can be substantial, especially in large enterprise networks. As part of your overall planning, determine whether a comprehensive IT disaster recovery plan is in place. If one is in place, this is the time to determine its scope and effectiveness, as well as to verify that it is being followed. If one isn't in place, this is the time to create and implement one.
Document the various data sets being archived, schedules, backup validation routine, staff assignments, and so on. Make sure there are provisions for offsite data storage to protect your data in the case of a catastrophic event, such as a fire, earthquake, or flood.
Examine the following:
Systems and servers Are all critical servers backed up regularly? Are secondary and/ or backup servers available in case of system failure?
Enterprise data Are regular backups made of core enterprise data stores such as databases, Active Directory, and the like?
User information Where is user data stored? Is it routinely archived? Does the backup routine get all of the information that is important to individuals or is some of it stored on their personal machines and thus not archived?
Caution
Whatever your current disaster recovery plan, make sure that it is being followed before you start making major changes to your network. Although moving to Windows Server 2003 should not present any major problems on the network, it's always better to have your backups and not need them than the other way around.
This is an excellent time to assess your current suite of network management tools. Pay particular attention to those that are unnecessary, incompatible, redundant, inefficient, or otherwise not terribly useful. You might find that some of the functionality of those tools is present natively in Windows Server 2003. Assess the following aspects of your management tools:
Identify the tools currently in use, which tasks they perform, who uses them, and so on. Make note of administrative tasks that could be eased with additional tools.
Decide whether the tools you identified are actually used. A lot of software ends up sitting on a shelf (or on your hard disk drive) and never being used. Identifying which tools are truly needed and eliminating those that aren't can save you money and simplify the learning curve for network administrators.
Disk management and backup tools deserve special attention because of file system changes in Windows Server 2003. These tools are likely to require upgrading to function correctly under Windows Server 2003.
Inside Out: Think about compatibility issues early
Dealing with compatibility issues can take a lot of time, so examine them early in the process. The time needed to determine whether your current hardware and software will work and what changes must be made to allow them to work with Windows Server 2003 can be lengthy. When you add to that the time necessary to requisition, obtain, install, and configure new software—especially if you must write custom code—you can see why you don't want to leave this until the end of the project.