Organize your IT assets to get the most out of AD long term
However, a surprising number of organizations running Windows 2000 are only now beginning to deploy Active Directory, because of the complexity involved in migrating from Windows NT's domain model and the lack of "killer applications" to drive adoption.
But with the current evaporation of IT spending, a lot of companies want to get more out of the Active Directory they already have. As these companies move from the strategic view of leveraging assets to the tactical view of implementation, the question quickly arises: "How do you organize your IT assets to get the most out of Active Directory?" There is no single answer to this question, as every organization is different, but here are some guidelines for getting the most bang for your buck.
First, instead of trying to organize your assets to fit into a cookie-cutter Active Directory model, take the opposite tack: design Active Directory to fit your business. This may seem simplistic, but one of the strengths of Active Directory is its flexibility, and modifying your workflow and processes is expensive. Remember the "business process re-engineering" movement of the '90s. By minimizing modifications, you minimize "change," which reduces training expenses and goes a long way toward positive user adoption.
One of the key aspects of organizing IT assets is the "centralization versus decentralization" debate. Your organization may be centralized or decentralized right now, and Active Directory easily supports either structure. But to get the most out of your assets, you should review your history. You may find that the entire organization oscillates every few years from one extreme to the other, like a pendulum. So when you design, ask yourself what changes you would have to make, or what you would do differently, if you had to delegate or assume a large number of tasks. If you design this operational flexibility into the system, future changes to your Active Directory implementation will be incremental improvements, as opposed to total redesigns.
Make sure you understand why you're deploying Active Directory. What is driving the project? For instance, while you can take advantage of cutting-edge features and cut IT expenses by making your operation more efficient, you usually have a primary goal. If the success of your deployment is going to be judged on whether it actually reduced IT support expenses, then you don't want to include every Active Directory bell and whistle in your project. Plan for them, to be sure, but focus on success. Consider whether each feature is something that adds functionality or increases efficiency.
Next, when you're designing your naming schemes, forests and OUs, don't limit your scope. Consider all the devices and software in your organization that might be network-attached in the next decade. Many designers focus on their immediate responsibilities, such as Windows servers, PCs, printers, routers and switches, and enterprise software such as Exchange, PeopleSoft and DB2. These are important, of course, but far from comprehensive. The result is a namespace that isn't flexible or intuitively obvious. Be sure that your design includes room for telephony, which is rapidly becoming integrated with data networks, and security devices, such as badge readers. Also consider the peripherals that are in use in factories and warehouses, such as computerized machinery and wireless barcode readers. While these devices might be out of the scope of your initial project, for Active Directory to be successful in the long term, it needs to facilitate holistic management of your organization easily. On the other hand, failure means your directory will be full of "one-offs;" individual items that don't fit neatly into any category. As the number of these increases, the efficiency decreases, and so do any cost savings.
Finally, don't limit your view to your organization. You probably deal with suppliers, vendors, partners, customers and a host of other external individuals, such as auditors and accountants, consultants and government workers. Any of these people may at some point need to authenticate and access your resources, or vice versa. Thus, you want to make sure that you design organizational flexibility into the system as well. To start, play "what if" games: "if I outsource the management of my WAN or LAN, will my design allow the vendor and my internal staff the access and control that each group requires?" Similarly: "if my PBX, HVAC, and copy machine vendors want to access their equipment remotely for support, can I do this securely?" And: "if I acquire a competitor..." Also: "if I need to move a group of resources into a DMZ…"
Thomas Alexander Lancaster IV is a consultant and author with more than 10 years' experience in the networking industry. His work has focused on Internet infrastructure.
This was first published in November 2002