What is the term for domain and forest functions that must be coordinated from a single domain controller?

1.2.7 Global Catalog Server

The Global Catalog (GC) server holds the same information as a domain controller. However, the global catalog server also holds a read-only replica of every domain naming context in the forest. Thus, a domain controller only knows about the objects in its domain, while a global catalog server knows about objects in its domain and every other domain. Although the global catalog server knows about all objects from every domain, it only has knowledge of a subset of the attributes for each object. The objects that are available for replication to a global catalog server are controlled by the Active Directory Schema Manager snap-in. By default, the first domain controller in a domain is a global catalog server. Global catalog servers listen on port 3268 (using LDAP) for queries, as well as on the standard LDAP port 389. Port 3269 may also be used on a global catalog server to process requests for global catalog information over Secure Sockets Layer (SSL). A domain controller can be made into a global catalog server by selecting the option from the Active Directory Sites and Services snap-in.

Global Catalog servers

Global Catalog (GC) servers are DCs assigned to host additional information about the forest. A typical DC contains details about the domain in which it resides, however, GC servers contain additional information about every domain in the forest. GCs are especially important to properly plan when deploying multiple AD domains. GCs are designated using the AD Sites and Services console as seen in Figure 4.17. Some applications, such as Microsoft Exchange server, rely on connectivity to GCs opposed to normal DCs. You will want to ensure that you have adequate redundancy for GCs when planning your AD deployment.

Summary of Exam Objectives

The Global Catalog (CG) server is one of the most important roles played by one or more DCs in your network. It might not appear to do much on the surface, but the GC is responsible for helping resolve names for objects throughout your forest. The GC server holds a copy of all the objects in the domain in which the server is located. That same GC server holds a partial replica of other domains in the forest. The information that the GC holds from other domains includes common search items. This limited but frequently accessed information makes queries very efficient.

GC servers are responsible for UPN authentication. When a user logs on using the UPN, the GC is queried to locate the user account and a domain controller (DC) in the appropriate domain. GC servers are also responsible for answering queries against Active Directory. If a user wants to locate another person within the organization, that user could use his workstation to search Active Directory. The queries are sent to the IP port 3268, which is used for GC communication.

Placement of GC servers has to be considered early in the design process for your network. If you don’t determine where you do and do not need a GC server and plan accordingly, you could have communication problems and users could be adversely affected. A good rule of thumb is to remember that if a location has over 50 users, a DC is needed at that location. Dividing the network into sites makes a difference in how replication traffic is handled in regard to GC information. Replication within a site (intrasite replication) is handled differently than replication between different sites (intersite replication). Placement of GC servers within every site might not be necessary, but you should keep track of how much bandwidth computers are using. GC queries in large quantities can tie up significant bandwidth.

If the domain functional level is at least Windows 2000 Native, Universal Groups will be available. The GC is the only location in which Universal Group information exists. When users log on, their Universal Group membership is verified. The authenticating DC makes this request of the GC server. If the GC server cannot fulfill the request, logon can be denied. However, with Windows Server 2003, Universal Group membership can be cached to prevent this problem. Caching must be turned on under NTDS Site Settings Properties in the Active Directory Sites and Services console as explained previously in this chapter. With this setting turned on, the authenticating DC will query the nearest GC for Universal Group membership. The information received will be cached on the authenticating DC, and refreshed every eight hours by default. With caching enabled, that authenticating DC will be able to process logons in the event the GC cannot be reached because the information has been cached.

The schema defines the structure of your Active Directory. Various types of objects can be administered in Active Directory. An object in Active Directory is an instance of a class, such as User or Printer. A class defines the type of object. Associated with each Object class are attributes that can be modified. For example, an attribute can be the Location or First Name, There are two different types of attributes. The most common is the single-value attribute, which contains one piece of data. You might also work with multivalue attributes, which can contain more than one piece of data. An example of the latter is a telephone number. The Other button allows you to add additional entries in the event that someone has more than one telephone number.

To speed queries and make searches easier, attribute indexing can be enabled. This process builds an index of every attribute in an instance. Common attributes should be indexed, but not all attributes should be indexed. Special consideration should be given to indexing multivalued attributes. You can produce a lot of extra traffic because of replication of all the multivalued attributes in an instance. When you are working with Schema objects, there are different ways you can reference an object. Common ways to describe objects include LDAP names, Common Names, and OIDs. LDAP is an industry standard protocol and the primary access protocol for Active Directory. The Common Name is an easier way to identify an object. The OID is assigned by a third-party authority. There are standards that must be followed in regard to OIDs. We recommend that you follow the naming standards laid out for LDAP and Common Name.

You can use the Schema MMC snap-in to do all modifications in regard to GC and schema. To install the snap-in, you must first register the schmmgmt.dll file; then you can create a custom MMC and add the Schema snap-in. The Schema snap-in is used to extend the schema if the default classes and attributes do not meet your needs. When considering extending the schema, you need to make sure you have tested the changes thoroughly before applying them to a production network. A problem with the schema can mean serious trouble for your network. You must log on as a member of the Schema Admins group to make any modifications or extensions to the schema. The only default member in this group is the Administrator of the forest root domain.

Changes made to the schema cannot be deleted, but they can be deactivated. Windows Server 2003 doesn’t allow for deletion of classes or attributes within Active Directory. A deactivated class or attribute is still in the schema database, but is unavailable for use.

2.3.3 Deploying Global Catalogs

Because you need to have at least one Global Catalog server in each site that supports an Exchange 2007 server, Global Catalog servers are a critical component of your Exchange 2007 deployment. As you roll out servers to support Exchange 2007, you may want to investigate what Global Catalogs are deployed within your infrastructure. Some of these computers may not be required as you can normally consolidate the workload done by several 32-bit Global Catalog servers into a smaller number of 64-bit servers. This is especially valuable when your Active Directory includes more objects than can be cached in the memory available to 32-bit Windows servers. It's difficult to be precise as to exactly how many objects this represents because the average size of an Active Directory object depends on the object type (user objects are bigger than contacts or groups, for instance) and how many of their properties are populated. A good rule of thumb is deploy 64-bit Global Catalogs when the forest contains more than 100,000 objects. Of course, over time, the natural server replacement cycle will replace the 32-bit version of Windows with 64-bit servers and the process will complete naturally, but it's certainly a good idea to move faster when you have large directories to manage.

As an example, tests inside HP's production Windows environment showed that a single 64-bit Global Catalog server (dual CPU, either Opteron or IA64, equipped with 14GB of memory) can handle the load previously processed by eleven 32-bit servers for 20,000 users in a single large campus site. In HP's case, the size of the DIT (AD database file) varies between 10 and 11GB to hold approximately 350,000 objects, depending on the amount of white space in the database, so it is possible to cache the entire database if the server is equipped with enough physical memory. Normal Exchange messaging activity in a reasonably busy site will populate the cache on a Global Catalog server quickly and once the cache is populated, further access is very fast indeed. Depending on the size of your Exchange and Active Directory infrastructure, your mileage will vary, so do not take these figures as anything more than a guideline to what might be possible. It is also obviously not a good idea to depend on a single large Global Catalog to handle the workload generated by a set of Exchange servers as a failure on the Global Catalog will affect thousands of users, so in a production environment, you would have at least two or three Global Catalogs for a site that supports 20,000 users, even if one can handle the workload.

Before you can decide what Global Catalogs to refresh or consolidate, you need to know where they are. There are at least three ways of discovering what Global Catalog servers exist inside the forest. First, you can use the NSLOOKUP utility to check what servers have registered themselves as offering a Global Catalog service

The difficulty here is that servers might have registered themselves as Global Catalogs at some point in the past and subsequently ceased this role but never removed their information from Active Directory. You can go to every Domain Controller and query it to see if its isGlobalCatalogReady attribute is true, but this can be quite a lot of work.

Microsoft also provides the REPLMON utility as part of the Windows support tools. You can add a server to its list and then right click on the server and select the “Show Global Catalog servers in the Enterprise” option to view the data. Other products such as the HP OpenView Smart plug-in for Active Directory are able to graphically chart the replication topology and show you what's going on inside your network. These approaches work equally well with both before and after you deploy Exchange 2007. Once you start to deploy Exchange 2007, you'll be able to use PowerShell, the new Windows scripting language. There is much more coverage of PowerShell and how you can use it to manage Exchange 2007 in Chapter 4. For now, we should recognize that PowerShell has a huge influence over how you will manage Windows, Exchange, and other components going forward, so it's not surprising to discover that you can use PowerShell to interrogate the Active Directory and find out what Global Catalog servers exist.

After you start up PowerShell, we start off by populating a variable with details of the forest.

You can view details of the forest by typing the name of the variable and this reveals some interesting information which you can capture by piping the output to a text file:

You'll see something like this:

This list is easy to understand in a small organization, but it can be difficult to interpret in more complicated environments, so we can break out the Global Catalogs and list them as follows:

