The Best Damn Windows Server 2003 Book Period- P59 pptx

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

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

Figure 16.3 General Tab of NTDS Settings Properties

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

Figure 16.4 Adding Attributes to the GC

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

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

Figure 16.5 Configuring Universal Group Caching

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

Object classes define your objects in the directory Examples of Object classes include:

■ 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.

Figure 16.6 Schema Components Diagram

Classes Attributes

User

Computer

Printer

First Name Last Name Location Telephone Fax Number Profile Path

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

Figure 16.7 Object Classes in Schema

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.

Figure 16.8 Properties of an Attribute

Figure 16.9 Default Attributes in Active Directory

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

Figure 16.10 Multivalue Attributes

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 Directoryas 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 propro-tocol 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

Figure 16.11 Indexing Attributes