8.7 Design Examples

Having covered the design of the namespace, some real-world example designs are in order. We have created three fictitious companies that will serve as good models for demonstrations of the design process. We will also use these three companies in the following chapters. The companies themselves are not fully detailed here, although there is enough information to enable you to make a reasonable attempt at a namespace design. In the chapters that follow, we will expand the relevant information on each company as required for that part of the design.

We used a number of criteria to create these companies:

• The companies were set up to represent various organizations and structures.

• While each corporation has a large number of users and machines, the design principles will scale down to smaller organizations well.

• In these example corporations, we are not interested in how many servers each company has or where those servers are. These facts come into play in the next chapter on sites. We are interested in users, groups, machines, domains, and the business and administration models that are used.

8.7.1 TwoSiteCorp

TwoSiteCorp is an organization that employs 50,000 people using 50,000 machines. The organization spans 2 sites connected with a 128 Kb dedicated link. The London site has 40,000 clients and 40,000 employees, while the new expansion at the Leicester site has 10,000 clients and 10,000 employees. TwoSiteCorp's business model is based on a structure in which users are members of one of three divisions: U.K. Private Sector, U.K. Public Sector, and Foreign. No division is based entirely at one site. Various other minor divisions exist beneath these as required for the management structure. Administration is handled centrally from the major London site by a team of dedicated systems administrators.

8.7.1.1 Step 1—Set the number of domains

While TwoSiteCorp's 128 Kb link between its two physical locations is slow for site purposes, there is no need to split the two sites into two domains. No particular part of the organization has a unique policy requirement, because the administrators decided that they will implement one set of policies for all users. Finally, the sites already have two Windows NT domains installed. However, management has no desire to maintain either, so both will be rationalized into one domain. Thus, TwoSiteCorp will end up with one domain.

8.7.1.2 Step 2—Design and name the tree structure

TwoSiteCorp's single domain will be the forest root domain. The designers decide to name the domain twositecorp.com after their DNS domain name. With only one domain, they do not have to worry about any other trees or forests or the domain hierarchy.

8.7.1.3 Step 3—Design the workstation and server naming scheme

TwoSiteCorp decides that each machine name will be made up of four strings concatenated together. The first string is three characters representing the location of the machine (e.g., LEI or LON). The next three characters are used to indicate the operating system (e.g., WXP, W2K, NT4, or W98). The next string holds two or three letters indicating the type of machine (e.g., DC, SRV, or WKS). Finally, the last string is a six-digit numeric string that starts with 000001 and continues to 999999. The following are example machine names:

• LEIW2KDC000001

• LEIW2KDC000002

• LONNT4WKS000183

8.7.1.4 Step 4—Design the hierarchy of Organizational Units

TwoSiteCorp needs three major Organizational Units (U.K. Private Sector, U.K. Public Sector, and Foreign) based on its business model of divisions. The second and succeeding tiers of Organizational Units can then be created according to the lower-level management structure if required. There is no necessity to do so in this scenario, although it would make the structure easier to manage visually. In fact, this domain could be completely flat with all users and machines in one Organizational Unit, but then you aren't gaining much from Active Directory's ability to structure the data in a useful manner for administration. Speaking of administration, since it is handled centrally, there is no need to delegate administration for the three top-tier Organizational Units to any specific group of administrators, although there is room for expansion should that become necessary. Nor does TwoSiteCorp need to delegate any other permissions to the Organizational Unit structure. Now TwoSiteCorp has a fairly simple hierarchy that perfectly maps their domain.

8.7.1.5 Step 5—Design the users and groups

TwoSiteCorp has two Windows NT domains at present using a variety of global groups and local groups. During the migration, the company will have a mixed- mode domain. However, their ultimate aim is to move to native mode very quickly and reap the added benefits of universal groups. The design therefore needs to cover what universal groups the company would like for its resources. The existing global and local groups can be moved to Active Directory during migration, allowing the current setup to work with the new system. Once the switchover to native mode goes ahead, either the groups can be converted to universal groups and rationalized to fit into the new design, or they can be left as they are and new universal groups created according to the design to take the place of the old groups.

8.7.1.6 Step 6—Design the Global Catalog

TwoSite Corp has no specific GC requirements and therefore leaves the system to work out its own defaults.

