Windows Server 2003 on HP ProLiant Servers : Defining the Windows 2003 Infrastructure

If you are currently in a Windows NT domain structure, this section can be used as a precursor to the AD design. In conducting assessments for Windows NT environments, I often used this section to give the customer a preview of how its environment will fit into AD, and to educate the customer about known best practices. With experience in doing migrations, and after completing the review of the environment, what needs to be done to complete the migration becomes fairly clear. Doing a thorough job here makes it easy to complete the recommendations section later in the assessment document.

If you have a Windows 2000 forest structure, this will be an opportunity to determine whether changes should be made. Sometimes, just getting all stakeholders together and taking a step back to analyze the infrastructure will create a list of problems and headaches that should be addressed. With many companies relying on the benefit of three or four years of experience running Windows 2000, and with the evolution of knowledge that accompanies that experience, this assessment provides a chance to make changes to correct those problems and employ best practices.

Structure of AD

Your design of the AD structure is dependent upon the DNS structure, domain structure, and to some extent, naming standards. Your assessment then, must include an accurate description of the current DNS infrastructure so that the Windows 2003 DNS requirements are integrated as seamlessly as possible. The existing domain structure—whether it be Windows NT or Windows 2000—must be accurately defined during the assessment, including a description of infrastructure problems. This will help your AD design team design the new domain structure to address those problems.

DNS Structure

Having previously assessed and defined the existing DNS structure and reviewing the role of DNS in the Windows 2003 environment, I usually do a brief analysis of how the customer's DNS structure will support the needs of the Windows 2003 forest. The following points will help you in that analysis:

• DNS must support dynamic updates and Service Locator (SRV) resource records. Although technically dynamic updates are not required, it would be an administrative nightmare to keep DNS updated without them. Think of updating the CName records that map the GUID to the FQDN for a large number of DCs.

• Is the External DNS namespace different from the Internal? Although AD will work with either configuration, a single namespace presents challenges that must be resolved.

• Are there non-Windows clients or a non-Windows environment, such as UNIX, Linux, or OpenVMS, that requires DNS and for which DNS already exists in the environment? You need to determine how the Windows 2003 DNS structure will fit in (most likely via a delegation from the existing DNSs).

• How is the connection to the Internet made? This might be via an ISP or perhaps you have name servers registered on the Internet. This will affect how the Windows DNSs configure forwarding to permit the Windows clients to get access to the Internet. (Answers to the previous two points will help form the forwarding strategy.)

  note

  AD does not require access to the Internet. Configuring forwarders to permit this access is for convenience of the users only. Note that Windows Server 2003 Help and Support and event messages contain links to Microsoft articles to assist in problem resolution, so connection to the Internet does have value.

  
  

• Are there any Windows-based DNSs in the environment (that is, in the Windows NT structure)? If there are, the new Windows 2003 DNS structure will need to be merged to the existing structure.

It is critical to do a thorough analysis of the existing DNS structure and how the new Windows Server 2003 structure will fit into it. AD depends heavily on a proper implementation of DNS.

Windows 2003 Domain Structure

The content of this section depends upon whether the existing domain structure is Windows NT or Windows 2000. If you are migrating from Windows NT, you can take this opportunity to identify key Windows 2003 domain components such as single versus multiple forest structure, single versus multiple domain structure, and naming conventions. In the case of an existing Windows 2000 structure, this section could be used to list the pros and cons of these domain and forest options. You could then do a brief analysis, not giving a recommendation of the domain structure you might recommend at this point, but rather presenting how the company's infrastructure might look. Figures 1 and 2 show how I presented this to one customer, explaining the options of creating separate domain trees versus a single tree with child domains off of a single parent (root). This gave us the opportunity in a design review to explore both options and determine which made more sense for the customer's situation. Although this initial design might change after designing the OU structure, analyzing security implementation, and determining how the administration model will be configured, this at least gives you a starting point.

Naming Standards

This section should include two parts: Current Standards and Considerations. If the current environment is Windows NT, there will likely be significant changes; for example, the elimination of names with special characters that are incompatible with DNS, such as “.” and “-”. Although Microsoft's DNS allows Unicode characters, it's best not to include them for compatibility with other flavors of DNS. In addition, Windows NT domains were often implemented by many different entities within an enterprise without following company-wide standards for names and configuration. Many Windows 2000 and 2003 environments tend to include site codes, domain codes, and so on into the name to reflect where the server is in the topology.

If the environment is already Windows 2000, you might want to examine the current structure to determine whether the standards have been followed and whether changes to the environment or topology require a different naming scheme. Although this isn't the place for recommendations, it is the place for education, so note any concerns or problems with the current scheme and provide some examples or alternatives to be considered. In the recommendations section, you can formally make a recommendation of a particular scheme or specific changes.

Windows 2003 Network Services

Of course, network services are important in providing the AD data and services to users. These network services include subnetting, DHCP, WINS, DNS, and remote access as you might expect, but also includes the Distributed File System (DFS). The following list includes tasks that should be included in the assessment:

• TCP/IP: Any changes in the subnet scheme should be made prior to the migration to Windows 2003. This could be the addition of new subnets or concatenation of existing ones, or changing the focus of the subnets. This will put the network on firm footing, preventing changing network addressing after the migration and adding to problems you might have that are caused by the migration. In other words, it reduces the potential problems to solve after the migration takes place.

  Technical Advantage A logical subnet scheme is critical to Windows 2003 as well as Windows 2000 due to the “client awareness” feature, which allows clients to find resources (DCs, GCs, DFS replica targets, and so on) in the client's site preferentially. Mapping a single subnet across multiple sites impacts this feature, causing clients to be authenticated by unexpected DCs. With the introduction of AD Partitions in Windows 2003, this is even more important if you plan to take advantage of these nondomain partitions and their site awareness characteristics.

  
  

• DHCP: The DHCP scopes might need to be configured as required for the new Windows 2003 structure, including new scopes (or changes to existing scopes), lease times, DNS configuration, and so on prior to the migration. Part of the assessment might be to determine scope utilization. This section can be used to identify those weaknesses that should be considered for changes.

• DNS: The DNS structure should be designed and in place prior to creating the new Windows 2003 domain structure. In Windows 2000, it was critical to configure DNS prior to building the forest.

  tip

  Microsoft, as of this writing, has created an excellent DNS resource called DNS Center at http://www.microsoft.com/DNS. The DNS Center contains Webcast recordings, whitepapers, KB articles, Best Practice papers, and even some training documents. Whether you are unfamiliar with Windows DNS requirements and functionality or are a veteran looking for best practices, this is a great resource.

  
  

• WINS: If you have Windows NT, you need to keep WINS for backward compatibility for Windows NT machines. With Windows 2000 to 2003 migration, you can elect to eliminate WINS altogether. But remember that downlevel clients and some applications relying on special records stored in WINS might prevent you from proceeding with this strategy anytime soon. Note that even though HP is operating in a Native Windows 2003 environment, we still use WINS.

Application Validation

Your applications—third-party or custom in-house developed—must be validated in the new environment. Even if the applications have been working in a Windows 2000 environment, they should be tested and validated with Windows 2003. It's amazing how many DOS-based client-server applications are still hanging around that depend on Windows NT servers or even Backup Domain Controllers (BDCs). Of particular interest are those that interact with Windows NT or perhaps the Windows 2000 AD.

Consider the following points in evaluating application compatibility:

• Apps leveraging Windows NT 4.0 domain for Authentication or account lookup can leverage anonymous user access to DCs to access domain data.

• Apps running on Windows NT 4.0 DCs. If migrating, need to be reinstalled on other machines, because DCs cannot be migrated. If upgrading, you need to ensure compatibility with Windows Server 2003.

• Apps leveraging Windows 2000 AD need to check schema-compatibility prior to upgrading to Windows Server 2003 AD schema.

Make sure you test these applications as thoroughly as possible to avoid any surprises when the users access them during the migration.

This section of your assessment should review the user environment—the client workstations —and how the current configuration will work in the new Windows 2003 structure. Most companies have a regular client upgrade program, purchasing new workstations every three to four years. In this case, the clients will likely have the newest OS and be able to take advantage of new features in the Windows 2003 domain. These features include security, remote connections, Encrypted File System (EFS), new Group Policy features in XP and 2003, SmartCard support, and additional hardware support.

The client features can significantly affect the ROI and Total Cost of Ownership (TCO) figures. Improving security, reducing support costs, and providing users with better remote connection support can be translated into direct cost savings. Laboring with Windows 9x clients might be cheaper in that you don't have to buy XP licenses, but limited support for new devices, archaic troubleshooting tools, and problematic site awareness causing them to ignore the local DC, can eat up that savings in additional support costs for your IT staff.

The following security improvements have changed the behavior of Windows 2003 Server DCs compared to Windows 2000 and Windows NT:

• Server Message Block (SMB) signing and secure-channel encryption is enforced, as well as DC access policies

• Adjustments are needed for Windows NT 4.0 pre-SP4 and Windows 9x clients (Microsoft KB 811497) to permit domain logon. However, Windows NT 4.0 SP4 and higher, Windows 2000, and Windows XP clients work without adjustments. Windows 9x and Windows NT 4.0 pre-SP4 clients or servers don't support SMB and secure channel signing by default.

Use this section to review potential savings in the user environment as well as how new technology can improve productivity.

