Once you have determined the overall scope of your Windows deployment project and the associated network changes, you must develop the technical specifications for the project, detailing server configuration, changes to the network infrastructure, and so on. As much as possible, describe the process of transitioning to the new configuration. Care should be taken while developing this document because it will serve as the road map for the actual transition, much of which is likely to be done by staff members who were not in the planning meetings.
In defining the new (updated) network environment, you must review the current and projected infrastructure for your network. Analyze the domains in use on your network, and evaluate the implications for security operations and network performance.
If you are implementing Active Directory for the first time, designing the domain architecture is probably going to take a substantial amount of work. Businesses already using Microsoft Windows 2000 to manage their network, on the other hand, will probably not have to change much, if they change anything at all. The amount of planning involved varies widely, depending on the current state of your network:
No Windows domains If you are starting from scratch, you have a bit of work ahead of you. You should plan DNS and Active Directory carefully, taking plenty of time to consider the implications of your design before implementing it.
Windows NT 4 domains This move will still entail quite a bit of change, yet it does provide the opportunity to rethink the current domain configuration before you start configuring Active Directory. Decide whether Active Directory will use existing DNS namespaces or new ones.
Windows 2000 domains No changes are required, although you are free to make changes if you wish. Any changes to the domain structure will likely be made to optimize operations or support additional functionality.
Also, consider whether you are going to be changing the number of domains you currently have. Will you be getting rid of any domains through consolidation?
You also must assess the impact of the projected changes on your current network operations. Consider issues such as the following:
Will network traffic change in ways that require modifications to the network infrastructure? Assess additional loads on each network segment as well as across WAN links.
Do you need to make changes to network naming or addressing schemes? Are new DNS namespaces needed, and, if so, have the DNS names been registered?
This is a good time to seriously review the security measures implemented on your network. Scrutinize the security devices, services, and protocols, as well as administrative procedures to ensure that they are adequate, appropriate, well documented, and adhered to rigorously.
Security in Windows Server 2003 is not the same as in earlier versions of Windows server operating systems—the security settings for the default (new) installation of Windows Server 2003 are much tighter than in previous versions. This might mean that services that were functioning perfectly prior to an upgrade don't work the same way afterward. Some services that were previously started by default (for example, Internet Information Services [IIS]) are now disabled when first installed.
Assign staff members to be responsible for each aspect of your security plan and have them document completion of tasks. Among the tasks that should be assigned are the following:
Applying regular updates of virus software Antivirus software is only as good as its virus definition files, so make sure yours are current. This means checking the vendor site every single day, even on weekends if possible. Many antivirus packages can perform automatic updates, yet you should verify that the updates are occurring.
Reviewing security alerts Someone should read the various sites that post security alerts on a regular basis and/or receive their newsletters and alerts. The sites should include Microsoft (http://www.microsoft.com/security/), vendors of your other software (http://www.symantec.com/), network device vendors (http://www.cisco.com/), and at least one nonvendor site (such as http://www.SANS.org/).
Checking for system software updates IT staff should consider implementing the Software Update Service (SUS) to help keep up-to-date on security patches, service packs, and other critical updates for both servers and clients. SUS enables administrators to automatically scan and download updates and patches to a centralized server and then configure Group Policy to automatically distribute the updates and patches to computers throughout the network.
Checking for hardware firmware updates It is important that the various devices on the network, especially security-related ones such as firewalls, have up-to-date firmware.
Tip
Keep current with security updates
It can be hard to keep up with the constantly changing set of patches and updates when you have a number of software packages in use. SUS can help you keep current with security updates as well. You'll find the SUS feature pack, as well as a detailed deployment guide, on the CD-ROM that accompanies this book.
While you are rolling out Windows Server 2003 is an excellent time to fine-tune your administration methods and deal with any issues introduced by the growth and change. Well-designed administrative methods with clearly documented procedures can make a huge difference in both the initial rollout and ongoing operations.
Active Directory provides the framework for flexible, secure network management, allowing you to implement the administration method that works best in your environment. There are mechanisms that support both centralized and distributed administration; group policies offer centralized control, while selected administrative capabilities can be securely delegated at a highly granular level. The combination of these methods allows administration to be handled in the method that works best for each individual business in its unique circumstances.
Tip
Make sure that all administrative tasks and processes are clearly defined and that each task has a person assigned to it.
Some administrative changes will be required because of the way Windows Server 2003 works. You might find that existing administration tools no longer work or are no longer needed. So, be sure to question the following:
Whether your existing tools work under the new operating system. A number of older tools are incompatible with Windows Server 2003—management utilities must be Active Directory–aware, work with NTFS 3.1, and so on.
Whether current tools will be needed once you move to Windows Server 2003. If a utility such as PKZIP, for example, is in use now, it might not be required for operations under Windows Server 2003, which has incorporated the functionality of ZIP into the operating system. Eliminating unneeded tools could well be one goal of the Windows Server 2003 deployment project, and it will have a definite payoff for the IT department as well in terms of simplified management, lower costs, and so forth.
You will also want to select and implement standards. If your IT department has not implemented standards for naming and administration procedures, this is a good time to do so. You'll be gathering information about your current configuration, which will show you the places where standardization is in place, as well as places where it would be useful.
Make sure that any standards you adopt allow for likely future growth and changes in the business. Using an individual's first name and last initial is a very simple scheme for creating usernames and works well in a very small business. Small businesses, however, don't necessarily stay small forever—even Microsoft initially used this naming scheme, although it has been modified greatly over the years.
You can also benefit from standardization of system hardware and software configuration. Supporting 100 servers (or clients) is much easier if they share a common set of hardware, are similarly configured, and have largely the same software installed. This is, of course, possible only to a limited degree and dependent upon the services and applications that are required from each system. Still, it's worth considering.
When standardizing server hardware, keep in mind that the minimum functional hardware differs for various types of servers; that is, application servers have very different requirements than file servers. Also consider the impact of the decisions the IT department makes on other parts of the company and individual employees. There are some obvious things to watch for, such as unnecessarily exposing anyone's personal data—although surprising numbers of businesses and agencies still do.
Tip
Standardization is especially important for networks that are still running Windows NT 4, because many of those environments use an eclectic, and sometimes downright odd, collection of computer and device names.
Inside Out: Personal information is private!
The amount of personal information that businesses have about individuals is something that should give us all pause. What's even more alarming is the casual disregard with which much of this information is treated.
Consider the use of social security numbers in the United States; they show up as student ID numbers (and are posted on professors' doors) and health insurance policy numbers (and are printed on dozens of things from insurance cards to driver's licenses), to name two of the more common and egregious misuses. If that weren't enough, portions of your social security number are used as the default "secret PIN" for some accounts at financial institutions. The same social security number that you give to several people each time anyone in your family seeks medical care. How secret.
This might start to change, however. For example, social security numbers are part of what is protected under the Health Information Portability and Privacy Act (HIPPA), which carries severe penalties for inadvertent or negligent exposure of the data. HIPPA has specific data management requirements that are of concern to any IT department working with patient information. Even without the threat of federal penalties, all IT departments, not just those in the medical industry, would be well served by an inspection of which sorts of personal information they are managing and how they are protecting it.
Formalized change management processes are very useful, especially for large organizations and those with distributed administrative models. By creating structured change control processes and implementing appropriate auditing, you can control the ongoing management of critical IT processes. This makes it easier to manage the network and reduces the opportunity for error.
Although this is particularly important when dealing with big-picture issues such as domain creation or Group Policy implementation, some organizations define change control mechanisms for every possible change, no matter how small. You'll have to determine for which IT processes you must define change management processes, finding a balance between managing changes effectively or over-regulating network management.
Even if you're not planning on implementing a formal change control process, make sure that the information about the initial configuration is collected in one spot. By doing this, and collecting brief notes about any changes that are made, you will at least have data about the configuration and the changes that have been made to it. This will also help later on, if you decide to put more stringent change control mechanisms in place, by providing at least rudimentary documentation of the current network state.
Active Directory is an extremely complicated, and critical, portion of Windows Server 2003, and you should plan for it with appropriate care. This book goes into detail on doing this in Part 7; you should read this information if you are going to be designing a new Active Directory tree.
The following section discusses, in abbreviated form, some high-level aspects of Active Directory that you must consider. It is meant to offer perspective on how Active Directory fits in the overall planning picture, not to explain how to plan for a new Active Directory installation.
The Active Directory tree is based on a DNS domain structure, which must be implemented prior to, or as part of, installing the first Active Directory server in the forest. Each domain in the Active Directory tree is both a DNS and Windows domain, with the associated security and administrative functionality. DNS is thoroughly integrated with Active Directory, providing location services (also called name resolution services) for domains, servers, sites, and services, as well as constraining the structure of the Active Directory tree. It is wise to keep Active Directory in mind as you are designing the DNS namespace and vice versa, because they are immutably linked.
Note
Active Directory trees exist within a forest, which is a collection of one or more domain trees. The first domain installed in an Active Directory forest functions as the forest root.
The interdependence of Active Directory and DNS brings some special factors into play. For example, if your organization has outward-facing DNS servers, you must decide whether you will be using your external DNS name or another DNS domain for Active Directory. Many organizations choose not to use their external DNS name for Active Directory, unless they want to expose the directory to the Internet for a business reason, such as an Internet service provider (ISP) that uses Active Directory logon servers.
Within a domain, another sort of hierarchy exists in the form of container objects called organizational units (OU), which are used to organize and manage users, network resources, and security. An OU can contain related users, groups, or computers, as well as other OUs.
Domain trusts allow automatic authentication and access to resources across domains. Active Directory automatically configures trust relationships such that each domain in an Active Directory forest trusts every other domain within that forest—a vast improvement over Windows NT in which trusts require administrative planning and manual implementation.
Active Directory domains are linked by a series of such transitive trust relationships between all domains in a domain tree, and between all domain trees in the forest. By using Windows Server 2003, you can also configure transitive trust relationships between forests.
Tip
Understand explicit trust relationships
Explicit trusts between domains can speed up authentication requests. An explicit trust relationship allows authentication queries to go directly to the domain in question rather than having to search the domain tree and/or forest to locate the domain in which to authenticate a user.
Active Directory now has four domain functional levels and three forest functional levels, each constraining the types of domain controllers (Windows NT, Windows 2000, Windows Server 2003) that can be in use and the available feature set.
The domain functional levels are as follows:
Windows 2000 mixed Windows NT, Windows 2000, and Windows Server 2003 domain controllers are supported. Use of Universal groups is limited to distribution (not security) purposes, and group nesting is supported only for distribution groups and domain local groups. This is the default mode for new installations.
Windows 2000 native If you have only Windows 2000 and Windows Server 2003 domain controllers, select this mode, which offers additional features. It provides full Universal group functionality, group-nesting operations for security and distribution groups, and the ability to convert security groups to distribution groups. In addition, security principals can be migrated from one domain to another by the security identifier (SID) history.
Windows Server 2003 interim If you will have only Windows NT and Windows Server 2003 domain controllers, select the Windows Server 2003 interim mode.
Windows Server 2003 This mode supports only Windows Server 2003 domain controllers and enables all Active Directory domain-level features. In addition to the group features specified for the other domain functional levels, this mode supports the renaming of Active Directory domains, logon timestamp updates, and passwords for InetOrgPerson users. InetOrgPersons are a special type of user, discussed in Chapter 37.
The forest functional levels are as follows:
Windows 2000 Supports Windows 2000 mixed or native functional levels
Windows Server 2003 interim Supports Windows NT 4 domain controllers with Windows Server 2003 domain controllers
Windows Server 2003 Supports only domains at Windows Server 2003 functional level, which enables all Active Directory features, including the following:
Replication enhancements—Each changed value of a multivalued attribute is now replicated separately—eliminating the possibility for data conflict and reducing replication traffic. Additional changes include enhanced global catalog replication and application partitions (which segregate data, and thus the replication of that data).
Schema—Schema objects can be deactivated, and dynamic auxiliary classes are supported.
Management—Forest trusts allow multiple forests to easily share resources. Active Directory domains can be renamed, and thus the Active Directory tree can be reorganized.
User management—Last logon time is now tracked, and enhancements to InetOrgPerson password handling are enabled.
Note
In forests with Windows 2000 functional level, the replication enhancements discussed for the Windows Server 2003 functional level are supported but only between two domain controllers running Windows Server 2003.
Selecting your domain and forest functional levels is generally a straightforward choice. Ultimately, the decision regarding the domain and forest functional level at which to operate mostly comes down to choosing the one that supports the domain controllers you have in place now and expect to have in the future. In most circumstances, you will want to operate at the highest possible level because it enables more functionality. Also, keep in mind that all changes to functional level are one-way and cannot be reversed.
Table 2-1 shows a summary of the types of domain controllers supported by each mode. This is in addition to Windows Server 2003, of course, which works in all modes.
Table 2-1. Domain and Forest Functional Levels
Forest Functional | Forest Functional | Supported Domain Controllers | |
|---|---|---|---|
Windows 2000 | Windows NT | ||
Windows 2000 | Windows 2000 mixed | Yes | Yes |
Windows 2000 | Windows 2000 native | Yes | No |
Windows Server 2003 interim | Windows Server 2003 interim | No | Yes |
Windows Server 2003 Windows | Server 2003 | No | No |
In addition to serving as domain controllers, a number of domain controllers fulfill special roles within Active Directory. Some of these roles provide a service to the entire forest, while others are specific to a domain or site. The Active Directory setup routine assigns and configures these roles, although you can change them later.
The Active Directory server roles are as follows:
Operations masters A number of Active Directory operations must be carefully controlled to maintain the integrity of the directory structure and data. A specific domain controller serves as the operations master for each of these functions. That server is the only one that can perform certain operations related to that area. For example, you can make schema changes only on the domain controller serving as the schema master; if that server is unavailable, no changes can be made to the schema. There are two categories of operations masters:
Forest-level operations masters The schema master manages the schema and enforces schema consistency throughout the directory.
The domain naming master controls domain creation and deletion, guaranteeing that each domain is unique within the forest.
Domain-level operations masters The RID master manages the pool of relative identifiers (RIDs). (A RID is a numeric string used to construct SIDs for security principals.)
The infrastructure master handles user-to-group mappings, changes in group membership, and replication of those changes to other domain controllers.
The PDC emulator emulates a Windows NT 4 primary domain controller (PDC) for down-level clients and domain controllers and serves as the Windows NT 4–style domain master browser.
Global catalogs A global catalog server provides a quick index of Active Directory objects, which is used by a variety of network clients and processes to locate directory objects. Global catalog servers can be heavily used, yet must be highly available to clients, especially for user logon because the global catalog provides membership information for universal groups. Accordingly, each site in the network should have at least one global catalog server, or you should have a Windows Server 2003 domain controller with universal group caching enabled.
Bridgehead servers Bridgehead servers manage intersite replication over lowbandwidth WAN links. Each site replicating with other sites usually has at least one bridgehead server, although a single site can have more than one if required for performance reasons.
Note
Active Directory replication depends on the concept of sites, defined as a collected set of subnets with good interconnectivity. Replication differs depending on whether it is within a site or between sites; intrasite replication occurs automatically every 15 seconds, while intersite replication is scheduled and usually quite a bit slower.
When planning for server usage, consider the workload of each server: which services it is providing, the expected user load, and so on. In small network environments, it is common for a single server to act as a domain controller and to provide DNS and Dynamic Host Configuration Protocol (DHCP) services and possibly even additional services. In larger network environments, one or more stand-alone servers might provide each of these services rather than aggregating them on a single system.
Windows Server 2003 employs a number of server roles, each of which corresponds to one or more services. You can manage many Windows Server 2003 services by these roles, although not all services are included in a role.
Your plan should detail which roles (and additional services) are needed and the number and placement of servers, as well as define the configuration for each service. When planning server usage, be sure to keep expected client load in mind and account for remote sites that might require additional servers to support local operations.
The Windows Server 2003 server roles are as follows:
Domain controller Active Directory domain controllers are perhaps the most important type of network server on a Windows network. Domain controllers are also one of most intensively used servers on a Windows network, so it is important to realistically assess operational requirements and server performance for each one. Remember to take into account any secondary Active Directory–related roles the server will be performing (such as global catalog, operations masters, and so on).
How many domain controllers are required, and which ones will fulfill which roles?
Which domains must be present at which sites?
Where should global catalogs be placed?
DNS server DNS is an integral part of Windows Server 2003, with many important features (such as Active Directory) relying on it. Accordingly, DNS servers are now a required element of your suite of network services. Plan for enough DNS servers to service client requests, with adequate redundancy for fault tolerance and performance and distributed throughout your network to be available to all clients. Factor in remote sites with slow links to the main corporate network and those that might be only intermittently connected by dial-up.
Define both internal and external namespaces.
Plan name resolution path (forwarders and so on).
Determine the storage of DNS information (zone files, Active Directory– integrated, application partitions).
Note
Microsoft DNS is the recommended method of providing domain name services on a network with Active Directory deployed, although some other DNS servers provide the required functionality. In practice, however, the intertwining of Active Directory and DNS, along with the complexity of the DNS records used by Active Directory, has meant that Microsoft DNS is the one most often used with Active Directory.
Note
DNS information can be stored in traditional zone files, Active Directory–integrated zones, or in application partitions, which are new to Windows Server 2003. An application partition contains a subset of directory information used by a single application. In the case of DNS, this partition is replicated only to domain controllers that are also providing DNS services, minimizing network traffic for DNS replication. There is one application partition for the forest (ForestDnsZones) and another for each domain (DomainDnsZones).
DHCP server DHCP simplifies management of the IP address pool used by both server and client systems. A number of operational factors regarding use of DHCP should be considered:
Determine whether DNS servers are going to act as DHCP servers also, and, if so, will all of them or only a subset?
Define server configuration factors such as DHCP scopes and assignment of scopes to servers, as well as client settings such as DHCP lease length.
WINS server First, determine whether you still need WINS on your network. If you have a mixed environment with Windows NT and Windows Server 2003 systems, WINS might be required to translate NetBIOS names to IP addresses. If so, consider the following:
Which clients need to access the WINS servers?
What WINS replication configuration is required?
Remote access/VPN server Routing and Remote Access Services for Windows provides integrated routing of packets between network segments and protocols, as well as another important function: facilitating access by remote users. Consider the following:
Do you need to provide routing between networks?
Do you want to replace existing routers?
Do you have external users that need access to the internal network?
Application server A Windows Server 2003 application server runs IIS to support Web services and application development technologies such as ASP.NET and COM+. The application server role supports the Microsoft .NET Framework and related Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP), and Universal Description, Discovery, and Integration (UDDI) services.
Mail server The mail server offers basic e-mail functionality, providing Post Office Protocol 3 (POP3) and Simple Mail Transfer Protocol (SMTP) services, enabling simple sending and receiving of e-mail, and temporary storage of e-mail on the server. Active Directory manages access to e-mail accounts, providing authentication for POP3 account access.
File server The role of the file server is to provide network shares used for file storage, supporting searching, indexing, shadow copying, and disk space quotas. In addition, the file server role supports DFS operations, enabling a unified logical namespace for file shares stored on distributed servers.
Print server The print server fulfills the needed role of managing printer operations on the network. Windows Server 2003 enables publishing printers in Active Directory, connecting to network printers using a Uniform Resource Locator (URL), and enhanced printer control through Group Policy.
Streaming media server The streaming media server role supports the Windows Media Services operations in streaming video or audio content across intranet or Internet connections to network clients.
Terminal server The terminal server role supports thin client access, allowing for a single server to host network access for many users. A client with a Web browser or a Windows terminal or a Remote Desktop client can access the terminal server to gain access to network resources.
Automatic WINS Replication Partners
Automatic partner configuration allows WINS servers to detect other WINS servers and automatically configure replication—a significant improvement over manual configuration of WINS replication. Because this automated process allows replication between any two WINS servers on the network, a security mechanism has also been introduced. A list of servers with which a replication partnership can be established, as well as those that will not be allowed to replicate with a given server, can be created for each WINS server, providing more control over WINS replication.
Inside Out: Servers with multiple roles
It is common for a single server to fill more than one role, especially on smaller networks. When selecting which roles to put on a single server, try to select ones with different needs. For instance, putting one processor-intensive role (for example, an application server) and a role (such as a file server) that does a lot of network input/output (I/O) on a single system makes more sense than putting two roles that stress the same subsystem on the same machine.
As discussed in Chapter 1, there are several versions of Windows Server 2003 and each is intended for a particular sort of usage. Which version you select for each server depends upon both the required functionality and, in the case of upgrades, the operating system that is in place.
This is the general-purpose version of Windows Server 2003, designed for a variety of purposes. The 32-bit version supports up to four processors and 4 gigabytes (GB) of RAM. The 64-bit version supports up to four processors and 32 GB of RAM. It functions well as a domain controller; Web, application, file, or print server; or for providing other network services (such as DNS or remote access services). Some advanced features are not supported, including the Terminal Server Session Directory feature and clustering (although Network Load Balancing is included).
Because it is general purpose, and less expensive than most of the specialized versions, Standard Edition is the choice for many small and medium-sized businesses. Servers running Windows NT Server 4 or Windows 2000 Server can be upgraded to Windows Server 2003, Standard Edition.
The Enterprise Edition of Windows Server 2003 provides all the same services as the Standard Edition, with a few additions, as well as improved performance, scalability, and reliability. Enterprise Edition is available in both 32-bit and 64-bit versions. Servers running Windows NT Server 4, Windows NT Server 4 Enterprise Edition, Windows 2000 Server, and Windows 2000 Advanced Server can be upgraded to Windows Server 2003, Enterprise Edition.
Hardware support is enhanced from Standard Edition, with support for eight processors and 32 GB of RAM on 32-bit platforms (up to 64 GB of RAM on 64-bit platforms), along with additional functionality such as the capability to use hot-add memory, Non-Uniform Memory Access (NUMA), and eight-node clusters. Another significant enhancement is in application performance, which is improved by Address Windows Extensions (AWE), which changes how the Windows operating system allocates memory, reserving only 1 GB of memory for the operating system and allowing 3 GB for applications. Standard Edition, by comparison, splits memory equally between the operating system and applications, allocating 2 GB for each.
Windows Server 2003, Datacenter Edition, is the appropriate choice if you have missioncritical, high-volume applications or services that must be available 24/7. If you are running a largely commerce site, for example, this is the version of the Windows operating system for you. Datacenter Edition supports up to 64 GB of RAM and 32 processors with 32-bit platforms and up to 512 GB of RAM and 128 processors on 64-bit platforms; it even has a minimum number of processors, requiring at least 8.
In keeping with the intended role of this edition of Windows Server 2003, a few features are missing. For example, functionality designed to facilitate Internet connectivity, such as Internet Connection Sharing and Internet Connection Firewall, is not available. The Datacenter Edition is available in 32and 64-bit versions. Only Windows 2000 Datacenter Server can be upgraded to Windows Server 2003, Datacenter Edition.
Inside Out: Datacenter isn't a do-it-yourself project
The hardware support provided by the Datacenter Edition requires that each server manufacturer create a custom hardware abstraction layer (HAL). Datacenter Edition, in fact, is available only directly from a hardware vendor as part of a new server purchase. Once the vendor configures the server, you are not allowed to make any changes to the hardware without the vendor's authorization, and the vendor provides all support.
Windows Server 2003, Web Edition, provides the advancements of IIS 6, along with many standard Windows services and features at a lower cost than Standard Edition. Designed to appeal to administrators running dedicated Web servers, Web Edition is optimized for providing Internet services such as Hypertext Transfer Protocol (HTTP) services, File Transfer Protocol (FTP) services, Network News Transfer Protocol (NNTP) services, and so on. Web Edition, is only available preinstalled.
Because of its focus, this edition is missing a number of features used in a corporate environment. For example, a Web Edition server cannot be a domain controller (although it can join a domain), services for other operating systems (such as UNIX and Macintosh) are not available, and Web Edition servers cannot be part of a server cluster, although they can be part of a Web farm using Network Load Balancing. There are even some Internet-related services missing from the Web Edition, such as the Internet Authentication Service and Internet Connection Sharing. Although remote access server (RAS) functionality is generally unavailable, one virtual private network (VPN) connection per media type is allowed for administrative purposes.
Note
For more information about the supported upgrade paths for Windows Server 2003, see Table 7-1.