Deploying a Windows Server 2003 Infrastructure

Posted on
Like what you see? Share it.Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

In the book “1776,” David McCullough relates how George Washington, while not the best of generals, was still a great leader. He picked two commanders—one a Quaker, the other a bookseller—both with no military experience, who became some of the Revolutionary War’s greatest heroes. It was the 18th century, the Age of Enlightenment, where one could read about war as a valid substitute for experience.

What do Revolutionary War commanders have to do with Microsoft Certified Systems Engineers (MCSEs)? The question of paper MCSEs aside, it is possible, with a little experience and a lot of preparation, to successfully deploy a proper Windows Server 2003 infrastructure. Microsoft’s Web site is particularly strong at providing information on the deployment side.

Unlike older network operating systems (NOS), such as NT or NetWare pre-v.8, newer NOSs work most effectively based on not only the business administrative structure, but also the existing infrastructure, such as DNS, DHCP and WINS. Here are some of the steps needed to ensure a successful Windows Server 2003 rollout, and also some key references to help make your project plan successful. As in any project plan, make sure the executive sponsor, owner and clients can enforce any agreed-upon decision, and that you have a realistic timeline.

Deployment Guides
To help separate the logical and physical aspects of your network, and make the logical active directory (AD) structure follow your business’s structure, you will need to consult with those who manage workflow, the organizational chart and physical locations. Go to tinyurl.com/yuoyv for a helpful, detailed Deployment Guide. The general Deployment Guide can be found at tinyurl.com/7qmp4, but it changes often, so you may want to navigate to the general Windows 2003 Tech Info, deploy as above and follow the appropriate links. You also will want to download Resource Kit tools (rktools.exe) from “Downloads” under the general Window 2003 Deployment home page. If you are upgrading from NT 4.0, or wish to restructure 2000 or Server 2003 domains, download Microsoft’s Active Directory Migration Tool v.2.0 (ADMT), or use a more featured tool, such as Migration Suite AD 6.1 from Quest or Migration Suite 7.2 from NetIQ. Many technical 2003 Server papers can be found at tinyurl.com/a9osd. Finally, for more than 25 design templates, as well as scripts to gather and present information, go to tinyurl.com/f7qt, and click on the last entry shown: Job Aids Designing & Deploying Directory.

On the Microsoft Windows 2003 general deployment page, look under AD Deployment Topics, and read the papers on Deploying a Windows 2003 Forest Root Domain, and Regional Domains. Also, you should download www.reso-net.com/download.asp?Fichier=109 for a design checklist. Microsoft has begun using new terms—”isolation” and “autonomy”—to indicate whether each business unit requires total control over their resources, or some measure of local control. When you decide how much autonomy or isolation each area requires, and who will manage your network, you will be able to determine how many forests are needed. Only a separate forest can guarantee isolation, but you may have other considerations, such as resource constraints, planned mergers, acquisitions or splits. Also, read the Microsoft Security Guide for suggestions on root structure—because planning security in advance of deployment is easier than implementing security later. Multiple forests either require a separate trust to domains in other forests, duplicate user accounts in each forest or a meta-directory to manage synchronization. In most cases, the preferred solution is one forest, for reasons of economy, overhead and management ease.

When designing the forest, also consider what schemas each business unit requires, since separate schemas require different forests. Regulatory or legal requirements may dictate separate forests, and NETBIOS names must be unique across the enterprise. Separate DNS namespaces may be organized by different trees. Given these considerations, “Designing a Windows Server 2003 AD and Network Infrastructure Exam #70-297 Study Guide” by Brian Barber, Melissa Craft and Brian P. Mohr, lists several more models that define roles and service models that dictate forest design. Other MCSE exam guidebooks from Microsoft, Sybex and Que-ExamCram2 are similar.

In the deployment kit article “Forest Design Models,” Microsoft lists three types of forests: organizational, resource and restricted. In the organizational model, both users and resources are managed within the forest according to whatever scheme is envisioned. You may provide isolation—to data, services and so on—depending who is restricted from outside. Trust between organizations allows resource sharing, if desired. Managing resources separate from users, except where duplicate or backup accounts for critical resources are placed, comprises a resource forest model. As the name implies, a restricted forest isolates those user accounts, resources or data that must be kept secure. Separate accounts and separate computers are used to log in to this restricted network. An example of this would be a high-security military or government network.

AD is replicated by partition, so domain design is a little more influenced by philosophy rather than strict design rules. In your organization, is geography a primary consideration for administration, or WAN links? Link speed replication speed is compared to cost in Chapter 3 of the Deployment Guide, “Designing the Site Topology” (tinyurl.com/7osj6) and compared to bandwidth necessary per users, in Chapter 2, “Designing the AD Logical Structure.” Another political consideration is business structure autonomy—different units may have different security policies or administrative requirements. AD also is multi-master, in that read-write copies of the various partitions (local domain, other domains, configuration, application directory) are on various DCs and global catalog (GC) servers. The exception to this is the schema master, because there is only one read-write copy of this on the DC or GC that hosts it. Therefore, AD changes may take some time before all DCs receive the updated information.

Since AD is so closely tied to DNS, the root domain is critical. In most cases, it should be registered, with a unique fully qualified domain name (FQDN). Additionally, most deployments now use a dedicated root domain. Two flexible single master operation (FSMO) roles, the schema master and the domain-naming master, are placed in the root domain by default. This separates forest service admins from domain service admins, ensures that no single unit “owns” the enterprise and schema admins, and may make later changes easier. Otherwise, the first domain assumes the role of the root domain, with the forest service roles, as well as the domain service admin roles. An introductory discussion of this and other design goals can be found at tinyurl.com/dbjsd. Unlike Windows 2000, Windows Server 2003 stores the _msdcs DNS domain where forest-wide DNS records reside—in an application partition. And, if using an AD integrated DNS, it is replicated to every forest DC.

Gone are the days when master, multiple master and complete trust were the domains of the day (NT 4.0). Domains are no longer the security boundary, because it is too easy for service admins to elevate their privileges to any domain in the forest. Microsoft 2003 domains may be set up according to a variety of models: single, regional or functional. Compared to a single domain, multiple domains will have to coordinate multiple admins, control policies (GPO, DC and security), DNS server and zone settings, ACLs, and face the added difficulty of moving objects inter-domain, requiring that policies be vetted before any move. See tinyurl.com/a63gh for information on using Group Policy Management Console (GPMC) to move Gro

Like what you see? Share it.Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone
cmadmin

ABOUT THE AUTHOR

Posted in Archive|

Comment: