• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    Strategies for OU Design

    Figure 8.6 shows the default structure of a Domain naming context. The standard containers in a domain have the advantage of simplicity, but that's about it. Using them is acceptable for small organizations but they fall short of the mark if you want to compartmentalize management or group policies. If you start off using the standard containers, you'll know it's time to tailor a new design when administrators start pointing fingers at each other when directory objects or rights "mysteriously" change or when users from one department complain that they want a different desktop than users in another department.

    Figure 8.6. Default containers for a new Windows Server 2003 Domain naming context.


    Both of these problems, lack of management granularity and inability to target specific group policies, can be solved by aggregating Active Directory objects into separate containers then assigning different rights and policies to those containers. The only general-purpose container at your disposal in Active Directory is the Organizational Unit (OU). The more generalized Container class is available only to the system. The Country, Organization, and Locality classes defined by LDAP are present in the Active Directory schema but are not exposed by the standard tools.

    You should consider several factors as you decide where to place OUs:

    • OUs represent separate management units because permissions on the OU and its child objects can be delegated.

    • OUs represent separate user configuration units because group policies can be linked to them.

    • OUs act as a sorting tool when constructing LDAP queries. In essence, they help keep the directory tidy, not a trivial thing when you have thousands upon thousands of objects to manage.

    OU Placement

    The OU container is intended to facilitate management based on the functional boundaries within an organization. Before putting in a call to HR to get the most current org charts, though, consider who uses the directory.

    Users never interact with the Active Directory unless you show them how to perform searches. Even then, most searches deal with the entire forest rather than distinct domains or OUs. The only people who care about the AD structure are administrators. So, when you lay out your OUs, you want to match the operation of your IT staff, not the users. If you build it, they will come.

    Management Divisions

    Figure 8.7 shows the IT organization for a company with two business lines. The primary business line carries the company's principal name, Company, Inc. The second business line is a wholly owned company named Subsidiary Corp. These two business lines share common offices in a couple of cities. Other than the fact that their employees eat lunch in the same cafeteria and bank at the same credit union, they are completely separate operating entities.

    Figure 8.7. Example IT organization for moderate-sized company.


    This separation applies to the IT departments, as well, and with a vengeance. Not only do the Company and Subsidiary IT departments have their own staff and budgets, their administrators pride themselves on managing their systems a thousand times better than those dunderheads on the other side of the basement. The company also maintains a small corporate IT group, but those folks are forced to do five-year return-on-investment projections and distribute hefty reports in Lotus Notes instead of centrally managing technology deployments.

    Administrative Functions

    If you try to design the OU structure based solely on the IT organization chart, you're destined to spend many, many days in long and arduous meetings getting one ephemeral consensus after another, all of which evaporates like a mist in the morning when your plan gets to upper management.

    Organizational charts don't reveal functional hierarchies, regional hierarchies, and business-line cross-matrix hierarchies that affect the way the IT department really runs. Even modern, forward-thinking companies dedicated to empowerment and individual ownership have some sort of hierarchical relationship among groups, if only to determine who gets first dibs on the parking spaces.

    So, don't design in a closed office. Get out and interview people, even if you've known them for years. Determine how your IT organization divides its management duties, either vertically by business unit or horizontally by region, then put on your detective hat and search out all the administrators and their managers and see how they interact on a day-to-day basis.

    While you're sleuthing, don't just look for people with job titles that say Administrator. Look for hidden lines of responsibility. You'll find power users and department gurus outside of the formal IT structure who have wide-ranging administrative responsibilities. You may find corporate IT staffers matrixed into local organizations with a variety of administrative rights. And you are bound to find a few consultants who have administrative or management duties that are integral to daily operations but not officially recognized by management. In short, find anyone who might need or want administrative privileges in the domain or domains you are designing.

    After you outline the true IT administrative hierarchy, find out how the staff members interact with each other. Define their administrative privileges then separate them into groups based on the privileges they exercise and who they administer.

    Upper Level OUs

    With all the information you collected about the IT administrative structure laid out in front of you, sketch two OU layers:

    • An upper layer that defines IT staff administrative boundaries. For example, an oil company like Conoco might define two top-layer OUs, Upstream and Downstream, to separate the business units with autonomous IT staff.

    • A second layer that defines objects requiring the same group policies or with specialized management needs. For example, you may outsource your desktop support so you would want to create a separate OUs for computer objects with permissions delegated to the outsource group.

    Use the upper OUs layer to delegate administrative permissions. For instance, you might give the local administrators Full Control rights over their own OUs but no rights on any other OUs. This compartmentalizes system administration.

    Use the lower layer or layers to distribute group policies (more on this in a moment) and separate out departments that need administrative permissions on their own equipment, groups, or users. Often managers are willing to trust a central IT group for managing equipment but splinter off user and group management to their own department personnel.

    It doesn't take a Wharton MBA to figure out that you want to push management responsibility as low in the organization as possible. Design to achieve centralized control of the directory structure with localized control of directory objects. In a nutshell, this means that a few top-level administrators can create or modify OUs at the root of the domain, whereas local administrators can create, modify, delete, and change permissions for objects in those OUs.

    Decentralized Operations

    Figure 8.8 shows the top-level OUs structure for a domain that encompasses a good chunk of the western United States, Mexico, and a bit of Central America. The company has two business lines; a wholly owned subsidiary shares facilities in two of the company offices and has separate facilities in two remote cities.

    Figure 8.8. Upper container structure for North American company with two business lines and a single domain.


    The company has several departments with quasi-independent computing staff. The HR department, for example, insists that the confidential nature of the data on their servers and local hard drives (they still don't quite trust the network) makes it imperative that only members of their own administrative staff manage their resources.

    The upper container structure for this domain divides along geographic lines because each office has its own IT staff. Departments with independent computing staff get separate containers under their office. This permits local IT personnel to administer the subordinate containers instead of relying on a central IT group. The Salt_Lake OU is an example of the opposite situation. The local IT staff would be perfectly content being in the Phoenix OU, but the Phoenix staff didn't want them to have administrative rights.

    The design puts nearly all the OUs at or near the top of the directory. No performance penalty accrues for having a wide directory structure. In fact, the opposite is true. You should avoid going too deep with your OU structure. The indexing and caching features in the Active Directory engine can handle 10 levels with ease. Going deeper is possible but not recommended. If you are having trouble maintaining a shallow container structure, you might want to consult with Microsoft field engineers to determine an optimal configuration for your situation.

    Centralized Operations

    The OU structure in the previous example would change radically if the company had an omnipotent central IT department with closely bound office staff subject to frequent audits and performance appraisals. In such a case, you could eliminate an entire upper stratum of the directory. Figure 8.9 shows an example.

    Figure 8.9. Upper containers for highly centralized IT organization with subsidiary business line configured as a peer domain in a forest.


    The container layout for a highly centralized IT organization distributes management rights among autonomous groups in the central IT organization. These containers hold the users, groups, computers, printers, and shared folders controlled by that group regardless of the office where they are located. The directory is replicated everywhere, so a container such as User Support can hold user objects from Phoenix, Houston, and Mexico City. Notice that the administrators in the Subsidiary business unit didn't trust the central IT group and insisted on having a separate namespace joined to the forest with a Tree Root trust.

    Display Specifiers and Localization

    Special filter objects called Display Specifiers in the Active Directory schema handle translation of the object contents. Display Specifiers look to see what language group was selected when a particular workstation or server is installed and they filter the object contents accordingly. Thanks to Display Specifiers, the fields and options for directory objects in the example would be displayed in Spanish for the Mexico City staff.

    Lower Level OUs

    The rules for OU placement at lower levels of the domain are based more on user and computer management than delegating administrative privileges. This involves manipulating the user experience in one way or another. The tools most suited for this purpose are group policies.

    Chapter 12, "Managing Group Policies," covers group policies in detail. Here is what we need to know at this point to aid in making design decisions. Group policies are a set of instructions that modern Windows clients (Windows 2000 and XP) download from their logon server and apply to their local Registry and security databases. There are 13 different policy types in Windows Server 2003. The operations supported by these policy engines are as follows:

    • sRegistry updates (known as Administrative Templates)

    • Security updates

    • Logon/Logoff scripts

    • Software distribution

    • Folder redirection

    • Disk quota management

    • Wireless network management

    • Restricted software selection

    • Public key distribution

    • IPSec policy management

    • Internet Explorer management

    • Remote Installation Services management

    • Quality of Service (QoS) management

    Group Policy Links

    Group policies are linked to containers in Active Directory. This is how clients determine which policies affect them. Group policies can be linked to the following containers, listed in order of least precedence to highest:

    • Sites

    • Domains

    • Organizational Units

    Policies flow down the Active Directory tree. In other words, users and computers inherit policies linked to their parent OUs and to any superior OUs, then the domain, then their local site.

    The list of policies that apply to a particular user or computer is called a Resultant Set of Policies, or RSoP. Windows Server 2003 includes a new feature that displays the RSoP for a user or computer. Figure 8.10 shows how policies inherit in a tree and what an RSoP display looks like.

    Figure 8.10. Domain and OU structure showing inherited group policies and the RSoP.


    Here's a rule of thumb: The closer a group policy object sits in relation to a user or computer in the Active Directory tree, the higher the precedence of the policies in the group policy object. For instance, a "Hide The 'My Computer' Icon" policy linked directly to the OU holding a user object will override a "Don't Hide The 'My Computer' Icon" policy linked to an OU higher in the tree.

    As we'll see in Chapter 12, "Managing Group Policies," you can block policy inheritance at a particular OU so that objects below that point don't experience the effects of policies linked to sites, domains, and other OUs higher in the tree. You can also override a policy block so that administrators in subordinate OUs cannot stop their users from getting policies dictated by central IT management.

    Group Policy Components

    Group policies have two distinct components that work together to deliver the policy instructions to the client for processing.

    • Group Policy Container (GPC). The GPC is an Active Directory object that defines a policy name, the client-side extension used to process the policy, where the instructions for the policy resides, and what container the policy is linked to. The GPC is located in the cn=Policies,cn=System,dc=<domain_name>,dc=<root> container in the Domain naming context. You can use the AD Users and Computers in Advanced View to see this container. Figure 8.11 shows an example of a policy that contains a software distribution policy, which puts additional information into Active Directory.

      Figure 8.11. AD Users and Computers showing Policies container.


    • Group Policy Template (GPT). The GPT is a set of instructions associated with a particular group policy. For example, a Logon policy would have a GPT consisting of a script. An Administrative Template (Registry) policy would have a GPT consisting of an entry in a file called Registry.pol. Clients download these GPT files and process them locally. The GPT files for a particular policy are located in the \Windows\Sysvol\Sysvol\<domain_name>\<policy_name> folder. The Sysvol contents are replicated among domain controllers via the File Replication Service, or FRS.

    These two group policy components, taken together, are called a Group Policy Object, or GPO. Microsoft's use of the term GPO was unfortunate because you typically think of objects as being entries in Active Directory, whereas the GPO is an umbrella term for a directory object and a set of template files.

    When you create a new group policy, you link it to an OU, domain, or site. The next time computers in that container start up, or users in that container log on, they download the policy. Administrative Template policies are applied in a volatile fashion so they do not tattoo the Registry like NT System Policies.

    Group Policy Tools

    Group policies are created and configured using the Group Policy Editor (GPE). You open the GPE by opening the Properties window for the container where you want to link the policy then selecting the Group Policy tab. Figure 8.12 shows the default group policies linked to the Domain container.

    Figure 8.12. Group Policy Editor showing the Default Domain policies.


    When you add or change a policy in the GPE, the system immediately creates or updates the associated GPC object and GPT files. There is no "Are you sure you want to do this?" warning.

    Group Policies and OU Design

    You will find yourself using policies extensively to control users and computers in an Active Directory domain, so it's important to take them into account when you lay out the lower OU levels. For example, the Sales manager might want every desktop in her department nailed down tight so that the salespeople focus on their quotas instead of fooling with their PCs. On the other hand, the field construction superintendent might consider even mild desktop restrictions to be too confining.

    Figure 8.13 shows an example OU design based around applying group policies. All designs are different, but here is the basis for the design decisions in the example:

    • Users. This container holds the accounts for all users in the Phoenix office except for HR and field personnel, who attach to the network via a WAN link to the Phoenix LAN. Putting all users in a single container makes it possible to delegate administrative control of the container as well as define group policies. The subordinate container for Sales accommodates a request for a different group policy. In theory, each department could have its own OU with policies tailored for its specific needs.

    • Groups. You cannot assign group policies to groups, only users and computers, but this container reflects a certain tidiness on my part. I like keeping group objects in a separate container to make them easy to find. There is no performance penalty for putting groups in different containers from their members.

    • Field. This container provides a place to put objects for remote locations such as job sites and temporary quarters. The separate container accomplishes two things. First, group policies for field personnel are usually much less restrictive than office policies. Second, field operations often have local technicians who are not full-fledged administrators. The separate container provides a way to assign them limited administrative rights over their users and machines.

    • IS and HR. These containers provide discrete management units that satisfy the need for autonomy on the part of the staff. The danger, of course, is that the department administrators in the HR container will somehow bollix up their part of the directory and no one from the main IT group will be able to rescue them.

    • Printers and Shared_Folders. These containers place items that users search for near the top of the container structure. The fewer containers a user has to negotiate to find a shared item in the directory, the more likely they are to use it. If you don't make directory access drop-dead simple, you'll never wean users away from browsing.

    • Hardware. This container puts Computer objects into two separate containers, one for workstations and one for servers, where they can be managed as distinct units. The desktop administrators or break/fix technicians can be given admin rights over the Workstation container, whereas only network administrators have rights over the Server container. There is no operational advantage to putting Computer objects in the same container as their users. It's much easier to find objects in a container that isn't cluttered with different object classes.

    Figure 8.13. Lower-level container structure for single domain in a multiple-domain directory.


    After you draw out the lower-level design, start getting input from your colleagues, administrators in other parts of the organization, and management. Plan on this stage taking a while, even in a small organization. You might want to set up a small lab environment so that you can walk through typical operations.

    Simplified OU Structure

    If you work in a smaller organization, or you are a consultant with a practice that focuses on small and medium-sized companies, you may find the design in Figure 8.13 to be a bit too much. Figure 8.14 shows a directory for a smaller organization.

    Figure 8.14. Directory design for a small company.


    When IT staff is limited, local department gurus and power users tend to take on more administrative duties. For this reason, the design in Figure 8.14 divides the lower containers along functional lines. A group in each OU can be assigned management rights for the OU and you or a central administrator can modify the group memberships based on requests from the department managers.

    Whatever design method you choose, leave yourself room for changes and don't be afraid to shake up the design quite a bit in response to changes in the IT work processes. As long as you can avoid splitting off a new domain and you don't get too creative with your policies, you can make changes without affecting users.

    This just about takes care of the design preparations. Now you need to attend to a few housekeeping chores involving the placement of special-purpose servers.

      Previous Section Next Section