Using the New System State Backup Method

Windows 2000 only offered two choices when deploying DCs and GC servers for remote sites, and neither choice was ideal for many companies. The first choice was to build the server at the home office where it could replicate over the LAN, and ship it to the remote location. This worked, as long as you got the new server online within the 60-day tombstone lifetime. If you didn’t, the DC or GC could reanimate previously deleted Active Directory objects, including user accounts.

The second choice was to promote the server at the remote location and hope that replication would finish before users needed to use your WAN bandwidth for something else—like logging on to the domain. Replication can take days over a slow link, depending on the size of your directory and the available bandwidth. The tombstone problem still exists, but it is easier to ship new backup media from the main office than it is to ship an entire server.

This final DC installation procedure covers the new method of installing the Active Directory database on your new DC from backups, as illustrated in Figure 4.33.You should use a healthy Windows Server 2003 DC as the source of the system state, and DNS should be working before you begin. Exercise 4.09 is an advanced procedure, and assumes certain skills such as installing Windows Server 2003 as a member server, the use of Windows Backup, and general Windows administrative abilities. You should also test this procedure in a lab environment before trying it on an operational network. In addition, Exercise 4.09 will show you how to use an answer file to automate the promotion process, making this the optimal procedure for unattended installations. Figure 4.34 shows a sample answer file. The /ADV switch with dcpromo is only necessary for promoting from a backup file.

Exercise 4.09

Creating a New Domain Controller in an Existing Domain Using the New System State Backup Method

Steps 1 through 3 walk you through taking the snapshot.

Log in as a local Administrator on the healthy DC.

Create a directory called C:\Backup. If the folder already exists, remove any files that it contains.

Using Windows Backup, save the system state. It is a good practice to name the file after your source DC, giving it a .bkf extension.

You now must transport the file. Use the backup media of your choice, ensuring your ability to perform the restore at the other end. Remember that the backup file can be many GBs in size. If you choose to use the network to transport the file, you can perform the restore and the copy at the same time using the following steps. There are various ways to accomplish this. If you choose to use a third-party backup program to transport the file on physical media such as DLT tape, CD, or DVD, you will still need to use Windows Backup at the other end to extract the data from the backup file. Adjust the procedure to your preferences.

Log on as a local Administrator on the member server that you want to promote, and create a shared folder called C:\Restore. It might be on your LAN or across a WAN at this point, so you might need a helping hand at the other end.

Back at the DC, map a drive to the shared folder created previously if you choose to copy the file over the network.

You have two options, depending on your choice of transport. If you are copying the file across the network, use the Restore Wizard within Windows Backup from the existing DC to restore the domaincon-trollername.bkf file to the shared folder in the member server. If you have created physical media for transport, use the Restore Wizard directly on the member sever using the local physical media.

NOTE

Within Windows Backup, select the System State as the file to restore. Most importantly, select Advanced Options and specify the mapped drive as the destination if you are restoring from the source machine. If you don’t, it will assume the file’s original location and you will revert your DC to the state it was in at the time of the backup.

Create a file on the member server containing the following settings. For the exercise, we call this file DCUnattend.txt. Examine the options in Figure 4.34. They allow for unattended Active Directory installations in other configurations such as directly across the network from an established DC. Remember to rename the member server before promoting it, or you will be faced with the opportunity to perform a domain controller rename procedure, which is another new feature of Windows Server 2003.

NOTE

Coordinate with your computer security department if necessary, since the username and password of an administrator account will be hard coded into the answer file. You might have local regulations prohibiting this. Microsoft has provided a risk mitigation method of automatically erasing the password from the file as soon as it is used. If you want to run the answer file again, you must edit the file and re-enter the password. One way around this is to delegate permission for this operation to a regular domain user account and use that account within the answer file, although other security issues have to be considered in that case.

Open a command prompt and type the following command: Dcpromo /adv /answer:C:\DCUnattend.txt. After it is complete, the system will reboot. If dcpromo stops and asks for information, then some information was missing from the answer file.

Verify that the installation was successful. Open a command prompt and enter the Net Share command. It should report the existence of the Netlogon and SYSVOL shares. To verify that the DNS service locator records for the new DC were successfully created, follow these steps:

Click Start | Administrative Tools | DNS to start the DNS administrator console.

Expand the server name.

Expand Forward Lookup Zones.

Expand the domain.

Verify that the _msdcs, _sites, _tcp, and _udp folders are present and contain records for your new DC. These service location records are crucial to the operation of the DC. See Table 4.7 for a more detailed description.

