No matter how you migrate to Active Directory, at some point you’ll need to determine exactly what data you will store for the objects in Active Directory. Will you use the physicalDeliveryOfficeName attribute of the user object? What about the telephonePager attribute? Do you want to merge the internal staff office location list and telephone database during the migration? What if you really need to know what languages each member of your staff speaks or what qualifications they hold? What about their shoe size, their shirt size, number of children, and whether they like animals?

The point is that some of these attributes already exist in the Active Directory schema, and some don’t. At some point, you need to determine the actual data that you want to include. This is an important decision, since not all data should necessarily be added to Active Directory. While it may be nice to have shoe size data in the directory, it may not make much business sense. You need to ask, “Is this data needed on all domain controllers for a given domain or all global catalogs in the forest?” It is possible that an application partition, Active Directory Lightweight Directory Services (AD LDS), or even a SQL Server database may be a better store for this information. Solutions outside of the AD forest are often particularly appropriate when the data in question is sensitive or confidential in nature.

Keep in mind that every piece of data that gets added to the directory needs to be replicated. This can have a significant impact on network traffic, storage needs, and the time required to build new domain controllers. If the data will change frequently, factor in the increased replication load. If replication is a burden on your network, you may experience additional latency in overall replication due to the added overhead.

When you identify a deficiency in your Active Directory schema, you have to look into whether modifying the schema is the correct way to proceed. Finding that the schema lacks a complete series of objects along with multiple attributes is a far cry from identifying that the person-who-needs-to-refill-the-printer-with-toner attribute of the printer object is missing from the schema. There’s no rule, either, that says that once you wish to create three extra attributes on an existing object, you should modify the schema. It all comes down to choice.

To help you make that choice, you should ask yourself whether there are any other objects or attributes that you could use to solve your problem.

Let’s say you were looking for an attribute of a user object that would hold a staff identification number for your users. You need to ask whether there is an existing attribute of the user object that could hold the staff ID number, which you are not planning to use. This saves you from modifying the schema if you don’t have to. Take Leicester University as an example: we had a large user base that we were going to register, and we needed to hold a special ID number for each of our students. In Great Britain, every university student has a University and Colleges Administration System number, more commonly known as the UCAS number; this is a unique alphanumeric string that UCAS assigns independent of a student’s particular university affiliation. Students receive their UCAS numbers when they first begin looking into universities. The numbers identify students to their prospective universities, stay with students throughout their undergraduate careers, and are good identifiers for checking the validity of students’ details. By default, there is no schema attribute called UCAS-Number, so we had two choices: we could find an appropriately named attribute that we were not going to use and make use of that, or we could modify the schema.

Since we were initially only looking to store this piece of information in addition to the default user information, we were not talking about a huge change in any case. We simply looked to see whether we could use any other schema attribute to contain the data. We soon found the employeeID user attribute that we were not ever intending to use, and that seemed to fit the bill, so we decided to use that. While it isn’t as appropriately named as an attribute called UCAS-Number would be, it did mean that we didn’t have to modify the base schema in this instance.

The important point here is that we chose not to modify the schema, having found a spare attribute that we were satisfied with. We could just as easily have found no appropriate attribute and decided to go through making the schema change using our own customized attribute.

If you’ve installed Microsoft Exchange into the forest, there is also a set of attributes available for you to use for whatever you need. These are known as the extension or custom attributes and have names like extensionAttribute1, extensionAttribute2, and so on. These are not generally used by the operating system and have been left in for you to use as you wish. There are 50 created by default with Exchange Server 2013, thus giving you spare attribute capacity built right into Active Directory. So, if we wanted to store the number of languages spoken by a user, we could just store that value inside extensionAttribute1 if we chose.

Making use of extension attributes and making use of unused attributes works well for a small number of cases. However, if there were 20, 30, or more complex attributes, each with a specific syntax, or if we needed to store 20 objects with 30 attributes each, we would have more difficulty. When you have data like that, you need to consider the bigger picture.