8.7.1.7 Step 7—Design the application partition structure

Since TwoSiteCorp has only two sites to replicate, they do not need to create any application partitions.

8.7.1.8 Recap

This is a very simple system that maintains a good level of administration based on the structure of the organization while managing to maintain control over its expansion in the years to come.

8.7.2 RetailCorp

RetailCorp is a global, multibillion-dollar retail organization that has more than 600 stores spread throughout the world under 4 different store names. There are around 60,000 staff members in the company, with about 25,000 in the central office based in Leicester in the United Kingdom. Each store is connected to the central HQ via 64 Kb leased lines. Each store has a number of Windows NT point-of-sale workstations running database software and one or more large database servers in the back room. The database servers replicate the day's transactions down the links each evening to the central HQ.

RetailCorp is very centralized with almost no administrators at the stores themselves. The only really special requirement that the company has is that it would like the administrators to be able to easily hide the operating environment from staff on the tills at each branch. Changes to tills should be possible on an individual branch or global level.

8.7.2.1 Step 1—Identify the number of domains

RetailCorp has no need to isolate replication or do any in-place upgrades. The part about policies is a little tricky: do they need new domains for every branch in case policy changes need to be applied to one branch specifically? The answer is no. The administrators need to be able to apply policies to certain branches or all branches, but these policies have to do with the user interface and thus fall into the area of GPOs rather than individual domains. That effectively leaves them with one domain.

8.7.2.2 Step 2—Design and name the tree structure

RetailCorp, having only one domain, makes that the forest root domain. The namespace has the retailcorp.com global name that is already in use.

8.7.2.3 Step 3— Design the workstation and server naming scheme

RetailCorp uses a central database to register machines, which automatically produces a 15-character name based on a machine's location and purpose (i.e., client, database server, file and print server). Every time a machine is moved or its function changes, the name is updated in the central database, and the machine is renamed.

8.7.2.4 Step 4—Design the hierarchy of Organizational Units

It is decided to make each store an Organizational Unit, so that central administrators can delegate control over individual stores and their objects as required. However, to make things even easier to manage and delegate on a countrywide or regional basis, RetailCorp creates a series of country Organizational Units under the base. Each of these country Organizational Units contains either the shop Organizational Units directly (for countries with only a handful of stores) or a series of regional Organizational Units that themselves contain the store OUs.

8.7.2.5 Step 5— Design the users and groups

RetailCorp uses a central database to generate its own unique usernames and group names as needed. It has done this for many years, and the database produces a changes file on an hourly basis. A script picks up the changes file and applies it to Active Directory in the same manner that it does with all other systems.

8.7.2.6 Step 6—Design the Global Catalog

RetailCorp has had problems with printers before, with users printing to printers at the wrong site. To make sure that printer details are not replicated past boundaries, all printer attributes are removed from the GC. The rest of the defaults are accepted as standard, and the company intends to keep an eye on the situation to make sure that there are no problems with this in the future.

8.7.2.7 Step 7—Design the application partition structure

Since RetailCorp is using a centralized deployment model and has no special replication requirements, there is no need to create any application partitions.

8.7.2.8 Recap

This example shows how a geographically based company can do its own design. It's not particularly difficult, although this design does not take into account the slow links between the stores and the HQ. That is left until the next chapter, when we revisit RetailCorp from a physical-layer perspective.

8.7.3 PetroCorp

PetroCorp (see Figure 8-1) is a global multibillion dollar petrochemical organization that has more than 100,000 people and machines at about 100 sites around the world. The business has its global headquarters in Denver. There are 5 major sites that link to the HQ and to which the smaller 94 branch offices link. The major sites or hubs represent Asia-Pacific, Australasia, USA-Canada, South America, and Europe. The small sites link to the 5 hubs via 64 Kb links; the hubs connect to the HQ via T2, T1, 256 Kb, and 128 Kb links. Some of the hubs are also interconnected. Management structure is geographic, with each geographical unit running itself as an independent business as part of the global whole. The top level of the management structure is at HQ, which sits above the 5 hubs. Even though Denver could be considered within the USA-Canada area, the organization is not structured that way. In fact, Denver oversees the hubs in terms of selecting the administrators and how the network is to be structured. Corporate policy dictates that branches that have more than 500 people have their own administrator, backup support, and helpdesk staff locally. Branches with fewer than 500 people have to be managed by the administrators of the hub to which they connect (see Figure 8-4).

