You can actually organise AD in many ways to meet the needs of your company's structure. One popular method is to divide AD into organisational units (OUs) based on department. For example, you might have an OU for the finance department and another for the marketing department. Of course, all these OUs are still a part of the same AD, and users within one OU can still see objects elsewhere in AD (assuming you have given them permission to do so). The advantage of grouping each department into a separate OU is that group policies can be applied to individual OUs. This means that you can easily apply a single set of security policies to an entire department. If a new employee is hired, simply make the employee a member of the appropriate OU, and all of the department's security policies will automatically be applied. Likewise, if a user changes departments, simply move the corresponding user object to the new department's OU, and the user will lose the permissions to the old department and gain the permissions of the new department. Before you start moving objects around, though, you need to know that the method you'll use to move the objects will depend largely on the object's location. You'll use different methods depending on whether an object's current location and future location exist within the same domain or in different domains. Moving objects within a domain
The process of moving objects that share a common domain is extremely simple, but keep a few things in mind. First, it's possible to move multiple objects simultaneously. This means that if you're restructuring AD for the first time and have a large number of objects to move, you can move large numbers of objects with just a few mouse clicks. You also need to know how the move affects an object's security, which depends on how the permissions were applied in the first place. As I mentioned, any time you move an object to a different OU, the old OU's permissions cease to apply and the permissions associated with the new OU take effect. An object would keep its original permissions only when the permissions were assigned at a level other than OU. For example, if a group policy had been applied to the domain level, then simply moving an object to a different OU within the same domain wouldn't get rid of a domain-level group policy permission scheme. Likewise, permissions that were assigned directly to an object would still apply to that object regardless of where it exists within the domain (unless another permission overrides it). Now that you know a little about the consequences of moving AD objects within a domain, let's take a look at how to do the actual moving. To move an object, open the Active Directory Users And Computers utility. When the console opens, select the object you want to move. (You can select multiple objects by holding down the [Ctrl] key and clicking on each object you want to select.) Now right-click on the object or objects that you've selected and select the Move command from the resulting context menu. You'll see the Move dialog box shown in Figure A. Select the location to which you want to move the objects and click OK.
| Figure A |
 |
| Select the container to which you want to move the objects and click OK. |
pb title="Page 2: Moving objects"> Moving objects to a different domain As you can see, moving objects within a domain is easy, but moving objects to a different domain can be tricky. Unfortunately, you can't move objects between domains with a simple drag-and-drop operation like the one you use to move objects within a domain. Instead, you'll have to resort to using a command-line utility called MOVETREE. Although MOVETREE is included with Windows 2000, it isn't installed by default. Instead, MOVETREE is a part of the Windows 2000 Support Tools. You'll have to install the Support Tools to gain access to the utility. To do so, insert your Windows 2000 Server CD. When you see the splash screen, select the option to browse the CD's contents. Then, navigate through the CD's directory structure to the \SUPPORT\TOOLS directory and run the Setup.exe program. Once you've installed the Windows 2000 Support Tools, you can move objects between domains. Before doing so, though, let's take a look at what actually happens when you move an object or a group of objects. As with Windows NT, every object in Windows 2000 is assigned a security identifier (SID) number. The SID uniquely identifies the object to Windows so that Windows can know which security attributes to apply to the object. When you move an object to a new domain, the object keeps its globally unique identifier number (GUID) but takes on a different SID. The new SID associates the security attributes that are applied after the move with the relocated object. However, in most cases, the object will need to retain some of its previous security attributes that were associated with the previous domain. To do so, the object makes use of a Windows 2000 attribute called SID History. This attribute compiles a list of every SID number that's ever been associated with the object. Therefore, Windows 2000 still uses the GUID to identify the object, but when creating the object's access token, it looks at all the object's SIDs and applies the security information that's associated with them. The drawback to this technique is that it works only in Native Mode. Now that you have an idea of how the move process works, let's take a look at some other issues you'll encounter. You might be wondering which types of objects can be moved. The MOVETREE utility allows you to move users, groups, organisational units, servers (including domain controllers), and workstations between domains. In general, there are heavy restrictions on interdomain moves and some even bigger restrictions on some of the types of moves I've mentioned. In fact, in some cases, I recommend using an alternate tool for the move. Perhaps the biggest restriction with all moves between domains is that the move must take place between two domains within a common forest. Remember that if two domains are in different forests, they have no knowledge of each other and don't share a common AD schema or global catalog. Therefore, the move is impossible. Another restriction is that whatever type of object you're moving, you must move it into a container that already exists within the new domain. The MOVETREE utility can't create a new container for you. pb title="Page 3: Troubleshooting" Why did the move fail? As I mentioned, the process of moving AD objects between domains involves using a command-line utility. As with many other command-line utilities, the syntax can be rather complex, and there is a strict set of rules you must adhere to. This leaves a lot of room for things to go wrong. Check your syntax. Another possible cause of a failed move is that the object you're moving is locked. As you probably know, AD is designed to allow multiple users to access it simultaneously. Because of this, the entire directory is never locked. However, it is possible that Windows can lock a portion of AD. For example, any time you create a child object, the child's parent object is locked during the creation process. Whenever an object is locked, it can't be moved until the lock has been released. Another cause for failure is a schema mismatch. The two domains you're moving objects between must be within the same forest. Because they do exist within the same forest, the domains share a common global catalog and AD schema. A schema mismatch would occur whenever the two domains don't actually belong to the same forest. You could also have a schema mismatch if you made a big change to AD and the change hasn't finished replicating to all the domain controllers. In such a situation, some domain controllers within the forest would have the new schema, while other domain controllers would still have the old schema. A replication-related schema mismatch will take care of itself when the next replication cycle completes. Another replication-related failure would be a situation in which you tried to move an object that had been deleted. Remember that when you delete an AD object, the object is removed from only a single domain controller. The deleted object remains on all other domain controllers until after the next replication cycle has completed. Therefore, if you attempt to move such an object, the object may appear to be valid because it still exists on the domain controller you're looking at. However, a move would fail because the deletion process has already been initiated. A more common cause for a failed replication might be running out of hard disk space on the destination domain controller. Invalid login credentials for either the source or the destination domain would also cause the move process to fail. Conclusion AD's structure should mimic your company's organisational structure. However, many times this means that you'll have to reorganise AD to better meet your needs. Reorganisation can be a daunting prospect, but it doesn't have to be as challenging as you think if you do a little planning and know what's involved.
Have your say instantly in the Tech Update forum.
Find out what's where in the new Tech Update with our Guided Tour.
Let the editors know what you think in the Mailroom.
Talkback
ITS SPELLED ORGANIZATION!!!
Good article tho.