So, you have a list of all your data, and you suspect either that the schema will not hold your data or that it will not do so to your satisfaction. You now need to consider the future of your organization’s schema and design it accordingly. The following questions should help you decide how to design for each new class or attribute:

Basically, these questions boil down to four much simpler ones:

An important rule of thumb is to never modify default system attributes. This ensures that you never conflict with anything considered a default by the operating system, which might eventually cause problems during upgrades or with other applications, such as Exchange. Adding extra attributes to classes is fine, but avoid modifying existing attributes.

The Schema Management MMC snap-in is not available from the Administrative Tools menu, like the other Active Directory snap-ins. To use it, you need to first register the Dynamic Link Library (DLL) file for the snap-in by typing the following command at the command prompt:

regsvr32.exe schmmgmt.dll

You can then start the Active Directory Schema console by creating a custom MMC and adding the Active Directory Schema snap-in to it. To create a console, go to Start → Run, type mmc.exe, and click OK. Then, in the empty MMC, go to File → Add/Remove Snap-in. From here, you can click the Add button and select Active Directory Schema as the item. If you then click the Add button, followed by Close, and then the OK button, that will give you an MMC hosting the Active Directory Schema snap-in for you to use and later save as required.

REGEDIT4
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParameters]
"Schema Update Allowed"=dword:00000001

Each domain controller maintains a copy of the entire schema in memory. This is known as the schema cache. It is used to provide a very rapid response when requesting a schema object OID from a name.

The schema cache is actually a set of hash tables of all the classSchema and attributeSchema objects known to the system, along with specific indices (attributeID, mAPIId, and lDAPDisplayName for attributeSchema objects and governsID and lDAPDisplayName for classSchema objects) for fast searching.

The objects are loaded into the schema cache when the domain controller is booted, and again five minutes after an update. However, if you need the schema cache to be updated immediately for some reason, say after the creation of a new object or attribute class, you can force an immediate reload of the cache.

As we said, the system holds a copy in memory solely to aid in searches that require quick and regular access to the schema. If the system were to keep the cache and the actual Active Directory schema in sync, it could be costly in terms of performance; making changes to the schema is an intensive process due to the significant checking and setting of object defaults by the system upon creation of new objects. Consequently, there is a time delay between changes made to the underlying schema and the cached copy. Typically, the schema tends to be updated in bunches. This is likely to be due to applications creating multiple classes for their own purposes during an installation or even normal operation. If classes are still being created after five minutes, the system updates the cache in five-minute increments after the first five-minute update has completed. This continues for as long as the schema class updates continue.

During the intervening five-minute period, when the underlying schema has been modified but the cache has yet to be updated, instances of objects or attributes of the new classes cannot be created. If you try to create an object, the system will return an error. This is due to the fact that object creations refer to the cache and not the underlying schema. To get around this problem, you can force an immediate reload of the cache by updating a special operational attribute on the RootDSE. We’ll cover this later when we consider how to use the Schema Management MMC snap-in to create and delete classes. In a similar vein, if you mark an object as defunct, this will not take effect until the cache is reloaded.

Although you cannot create new instances of new object types that you have created until the schema cache refreshes, you can add new attributes or classes that you have created to other classes that you are creating. For example, if you create a new attribute, you can immediately add it to a new class. Why? Because the attribute or class is added using an OID, and the system thus doesn’t need to do any lookups in the schema cache. While all system checks by Active Directory confirming that the data is valid—covered in the section “Checks the System Makes When You Modify the Schema” (page 508)—will still be performed, the checks are performed on the schema in Active Directory, not the cache. If this weren’t the case, you would have to wait for at least five minutes before any new attributes that you created could be added to new classes, and that would be unacceptable.

The schema master FSMO is the domain controller where changes to the schema take place so that multiple users or applications cannot modify the schema on two or more different domain controllers at the same time. When Active Directory is installed in an enterprise, the first server in the first domain in the forest (the forest root domain) becomes the nominated schema master FSMO. Later, if changes need to be made to the schema, they can be made at the current master.

