Now that I’ve thoroughly emphasized the different approach you’ll have to take on this exam, it’s time to get to work on what skills you’ll have to display to be successful.
The first task is to gather information about the company. There are three general categories you’ll need to look at:
- Requirements and goals
You’ll need to make a list of everything that is required, such as limited access to the billing system and nightly backups. You’ll also need to prioritize a list of goals that must not conflict with the requirements. Goals might include the ability to access files from a certain branch office. You’ll have to decide whether the security and physical structure of the network will allow for that goal to be included, given the strict adherence to the requirements. No number of secondary goals is equal to the importance of a single requirement.
- Planning for the future
Active Directory is modular, so growth or reorganization is usually easily accommodated. The one area where you’ll have to be particularly careful is planning replication sites. They have very specific bandwidth requirements, and growth can disrupt the process and require the addition of expensive dedicated circuits, like T1, DSL, or coaxial cable connections. Adding an Ethernet hub and some Cat5 cable is usually not an issue, but be careful if you’re replicating between remote locations. I can’t think of a single question that has ever mentioned downsizing, so when questions talk about the future, plan on managing growth.
- Business structure and personnel considerations
It is fairly straightforward to model an Organizational Unit (OU) structure after the company’s departmental structure. Permissions can usually be inherited by departments intact, but it gets a bit more complex when companies have more than one location with similar departments and managers who need access to multiple departments in multiple domain trees. You can also manage business modeling efficiently using the empty root domain structure discussed later in this chapter.
Microsoft has included a bit of jargon to help you organize your notes when designing a solution. The jargon will probably show up, so it’s a good idea to memorize these decisions. Also, the authors of the questions will probably have this model in mind when designing the questions, so using the same model may make deciphering the questions a bit easier.
Remember that some of the questions will be quite long and include several pages of requirements, goals, suggestions, and distracting filler. By using the four-point model shown in Table 23-1, you may be better able to prioritize both the requirements and the secondary goals.
Table 23-1. Analyzing Your Notes
|
Analysis Step |
Purpose |
|---|---|
|
An individual item that is either required or suggested. You should separate the requirements from the goals and then prioritize the goals, grouping them so the goals that aren’t mutually exclusive are listed together. You can then score each group of goals by importance and create a packaged solution. | |
|
When you score the goals, be sure to take into account the effect that each goal has on the implementation of the others. If one goal would negatively impact many other goals, you may want to reconsider, even if the first individual goal is slightly more important than individual goals in the group it affects. | |
|
You have to consider both the technical and financial costs of each solution. If adding a convenience feature poses an undue security risk, a client such as a lawyer or a bank has to abandon that feature. | |
|
On the questions, you’ll sometimes have one group that wants a feature that could adversely affect another group. You’ll have to do your best to weigh all of the options and be very careful with the precise wording of these sorts of questions. |
You should make a chart of all the departments, who is in them, and what their job functions are. You should also determine all of the data- and equipment-sharing relationships between departments. If two departments need to share access to the same network resources, that should be considered when you design the Organizational Unit (OU) structure.
There are a few different ways to map the structure of an organization, and you may not be able to immediately pick out which way is best. In the next sections, you’ll find descriptions of the common ways to map an organization.
Because almost every organization has different departments, but not every company has multiple locations, it may be easier to start with locations. If a company has multiple physical locations, especially if the different physical locations have the same departments, you may want to create a physical locations chart first and have it handy when making the functional chart.
After you define all the physical locations, you’ll want to map out the network connections available between them. For Active Directory to function efficiently, high-speed replication of network data is a must. If a remote location has a slow or intermittent connection to the rest of the organization, that will have to be resolved before they can fully participate in the AD. Careful placement of servers can often overcome some weakness in the bandwidth available for remote sites, especially in the case of domain controllers’ being able to handle user logon traffic locally, without having to cross the slow connection for authentication.
Within each physical location, you should chart the different departments and interview the managers and employees to find out which resources they need access to and which they need to share with other departments. The main departmental divisions will likely be the main OU divisions, so access permissions planning is a must at the departmental level. Always try to assign permissions to the largest groups possible for easier administration.
The advantages of the departmental structure are that it’s very easy to convert to an OU structure, employees are already familiar with it, and employee transfers between departments are easy. Assuming the departmental manager has the necessary knowledge, departmental OU structure also facilitates the delegation of authority to local department managers.
The Active Directory system is all about managing data. How does it go from place to place and who has access to it? The division of data access does not always follow strict departmental lines. If the company is designed in such a way that billing and sales need access to customer financial records and customer service and technical support need access to customer product records, you can divide by function rather than department. Instead of having four separate OUs based on department, you may be better off with two OUs, based on the data they need to access.
Don’t forget that OUs are automatically arranged in a hierarchical structure with permissions inheritance. You can create top level OUs based on the data they need to access and lower level OUs by department. Then you can move an entire department in and out of data access OUs whenever the department’s needs change.
Because permissions would be automatically inherited from the top level data access OU to the lower level departmental OU, you wouldn’t have to change permissions for employees on an individual basis. They would inherit permissions from their departmental OU, which in turn inherits permissions from the data access OU.
Most of the time departments have many unrelated or conflicting functions that may cause this type of organization to be difficult, if not impossible, to create and maintain. Technically, you can block some permissions inheritance to solve these types of problems, but experience has shown that repeated blocking of permissions inheritance is more trouble than it’s worth.
This exam will probably make you feel like a consultant. Microsoft wants you to be able to design an Active Directory solution that can be managed by someone other than yourself, namely the IT staff at the fictitious enterprise mentioned in their questions. There are several types of IT management structures based on the size and purpose of the company. They are described in Table 23-2. You’ll need to know about each one and how it will impact your decision making.
Table 23-2. IT Structure Types
|
Type |
Definition |
Issues |
|---|---|---|
|
All IT decisions and operations are handled by a single department in a single location. |
Good communication with outside departments and locations is essential. | |
|
IT decisions are handled independently at each location. |
Interoperability, security, and cooperation are essential. | |
|
IT management is distributed, but technology is relatively consistent. |
Affected by both the centralized and the decentralized issues. | |
|
IT decisions are implemented and maintained by an outside interest. |
Response time and communication are essential. |
Remember that you can mix and match these structuring techniques to create a hybrid structure. It’s often easiest to divide first by location, then by department, and finally by function. In any case, you may be better off creating all three charts and checking to see if the IT structure tips the scales at all.