It's important to know how to design a plan to implement Active Directory. You should always fully document your intended domains, forests, organizational units, sites, DNS infrastructure and security strategies. This documentation becomes the plan for your new infrastructure when you make the migration.
The basics of Active Directory planning
When you are performing an Active Directory migration, you basically have two options: domain upgrading or domain restructuring. Domain upgrading is little more than upgrading each existing Windows domain controller to a more current Windows domain controller. The upgrade process starts by upgrading the PDCs in each domain, followed by the BDCs. Domain restructuring involves creating an Active Directory network from scratch. In a restructure, you will move systems and reroute connections to comply with a new infrastructure and layout design. Often restructuring will result in fewer but larger domains.
So the question becomes, "Should you upgrade or restructure?"
Deciding which path to take, or which process to perform first, all depends on your specific situation. But there are a few guidelines that can help you make the choice.
First, if your current domain structure is supporting your work tasks and doesn't seem to involve an inordinate amount of extraneous administration, then upgrading may be preferable. However, if the current domain structure is not adequate and is the primary motivation for the migration, restructuring is likely the way to go. Secondly, if you must support the production environment throughout the migration process, upgrading will retain overall network functionality and therefore is preferable. But if you can afford to lose productivity during the migration, restructuring is better. However, restructuring can be performed on a staggered schedule so no significant loss of productivity is noticed.
Rememeber that while upgrading will cause the least downtime in terms of getting the domain back into working order, it often is an insufficient migration. Many of the benefits of Windows 2000 and Windows 2003-based Active Directory domains cannot be fully realized without reconfiguring the design of your network. Restructuring will require significant work to implement, but it makes reaping the benefits of Active Directory easier to exploit for your organization.
Developing an Active Directory migration strategy
When taking on an Active Directory migration project, like with all large projects, it's best to have a strategy in place. It is key to create an Active Directory migration checklist, with steps such as collecting diagrams and configuration of the current DNS and network structure (bandwidth, remote locations, stability, etc.), determining the rights, objects and policies that will need to be migrated, and creating fall back procedures in case of failure.
Another part of developing your migration strategy, is being aware of the key things you should and should not do when performing an Active Directory migration.
For starters , it's important to make sure that your support staff is brought up to speed before you begin migrating any production system. Depending on the size and structure of your organization, you should have a help desk staff taking support calls. For a complex project like Active Directory, it's a good idea to make a couple of network engineers available as well. Be sure to train all members of the support staff involved in the process. Otherwise, you'll have IT staff fielding questions that they don't know how to answer, and frustration will abound on all sides.
You should also establish a test bed that mimics your production environment as closely as possible in terms of hardware specifications and network speed. Leave nothing to chance in the testing phase. Speaking of testing, be sure to test name resolution and replication before deploying Active Directory in production. Unlike replication under NT4, Active Directory replication is possibly the single most important item required for AD to function correctly. Second only to file replication for a solid Active Directory implementation is name resolution. Whether you are deploying WINS or DNS, ensure that all systems that need to can effectively talk to one another.
Designing Active Directory simply
Active Directory is very flexible. So flexible that you can design an Active Directory forest that is complex beyond imagination. Both Windows 2000 Server and Windows Server 2003 support the Active Directory containers of forest, domain, site, and organizational unit (OU). With the only real restriction of one forest per namespace, you can deploy as many domains, sites, and OUs as you deem necessary.
However, don't be so fast to rush off and design an Active Directory network that includes a domain for every department in your enterprise. The key to Active Directory design is simplicity. As a general rule, you want to keep the number of domains to a minimum whenever possible. If you really need department level divisions on your network that reflect the organization of your business, then use OUs instead. OUs are much more flexible and easier overall to manage than domains.
If you are migrating from a Windows NT 4.0 network to a Windows 2000 Server or Windows Server 2003 Active Directory network, compare the number of domains from your existing legacy system and compare that with the number of domains in your new AD-based design. If your new Active Directory network has more domains than your legacy network, you may need to re-think your design. Yes, it is possible to use as many domains as you wish, but you'll likely regret that decision down the line. If you need lots of groupings and divisions, it is best to rely upon OUs.
Active Directory domain design
When you are designing your Active Directory network, it is important to use the four divisions (forests, domains, organizational units, and sites) to their maximum potential. This is especially true for Active Directory domain design.
Domain divisions are most often used as logical containers. However, Microsoft recommends that you employ domains also as physical containers. In other words, create domains whose members are all geographically close rather than distant. This is an important design aspect since the level of traffic within a domain is considerably higher than that between one domain and another. In general, a domain with limited physical size is less likely to include expensive WAN links or pay-per-bit connections. When slow links must be included in a network design, it is often beneficial to create multiple domains connected by the slower connections.
Remember that it is not necessary to create separate domains to divide administrative privileges. Within Active Directory, it is possible to delegate administrative privileges based on organizational units.
Designing groups and organizational units
With the proper preparation and advance knowledge of their use, a functional organizational unit (OU) and group design can do wonders to simplify your Active Directory environment. It can also go a long way toward helping you gain control and reduce overhead.
Often, OUs are indiscriminately used without reason, and group structure is ineffectual and confusing. Without some form of logical organization of users within your network environment, chaos reigns and administration grinds to a halt. Some best practices when designing OUs include:
* Keep the OU structure as simple as possible
* Do not nest OUs more than 10 layers deep
* Keep the number of OUs to a minimum
* Apply Group Policy to groups through Group Policy filtering
* Don't utilize local groups for permissions in a domain environment
* Use domain local groups to control access to resources, and use global groups to organize similar groups of users.
You also have the option of hiding your OUs. The primary purpose of hidden OUs is to prevent an administrator from one OU from being able to view, access, or alter another OU. Hidden OUs are often used in environments that offer network application services to internal departments or external customers. It allows for a solid separation of duties without requiring separate domains or forests.
Design rules for Active Directory sites
Sites are an extremely useful design element for Active Directory domains. Sites are limited to any computer object within a forest. Thus, they can cross domains and organizational units (OUs) with indifference. An object's membership in a domain or OU does not exclude simultaneous membership in a site. Sites are used to impose physical network divisions for the purpose of traffic flow.
By using sites, you can control and reduce the amount of traffic that flows over your slower WAN links. This can result in more efficient traffic flow for productivity tasks. It can also serve to keep WAN link costs down on the pay-by-the-bit services.
In general, when designing sites, keep the following in mind:
* Sites should generally reflect the physical or geographic topology of the network.
* Each site should contain at least one local DC.
* Sites should not contain slow links of any type.
* Remote-access clients do not need a dedicated site.
* Sites should be used whenever control over replication traffic is needed or desired.
* Sites can be added, removed, changed, and moved easily without affecting any other AD container configuration.
No comments:
Post a Comment