It’s been said that the only constant thing is change. This statement is especially true in the world of networking. Some changes, such as new service packs, are easy to deal with; others, like major restructuring, take a little more planning. In the past, it was a monumental task to redesign a network to fit the corporate infrastructure every time a company’s organizational chart changed. However, Active Directory makes this once near-impossible task easier. In this article, I’ll discuss some situations in which you may have to reorganize the Active Directory. I’ll then go on to explain how to complete the process.
One of the main reasons for reorganizing is to ensure that the network’s design can continue to meet the ever-changing organization of your company. For example, suppose the accounting department and the financial planning department both have individual domains. Now, suppose the two departments merge. In Windows NT, you can create a trust relationship between the two domains to deal with the merger. However, you’ll never truly unite the two domains without completely reloading all the servers in one of the domains and manually recreating all the users and resources that previously existed within those domain controllers. In Windows 2000, it’s much easier to reorganize the Active Directory to match the changing corporate structure. Sure, sometimes a lot of work is involved, but you should never have to resort to reformatting servers or manually recreating resources.
You may also want to reorganize the Active Directory in a less dramatic situation: when an employee changes departments. In the past, if those departments were in different domains, you’d have to delete the account from the old domain and recreate it in the new domain. However, in Windows 2000, it’s possible to simply move the account between domains.
Corporate restructuring isn’t the only reason for reorganizing your Active Directory. Suppose for a moment that you’re hired to take over an existing Windows NT network. That network may or may not have been designed to optimally meet the company’s needs. If you ever upgrade to Windows 2000, you’ll be able to take full advantage of Active Directory and reorganize the network to best meet the company’s needs.
Before You Begin
As with most types of major network restructuring, you can’t just sit down at a terminal and say, I think I’ll completely revamp the entire network. Instead, you must plan the changes you want to make and how they will affect the rest of the network. You also need to be familiar with the procedures used for the task at hand.
There’s no master procedure that can be used for all types of Active Directory restructuring–the methods you’ll use depend on the task you’re trying to accomplish. For example, you’ll use one procedure to move objects within a domain and a different procedure to move objects between domains. In this series of articles, I’ll discuss these and other procedures that you may use, in detail.
Moving Objects Within a Domain
Let’s begin by discussing how to move objects within the same domain. Because replicas of user accounts are stored on each domain controller, you’ll rarely, if ever, use this procedure to move users. Instead, this procedure is generally used to move resources. For example, you might move a printer to a different print server.
When moving objects within a domain, it’s usually a good practice to move objects between organizational units within the domain. This is especially true when the object will keep its original security requirements.
With this in mind, you need to know a few things about the way security is handled when moving an object from one organizational unit to another. If permissions were originally assigned directly to an object, the object will retain those permissions during the move. For example, suppose you had assigned permissions directly to a printer that allowed members of the Managers group to print to the printer. After moving the printer, the Managers group will still have access to the printer.
Inherited permissions are handled a bit differently. Remember that inherited permissions are hierarchical, and are therefore passed down from higher levels of the Active Directory hierarchy. Moving an object to a different location within the Active Directory will change the object’s position within the Active Directory, and therefore will change its inherited rights as well. If the object that you’re moving depends on inherited permissions, you may need to add permissions to the new organizational unit that will allow the object to inherit permissions equivalent to the original permissions it previously inherited.
I should also point out that when moving objects within a domain, it’s possible to move multiple objects simultaneously. This feature can save you a lot of time during a major reorganization in which dozens or even hundreds of objects are being moved.
The process of actually moving an object to its new location is quite simple:
- Open the Active Directory Users and Computers snap-in for Microsoft Management Console.
- Within this snap-in, select the object(s) you want to move.
- Select the Action|Move command to open the Move dialog box.
- In this dialog box, select the new location and click OK. The object will be instantly moved to the location you’ve specified.
Moving Objects Between Domains
Unlike moving objects within a domain, moving objects between domains is more of a science than a simple procedure.
SIDHistory is unique to Windows 2000 and is active only when Windows 2000 is running in native Active Directory mode. The SIDHistory attribute maintains a list of all the SID numbers the object has ever been assigned. To see how SIDHistory really works, consider a situation in which you’re moving a user account from one domain to another. During the process of the move, the user account retains its original Globally Unique Identifier (GUID) but takes on a new fully qualified domain name and SID. The account’s original SID is recorded in the account’s SIDHistory attribute. The next time the user logs on the new SID is active.
Normally, the user wouldn’t be able to access his old files and other resources, because the account’s new SID isn’t registered as having access to those resources. However, during the login process, Windows 2000 looks at the SIDHistory. When Windows 2000 creates the access token, it bases the access token on the current SID and on all previous SIDs. It’s almost as if it’s possible for a user account to be registered to multiple SIDs. Because the resources to which the user previously had access recognize the old SID from the SIDHistory, the user will still be able to access his resources as if nothing happened.
This process involves using a utility called MOVETREE. MOVETREE is included with Windows 2000, but it must be installed manually. I’ll explain how to install MOVETREE in Part 2 of this series. For now, you should know that you must follow a very strict set of rules when moving objects between domains. Some objects can be moved easily, whereas other objects simply can’t be moved at all. Still other types of objects can be moved with some manipulation, but Microsoft doesn’t officially support those procedures.
In spite of all the complicated procedures, the basic premise of moving objects between domains isn’t that different from moving objects within a domain. Whether you’re moving a leaf object or a root object, the idea is to move the object from its current location into a pre-existing parent object elsewhere in the forest. When you complete such a move, the object’s fully qualified domain name will automatically change to reflect its new position within the Active Directory hierarchy. Even with the new fully qualified domain name, the object still retains its original Globally Unique Identifier (GUID).
Although the object’s GUID remains the same after it has moved, the object takes on a new SID. As you may recall, in Windows NT (and to some extent in Windows 2000), the SID is used to create an object’s access token. In Windows NT, changing a user’s SID will render the account useless, because it will no longer be associated with any security information. To get around this problem, MOVETREE takes advantage of an object attribute called SIDHistory (see sidebar).
Now that you know how the MOVETREE utility works, it’s time to get into the rules that you must follow when using MOVETREE. I’ll cover these rules along with the MOVETREE installation procedure in Part 2 (
Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it’s impossible for him to respond to every message, although he does read them all.