The Best Damn Windows Server 2003 Book Period- P59

Chia sẻ: Cong Thanh | Ngày: | Loại File: PDF | Số trang:10

Thêm vào BST

Báo xấu

32
lượt xem 2
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

The Best Damn Windows Server 2003 Book Period- P59:The latest incarnation of Microsoft’s server product,Windows Server 2003, brings many new features and improvements that make the network administrator’s job easier.This chapter will briefly summarize what’s new in 2003 and introduce you to the four members of the Windows Server 2003 family: the Web Edition, the Standard Edition, the Enterprise Edition, and the Datacenter Edition.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: The Best Damn Windows Server 2003 Book Period- P59

546 Chapter 16 • Working with Global Catalog Servers and Schema Figure 16.3 General Tab of NTDS Settings Properties 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 trafﬁc 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 efﬁciently 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 trafﬁc to a minimum.
Working with Global Catalog Servers and Schema • Chapter 16 547 Attributes in GC When you ﬁrst 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. Figure 16.4 Adding Attributes to the GC 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 trafﬁc. With Windows Server 2003, only the additional attribute or attributes are repli- cated to other GC servers.This makes more efﬁcient 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 ﬁrst DC that is conﬁgured 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 ofﬁces you might be okay, but many branch ofﬁce links use limited bandwidth connections. If the connection between locations is less than a T1, you might have limited bandwidth depending on what trafﬁc 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.
548 Chapter 16 • Working with Global Catalog Servers and Schema Another factor is reliability. If your WAN links are unreliable, replication trafﬁc and synchroniza- tion trafﬁc 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 trafﬁc can cause problems in a large network. Sites help control replication trafﬁc. 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 ﬁnd the information they need from Active Directory, they might not be able to log on or ﬁnd the information or data they need. Bandwidth and Network Trafﬁc 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 ofﬁces 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: I 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 trafﬁc for normal DC trafﬁc, it should also handle GC trafﬁc. I 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. I 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 trafﬁc 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 efﬁcient 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 veriﬁed. 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 ﬁrst 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
Working with Global Catalog Servers and Schema • Chapter 16 549 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 trafﬁc distribu- tion on the network. Figure 16.5 Conﬁguring Universal Group Caching 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: I Replication latency between GC servers I Slow query response I 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 conﬁguration. Adding sites might help with replication trafﬁc, as trafﬁc 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 conﬁguration can help as well. Workstations within a site will query the local GC server versus going across a WAN link.
550 Chapter 16 • Working with Global Catalog Servers and Schema If the overall load is too high, you need to look at adding more GC servers to balance the trafﬁc.This also results in more replication trafﬁc 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 deﬁnes your directory. For an object to store data such as a username or telephone number, there has to be a ﬁeld in which this information can be entered.These ﬁelds 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 deﬁnes 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 deﬁnes its structure, the database model.The founda- tion, or model, is based on various components (see Figure 16.6).The ﬁrst 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 deﬁnes the structure of your data. Associated with each object are ﬁelds, or attributes, that you ﬁll 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: I Object classes I 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.
Working with Global Catalog Servers and Schema • Chapter 16 551 Figure 16.6 Schema Components Diagram Classes Attributes First Name User Last Name Location Telephone Computer Fax Number Profile Path Printer Classes Object classes deﬁne your objects in the directory. Examples of Object classes include: I User I Printer I 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 deﬁned 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 deﬁned 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.
552 Chapter 16 • Working with Global Catalog Servers and Schema Figure 16.7 Object Classes in Schema Each Object class has a deﬁnition that determines which of its allowed attributes are required and which are optional.These are known as ClassSchema objects in Active Directory, and deﬁne 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 deﬁne the structure objects (these are like a template for cre- ating structural objects); and auxiliary objects, which are a predeﬁned 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 deﬁne 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 ﬁlled in when you create the user account and are deﬁned in Active Directory as containing a certain type of data. The AttributeSchema object deﬁnes the characteristics of a given attribute. Conﬁguration 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 speciﬁed format, such as Access code-Area or Country Code-Preﬁx-Number (for example, 1-512-555-1234). However, the schema is not this speciﬁc; it speciﬁes 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 deﬁning the syntax, each attribute’s properties will also include an X.500 object identiﬁer (OID) for interoperability with other directories that comply with X.500 speciﬁcations, 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.
Working with Global Catalog Servers and Schema • Chapter 16 553 Figure 16.8 Properties of an Attribute 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. Figure 16.9 Default Attributes in 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 ﬁrst name is entered, you have to create a completely different object if you want to have another object with a different First Name attribute.
554 Chapter 16 • Working with Global Catalog Servers and Schema 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.) Figure 16.10 Multivalue Attributes 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 efﬁcient responses to queries based on that data.You can set attributes as indexed to help users ﬁnd 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 trafﬁc. 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.
Working with Global Catalog Servers and Schema • Chapter 16 555 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. Figure 16.11 Indexing Attributes 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: I 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. I Common name The common name is a simpliﬁed 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. I Object Identiﬁer (OID) An identiﬁcation 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 speciﬁcations. 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 modiﬁes the schema, certain standards must be followed for the software to