While catastrophic if done incorrectly (always back up!), the editing the registry is the only solution to problems that Active Directory tools can’t fix.
I think that it’s probably safe to say that most Windows admins are familiar with the Active Directory. The Active Directory was first introduced with Windows 2000 Server, and will be turning 20 years old in a couple of years. Sure, the Active Directory has evolved a bit along the way, but it still adheres to the same basic structure that it did when it was first introduced so long ago.
Many of the Active Directory-related tools that we have today can also trace their roots back to much earlier versions of Windows. For example, the Active Directory Users and Computers tool that exists today in Windows Server 2016 really hasn’t changed very much over the years.
The point is that Active Directory is a mature technology, and most Windows Server admins probably know how to use the various Active Directory tools to perform tasks such as creating user accounts, sites, and OUs. Even so, the usual Active Directory tools can be inadequate in some situations. These tools are designed to be safe, and to protect inexperienced administrators from making potentially catastrophic mistakes. Sometimes however, the same safety mechanisms that exist to protect us can also get in the way. This is where the ADSI Edit tool comes into play.
Before I show you what the ADSI Edit tool looks like, and how to use it, I want to compare it to another tool that is built into Windows — the Registry Editor. As I’m sure you know, the vast majority of Windows’ configuration settings are stored in the Windows registry. In fact, many of the GUI based management utilities are really nothing more than registry front ends. When you use the Group Policy Editor to make a change to a policy for example, the Group Policy Editor is actually editing the registry behind the scenes on your behalf.
GUI-based tools such as the Group Policy Editor exist for two purposes. First, they make an administrator’s life easier by exposing related settings in some sort of logical way. Imagine how much more difficult it would be to implement a complex collection of group policy settings if you had to track down each policy setting through Registry Editor.
The other thing that GUI based tools such as the Group Policy Editor do for us, is that they make basic administrative tasks much safer than they would be if we had to do everything through the Registry Editor. Editing the registry can be dangerous. If you make a mistake while editing the registry, you can destroy Windows. The various Windows administrative tools are designed to make registry edits much safer by acting as an isolation boundary between the administrator and potentially dangerous registry settings.
These are the same two things that the various Active Directory tools are designed to do. Such tools present the Active Directory elements in a more simplified and logical way, while also making the process of editing the Active Directory far less dangerous than it might otherwise be.
The problem with the built-in Windows administrative tools however, is that they can’t help in every situation. Sometimes an administrator must directly edit the registry in order to fix a problem. That’s where the Registry Editor comes into play. Similarly, there are some Active Directory problems that simply cannot be fixed using the usual tools, and that’s where ADSI Edit comes into play. For example, I have used ADSI Edit to remove Active Directory remnants that were left behind by a failed Exchange Server installation. Like the Registry Editor however, ADSI Edit bypasses all of the usual safeguards, and you can do catastrophic damage by using it incorrectly, so it is a good idea to back up your Active Directory prior to using this tool.
The easiest way to access ADSI Edit is by choosing the ADSI Edit command from the Server Manager’s Tools menu. Upon doing so, you will be presented with a condole screen that looks like the one shown in Figure 1.
The first step in putting this tool to work is to connect it to your Active Directory. To do so, choose the Connect To command from the Action menu. This will bring up the Connection Settings dialog box. You must select the naming context that you want to connect to. In most cases the defaults work just fine, as shown in Figure 2.
Once you connect to the Active Directory, the console will look like what you see in Figure 3. Like the Registry Editor, ADSI Edit uses a hierarchical, tree view. The difference however, is that the option to expand the Default Naming Context and other layers of the hierarchy does not appear until the node is clicked on.
As you navigate the Active Directory, things should begin to look a lot more familiar. As you can see in Figure 4, ADSI Edit gives you the ability to move, delete, rename, or otherwise modify objects that you wouldn’t ordinarily be able to.