Placing the FSMO Roles within an Active Directory Environment

It is a good idea to place the RID and PDC Emulator roles on the same DC. Down-level clients and applications target the PDC, making it a large consumer of RIDs. Good communication between these two roles is important. If performance demands it, place the RID and PDC Emulator roles on separate DCs, but make sure they stay in the same site and that they are direct replication partners with each other.

As a general rule, you should place the Infrastructure Master on a DC that is not a GC server to maintain proper replication. There are two exceptions to this rule:

Single domain forest If your forest contains only one Active Directory domain, there can be no phantoms. The Infrastructure Master has no functionality in a single domain forest. In that case, you can place the Infrastructure Master on any DC.

Multidomain forest where every DC holds the GC Again, there can be no phantoms if every DC in the domain hosts a GC. There is no work for the Infrastructure Master to perform. In that case, you can place the Infrastructure Master on any DC.

Additionally, ensure that the Infrastructure Master has a direct connection object to a GC server somewhere in the forest, preferably in the same site.

Considering the forest-wide FSMOs, the Schema Master and Domain Naming Master roles are rarely used and should be tightly controlled. For that reason, you can place them on the same DC. Another Microsoft-recommended practice is to place the Domain Naming Master FSMO on a GC server. Taking all of these practices together, a Microsoft-recommended best-practice empty root domain design might consist of two DCs with the following FSMO/GC placement:

DC 1:

Schema Master

Domain Naming Master

GC

DC 2:

RID Master

PDC Emulator

Infrastructure Master

Managing Roles of GC Servers

As stated in the preceding section, you can determine the perceived and actual performance of your network by where you place the GC servers on domain controllers. The disadvantage to adding copies of the GCs around your network is that they need to replicate with each other, and increasing the number of GC servers may degrade performance, especially across slow network links. You can add or remove GCs from domain controllers from the command line.

The command for adding or removing a GC from an individual server is dsmod server. When using DSMod with other object types, the command permits you to set and modify myriad properties. With the server object type for domain controllers, it only permits you to set and modify the description and management of the GC role. The following is the full command syntax for dsmod server.

To manage the GC role, however, the following command is required:

Earlier in the chapter, we discussed the technique for locating domain controllers that host a copy of the GC. Figure 11.30 shows how to remove the GC from a server. Once the server is found, enter the following command:

No confirmation is required to complete performance of this task, and the success message is displayed when complete. Adding the GC involves entering the same command using a server that is not currently hosting a copy of the GC, and changing the modifier for –isgc from no to yes.

10.3 Exchange, DSAccess, and Firewalls

Versions of Exchange 2000 prior to SP2 always used RPCs to facilitate connections from the DSAccess component on the front-end server to domain controllers and global catalog servers in the internal network. However, versions of Exchange since Exchange 2000 SP2 up to and including Exchange 2003 make significant improvements when it comes to controlling the port access required from DSAccess on front-end servers in the DMZ to internal domain controllers and global catalog servers. Since Exchange 2000 SP2, LDAP is used for DSAccess to domain controller–global catalog server communication, but DSAccess will still attempt to use the NetLogon service to communicate with each DC and GC that it discovers. I haven't suggested blocking RPC traffic across the internally facing firewall to the intranet (for reasons upon which I'll expand later), but if you do, then DSAccess will simply determine that the RPC traffic is blocked but domain controllers and global catalog servers are still available. This is not a major problem, but for reasons of performance, you should disable the NetLogon checking (I described how to do this in Chapter 1).

It's also common in DMZ firewall environments to have Internet Control Message Protocol (ICMP) packets blocked by the internally facing firewall to prevent system discovery and Denial-of-Service (DOS) attacks. However, the DSAccess that ships with SP2 uses ICMP pings to validate the availability of domain controllers and global catalog servers. Blocking ICMP traffic therefore causes DSAccess to assume that domain controllers and global catalog servers are unavailable and to force new topology discoveries using LDAP access to those servers. Similarly, this has a negative performance impact, and, again, it is advisable to disable DSAccess from performing these ICMP pings to the domain controllers and global catalog servers. (Again, I described how to disable this in Chapter 1).

Preparing the Environment for a Transition to Exchange Server 2007

The domain controller that is the schema master in the Active Directory forest should run Windows Server 2003 with at least Service Pack 1 applied.

Any Global Catalog servers in each Active Directory site in which you plan to deploy Exchange 2007 should run Windows Server 2003 with at least Service Pack 1 applied.