Figure 8-4. PetroCorp's wide area network

Other considerations include the following:

• Due to special company policies, public-key encryption and different language settings are used in each of the hubs (and their branches). So Europe and its branches have different settings from those in Australasia and its branches.

• Japan has a database system running on Windows NT 4.0 that must stay in its own domain.

• PetroCorp recently acquired OtherCorp, a Canadian company that has a strong brand name that PetroCorp would like to maintain. OtherCorp is solely based in a new branch in Canada.

• The links between the eight South American branches and the hub are very unreliable.

• The branch in France needs to maintain a number of Windows NT BDCs and member servers running legacy applications and services that will not run under Windows 2000. This requirement may exist for a few years.

• The Asia-Pacific 128 Kb link to Europe is severely congested at all times.

• Current U.S. laws explicitly state that information in a U.S. directory can be published anywhere except in countries that are subject to American export restrictions (currently including but not necessarily limited to Cuba, the Federal Republic of Yugoslavia (Serbia and Montenegro), Iran, Iraq, Libya, North Korea, and Syria). Since Active Directory is a directory that has the United States as its origin, it cannot be exported to those countries.

8.7.3.1 Step 1—Set the number of domains

There is a wrong way and a right way to look at PetroCorp:

The wrong way

PetroCorp starts off with five domains representing the hubs because each requires different public-key security settings.^[1] As the branch offices are part of the domain at each hub, the hub's settings will apply to the branch offices as well because the settings are domainwide. So extra domains are not needed, although they are needed for each branch office for Japan and OtherCorp. As France cannot upgrade, whatever domain France is in must remain in mixed mode. Management could make the Europe domain mixed mode but would like it to be native mode to make use of the features. So a special domain for France makes a total of eight domains.

^[1] That they also require different language settings is a red herring: Windows 2000 can support different language settings on a per-client basis rather than a per-domain basis like Windows NT.

The right way

PetroCorp starts off with one domain: the one representing Denver, the HQ of PetroCorp. The organization then needs to create a separate domain for each of the five hubs for the public-key security settings. As the branch offices are part of the domain at each hub, the hub's settings will apply to the branch offices as well, due to the settings being domainwide. Now an extra domain each is needed for Japan and OtherCorp. France cannot upgrade, so whatever domain France is in must remain in mixed mode. Management could make the Europe domain mixed mode, but would like it to be native mode so that they can make use of the Active Directory features. A special domain for France makes a total of nine domains.

Both solutions can seem valid, although you may feel that the first is not as valid as the second. The first solution would result in problems during later parts of the design process. That there are different sites with different link speeds is not really an issue here. The issue revolves around the major HQ that is separate from but which oversees the five hubs in an administrative capacity. In the wrong design, one of these domains must become the forest root domain with the relevant authority that confers. USA-Canada is the natural choice. Then HQ administrators would effectively be running the USA-Canada domain, which conflicts with the initial company notes that each hub and the HQ has its own administrators. Consequently, the second design is better.

8.7.3.2 Step 2—Design and name the tree structure

PetroCorp chooses the Denver domain as the forest root domain. The forest root domain is to be called petrocorp.com.

When it comes to choosing a naming scheme for the domains corresponding to the hubs, the administrators choose a simple one. The domains will be called:

• europe.petrocorp.com

• usacanada.petrocorp.com

• samerica.petrocorp.com

• asiapac.petrocorp.com

• australasia.petrocorp.com

The domain representing OtherCorp will be called othercorp.com. They could have merged OtherCorp into PetroCorp's structure and just used multiple DNS names for the web servers and so on. However, the company may be sold for a profit in the future, and management wants to keep it politically separate.

There are obviously now two distinct trees. We'll put them in the same forest so that resources can be shared. The subdomain hierarchy is fairly easy to follow from now on. The domains for France and Japan will follow ISO 3166 country codes and be called fr.europe.petrocorp.com and jp.asiapac.petrocorp.com. Figure 8-5 shows the forest view of the domain trees.

Figure 8-5. PetroCorp's forest domain tree hierarchies

8.7.3.3 Step 3—Design the workstation and server naming scheme