Security

In this section of the assessment report, note the security features in Windows 2003 compared to Windows 2000 and Windows NT. A comparison chart such as that shown in Table 1 can be used to point out that security design is not only important, but that Windows 2003 features give the company a lot of power and flexibility in securing the enterprise—much more so than Windows NT and even better than Windows 2000.

Management and Administration

The way that Windows 2003 management and administration affect current practices and organizations depends on whether the current infrastructure is Windows NT or Windows 2000.

Windows NT administration models were largely driven by OS constraints. For example, due to the lack of granular delegation of authority in Windows NT, we were forced to grant full domain Administrator privileges to Administrators who had limited roles. In addition, due to the limit of the number of objects that could exist in a Windows NT domain, the inability to delegate administration authority to any entity other than a domain, and other limitations of Windows NT, large enterprises were forced to create many domains, which inflated the number of Administrators required to manage this structure. Before Compaq migrated to Windows 2000 from its Windows NT multiple master domain model, they had 13 master user domains and more than 1,700 resource domains. Compaq had staff whose full-time jobs were validating and maintaining Windows NT trusts. In addition to creating domains to satisfy the delegation of authority, some domains were used simply to improve browsing performance. In the Hewlett-Packard Windows NT model, prior to the Compaq merger, there were 8 master user domains and about 800 resource domains.

In Windows 2000, with granular administrative functions you can delegate responsibility for a small group of users, groups, and computers, or Group Policy management, for example, to a single Administrator without giving him or her the “keys to the kingdom.” With the scalability of Windows 2000 and consolidation of domains, the need for domain-level Administrators is greatly reduced. Compaq (now HP) reduced their environment from more than 1,700 domains to 4. Consider the impact on administration that reduction had. And, with transitive trusts, that Administrator taking care of all the trusts can be used somewhere else where he or she can be more productive.

You should be aware that there is not a dramatic change in the Windows 2003 administration model if you are migrating from Windows 2000. One area of increased complexity is Group Policy. There are approximately 200 new Group Policy settings in Windows 2003 compared to Windows 2000. Windows NT had about 79 System Policies, which are the equivalent of Group Policies in Windows NT. If you have an Administrator who is responsible for Group Policy administration, he or she should become familiar with the policy settings and analyze whether they are going to impact your environment and whether you should take advantage of them. Microsoft has made an obvious effort to implement features and bug fixes through Group Policy and it is growing. Windows XP included its own set of policies that can be uploaded to the Windows 2000 DC and managed from there. You might consider identifying a Group Policy Administrator to keep track of these important settings.

During the assessment, you should review the existing management and administration structure and note how Windows 2003 will impact this structure. One of the biggest impacts will be migrating from Windows NT to Windows 2003 and the reduction of domains. This will reduce the number of domain Administrators needed and will change the role of the ones who are retained as OU Admins. Again, making a chart and listing the current administrative assignments as well as the assignments needed for 2003 will easily show which changes need to be made. Don't forget training for these new Admins—whether they are Windows NT Admins or Windows 2000 veterans, Windows 2003 will require training.

Other management and administration areas to be included in the assessment are

• Administration model: Define whether the centralized or distributed administration model is being used and whether there is need for change. This will affect how you deploy software, manage Group Policy, and to some extent, how the OU structure is designed.

• Tools: In addition to the snap-ins that Microsoft provides out of the box, there are some very powerful tools that you should explore. This is especially true if you have a large environment, and you intend to do some sort of AD health monitoring. Although the snap-ins will help to a degree, they won't monitor the AD for you. Some excellent management and monitoring tools are now available:

  • Microsoft's MOM (Microsoft Operation Management) tool is free and a better alternative to the snap-ins.
    

    Microsoft's new Group Policy Management Console (GPMC) is a free download from Microsoft's Web site at http://www.microsoft.com/gp.

  • HP's OpenView Operations for Windows (OVOW) offers AD management, including an excellent 3D graphical tool called the Active Directory Topology Viewer (ADTV) that will make diagnosing difficult replication problems easy.

  • Other third-party companies, such as NetIQ (http://www.netiq.com), Quest Software (http://www.quest.com), BindView (http://www.bindview.com), Aelita Software (http://www.aelita.com), and NetPRO, (http://www.netpro.com), offer suites of very sophisticated tools for monitoring and managing AD as well.

As part of the assessment, you should review these tools and choose one or two to evaluate in the pilot. Take some time to find one that will fulfill the needs of your environment at a cost you can afford. This can result in cost savings by reducing administration time and “cost to solution” by solving problems when they occur. Regardless, ensure that some form of a management and monitoring system is put in place as the robust fault-tolerant nature of Windows 2003 might let problems go unnoticed until it is too late.

Growth