For any non-English domain controllers in your Active Directory forest, apply the hotfix mentioned in MS KB article 919166 (http://support.microsoft.com/kb/919166).

Exchange 2007 requires that the domain functional level is set to Windows 2000 Server or Windows Server 2003.

Since Exchange Server 2007 requires that the legacy Exchange organization is running in native mode, we need to decommission any pre-Exchange 2000 servers (that is, Exchange 5.5 servers and previous versions) that exist in the Exchange organization.

Depending on your topology, Link State updates must be suppressed on any Exchange 2000 or 2003 servers in the Exchange legacy organization when you're deploying an Exchange 2007 Server. Bear in mind that this is required only if you're planning to establish more than one routing group connector in the organization.

What is Exam 70-294?

Exam 70-294 is one of the four core requirements for the Microsoft Certified Systems Engineer (MCSE) certification. Microsoft’s stated target audience consists of IT professionals with at least one year of work experience on a medium or large company network. This means a multi-site network with at least three domain controllers, running typical network services such as file and print services, database, firewall services, proxy services, remote access services and Internet connectivity.

However, not everyone who takes Exam 70-294 will have this ideal background. Many people will take this exam after classroom instruction or self-study as an entry into the networking field. Many of those who do have job experience in IT will not have had the opportunity to work with all of the technologies covered by the exam. In this book, our goal is to provide background information that will help you to understand the concepts and procedures described even if you don’t have the requisite experience, while keeping our focus on the exam objectives.

Exam 70-294 covers the basics of managing and maintaining the Active Directory infrastructure in a network environment that is built around Microsoft’s Windows Server 2003. Objectives are task-oriented, and include the following:

Planning a strategy for placing global catalog servers, including evaluating network traffic considerations and evaluating the need to enable universal group caching.

Planning the placement of flexible operations master roles, including how to plan for business continuity of operations master roles and identifying operations master role dependencies.

Implementing an Active Directory directory service forest and domain structure, including creating the forest root domain, creating a child domain, creating and configuring Application Data Partitions, and installing and configuring an Active Directory domain controller. This objective also includes setting an Active Directory forest and domain functional level based on requirements, and establishing trust relationships such as external trusts, shortcut trusts and cross-forest trusts.

Implementing an Active Directory site topology, including configuring site links and configuring preferred bridgehead servers.

Planning an administrative delegation strategy, including planning an organizational unit (OU) structure based on delegation requirements and planning a security group hierarchy based on delegation requirements.

Managing an Active Directory forest and domain structure, including managing trust relationships, managing schema modifications, and adding or removing UPN suffixes.

Managing an Active Directory site, including configuring replication schemes, configuring site link costs, and configuring site boundaries.

Monitoring Active Directory replication failures, using tools such as Replication Monitor, Event Viewer and support tools to monitor Active Directory replication and File Replication Service (FRS) replication.

Restoring Active Directory directory services, including performing both authoritative restore and nonauthoritative restore operations.

Troubleshooting Active Directory, including diagnosing and resolving issues related to Active Directory replication, operations master role failure, and the Active Directory database.

Planning a security group strategy.

Planning a user authentication strategy, including planning a strategy for smart card authentication and creating a password policy for domain users.

Planning an OU structure, including analyzing the administrative requirements for an OU and analyzing the Group Policy requirements for an OU structure.

Implementing an OU structure, including creating an OU, delegating permissions for an OU to a user or a security group, and moving objects within the OU hierarchy

Planning a Group Policy strategy, including using Resultant Set of Policy (RSoP) planning mode, and strategies for configuring the user environment and computer environments using Group Policy.

Configuring the user environment with Group Policy, including distributing software to users via Group Policy, automatically enrolling user certificates with Group Policy, redirecting folders via Group Policy and configuring user security settings using Group Policy.

Deploying a computer environment using Group Policy, including distributing software to computers via Group Policy, automatically enrolling computer certificates with Group Policy, and configuring computer security settings using Group Policy.

Troubleshooting issues related to Group Policy application and deployment, using tools such as RSoP and the gpresult command.

Maintain installed software using Group Policy, including distributing updates to software distributed by Group Policy and configuring automatic updates for network clients using Group Policy.

Troubleshoot the application of Group Policy security settings, using tools such as RSoP and the gpresult command.

Microsoft reserves the right to change the objectives and/or the exam at any time, so you should check the web site at http://www.microsoft.com/traincert/exams/70-294.asp for the most up-to-date version of the objectives.