PetroCorp has decided that it specifically does not want to use any parts of its naming scheme to duplicate data that can be obtained elsewhere. For example, PetroCorp does not want to use country, city, or building information, as this can be gathered from the exact Active Directory site that the client is in. For example, there's no point in including the data UK, London, Building 3 if the site that the computer resides in is called UK-London-Building3. They also do not want to include indications of the operating system or version, as they will be using Microsoft Systems Management Server (SMS) to inventory each device; the required information can be retrieved directly from SMS's own database. They do, however, want to include the department that the client is installed in.

They also decide to use this name as part of the worldwide asset-registering system under development, so that they can institute a worldwide rolling update program of older devices. Thus, they need to include the year the client was purchased and when the client was introduced to the network.

To do this, they decide to take a leaf from the FSMO RID Master's book and use a central pool of values at their HQ for the naming of machines. Names of machines will start with a department code of seven or fewer letters, followed by a two-digit year code and a number consisting of six or fewer digits, allocated from the central pool.

When a client is to be installed, the user doing the installation goes to a web page on PetroCorp's intranet and provides his ID and the department and two-digit year for the machine. The web page (which is connected to a database) allocates that user the next central value in the list. In this manner, the central database maintains an exact note of which department a machine is in, what year it was purchased, when it was installed, what its full name is to be, and who installed it.

8.7.3.4 Step 4—Design the hierarchy of Organizational Units

As far as the internal structure of the hub domains goes, each domain is to be broken down into a number of Organizational Units based on its branches. Every branch gets an Organizational Unit created, which will contain its servers, users, and groups.

We don't have enough information to specify the internal structure of the HQ, the Japanese domain, and the OtherCorp domain. However, that doesn't matter, since we do know that local administrators at all three will manage their respective domains. That means we do not have to worry about delegating administration of internal parts of those domains to particular administrators. So effectively we have carte blanche to do what we wish with those designs.

The company notes state that each branch with more than 500 people locally employs its own administrator, backup support, and helpdesk staff. Assuming we have identified the standard set of permissions that each of the 3 sets of staff require at each branch, we need to delegate administrative responsibility for the 3 functions to the relevant groups of staff in those branches. Branch staff members now have administrative responsibility for their branch Organizational Unit only, and branches without any staff will be centrally managed.

8.7.3.5 Step 5—Design the users and groups

In addition to whatever other groups the organization's designers decide it needs, three groups corresponding to the three delegated jobs need to be created in every branch that is to have autonomous control. These three groups will be used when delegating responsibility.

Any domains intending to stay on Windows NT (i.e., France) can run in mixed mode, with other domains going native as soon as is feasible. Domain Global Security and Domain Local Security will be mainly used, although a scattering of Domain Universal Security groups will be used in the native-mode domains as soon as conversion takes place.

8.7.3.6 Step 6—Design the Global Catalog

Current U.S. laws explicitly state that information in a U.S. directory can be published anywhere except in countries that are subject to American export restrictions. As PetroCorp's Active Directory is a directory that has the United States as its origin, Active Directory cannot be exported to those countries. That throws a monkey wrench into PetroCorp's design, as PetroCorp has offices in several of those countries.

PetroCorp has a number of solutions open to them. They could have Europe or Australia host the PetroCorp domain and make the Denver office a subdomain, with Denver managing both. That's not particularly appropriate here. There are many other variations along those lines as well as a number of solutions that are workable. Here are two examples:

• Create entirely separate domains in separate forests in those countries. These forests, being outside the central forest, will have no Global Catalog exporting issues.

• Create one entirely new forest called something like export.petrocorp.com, which is not in any way related to the existing petrocorp.com domain even though the name appears that way. The export.petrocorp.com forest could contain servers from all the companies that have export restrictions, holding them together under one manageable structure. This can be hosted (have the forest root domain in another country) and be remotely managed. Manual trusts between forests can now be considered as long as these don't also break the laws.

8.7.3.7 Step 7—Design the application partition structure

PetroCorp has several corporate applications that need to store data in Active Directory. Since everyone in the company uses these applications, placing the data in a single domain would not be sufficient. For this reason, an application partition should be created and replicated to a domain controller in each major geographic location.

8.7.3.8 Recap

This example shows how a global company can create its own design and maintain a large degree of control. It also shows how laws in the real world can wreak havoc with a good design!