The Best Damn Windows Server 2003 Book Period- P60

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

Thêm vào BST

Báo xấu

37
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- P60: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- P60

556 Chapter 16 • Working with Global Catalog Servers and Schema meet the “Certiﬁed for Windows” requirements. If you stick with the standards, any changes you make will be less likely to cause problems. Working with the Schema MMC Snap-In When working with the Schema snap-in, you need to be aware of some other conﬁguration items. If you right-click Active Directory Schema, you are presented with various options as shown in Figure 16.12. Figure 16.12 Schema Administrative Options If you select Change Domain Controller, you can choose what DC you want to feed the schema information. If you select Operations Master, you can see what server is holding the Schema Master role, or change the server responsible for that role.You can use the Permissions option to change permissions on the schema. In most cases, network administrators would have no reason to go into the Permissions tab. The last option in the ﬁrst section of the list is Reload the Schema.This option will reload the schema from the database to make sure you don’t have cached information that could be outdated. When working with the Schema snap-in in a mixed environment, you might ﬁnd yourself at a Windows 2000 server. If you are making schema modiﬁcations from a Windows 2000 server, you must ensure that Service Pack 3 for Windows 2000 has been installed. Modifying and Extending the Schema There will be times when the default schema layout doesn’t meet your needs. If this is the case, you can modify the schema by changing existing classes or attributes.You could also extend the schema by adding classes or attributes that do not exist. Again, you must be extremely careful when making changes to the schema; modifying or extending the schema should only be done when absolutely necessary.
Working with Global Catalog Servers and Schema • Chapter 16 557 To modify or extend the schema, use the Schema snap-in. Begin by making your changes in a test environment and testing thoroughly before making modiﬁcations or extensions on your pro- duction network. Remember that the user using the snap-in must be a member of the Schema Admins group. Before you modify the schema by changing or adding classes or attributes, keep the following guidelines in mind: I Double-check to be certain that the existing schema conﬁguration does not meet your needs. It is possible that there is an existing class or attribute that will work for your requirements. I When you add a class or attribute, that class or attribute cannot be removed.You can, how- ever, deactivate a class or attribute. We will look at that in the next section. I Make sure you have a valid OID; do not just pick one out of thin air. I Default system classes cannot be modiﬁed. Windows uses these classes for basic function- ality. I Review documentation on the schema. In particular, review the Active Directory Programmer’s Guide, which can be downloaded at www.microsoft.com, if you intend to make extensive modiﬁcations or extensions. I Remember that schema changes affect the entire forest, because only one schema exists in a Windows Server 2003 forest and is shared by all domains in that forest. When creating a new class, various attributes need to be ﬁlled out as shown in Figure 16.13. The ﬁrst section is the Identiﬁcation section.You will have to complete both Common Name and LDAP Display Name.You also have to enter the object ID, so you need to know how they are assigned.There is also an optional Description attribute that you use if you want to. The other section is Inheritance and Type.The Parent class will have permissions assigned. Being a Child class, we would inherit the permissions from the Parent class objects. Figure 16.13 Create a New Object Class
558 Chapter 16 • Working with Global Catalog Servers and Schema Deactivating Schema Classes and Attributes If changes or additions are made to the schema, they cannot be deleted. Windows Server 2003 does not allow for deletion of classes or attributes after they are deﬁned in the schema. However, you can deactivate a class or attribute if you don’t want to use it anymore.This is essentially the same as dele- tion, because the class or attribute is no longer available for use. However, the class or attribute still exists within the schema.The deactivated class or attribute is called defunct. Default classes and attributes cannot be deactivated. If you decide that you need to have the attribute available, you can reactivate it later. When you deactivate a class or attribute, you can redeﬁne it if your forest is at the Windows Server 2003 functional level. For example, if you have an attribute that has the wrong syntax, you can deactivate the existing attribute and then create a new attribute with the proper syntax.You can reuse the LDAP display name and the OID. Note that you have to rename the original attribute after you deactivate it and before you create the new attribute to prevent conﬂicts. You use the Schema snap-in to deactivate or reactivate an attribute or class. Figure 16.14 shows where you can activate or deactivate an attribute. Figure 16.14 Activating or Deactivating Create and deactivate classes or attributes In this procedure, you will use the Schema snap-in to create an attribute, and then you will deacti- vate it.You should work on a test system before using this procedure on a live schema since addi- tions to the schema cannot be removed (only deactivated). 1. Open the Schema snap-in. 2. Expand Active Directory Schema, right-click Attributes, and select Create Attribute. 3. Click Continue at the warning dialog box. 4. In the Common Name dialog box, type Telephone number 2.
Working with Global Catalog Servers and Schema • Chapter 16 559 5. In the LDAP Name dialog box, type Telephone number 2. 6. For the OID, type 2.5.4.20.2. 7. Change the syntax drop-down to Integer, and then click OK. 8. Now, ﬁnd the new attribute, right-click, and choose Properties. 9. On the General tab, you should see a check box for Attribute is Active. 10. Click the check box to remove the check. Click Yes to the question about the making the object defunct. 11. Click OK and the status window in the details pane should show Defunct under the Status column. Troubleshooting Schema Issues You might run into issues when working with the schema.They could be as simple as not ﬁnding the Schema snap-in to not being able to extend the schema.The most common problem is running or ﬁnding the snap-in. Make sure you register the .dll for the snap-in, and then create a customized MMC to run the snap-in. There might be times where you simply cannot extend the schema; for example, if you are trying to add a class and are unable to complete the operation. A few things could cause this; the most common being that the user trying to make the changes is not a member of the Schema Admins group. In addition, the Schema Operations Master role has to be up and available on the network. If the Schema Operations Master role is across a WAN link, you might be experiencing too much latency.You can move this role if needed to solve network connectivity problems. You might also experience an issue where you cannot associate an attribute with a class. This is because the schema cache is not up to date. If this happens, you need to make sure the Schema cache is updated by reloading the schema.This could also be caused by trying to make changes on a server other than the Schema Operations Master. When modifying the schema, it is recommended that you make changes on the server running the Schema Operations Master role.
Chapter 17 Working with Group Policy in an Active Directory Environment In this chapter: Understanding Group Policy Planning a Group Policy Strategy Implementing Group Policy Performing Group Policy Administrative Tasks Applying Group Policy Best Practices Troubleshooting Group Policy Introduction We brieﬂy touched on Group Policy in earlier chapters. In this chapter, we’ll take an in- depth look at Group Policy in Windows Server 2003. Group Policy is used to manage and control various features and components of the Windows Server 2003 network. Group Policy settings can be used to deﬁne users’ desktop environments, to specify security settings, and to conﬁgure and control application behavior. Group Policy can be used to automatically deploy software to users and computers.You can also use group policies to assign scripts and redirect folders. Policies can be applied to a site, a domain, an organizational unit (OU) or a local computer. Because Group Policy is used for so many important management functions, it is important for network administrators to be intimately familiar with how Group Policy works, and how they can use it for more ﬂexibility and control of network components. This chapter starts with a brief review of the basics of Group Policy terminology and concepts, including user and computer policies and Group Policy Objects (GPOs). We discuss the scope and application order of policies, and you’ll learn about Group Policy integration in Active Directory. We show you how to plan a Group Policy 561
562 Chapter 17 • Working with Group Policy in an Active Directory Environment strategy, and then walk you through the steps of implementing Group Policy. We show you how to perform common Group Policy tasks, and discuss Group Policy propagation and replication.You’ll also learn best practices for working with Group Policy, and we’ll show you how to troubleshoot problems with Group Policy. Understanding Group Policy Group Policy is derived from the System Policies of the Windows NT days, and has been signiﬁ- cantly enhanced, ﬁrst in Windows 2000 and now again in Windows Server 2003. Implementing Group Policy in the Active Directory allows system administrators to control aspects of the user or service environment within the network from a global perspective. You can use Group Policy to accomplish the following tasks, among others: I Assign scripts You can specify scripts that will run at login, logoff, startup, shutdown, and other times. I Manage applications You can designate applications that will be installed on, updated on, or removed from computers. I Redirect folders You can specify alternate locations for system folders, such as My Documents, My Pictures, and others. I Change Registry settings You can designate a set of Registry settings that will be applied to the local computer when a user logs on. Gaining a full understanding of how Group Policy can impact the network requires a full understanding of the terminology and concepts. Terminology and Concepts You will encounter a number of terms, acronyms, and jargon when designing and implementing a group policy in your organization. When we refer to Group Policy, we are actually talking about the superset of all the individual components that make up the larger whole.You will ﬁnd policy ele- ments that affect only users or computers, policies that are set at the workstation level or applied to an OU in Active Directory, and ways to apply basic security to policies. Let’s review the basic terms used as the foundation of building Group Policy. Local and Non-Local Policies Group Policy allows you to set policies that will impact resources connecting to a speciﬁc computer or interacting with the entire directory.The terms local policy and non-local policy identify where the group policy settings originate. A local policy is stored on a speciﬁc computer (a workstation or a member server) and applies only to activities on that computer. For example, a local policy only affects a user object when the user logs on interactively on the server, either at the console or via terminal services. Local policies can also affect the way a user object accesses data from the speciﬁc server across the network. Generally, local policies should only be used on workstations; however, there are a few situations where local policies on a server would make sense.
Working with Group Policy in an Active Directory Environment • Chapter 17 563 Non-local policies are applied primarily to group objects.These policies affect objects in the directory and are enacted when the object is active in the network. If a non-local policy affects a user object, its effect is applied every time that user object logs on, no matter what PC is used as the logon console. Group policies can apply to any of the following: I A local computer I An entire site I A domain I A speciﬁc OU Group policies can be ﬁltered through security settings, much like NTFS ﬁle and folder permis- sions control access to data on a server volume. As you will see shortly, there is a speciﬁc order in which policies are applied if local and group policies differ in a speciﬁc area, but the best practice for policies in general is to apply the policies at the group level, not at the local level. User and Computer Policies As you might have guessed, some policies apply to user accounts, and other policies apply to com- puter accounts.You can only apply policies to user and computer objects, not security groups or other objects (however, policies can be ﬁltered by security groups by setting the security group Access Control Entry on the GPO).These two types of policy application work as follows: I User policies affect how user accounts interact with the network and are applied when a user logs on to the network. I Computer policies affect how computer objects interact with the network and only apply to those computers that participate in the Active Directory. You conﬁgure each of these types of policies in separate areas in the GPO Editor. User and computer policies are divided into three groups: Software Settings, Windows Settings, and Administrative Templates. Software Settings The primary use of this setting is to install, update, or remove software on computers on the net- work.The Software Installation node is located in this group, and other policy groups can be added in this area by other applications. Software policies set in this area under Computer Conﬁguration apply to all users who log on to the computer where the policy applies.This policy setting could be used to designate a speciﬁc computer on the network where a particular application should be installed, no matter who logs on to the computer. Software policies set in this area under User Conﬁguration apply to all computers that a particular user logs on to.This setting is useful if a particular user has a speciﬁc application that he or she needs to use, no matter where that user uses a computer in the organization.The policies can be set so that if an application is installed on a computer this way, only the user to whom the policy is applied is able to see or run the application.
564 Chapter 17 • Working with Group Policy in an Active Directory Environment Windows Settings Policies applying to scripts, security, folder redirection, and Remote Installation Services, among others, are located in this area.There are signiﬁcant differences between these policy settings depending on whether they are applied in the Computer Conﬁguration or User Conﬁguration node.Table 17.1 details some of the policy groups and whether they are applied to user or com- puter settings. Table 17.1 Group Policies for Windows Settings Policy Location Description Scripts Computer Conﬁguration Speciﬁes startup and shutdown scripts to be run on the computer. Scripts User Conﬁguration Speciﬁes logon and logoff scripts to be run by users. Account policies Computer Conﬁguration\ Contains policies related to pass- Security Settings word and account lockout settings. Folder redirection User Conﬁguration\Security Contains policies to redirect certain Settings user folders, such as Application Data, My Documents, and Start Menu, to alternate locations. Internet Explorer User Conﬁguration\Security Contains settings to modify maintenance Settings defaults for Internet Explorer, such as user interface settings, favorites, connection settings, and security zone settings. Public Key policies Computer Conﬁguration\ Contains policies related to Security Settings system-level public key activities, such as Encrypted File System, Enterprise Trust, Autoenrollment settings, and Automatic Certiﬁcate Request settings. Public Key policies User Conﬁguration\Security Contains policies related to Settings user-level public key activities, such as Enterprise Trust and Autoenrollment settings. Administrative Templates Policy settings that appear in the Administrative Templates node of the GPO Editor contain Registry settings to achieve each of the settings contained in the hierarchy. Policies for user conﬁgu- ration are placed in the HKEY_CURRENT_USER (HKCU) area of the Registry, while those for computer conﬁgurations are placed in the HKEY_LOCAL_MACHINE (HKLM) area.
Working with Group Policy in an Active Directory Environment • Chapter 17 565 Administrative templates contain settings for Windows components such as NetMeeting, Internet Explorer,Terminal Services, Windows Media Player, and Windows update, to name a few. Other components common to both user and computer conﬁgurations include settings for user proﬁles, script execution, and group policy. While the different policy settings between user and computer conﬁgurations are too numerous to list here, there are some key components available for the user conﬁguration.These include the Start Menu,Taskbar, Desktop, Control Panel, and Shared folder settings. Group Policy Objects All group policy information is stored in Active Directory in GPOs.You can apply these objects at the site, domain, or OU level within the directory. Since the GPO is an object in the directory, you can set security permissions on the objects to determine who will access the policy settings stored in the GPO. Because GPOs can impact a large portion of the directory, you should update GPOs infrequently. Each GPO update must propagate across the entire directory to take effect, and this could be a time- consuming process if the directory structure is very large.You should also restrict the number of indi- viduals who make changes to GPOs that can impact the entire organization. Otherwise, you can run into the situation where two administrators make contradictory changes to a GPO in different loca- tions of the tree, and the changes propagate differently around the tree, potentially causing problems until the directory has completely updated the GPO changes. Scope and Application Order of Policies A single object in the network can be subject to multiple policy settings, depending on how Group Policy is conﬁgured on the local machine and in the directory. Active Directory processes policy set- tings in a speciﬁc manner when an object connects to the network. Knowing this process will help you troubleshoot problems with policy settings as they arise. Local, Site, Domain, OU Group Policy settings are applied in the following order: 1. Local settings Each computer has its own local GPO, and these settings are applied before any others.There is only one local GPO per computer. 2. Site settings Group policies associated with the site in Active Directory are processed next.The system administrator can set a speciﬁc order in which the site policies are to be applied, if more than one policy is deﬁned. 3. Domain settings Group policies associated with a domain object follow the completion of the site settings. If multiple domains are involved, the administrator can set the order of preference in which those settings will be applied. 4. OU settings Group policies associated with an OU are applied last in the processing order, but the processing starts with the OU highest in the directory structure.The remaining OU GPOs will be processed in descending order until the OU that contains the directory object is reached. If multiple policy settings are applied for a particular OU, the administrator can set the order in which the settings are applied.