The check box on the General tab is used to enable or disable GC functionality.To be able to change the state of the GC check box, you must be a member of the Domain Admins group or the Enterprise Admins group. As stated previously, the planning of GC server placement is important for a successful network. Each GC server creates additional replication traffic on the network. Understanding GC Replication You know now that GC servers hold information for all of the objects in their own domains and a partial copy of the objects from other domains in the forest through replication.The default attributes included in the GC make up the most commonly searched for items.These items are part of normal Active Directory replication. The Knowledge Consistency Checker (KCC) generates the GC replication topology.The GC is only replicated between DCs that are GC servers; the information is not replicated to other DCs. A few things can affect replication; for example, Universal Group membership, and the number of attributes included in the GC. Universal Group Membership The GC holds the sole responsibility of maintaining Universal Group membership.The names of the Global Groups and Domain Local Groups are also in the GC, but their membership lists are not. This helps keep the size of the database small enough to efficiently answer queries. For replication purposes, it is best to keep Universal Group membership relatively static. Every change made to a Universal Group is replicated to every GC server. Keeping these changes to a minimum will keep the GC replication traffic to a minimum. 546 Chapter 16 • Working with Global Catalog Servers and Schema Figure 16.3 General Tab of NTDS Settings Properties 301_BD_W2k3_16.qxd 5/12/04 1:28 PM Page 546 Attributes in GC When you first set up Active Directory, there is a series of default attributes from Active Directory in the GC. Sometimes, the default set of attributes is missing an item you would like to see. For example, perhaps you want to have a coworker’s department number as part of his user record; you can accomplish this by adding an attribute.You can use the Active Directory Schema snap-in to include additional attributes in the GC by using the General tab as shown in Figure 16.4.To get to this option, open the Schema snap-in, and expand the Attributes section. Right-click any attribute, and select Properties. Prior to Windows Server 2003, each time the attribute set was extended, a full synchronization of all attributes stored in the GC was completed. In a large network, this can cause a serious amount of network traffic. With Windows Server 2003, only the additional attribute or attributes are repli- cated to other GC servers.This makes more efficient use of network bandwidth. Placing GC Servers within Sites Another consideration when it comes to replication is placement of your GC servers. In a small net- work with one physical location, GC server placement is easy.Your first DC that is configured will hold the GC role. If you have one site, but more than one DC, you can move the role to another DC if you want to. Most networks today consist of multiple physical locations, whether in the same city or across the country. If you have high-speed links connecting your branch offices you might be okay, but many branch office links use limited bandwidth connections. If the connection between locations is less than a T1, you might have limited bandwidth depending on what traffic is crossing the wire. As a network administrator, you will have to work with your provider to gauge how much utilization there is across your WAN links. Working with Global Catalog Servers and Schema • Chapter 16 547 Figure 16.4 Adding Attributes to the GC 301_BD_W2k3_16.qxd 5/12/04 1:28 PM Page 547 Another factor is reliability. If your WAN links are unreliable, replication traffic and synchroniza- tion traffic might not successfully cross the link.The less reliable the link, the more the need for set- ting up sites and site links between the locations. Without proper planning, replication traffic can cause problems in a large network. Sites help control replication traffic. Making the most of available bandwidth is an important factor in having a network that allows your users to be productive. Logon and searching Active Directory are both affected by GC server placement. If users cannot find the information they need from Active Directory, they might not be able to log on or find the information or data they need. Bandwidth and Network Traffic Considerations Active Directory replication works differently depending on whether it is intersite or intrasite replica- tion, as we discussed in Chapter 14. DCs that are part of the same site (intrasite) replicate with one another more often than DCs in different sites (intersite). If you have sites that are geographically dispersed, you need to be careful how you handle your GC server placement.The bandwidth between geographically dispersed offices is often minimal.The rule of thumb is to have GC servers in selected sites. In most cases, you do not want to have a GC server in every site because of the vast amount of replication that would occur.The following examples describe situations in which you should have a GC server within a site: ■ If you have a slow WAN link between geographic locations. If you have a DC at each location, a good rule is to also have a GC server at each location. If the WAN link sup- ports traffic for normal DC traffic, it should also handle GC traffic. ■ If you have an application that relies heavily on GC queries across port 3268, you’ll want to have a GC server in the site that the application runs in. An example of this is Exchange 2000, which relies heavily on GC information. ■ If the domain functionality level is Windows 2000 native or later, you’ll want to have GCs in as many sites as possible because Universal Group membership comes into play. We look at caching of Universal Groups, which can reduce traffic related to this, in the next section. Data replicated between sites is compressed, which makes better use of available bandwidth. Because the data is compressed, more can be sent over a limited amount of bandwidth.This is how site placement and design can be critical to efficient network operation. For more information in site replication, refer to Chapter 14. Universal Group Caching The Windows Server 2003 Active Directory introduces Universal Group caching as a new feature. When a user logs on to the network, his or her membership in Universal Groups is verified. For this to happen, the authenticating DC has to query the GC. If the GC is across a WAN link, the logon process will be slow every time.To alleviate this, the DC that queries the GC can cache this infor- mation, which cuts down on the amount of data traveling across the WAN link for Universal Group information. The cache is loaded at the first user logon. Every eight hours by default, the DC will refresh the cache from the nearest GC server. Caching functionality is administered in Active Directory Sites 548 Chapter 16 • Working with Global Catalog Servers and Schema 301_BD_W2k3_16.qxd 5/12/04 1:28 PM Page 548 and Services as shown in Figure 16.5, and can be turned off if desired.You can also designate the GC server from which you want the cache to refresh, giving you more control over traffic distribu- tion on the network. Prior to Windows Server 2003, Active Directory logon failed if a GC could not be located to check Universal Group membership. With Universal Group caching, DCs cache complete group membership information, so even if a GC server cannot be reached, logon will still happen based on cached Universal Group information. Troubleshooting GC Issues As with anything on your network, you will spend a certain percentage of your time trou- bleshooting issues. Common issues with GC include: ■ Replication latency between GC servers ■ Slow query response ■ Overall load too high Determining the proper course of action depends on the problem you are encountering.The basic answer to any of the preceding issues will result in either moving or adding GC servers. If you are experiencing replication latency, you need to look at your GC servers and possibly your site configuration. Adding sites might help with replication traffic, as traffic between sites repli- cates differently than it does within sites. Between sites, the data is compressed and will cut down on bandwidth usage, which could help with the latency problem. Slow query response can be a result of slow links between locations. Adding a GC server to the location experiencing this problem if one isn’t already present will help. In addition, checking your site configuration can help as well. Workstations within a site will query the local GC server versus going across a WAN link. Working with Global Catalog Servers and Schema • Chapter 16 549 Figure 16.5 Configuring Universal Group Caching 301_BD_W2k3_16.qxd 5/12/04 1:28 PM Page 549 If the overall load is too high, you need to look at adding more GC servers to balance the traffic.This also results in more replication traffic if you are not careful, so planning and considera- tion of the impact on your network is important. There is no one single answer to troubleshooting your GC and the servers involved. Even with proper planning, problems sometimes arise. Working through the problem and testing will take time, and location of GC servers can make all the difference in a successful Active Directory layout. Working with the Active Directory Schema To have a directory, you must have a framework on which your directory structure is based.The Active Directory schema defines your directory. For an object to store data such as a username or telephone number, there has to be a field in which this information can be entered.These fields have names and belong to another component of the schema, which we will look at shortly. As with any other type of database, a schema simply defines the structure for the data. It is important to remember that there is only one schema per forest.Thus, all the domains in the forest share this single schema. Schema information is the backbone of your Active Directory and the data within. If problems develop in the schema, your entire network could be out of com- mission.This means that you must be very careful with the schema.—which is why only members of the Schema Admins groups have write permission to the schema.The only default member of that group is the Administrator account in the forest root domain.You should be very selective when choosing members of the Schema Admins group. Understanding Schema Components Every database is built on a foundation that defines its structure, the database model.The founda- tion, or model, is based on various components (see Figure 16.6).The first component of the foun- dation for the schema in Active Directory is the class. Objects in the database belong to classes. A little later in the chapter, we look at how the class defines the structure of your data. Associated with each object are fields, or attributes, that you fill in with data. We’ll look at how this component relates to the class, and then bring it all together. For now, remember that the important components of the schema are: ■ Object classes ■ Object attributes As with any database, there must be a naming standard. Within this section, we will look at schema object naming and how information can be referenced in different ways. If you decide that you need to extend the schema by adding additional classes or attributes, you need to plan exactly how you want it done. It is important to take extreme care in extending the schema. In most cir- cumstances, software installations will extend the schema rather than an administrator manually editing it. Software such as Microsoft Exchange or Microsoft SQL can use the schema and some- times require that changes be made.This is generally done as part of the software installation process and is the reason why you have to be logged on with a particular user account when installing that type of software. 550 Chapter 16 • Working with Global Catalog Servers and Schema 301_BD_W2k3_16.qxd 5/12/04 1:28 PM Page 550 Classes Object classes define your objects in the directory. Examples of Object classes include: ■ User ■ Printer ■ Computer When you create a new object in Active Directory, such as a new user account, you are creating a new instance of the existing User class.The class determines what attributes the object can contain. Classes are defined separately from attributes because there can be attributes that different classes share. A good example would be the location attribute.This attribute can be shared by the User class, Site class, and Printer class.Thus, the attribute is only defined once in Active Directory and is then linked to the respective classes of which it is a part. Figure 16.7 is a screen from the Active Directory Schema snap-in and some of the default Object classes. Working with Global Catalog Servers and Schema • Chapter 16 551 Figure 16.6 Schema Components Diagram Classes Attributes User Computer Printer First Name Last Name Location Telephone Fax Number Profile Path 301_BD_W2k3_16.qxd 5/12/04 1:28 PM Page 551 Each Object class has a definition that determines which of its allowed attributes are required and which are optional.These are known as ClassSchema objects in Active Directory, and define the common name for the object, a list of “must have” attributes, and a list of “might have” attributes, among other things.There are three types of Object classes in Windows Server 2003: structural objects that give an identity to the physical objects that make up your network (for example, servers or users); abstract objects that are used to define the structure objects (these are like a template for cre- ating structural objects); and auxiliary objects, which are a predefined list that contains attributes that can be included in structural and abstract objects.The Type 88 in Figure 16.7 is an example of an auxiliary object. Attributes You need to define various attributes for each object you create. Remember that the Object class determines which attributes are required and which are optional. All attributes associated with that class will exist, but some (the optional attributes) can be left blank.You will be required to enter information for the required attributes. An example of an attribute is First Name or Telephone Number.This attribute is associated with the User Object class.These attributes can be filled in when you create the user account and are defined in Active Directory as containing a certain type of data. The AttributeSchema object defines the characteristics of a given attribute. Configuration items such as common name, syntax rules, and other things make up the AttributeSchema object. For example, a Telephone Number attribute is generally in a specified format, such as Access code-Area or Country Code-Prefix-Number (for example, 1-512-555-1234). However, the schema is not this specific; it specifies that the syntax must be a Unicode string of characters, with a minimum of one and a max- imum of 64 characters. In addition to defining the syntax, each attribute’s properties will also include an X.500 object identifier (OID) for interoperability with other directories that comply with X.500 specifications, and a statement as to whether the attribute is single or multivalued as shown in Figure 16.8. Recall that X.500 is the directory standard upon which AD is built. 552 Chapter 16 • Working with Global Catalog Servers and Schema Figure 16.7 Object Classes in Schema 301_BD_W2k3_16.qxd 5/12/04 1:28 PM Page 552 You use the Active Directory Schema snap-in to maintain attributes just as you do with objects. Figure 16.9 shows some of the default attributes within Active Directory. Single-Value Attributes Most of the attributes you will work with will be single-value attributes. A single-value attribute is just what its name implies; it is an attribute with one piece of data entered.An example would be First Name.The First Name attribute cannot hold multiple values of data.After the first name is entered, you have to create a completely different object if you want to have another object with a different First Name attribute. Working with Global Catalog Servers and Schema • Chapter 16 553 Figure 16.8 Properties of an Attribute Figure 16.9 Default Attributes in Active Directory 301_BD_W2k3_16.qxd 5/12/04 1:28 PM Page 553 Multivalue Attributes Although most attributes are of the single-value variety, there are also cases where an attribute will hold more than one piece of information. Attributes such as Telephone Number can hold multiple values. When you create a user account or edit its properties, you can enter a main number of 555- 5555 for a user, and if that user has a secondary line, you can click the Other button to add addi- tional data as shown in Figure 16.10. (You can access the properties for a user account by opening the Active Directory Users and Computers (ADUC) administrative tool, clicking the Users container in the left console tree, right-clicking the username whose properties you want to edit in the right console pane, and selecting Properties.) Multivalue attributes do not sort or keep track of the order of the entries if there are multiple entries.They are simply there for convenience in the case of common attributes that can have more than one entry. Each value within a multivalue attribute must be unique. Indexing Attributes When you index data in a database, you are organizing the information so you can have efficient responses to queries based on that data.You can set attributes as indexed to help users find the infor- mation they need.This means that the attribute will be indexed in the Active Directory. With indexing attributes, wildcard searches will function, allowing the user the ability to enter a partial word with an asterisk and return multiple hits. When deciding which attributes to index, you have to be careful because you can slow your network down with extra replication traffic. When you mark an attribute as indexed, every attribute in that instance is added to the index. For example, if an attribute such as Location is part of a Printer object and a User object, both objects would be added to the index. With multivalued attributes, you could be using more bandwidth because you are replicating a large amount of information.The rule of thumb is to only index common attributes. 554 Chapter 16 • Working with Global Catalog Servers and Schema Figure 16.10 Multivalue Attributes 301_BD_W2k3_16.qxd 5/12/04 1:28 PM Page 554 To index an attribute, use the Active Directory Schema snap-in. Expand the Attributes section and right-click on the attribute you want to index. Select Properties, and then check the option to Index this attribute in the Active Directory as shown in Figure 16.11. Naming of Schema Objects If you are going to be working with Schema objects a lot, you need to be comfortable with the naming conventions that apply to Schema objects.There are different ways to reference objects in Active Directory, the most common of which are: ■ Lightweight Directory Access Protocol (LDAP) LDAP is the primary access pro- tocol for Active Directory. LDAP is an industry standard protocol for commonality among directories, and is based on the ISO’s X.500 directory naming conventions. LDAP names identify an entire path within the directory; for example, CN=JDoe, OU=Sales, DC=Frederick, DC=cc. ■ Common name The common name is a simplified way to identify an object. Common names are much easier to read than LDAP names. Common names must be unique within the container. An example common name would be JDoe. ■ Object Identifier (OID) An identification number issued by another authority.The International Organization for Standardization (ISO) and American National Standards Institute (ANSI) have developed standards for OIDs as part of the X.500 directory services specifications. Every OID is unique. An example is the Department attribute in Active Directory.The OID for Department is 1.2.840.113556.1.2.141.This same OID will be used for the Department attribute in any directory that follows X.500 standards. You should follow the LDAP or common name naming standards when setting up Schema objects. If you write software that modifies the schema, certain standards must be followed for the software to Working with Global Catalog Servers and Schema • Chapter 16 555 Figure 16.11 Indexing Attributes 301_BD_W2k3_16.qxd 5/12/04 1:28 PM Page 555 . With Windows Server 2003, only the additional attribute or attributes are repli- cated to other GC servers.This makes more efficient use of network bandwidth. Placing GC Servers within Sites Another. know now that GC servers hold information for all of the objects in their own domains and a partial copy of the objects from other domains in the forest through replication .The default attributes. For this to happen, the authenticating DC has to query the GC. If the GC is across a WAN link, the logon process will be slow every time.To alleviate this, the DC that queries the GC can cache this