You can transfer the role from an existing schema master in three ways: via the Active Directory Schema MMC snap-in, via the NTDSUTIL tool, or via code that makes use of ADSI or LDAP.

Using the Active Directory Schema MMC snap-in to transfer the role is easy. First you need to connect to the server that is to be the new master, and then you need to force the role to change to the server to which you are now connected. To start the process, simply run the MMC and right-click Active Directory Schema in the lefthand scope pane. From the context menu that drops down, select Change Active Directory Domain Controller.

You can now select a new server to connect to. You should transfer any FSMO roles (not just the schema master) to a new server before shutting down a server for an extended period, such as for maintenance. Once you have connected to the intended target for the schema master FSMO role, right-click on Active Directory Domains Schema in the scope pane and select Operations Master from the context menu. A dialog box will appear, showing the current DC holding the schema master FSMO role, as well as an option to change the role to the currently connected server. Figure 17-1 shows this dialog box. Click the Change button to transfer the schema master role.

Figure 17-1. Transferring the schema master FSMO

In the event that the schema master role owner becomes permanently unavailable (due to hardware failure, operating system corruption, etc.), you will need to seize the schema master role on another domain controller. In order to seize a FSMO, you must use the ntdsutil command-line utility. For more information about seizing FSMO roles, see Chapter 18.

One of the most commonly used ways to extend the schema is with the LDAP Data Interchange Format, or LDIF. LDIF was defined in RFC 2849 and provides a way to represent directory data via a human-readable text file. You can export data from Active Directory in LDIF format, and you can also add, modify, and delete data with LDIF. The ldifde program comes installed as part of any Windows Server and can be used to import and export LDIF data. To import the contents of an LDIF file, run the following command:

c:> ldifde -v -i -f import.ldf

Replace import.ldf with the name of the LDIF file you want to import.

LDIF files contain one or more entries, with each entry containing one or more attributes that should be added, replaced, or removed. The format is straightforward, but very strict. The following is an example of an LDIF file that would add a group object to the Users container:

dn: cn=mygroup,cn=users,dc=mycorp,dc=com
changetype: add
objectclass: group
description: My Group
member: cn=administrator,cn=users,dc=mycorp,dc=com
member: cn=guest,cn=users,dc=mycorp,dc=com

The first line must be the DN of the object. The second line is the changetype, which is one of add, modify, modrdn, or delete. When using add, as in this case, we must specify all the mandatory attributes for the object. For group objects, we need to specify only objectClass. The cn attribute is not required because it is already specified as part of the DN.

It is easy to create portable schema extensions using LDIF files. Simply create an LDIF file with all the necessary classSchema or attributeSchema object additions or modifications, and administrators using any LDIF-based client (such as ldifde, which ships with Windows) can easily import it into Active Directory. The following LDIF file shows how to create an attribute and an auxiliary class that contains the new attribute:

dn: cn=myCorp-ITUserBuilding,cn=schema,cn=configuration,dc=X
changetype: add
attributeID: 1.2.3.4.111.1
attributeSyntax: 2.5.5.1
oMSyntax: 127
isSingleValued: TRUE
lDAPDisplayName: myCorp-ITUserBuilding
objectClass: attributeSchema

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: cn=myCorp-ITUser,cn=schema,cn=configuration,dc=X
changetype: add
objectclass: classSchema
description: Class for MyCorp Employees
lDAPDisplayName: myCorp-ITUser
governsID: 1.2.3.4.111.2
objectClassCategory: 3
subClassOf: top
mayContain: myCorp-ITUserBuilding

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

To import this sample, you need to replace the placeholder DNs with the DN of the Schema NC. You can use the -c switch and ldifde’s macro expansion capability to easily do this:

>ldifde -i -f schema-extension.ldf -c "cn=schema,cn=configuration,dc=x" 
"#schemaNamingContext"

