Schema Considerations

Every organization needs to create a schema modification policy . This policy should identify the process they need to approve schema changes, who is allowed to change the schema, and when the schema modifications should go into effect. This policy has to be followed to the letter. Because the schema holds the definitions of the attributes and objects that can be used within the forest, schema modifications can cause several problems for Active Directory as well as the network infrastructure. Something as simple as adding a single attribute to an object class can cause replication issues throughout the infrastructure.

With all of the object classes and attributes that are built into Active Directory, chances are you may never have to make any modifications to the schema, with the exception of adding Active Directory “enabled applications. Microsoft has done a very good job of identifying those objects and attributes that most companies need. Keeping this in mind, any discussion of modification should start with a thorough examination of the existing classes and objects to make sure they will not suffice.

You will encounter instances when you need to make changes. Some Active Directory “ enabled applications add object classes and attributes before they will install and function. One very popular application is Exchange Server. Exchange Server 2000 and Exchange Server 2003 add several attributes and classes into Active Directory. The same holds true for ISA Server, Enterprise Edition. As more and more developers discover the benefits of storing information within Active Directory, chances are better that the schema will have to take on some updates.

The entire forest is affected by changes to the schema. Getting approval from the entire administrative staff of every domain can be difficult. You will need proof that every change is necessary. Make sure you have documented exactly what the change will provide for the company. For example, after the decision has been made to move to Exchange Server 2003, the issue becomes when, not if, the change should be made. If a developer has decided that a new attribute needs to be added to the user object class, make sure they have a valid reason for needing this attribute instead of using one of the 15 custom attributes that are available.

If changes are introduced, make sure they are made at a time when replication is allowed to propagate them efficiently and will affect the least number of services. Once a change is introduced, it will replicate to every domain controller within the forest. Potentially, propagation delays could introduce inconsistencies between sites and domain controllers. Careful planning as to when the change should be made and how replication should be enforced will minimize the issues.

In short, you should follow these rules:

• Make sure none of the existing attributes or object classes meet the needs of the organization.

• Do not grant anyone the right to make changes to the schema until they are necessary.

• Make sure to follow the guidelines of the change policy before you allow changes to the schema.

A well-defined schema modification policy reduces the problems associated with making changes. Debates will rage amongst the administrators of the domains, and the battles that need to be fought to prove the change needs to be put into place are hard enough without having to decide on all of the criteria to include within your policy.

Prior to implementing Active Directory, work into your design who will make up the schema modification approval committee. Meet with the administrators of all of the domains within the forest to gain approval of the policy. It will take buy-in from everyone who will be affected. This may not be a simple task, especially in an environment where you have service or data autonomy. Those administrators may not have a great deal of trust in other administrators. As mentioned before, make sure you have the appropriate allies so that you can get approval from the highest-level stakeholder.

Because the policy should lay out the requirements that must be met before the schema modification can occur, you should include each of the following components in the policy. Following the policy then guarantees that the modification being investigated benefits the company, and therefore it will be approved by all of the appropriate individuals.

Planning and Testing

Although planning and testing sounds like common sense, make sure you don t ignore it. A test environment is essential for a successful implementation. You can create test forests and domains that will not impact your current environment. Changes to the schema may affect applications other than the one you are making the change for. Try to account for every possibility. Within your test forest, install all of the applications used within the organization. Once the schema modification has been introduced into the test forest, thoroughly test all of the applications to determine if any problems arise.

This part of the policy should also spell out how the test forest will be built, who will be in charge, how permission to use the test forest will be granted, and what documentation will need to be completed prior to the approval of the modification. Because changes to the schema cannot be reversed easily, determining whom, when, and where changes will occur is a vital part of the Active Directory design.

Who Makes the Change?

The right to make changes to the schema is not granted to any user account. As a matter of fact, only one security principal is allowed to make changes: the Schema Admins group. Due to the sheer power this group has, it should be left without any members until absolutely necessary. Allowing an account to remain within this group would be like allowing someone to have the ability to alter your molecular DNA. The changes that could be introduced could be disastrous. Even if the user did not mean to be destructive, simple typos could introduce problems that could take months to diagnose.

The policy will specify who can control how accounts are added to the Schema Admins group. Members of the Domain Admins group in the forest root domain and the Enterprise Admins group are the only accounts who have the ability (by default) to modify the Schema Admins group membership. Therefore, the membership in these groups should be controlled and monitored . Auditing account modifications in the forest root should be enabled. This allows you to identify when a change occurred and who enacted the change.

The policy should point out who is allowed to add accounts to the Schema Admins group. Although this policy does not stop someone with the authority from implementing a change to the group, at least you have written documentation of the standards and policies that should be followed.

Plan the Roll-Out Schedule

Every network has busy periods when users are accessing the services and resources that reside on the network. Databases, e-mail, authentication traffic, print jobs, and many other types of data take up bandwidth on the network. Active Directory consumes bandwidth whenever replication traffic, authentication requests , or user and service queries occur. The typical daily patterns for the network traffic should be determined so that you know when the network is being used and when it is relatively silent.

For some companies, this is an easy process. They have most of their traffic occurring during the regular business hours and do not have to worry about after-hours traffic. Companies that have 24- hour cycles may not have the luxury of being able to make changes during the night because they still have a user population that needs to use the network. Large companies that span multiple time zones have even greater challenges. Changes have to be replicated to domain controllers across WAN links, through multiple sites, all at differing times.

As the person in charge of rolling out schema changes, you need to determine the best time for the roll-out. The timing of the roll-out is critical. Not only do you need to know when the change can occur due to the network bandwidth requirements mentioned above, but you need to address the propagation delay. The longer it takes for the changes to replicate, the greater the risk of having objects that are out of sync or built with the incorrect attributes.

Where to Make the Changes

All changes to the schema are made on the Schema Master. The Schema Master is the only domain controller that has the token that allows it to make changes to this service. You should enact any changes you need to make to the schema on this domain controller. If the change is made at another system, the change request and the authentication have to be sent to the Schema Master to take effect. Although this may not be an issue if you are adding a single attribute or object class, running the setup program for an Active Directory “integrated application such as Exchange Server 2003 sends far too much data across the network.