Reorganizing Active Directory
Brien Poseys new series on moving Active Directory objects walks you through procedures from the simple to the arcane. In Part 1, moving objects within and between domains.
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.
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.