As we mentioned, all mandatory attributes for attributeSchema and classSchema objects must be specified. The order of the additions is also important. Because we wanted to add the new attribute to the class, we needed to create it first. We also needed to reload the schema cache before attempting to reference the new attribute by lDAPDisplayName, or a failure would have occurred. To accomplish that, we perform a modify operation against the RootDSE (i.e., blank DN) and write to the schemaUpdateNow attribute.

The benefits of using LDIF to implement schema extensions are twofold. First, since LDIF is human-readable with a well-defined syntax, it is easy for those who need to implement the extensions to see what is going to be done. If you use a program whose source the administrator cannot view, he will not have as much visibility into what changes are made. Along the same lines, LDIF files provide a crude documentation mechanism for schema extensions. Because LDIF files are just text-based files, schema administrators can archive the files on a server and have instant access to exactly what changes were made for certain applications.

When you create a new class or attribute, the system performs some basic checks within Active Directory to see if the data is valid, in addition to any checks you provide. The checks for attributes are shown in Table 17-1, and those for new classes are shown in Table 17-2.

Active Directory does not allow you to delete objects from the schema. However, if your forest is running at the Windows Server 2003 or better functional level, you can redefine or disable classes and attributes. This allows you to correct potential mistakes you may have made or to repurpose classes or attributes you are no longer using.

If you create a class or attribute of some sort and decide that you don’t want it any more, you can simply disable it, which is otherwise known as making it defunct. This is achieved by setting the isDefunct attribute on the schema object to TRUE or by unchecking the “Attribute is active” or “Class is active” checkbox in the Active Directory Schema MMC snap-in.

For this to succeed for an attribute, the system makes sure that the attribute is not a mandatory or optional attribute of any non-defunct class and is not the RDN attribute (rDNAttID) for any class. For this to succeed for a class, the system makes sure that the class is not a parent of any other non-defunct class, is not an auxiliary class to any other non-defunct class, and is not a possible superior of any other non-defunct class. If you later decide that you want to use the schema object again, set the value of isDefunct to FALSE. The checks that occur when doing this are the same as for creating a new schema object of the appropriate type in the first place.

When an attribute or class is marked as defunct, the corresponding data stored in Active Directory is not removed. With this in mind, prior to marking a class as defunct, you should remove all instances of that class from the directory. Likewise, prior to marking an attribute as defunct, you should clear the attribute on all objects.

When a schema object is defunct, attempts to create instances of it fail as if it doesn’t exist. The same applies to modifying existing instances, whether of an attribute on an object or an object itself, as they will appear not to exist. You can, however, delete objects that are instances of defunct classes. Searches for objects that are instances of defunct classes will happily succeed, as will searches on non-defunct classes that contain defunct attributes. All attributes, defunct or not, can be read. This is all required to enable the administrator or application author to clean up and remove the now-defunct object instances and all values from now-defunct attributes.

Some applications that extend the Active Directory schema have done so in a way that doesn’t conform with the best practices discussed in this chapter. In the most egregious cases, third parties used arbitrary OIDs from Microsoft’s OID space. When administrators imported the schema extensions, they succeeded and everything appeared to be just fine. Unfortunately, Microsoft later used the same OIDs (as they were Microsoft’s to begin with), and steps such as Active Directory schema upgrades during adprep when upgrading the forest failed.

Prior to Windows Server 2008, the LDIF files used by adprep could be edited to mitigate a failure due to a conflict. While this alleviated the immediate problem, it led to a forest with a base schema that was divergent from the schema Microsoft ships with each version of Active Directory. To combat this problem, Microsoft changed the adprep process in Windows Server 2008 to require that the LDIF files be digitally signed. Digital signatures ensure that files have not been altered or tampered with.

Since the LDIF files for the base Active Directory schema are now signed, it’s not possible to simply modify them in advance of running adprep to ensure the process will succeed. Instead, you will need to first mark the conflicting classes or attributes as defunct, recreate them with valid OIDs, and then repopulate the attributes or recreate the objects. Once this process is complete, you will be able to successfully complete the adprep process.