لطفا منتظر باشید ...
PublisherDesign Objectives
I'm as much of a hardware/software geek as the next administrator. I admire innovative technology packed with cutting edge ideas. But networks don't exist just for administrators. We just tend the farm. Somebody else eats the crop. Like it or not, networks exist for users.Every administrator has war stories about impatient users who babble and scream when faced with even the most trivial network operation. Map a drive? Forget it. Connect to a printer? Out of the question. Users demand simple, reliable, high-performance access to network resources. If a resource is more than two clicks away or requires learning anything that remotely smacks of jargon, the resource might as well be in the Far Magellanic Clouds. If your Active Directory design doesn't create a simpler and more reliable environment for your users, it will fail.So, proper domain design should make resource access as intuitive as possible. Fine. But there is more to good design than simplicity. From the perspective of a system administrator, domain designs must meet a host of objectives. Here are some of the major ones:
- Security.
The methods and protocols used to control access to resources must be strong enough to protect millions or billions of dollars of data and hardware. The design must make it as difficult as possible to gain unauthorized access and as simple as possible to gain authorized access. It must support auditing so that abuse is discovered early before extensive damage is done. And it must do this security checking as fast and unobtrusively as possible. - Stability.
No network operating system is acceptable that presents network resources in an unpredictable manner or demonstrates oddball behavior when called on to do its chores. Network resources should operate in the same way every minute of every day. - Reliability.
A good design avoids single points of failure. Because full redundancy is hard to achieve, the design must also incorporate straightforward failure contingency plans that have a high probability of successful execution. - Manageability.
After a domain is in place, it should not take a platoon of system engineers working around the clock to keep it working. Ideally, a few administrators in a central location should be able to manage all system resources. - Interoperability.
No administrator can avoid running a mix of hardware and multiple operating systems. A good design should minimize friction when information transits from one system to another. - Recoverability.
Active Directory is a database, and no database is safe from corruption, bugs, and bad karma. A good design expects directory problems, monitors for them proactively, and makes allowances for repair with a minimum of service disruption. - Efficiency.
Directory service operations take a toll on infrastructure such as communication links and server hardware. Your Active Directory design should minimize infrastructure costs and make the unavoidable costs so incontestable that only the most miserly executive would dare slash them out of the budget.
In addition, there are less definable but equally compelling design influences generally grouped under headings such as ooomph , juice , pull , and politics . These influences can take an otherwise elegant design and mash it up beyond all recognition if you aren't careful. The foremost source of initial design compromises when laying out an Active Directory structure is the domain name. Let's address that issue first.
