This chapter is from the book
This chapter is from the book
This chapter is from the book
AD Sizing
Let's now talk a little about the AD database. We will begin with an overview of directory handling operations in Windows 2000 AD.
Overview
Windows 2000 AD uses the extensible storage engine (ESE), which is the same basic database engine used by Exchange. There are several files associated with this process:
- Ntds.dit: The whole database
- Log files
- Edb.chk: The check files used to keep track of checkpoints
- Temp.edb
AD runs as one process in Windows 2000, which is LSASS.EXE. Because it runs in a single process, there is only one way to stop AD on a server, and that is to kill LSASS.EXE. If you do this, it will reboot the box, as you will have no more security on the server.
There are only 2 tables in the AD database. These tables are the object table, which holds common objects and attributes such as users, printers, and the like and the object table and link. For each of the common objects there are columns in the object table. In the database, rows represent objects, and the columns represent attributes of the objects. There are both fixed columns and tagged columns. A fixed column means that we always know how much space the attribute will occupy. Fixed columns are only used for around 10 attributes. These are attributes such as an index that will take up a predictable amount of space. Most attributes in the AD database are tagged columns. Space is not reserved for tagged columns, as we do not know how much space the attribute will occupy.
The link table implements object relationships, such as linking users and their managers.
Fragmentation
Fragmentation is moving data in order to fill database pages more efficiently. There are two ways to deal with database fragmentation in the AD database. One is online defragmentation, which runs as part of a garbage collection cycle that runs by default on a 12-hour schedule. Online defragmentation, however, does not shrink the size of the database file; rather, space is simply made available for use later. This is the same way as it is in Exchange. The basic idea is that it requires a lot of processor time to expand the size of the database file, and if it grew once, then it will grow again. Therefore, we can be more efficient if we do not fool with shrinking the size of the database file. However, if you deleted 100,000 users for whatever reason, then when garbage collection runs it will free up a sizable amount of disk space. If those users will never return, then it makes sense to recover the space.
In order to recover disk space from the AD database, we will have to perform an offline defrag, the second approach. To perform an offline defrag, run the NTDSUTIL.EXE program with the appropriate options, and it will shrink the db file. To run the NTDSUTIL on a DC, AD has to be taken offline. To take a DC offline, you reboot into directory recovery mode. This is useful after converting a global catalog server domain controller into a normal domain controller.
The garbage collection process is a housekeeping service that frees up space in the AD database. There are several functions performed by garbage collection. One is to tombstone the log files. By default, the tombstones are kept for 60 days to ensure recoverability. Garbage collection also performs database defragmentation, as mentioned earlier. This occurs every 12 hours by default but is configurable (although in most instances, the defaults seem to work well). One thing to keep in mind is that garbage collection runs on each domain controller independently.
So what kind of sizes are we talking about with our AD database? Of course it depends, but for ballpark purposes, we could expect an AD size of 1.2 gigabytes for around 100,000 users with 30 attributes defined on each of the users, and machines with 8 attributes defined, and 10,000 groups with 4 attributes defined. When we add Exchange 2000, then AD size will go up to around 1.7 gigabytes for the same company. AD database growth is very predictable.
Hardware planning
In order to select the appropriate servers to run AD on, we need to look at a few factors. The first thing is to find the size of the company:
Add objects: Print queues, contacts, more groups
Treat security principals like users (add 4,400 bytes per object)
Treat nonsecurity principals like contacts (add 1,700 bytes per object)
For string attributes add 100 bytes/attribute. To be safe, then double the estimated size. The database will grow, and there will be tombstones. It is better to overconfigure (and much cheaper) at the outset than revisiting the machine.
Best predictions are achieved when you get the profile of your AD objects. Set up a replica of your AD schema on a test machine, and then fill in representative objects with their accompanying attributes. Then make some tests with this profile to get best results for the enterprise. Based upon the numbers you get from your tests, you will be able to come up with a very accurate prediction of the size of your AD.
Global catalog sizing is dependent on the domain design. Remember, the partial replica set in your schema from the other domains in the forest, the number of attributes defined, and group design all affect the size of your global catalog.
Do not forget to include directory-enabled applications in the figures that you derive from your calculations. For instance, Exchange 2000 will add nearly 40 percent to the size of information that needs to be replicated.
Predicting AD traffic
With AD traffic there are two main areas of interest: AD replication traffic and client logon traffic. Replication traffic is affected by namespace design, and client traffic is affected by the number of clients and the features set.
Replication intrasite uses DS-RPC (RPC over IP) and is not compressed. This means that while there is more network traffic generated, it does not incur a processor hit on the servers as they compress and uncompress the traffic. On the other hand, intersite replication uses DS-RPC (RPC over IP) that is compressed. The compression that is utilized can achieve a 15–20 percent compression ratio over the noncompressed variety. However, this comes at the price of additional processor utilization on the servers as they compress and uncompress the network traffic. The idea is that the WAN bandwidth is a more scarce resource than processor utilization.
Intersite replication uses DS-RPC (RPC over IP) or ISM-SMTP (SMTP) for configuration and schema replication. When we are looking at the amount of traffic that needs to be replicated, we can use some of these guidelines to help us create an estimate:
Users: 4k bytes each
Global groups: 2k bytes each + 165 bytes for each member of the group
Universal groups: 2k bytes each + 1.5k bytes
Group Policy Considerations
Group policy resides within group policy objects (GPOs). They are created within a domain, and can be linked to any number of sites, domains, and organizational units (SDOU). They cannot be linked to a container: Users and computers are containers. Multiple GPOs can be linked to a single SDOU.
Group policy gets applied to the computer configuration when the computer starts. The user configuration settings get applied when the user logs on, and are refreshed at periodic intervals. Group policy for clients and member servers is refreshed every 90 minutes by default with a randomized offset of 30 minutes for load balancing. The domain controller's policy settings are refreshed every five minutes. There are some portions of group policy that are not periodically refreshed.
How do we determine where group policy comes from? Group policy is not assigned to groups. Policy is inherited, and closer settings override ones that are farther away. So it depends entirely on where the computer or user resides in the AD hierarchy (site - domain - OU). It is not like a systems policy, as it really has nothing to do with groups.
We can modify the default inheritance settings with either the no override option, or with the block inheritance option. The no override option is a property of the GPO itself. Any settings within this GPO prevent the child containers from overriding policies that may be set at higher levels.
Block inheritance, however, is set at the container level. It prevents inheritance of all policies from the parent container. The highest no override setting will take precedence over lower no overrides. No override takes precedence over block inheritance. So as a domain admin, then your settings on a GPO will take precedence over settings that are made by a delegated admin of an OU.
But what if an OU is linked to multiple GPOs? Then the higher GPOs override the lower level GPOs. Group policy objects are processed in the reverse order listed on the tab. You can change the order of processing with the up and down button.
What if you don't want everyone in an OU to be affected by a GPO? Remember, you cannot link a GPO to a security group. You can, however, filter GPOs by changing the default permissions on the GPO by using security groups. You need to have the read and apply GPO ACEs to have a GPO apply. You need read and write in order to read or modify a GPO.
If you do not have read permission, then you cannot see the policy; therefore, it will not be applied. In order to filter out a policy from a higher level, remove the apply permission, and it will not apply to them. If you want administrators to be able to modify a particular GPO, then you must give them write and read permission to that GPO.
Default permissions to group policy are that authenticated users get read and apply. Local system, domain admins, and enterprise admins by default get all permissions except apply. However, remember that admins are by default members of authenticated users. In order to exempt admins from a particular GPO, then you must remove the apply permission from them.
So, where is GPO information stored? First, we need to understand that they are not real objects; they are virtual objects. They are, however, made up of two real objects: the group policy container that is located in the AD and the group policy template that is stored in the sysvol policies folder. The group policy container stores the version, status, and policy information. Unfortunately, it is named by a guid, and not a "friendly" name. The sysvol policies folder stores policy information and is also named by a guid, and not by a friendly name. The group policy container and the group policy template are replicated separately, as they are in different locations. Containers are replicated using AD replication, and templates are replicated with the file replication system (NTFRS). Individual policies will only be applied if both objects are in sync. The exception to this is IPsec, which is stored only in the template, not in the container; therefore there is nothing for it to be in sync with.
The group policy container has to be viewed with ADSI edit. In order to find the group policy container, you need to navigate to the domain name context, DC, system, policies section.
Deleting a GPO
In order to delete a group policy object, you need first to remove the link. You can remote the link while keeping the policy intact. If you keep the policy intact, then it is available for reuse later. If you prefer, you can permanently delete the GPO. The unlink method is preferred, because a deleted group policy object must be completely rebuilt if you decide you want to redeploy the policy. In addition, other AD containers might be linked to the group policy object and you would hose things if you removed the GPO without first checking to see if it was in use in other locations in the directory.
Be careful when deleting GPOs
Windows 2000 is perfectly content to allow you to delete a GPO that is still in use. No warning messages are generated. Ensure that a GPO is not in use prior to deleting it.
The bad thing about this is that there are no error messages generated if you delete a GPO that is in use in other places. This is doubly bad because normally Windows 2000 is very good about generating warning messages, and consequently many administrators are becoming sloppy in their work. It is as if they think, "Windows 2000 will tell me before it allows me to make a mistake"—and normally it will; just not in this instance. However, all is not lost, because you can check to see if the GPO is in use. All you have to do is to look at the properties of the group policy object, and go to the links tab to see what they are linked to.
Deployment Scenario Guidelines
Now let's look at a few guidelines for deploying group policy. Perhaps the most important design principle I can give is to follow the AD planning recommendations. We want to set up OUs based on the delegation of the control model. If it does not meet our needs entirely, then we add OUs as required for desktop management and other purposes. There are multiple types of OU structures, which we are likely to deploy. These are discussed in the section below.
Flat OU model
The easiest model to deploy, and the most prevalent OU model, is the flat OU model. A flat model, perhaps one to two levels deep, is the simplest to design, and the easiest to implement. The flat structure is typical of small or medium-sized organizations (SMORG). The flat structure is used to minimize the use of block inheritance, and override. In the flat OU model, there is very limited use of security group filtering through the use ACLs. When the AD namespace is flat, then the primary method of a flat OU model is to link the GPOs to domains or to the OUs. This allows us to keep it really simple. Any time we are modifying inheritance, we are introducing complexity and making troubleshooting more difficult.
Narrow OU model
The narrow OU model will typically nest OUs three to five levels deep. Normally, this type of structure will work out well for medium-sized organizations (MORGs). Because MORGs do not normally have the wide international organization typical of a large company, their directory structure will not be as wide. However, due to their size, they will have all the normal levels of complexity found in a large company—just not to the same extent. This will cause the OU model to be rather deep, but not as wide as that of the larger corporate organizations. As we begin to go deeper with our OU structure, we need to begin looking at ways to fine-tune the application of group policy. In the narrow OU model, the primary method of GPO deployment is to link GPOs to OUs as needed. The secondary method is to use block inheritance, enforce or ACLs as required to fine-tune the application of group policy. However, it is wise to moderate use of these types of approaches. The best way to approach a narrow OU model is to use the OU location in the active directory to determine the placement of the GPOs.
Deep OU model
In contrast to the other two principal types of OU models, the deep OU model typically has more than five levels of nested organizational units. This is the model most often found in large organizations (LORG). Due to the complexity of their organizational charts, and their complex reporting requirements, LORGs are often forced into intricate, deeply nested organizational units. In fact, just as large corporations do not have one type of reporting structure, they do not have one type of OU model. In fact, we will typically see a combination of flat, narrow, and deep OU structures at work in the LORGs.
In a deep OU model, we will use GPO placement to enforce group policy by linking the policy to specific organizational units; but we also will have to use security filtering to effect the desired outcomes. While we can use block inheritance and enforce, it behooves us in a deeply nested OU model to minimize the use of multiple methods when controlling the application of group policy. In a deep OU model, things are complicated enough without having to search through multiple methods of group policy application. Therefore it is best to use as few methods as are required for correct implementation.
Best practice
There are several layers in the AD structure that must be considered when working with group policy. These scopes are listed below.
- Domains
- Multiple domains (if present)
- Sites
The question then is, how you want to deploy GPO, and how you are going to manage them. These pointers will help:
Remember that sites are enterprise wide. If you have a site with multiple domains, and you link GPO to the site, then it affects every user and computer in the site—including multiple domains.
Remember that sites are enterprise wide, but GPOs are stored on a per domain basis. By default, only enterprise admins can create or modify a GPO that is linked to a site.
What happens when a site is linked to an existing GPO? Now it becomes possible for nonenterprise admins to make changes to the GPO. In addition, you need to look at the topology and the location of domains and the domain controllers.
There is a risk of creating an across-the-WAN fetch of a GPO for computers and users. The default when you create a GPO at the site level is it is stored in the forest root domain. You can, however, modify this behavior by pointing it to a different domain.
Don't link existing GPOs to the site. If you want to link a GPO to a site, then create a new GPO. This is because it would allow a down-level admin (who owns the GPO) to affect the entire site by modifying a GPO that he or she owns.
Best practice for desktop management
When you use organizational units and group policy objects for desktop management, often you will need to control the way the GPOs are applied. In a large organization, this can be quite complicated. Here are some of the ways you can control the application of group policy to manage the desktop, listed in decreasing order of preference:
- Use the existing structure.
- Modify the existing structure.
- Add and/or split existing OUs.
- Use block inheritance.
- Use a combination of block inheritance and enforce.
- Use filtering.
Note
Limit mixing multiple methods in any single tree.
Design Models
In a layered GPO design: Create GPOs as high in the tree as possible to contain domain-wide settings. Then let subadmins create specific GPOs for their area. Therefore a specific setting will be in as few places as possible. The trade-off is more GPO, which will add to time of logon. This is always a tradeoff.
Monolithic GPO design: Create one as high as possible, with everything in it. Great performance, but very limited control, unless you use block inheritance, and filtering.
Single policy type of design: Reflects the different modes that are in a GPO. For each of these nodes, will use only one GPO. One for computers, one for software, one for scripts. Downside, length of time to process this many GPOs will increase the number required.
Multiple policy type of design: A little more delegated. Want to create the GPOs as high as possible, then delegate the control at the OU level. Is useful for small orgs. Cuts down on amount of filtering based on ACLs.
Functional role: If OUs are based on function then only GPO applies to each OU. Then have subadmins create specific to the users. Settings are tailored to needs and people in the OUs. This is a good compromise between administration and performance and is an easy model to delegate to subadmins.
Team Design
Virtual teams: It is more and more common to create a virtual team for specific projects. One may want the virtual team to have a common GPO applied to them. All those people already have accounts in different groups and OUs. If a team has people from different OUs then there will be a need to make extensive use of filtering. Take the people and create a security group, then put the GPO high enough in a tree so that it applies to all the team members; only give that group permission to apply the GPO.
User and machine-specific design: Group policy is divided into user and computer configurations. All computer settings are in different GPO than the specific users' settings. If a GPO contains only user-specific stuff, then we can disable processing of the computer portion of the GPO, and vice versa.
A public computing environment: Requires users from all over organization to use common computers. We want to control what that desktop looks like. Suppose we have a kiosk mode. If a user from payroll logs onto the kiosk, they will get different settings. The solution here is to use loop-back processing, which says, forget the user settings—process only what applies to this particular computer. This allows us to take the user settings from the kiosk OU. Normally we would ignore the settings for a user from a different OU, but this allows processing user settings from that particular computer. If we merge settings, then we combine. If we replace, then ignore the user settings from the different account, and process from the kiosk OU.
Group policy delegation models
We first need to decide how to delegate control of the GPO. There are really two models: centralized and decentralized. In centralized the domain admin has as much control as possible. The idea is that it will need to use no-override settings quite a bit. In centralized, do we want lower admin blocking your settings from the higher level?
Distributed control: We want subadmins to have as much control as possible, but still force out company-wide policy. Use both no-override and block inheritance. There are still certain domain level policies we need to configure.
Use common configurations to lower desktop TCO. Driving costs for TCO: Not all users are knowledge workers. In a typical enterprise, there are high performance users (it actually hinders their job when we control their desktops), knowledge users, mobile users (we may need ability to install printer drivers), process users (task oriented; run one or two LOB or productivity apps; don't need much control over their own computers) and data entry users (we can really control here).
For most users, computers are simply tools to get another job done. Users spend too much time supporting themselves and each other. They tend to putz around doing things they do not need to do. The solution is change and configuration management. One image does not work for everyone.
Group policy scenarios are the replacements for ZAK. This ships as a Windows 2000 installer package. It defines six common configurations; it includes prebuilt GPOs and scripts to load the GPOs into active directory. We only need to link and modify to suit environment. Run loadpol.bat to load them. The six modes are:
Kiosk: Public workstation where we want only one application to run. No desktop. Actually uses Internet Explorer as the shell.
Task station: Originates from the ZAK kit. Similar to kiosk, and we want to run maybe one or two apps, save documents, and settings persist. Good for factory floor.
Application station: More apps available. Simple start menu. Marketing or finance department. Use four or five apps. Settings persist.
Public computing environment: Different users use this, and configure. When a user logs in, the apps are published to them (university lab, library). Students' need for class-based apps. Apps are assigned to the computer for common base, and then other apps are assigned to the individual through group policy.
Knowledge worker: We don't want lot of control here—it actually may hinder. However, we want to manage certain parts of environment. Works for knowledge, mobile, and even super users. Use a group policy to publish software. Still use GPO, but to ease administration.
Laptop: Two types—road warriors, and the ones who occasionally take it home to work. Do we assign software all time, or when we are well connected?
There are GPOs for each computer and user settings.
The technologies
Group policy
Administrative templates
User data and settings: roaming user profiles and folder redirection
Software installation and maintenance: publish and assign
Remote OS installation: RIS
Security settings
IE maintenance settings
Planning guidelines
Things to think about
Scope of management
Usage of group policy
Design flexibility
The AD structure: users' and computers' OU structure. Cannot plan in a vacuum: need a good understanding of the entire technology.
Performance: Will users tolerate a five-minute wait?
Keep it simple: Consider the highest TCO issues, and then use group policy to address them. The quicker we can show ROI, the better.
Major areas to consider for bang of buck
Desktop management: Registry settings, OS and components, applications, security settings, folder redirection
Software installation
Scripts
Management model: Centralized, delegated, or both. Delegation of administration (who can create GPO, who can link GPOs, or who can simply modify), separation of admin duties. Design for flexibility (don't lock yourself in).
Delegation of administration: Restrict to as few administrators as possible the ability to write to GPOs. Use the security tab (ACL editor). The group policy snap-in will not open a GPO that the current user does not have write permission to. All current extension snap-ins to gp assume they have write access. Use MMC policies to restrict certain snap-ins to those administrators who need them.
Tips for success
If using delegation model, then put the GPO there. Leverage the AD and associate GPOs at the level of delegation (typically lower in the tree).
If AD is flat, then delegation may not allow the granularity desired for gp. Use security groups and ACLs to filter the effects of GPOs.
For performance, limit the total number of GPOs that a given computer or user will have to process. Use ACLs and security groups to achieve this design goal.
Keep it simple: To ease management limit the use of block inheritance, enforce, and cross-domain GPO associations.
When these must be used, avoid using more than one at a time. Each one adds complexity.
Design tips
Disable unused portion of the GPO. Use revision number for user of computer as a hint to its usage.
Limit how often group policy is updated. Each update will require a replication among all DCs.
Limit the number of administrators that can edit GPOs.
The scope may be huge. For example: Think of GPOs as regedit for AD. Application installation and removal for users and computers. Security: Set file system ACLs for thousands of users and computers.
Use test GPOs first. Make sure you know what the effect will be first.
Use the group policy infrastructure for modifying all GPO ACLs.
Whether for filtering the effect of a GPO, or the delegation of administration.
The group policy infrastructure handles the inherent differences between the AD and the file system (sysvol) ACLs. Individually modifying ACLs on objects or files that group policy uses may result in unpredictable and undesirable results.
In general, group similar settings in a given GPO.
A GPO that publishes Office 2000 should include the registry-based policies for it as well. Monolithic GPOs contain settings for all or many of the possible snap-ins. There is fast performance and fewer GPOs to process, but delegation is harder to do; it contains divergent settings. Segmented GPOs contain settings only for an individual snap-in. This requires more GPOs, which will impact performance, but it is easier to delegate.