PART TWO Migration Strategies - Pearson Education · 2019-02-20 · Migration Strategies PART TWO • Chapter 2 Planning a Migration • Chapter 3 Selecting a Migration Strategy •

Migration StrategiesP A R T T W O

• Chapter 2 Planning a Migration• Chapter 3 Selecting a Migration Strategy• Chapter 4 Group Policy Planning• Chapter 5 Lowering Desktop TCO

There are several different things that go into planning a Windows 2000 migration.These are namespace design, forest planning, domain planning, OU design, sitetopology, and a DNS plan. Each of these is examined in this section of the book. Inaddition, we will talk about group policy and how we can use it to make life easierfor users and for IT staff.

ch02.qxd 11/5/01 12:00 PM Page 19

Prentice Hall PTR

This is a sample chapter of Designing Windows 2000 Networks ISBN: 0-13-066199-6 For the full text, visit http://www.phptr.com ©2001 Pearson Education. All Rights Reserved.

ch02.qxd 11/5/01 12:00 PM Page 20

21

T W O

Planning a Migration

CHAPTER OBJECTIVES• Relationship of Namespace........ 22• DNS Planning Considerations........ 26• AD Sizing........ 29• Domain Design Considerations........ 41• Evaluating Existing Network Infrastructure........ 63• Evaluating Existing Servers........ 63• Evaluating Existing Desktops........ 67• Chapter Review........ 69• In the Next Chapter........ 69

Many computer professionals have described the migration toWindows 2000 as one of the most difficult migrations they haveencountered in their careers. Depending on the scenario, the pathto a completely native Windows 2000 network can be a long one,and it is fraught with myriad potential gotcha’s. The reason forthis may not be immediately obvious to the uninitiated.After all,they may reason, it is a Microsoft product, and we are alreadyrunning Windows NT, so how hard can it be? But Windows 2000 isa nearly complete rewrite of its predecessor, and it is one that im-

ch02.qxd 11/5/01 12:00 PM Page 21

22 Chapter 2 • Planning a Migration

pacts nearly all aspects of the network.As we will see in this chap-ter, everything must be examined in excruciating detail.The plan-ning approaches the magnitude of a Napoleonic campaign. Thecost can be considerable, so companies must approach the migra-tion event with a sense of foreboding, respect, and anticipation.

Relationship of NamespaceAs you are designing the namespace, keep in mind the relationship to other(non-MS) DNS systems that may already be in operation on the network.Think of the tree/namespace design from all angles: admin, user, scaling,replication/network impacts, performance, policies. The namespace design isextremely important, and will provide the framework for your entire enter-prise. It must be correct.

Namespace design

The namespace is like the skeleton of an apatosaurus: It controls the outcome.

As you are trying to design the global catalog, take a look at the exist-ing Exchange deployment; it is a good indicator of how the company thinksabout directory issues. In addition, it can provide a pointer to how the name-space can be designed. In all cases, design and implement both the name-space and the directory before deploying client machines. This will keep youfrom having to play catchup on the desktop later in the game. Your goal is totouch the workstations only once and avoid the trap, so common in poorlyplanned deployments, of making repeated trips to the desktop machines. Notonly does it annoy users to be uprooted from their computers, it sends a badmessage to management. Sooner or later the question is going to come up,“Why didn’t you do that the last time you were at my machine?” The only ex-ception to this is the case of smaller organizations—those with fewer than1,000 machines. For these smaller networks, the desktop machines can moreeasily be deployed first. This will allow the company to reap the benefitsmore readily from the more stable Windows 2000 professional client plat-form.

Five Key Steps in DesignThere are five key steps in the design of a Windows 2000 migration that willgreatly influence the success of the project. The completion of each of thesesteps results in a document that describes a particular portion of the process.

ch02.qxd 11/5/01 12:00 PM Page 22

1. Forest plan document

2. Domain plan

3. OU plan

4. Site topology plan

5. DNS plan

First Domain on SiteIn this section we will look at considerations involving the first domain in a site.

FOREST/DOMAIN/SITES/OU/

The forest is the largest area in Windows 2000 enterprises. When you bringup the first Windows 2000 domain controller on your network, you automati-cally have a forest. You also have a domain, and you have a site. All this re-sides on a single box, and it was all created at the same time. The importantthing to remember is that there is but one schema for one forest. If you needto have multiple schemas, then you will need multiple forests. In addition,you need to agree on a schema change policy at the outset. Who owns theschema in the enterprise? Due to the importance of the schema (you canhose the entire enterprise with a single click of the mouse—the mouse thatroared), most companies have a dedicated person in charge of the schema.

Inside the forest we also have a domain tree. It is a boundary within theforest; the domain is a boundary for AD. All objects and attributes live insidethe domain. Within the domain you can have sites. You can put policy on thedomain, site, or OU.

A site is a well-connected network. Typically, a site is a physical loca-tion that has one or more subnets associated with it. Sites are used primarilyto control replication. A well connected network is usually defined as LANspeeds, but is commonly extended to include T-1 speeds as well. The defini-tion of well connected is, of course, user defined, and has been expanded insome instances down as far as 128K (dual band ISDN).

An OU is a feature of Windows 2000 management that allows thegrouping of related resources or users to simplify the application of policiesand security settings. There are several methods by which OUs can be struc-tured. For instance, some organizations will use OUs to group users and re-sources according to geography. Other companies, however, may decide touse OUs to group their users according to functionality, i.e., accounting, engi-neering, maintenance, information services, purchasing, and the like.

Single forest–single schema

If more than one schema is needed, then it is a multiple forest design.

Relat ionsh ip of Namespace 23

ch02.qxd 11/5/01 12:00 PM Page 23


TRUST PLAN

What are the costs of additional forests? For one thing, it requires more hard-ware, additional servers, and maybe more networking equipment. One of thequalifying questions: What groups have the business authority to overrideand make changes in schema?

DOMAIN PLANNING

A domain is a partition of the forest. It is a physical partition, a portion of theforest namespace. In addition, a domain is a logical partition. As such, itforms an administrative boundary. The domain is used as a policy boundary,and provides a unit of authentication. As you are doing your domain plan-ning for a migration to Windows 2000, start by considering a single domain.Remember, there are compelling reasons for staying with a single domain de-sign, and it can accommodate really large networks. Ease of administrationand reduction of equipment costs are two really strong arguments in favor ofa single domain forest.

If you start with a single domain design, then make sure you justify ad-ditional domains as (or if) they are incorporated into the domain plan. Somereasons to add additional domains to the domain plan:

• Upgrade existing domains in place• Logical partitioning: Admin/policy• Physical partitioning: Optimize replication

So we can see, there are valid reasons that exist for adding additionaldomains to our namespace. There are also obsolete reasons you need to beaware of. These may have been valid in the NT 4 days; however, they nolonger exist as valid reasons for additional domains in the Windows 2000world because of:

1. Recommended 40K object SAM size: AD scales to millions of objects.

2. PDC availability requirements: AD is multimaster.

3. Delegation of admin (resource domains): Delegate within domain usingOUs.

OUs allow granularity; an OU is a container within a domain and, assuch, it can be nested. An OU, however, is not a security principal. OUs areused to delegate administration, and are used to apply group policy. The OUhierarchy may or may not reflect business hierarchy; it maps to business rulesinstead. Users will not navigate the OU hierarchy; in fact, most users willnever even be aware of the OUs, nor do they use the OUs to find networkresources. Administrators use OUs to facilitate security and user administra-tion. OU depth does not impact performance: On the contrary, network per-formance is more affected by group policy. However, names should make

ch02.qxd 11/5/01 12:00 PM Page 24

sense to the administrators, and are best if kept short (makes certain Light-weight Directory Access Protocol (LDAP) tools easier to use).

SITE TOPOLOGY

Site topology is a logical representation of the physical network infrastruc-ture. As we develop our site topology, sites are connected by links. WithinWindows 2000, sites are used to route query and replication traffic efficiently.

A site is a set of networks with fast, reliable connectivity. Essentially, itis a collection of subnets. A site link is a network that connects two or moresites that may have low effective bandwidth or intermittently available (de-mand dial) bandwidth. In many instances, these links are characterized bylow reliability.

DNS PLANNING

DNS planning is the most difficult and political area of a Windows 2000 ADmigration for large organizations. It is a paradigm shift. Many companies arestill stuck in a combination of current DNS and WINS support models. Keepin mind that many versions of Unix BIND do not support SRV resourcerecords. Of the ones that do, however, SRV support must be specified at com-pile time.

In Windows 2000, DNS is the preferred name system and is the DC lo-cator. The DNS server in use on a Windows 2000 network must support SRVrecords or things simply will not work. In addition DNS should support dy-namic update for proper AD support. Windows 2000 DNS server (of course)provides all the necessary support for AD.

DISTRIBUTED SECURITY PLANNING

Do not let planning for the implementation of distributed security delay yourmigration. Part of the problem can simply be unfamiliarity with distributed se-curity on the part of the implementation team. There is a tendency to delaythe migration, or to slow planning, until all participates come up to speed ondistributed security. This is not required: PKI can be implemented at anytime; Kerberos with Unix interoperability can be rolled out at any time; EFScan be turned off for the domain and deployed later; IPsec or L2TP/IPsec isnot required. In most deployments, these items are held for Phase II. Unlessthere is a compelling business reason, there are enough things to worryabout in a Windows 2000 migration without the increased complexity of de-ploying distributed security systems.

PRODUCTION ROLLOUT PLANNING

In the deployment phase, most large customers will implement their ADstructure first to get the biggest bang for the bucks. Smaller customers can de-

Relat ionsh ip of Namespace 25

ch02.qxd 11/5/01 12:00 PM Page 25


ploy clients first and then upgrade the network infrastructure and memberservers. For smaller networks, the deployment of AD seems to be the laststep in the migration.

Remember, domains cannot be renamed and the domain hierarchycannot be restructured. Domains cannot be merged or split after they are inplace on your Windows 2000 network. If you have to reorganize you willbe limited to moving objects. You will be able to do a bulk import and ex-port operation via ldifde.exe. In addition, you can use movetree for intra-forest moves. However, at best it will be rip and replace procedure. Inmany aspects it will seem like another migration. The moral of the story isin order to avoid all this pain, do the domain planning well up front, andstrongly resist any temptation to restructure domains after they aredeployed.

Decide in advance how you will break down system administration re-sponsibilities for your network, and even for a specific application. This plan-ning can influence the organization of your OUs. Identify early who will begiven administrative permissions. Remember that in Windows 2000 we canbecome very granular in assigning certain administrative permissions. It is abest practice to severely curtail membership in the administrative groups. De-termine what policies are going to be enforced on a user’s system; this willhave a direct impact on how group policy is applied. Make sure you identifyan education and training plan as well.

DNS Planning ConsiderationsSince DNS is the preferred name resolution method in Windows 2000, it isone of the most important aspects of a migration. In fact, nearly all problemsI have seen in the field with AD have stemmed from improperly configuredDNS either on the client side, or on the server. From a planning perspective,there are three namespace scenarios we will be confronted with.

Three Namespace ScenariosThere are three scenarios that may exist when designing the namespace.The first, and most common in a pure NT environment, is there is no DNSinfrastructure. If DNS is in use, it is only for Internet name resolution, andtherefore is hosted by the ISP. The second scenario, and one that is com-mon in heterogeneous environments, is that there is an existing DNS server,but it does not support SRV records. The last, and most rare, scenario is thatthere is an existing DNS server, and it supports SRV records. We will look at

ch02.qxd 11/5/01 12:00 PM Page 26

each of these scenarios below, and offer possible courses of action foreach.

NO EXISTING DNS INFRASTRUCTURE

If there is no DNS server on the network, then the solution is easy: Use theWindows 2000 DNS server. This has the advantage of simplicity, and it allowsfor secure updates and AD integrated zones (which simplifies replication).While these are nice features, the most important feature for us is the supportfor the SRV resource records that are used to locate domain controllers andother services. In addition, the dynamic update feature reduces administrativemaintenance.

NAMESPACE OVERLAP

AD namespace overlap occurs when you give AD the same domain name asan existing one. For example, if fullservice.net is the currently used domain,and it is also the name of the forest root, then there will be overlap. If there isoverlap, then we need to make sure we have adequate DNS coverage. If theexisting authoritative DNS server doesn’t support SRV records, then we haveto either upgrade the DNS server, or migrate it to the Windows 2000 DNSserver. If we upgrade our DNS server, then we simply point AD to it.

We can also migrate our existing DNS servers to Windows 2000. To dothis, we introduce a Windows 2000 DNS server into the environment, make ita secondary DNS server for the existing DNS namespace, and then do a zonetransfer. Next we make it a primary DNS server for the domain, and then wedecommission the old one. This works rather well, and is actually pretty cool.Later, we can make it an AD integrated DNS server. This is actually my pre-ferred scenario (and it really gets the goat of old Unix hacks—always anadded bonus!).

There is of course, another option. We can delegate the zones that con-tain the DC with the specific records to the Windows 2000 DNS server. DNSmanagement is often a political struggle; in order to avoid this pain, we cansimply delegate the AD specific zones to our new Windows 2000 DNS server.The zones we need to delegate are:

• _msdcs.fullservice.net• _TCP.fullservice.net• _udp.fullservice.net• _sites.fullservice.net

You can then AD integrate these four subdomains. This is, of course,much more complicated, and you do not want to do it on a wide scale, butyou can do it for the root namespace. It is a solution I have implemented fora few clients. Then we allow the Windows 2000 DNS server to operate for the

DNS P lanning Cons iderat ions 27

ch02.qxd 11/5/01 12:00 PM Page 27


SRV records. Of course, we still need an A record for the host parent, and ina large domain this could be a problem. In a smaller domain it can be doneby hand. You can then disable the A record creation on logon for the domainthrough the registry.

In summary, then, when the AD namespace overlaps with the existingnamespace, you have a few choices as to how to handle it. If the authorita-tive DNS server does not support SRV records, then you can upgrade theserver, migrate to Windows 2000 DNS, or delegate the zones that contain theDC specific records, to a Windows 2000 DNS server or other upgraded DNSservers. If, on the other hand, the authoritative DNS server supports SRVrecords, then you can either use it or migrate it to Windows 2000 DNS.

NAMESPACE DOES NOT OVERLAP

If the AD namespace does not overlap with an existing one, then the situa-tion is much easier. For instance, if fullservice.net is the currently used do-main, while the name of the forest root is internal.fullservice.net, then we donot have an AD namespace overlap. Here we simply delegate the AD name-space to the Windows 2000 DNS server that is running on the DC. This is aquick solution, and has been done many times. It solves the political problemof DNS migration, and allows both DNS systems to interoperate in the sameenvironment. The presence of this type of effective solution can also impactyour naming strategy of the root in the first place. Delegate the AD name-space to the Windows 2000 DNS servers running on the DCs. If, however, theauthoritative DNS server supports SRV records, then you can use it, or goahead and migrate it to Windows 2000 DNS servers.

There are other problems that can arise with the split environment: Forinstance you have an external view, and you have an internal view. The viewof the namespace from outside the network and from inside the network canbe different. One way to solve this problem can be to use the traditionalname on the outside, and change the suffix on the inside of the company.Maybe it is Microsoft.com on the outside, and Microsoft.net on the internalnetwork. This makes it easy for the proxy server to handle. Another way todo this is to delegate the namespace. If you do this, then the proxy server canhandle it as well. If you only have a few servers that are accessible from theoutside, then you may be able to handle the name resolution issues by creat-ing a few A records on the internal DNS servers.

BEST PRACTICE FOR DEPLOYING DNS

Based upon our discussion so far, in this section I have collected best prac-tices that have been hammered out in the field from dozens of deployments.While none are cut in stone, they are strongly recommended. As always, theactual solution is—It depends on the situation.

ch02.qxd 11/5/01 12:00 PM Page 28

1. Delegate a DNS zone for each AD domain to the DNS servers runningon a DC in that AD domain.

2. Match your DNS naming partition with AD domain partition.

3. Install a DNS server on at least two DCs in each AD domain.

4. Install one DC in each site. Make it AD integrated.

5. If different domains of the forest are connected over slow links, thendelegate the zone_msdcs.forestname and make the DNS servers inevery site secondary for this zone. If the root domain is small, then justdelegate the whole zone.

6. Make the child domain AD integrated, and a secondary zone for theroot_mscds.

7. Each client should be configured to query at least two DNS servers, oneof which is in the same site.

8. Domain names greater than 15 characters should be avoided to facilitateNETBIOS name resolution.

9. Keep clients in default domain.

10. Avoid CNAMEs.

11. Avoid A records in other zones.

12. Bind 8.2.2 is compatible. It supports dynamic update, SRV records, andincremental zone transfer. It can be secondary to MS-DNS, standardzone, and AD integrated zone.

13. When using AD integrated, and you want a non-MS secondary, thenpoint the secondary to go always to the same primary DNS for a consis-tent view.

14. If the entry on the SOA record fails on dynamic update, then Windows2000 will try other DNS servers for name resolution. Bind 8.2.1 doessupport AD needs in this regard.

15. If using bind, then you need to disable name checking to allow –ldapSRV records. Check the names master ignore box for the primary zone.Check the names slave ignore box for secondaries. Check names re-sponse ignore. For all others, you can use the defaults.

AD SizingLet’s now talk a little about the AD database. We will begin with an overviewof directory handling operations in Windows 2000 AD.

AD S iz ing 29

ch02.qxd 11/5/01 12:01 PM Page 29


OverviewWindows 2000 AD uses the extensible storage engine (ESE), which is thesame basic database engine used by Exchange. There are several files associ-ated with this process:

• Ntds.dit: The whole database• Log files• Edb.chk: The check files used to keep track of checkpoints• Temp.edb

AD runs as one process in Windows 2000, which is LSASS.EXE. Becauseit runs in a single process, there is only one way to stop AD on a server, andthat is to kill LSASS.EXE. If you do this, it will reboot the box, as you willhave no more security on the server.

There are only 2 tables in the AD database. These tables are the objecttable, which holds common objects and attributes such as users, printers, andthe like and the object table and link. For each of the common objects thereare columns in the object table. In the database, rows represent objects, andthe columns represent attributes of the objects. There are both fixed columnsand tagged columns. A fixed column means that we always know how muchspace the attribute will occupy. Fixed columns are only used for around 10attributes. These are attributes such as an index that will take up a pre-dictable amount of space. Most attributes in the AD database are taggedcolumns. Space is not reserved for tagged columns, as we do not know howmuch space the attribute will occupy.

The link table implements object relationships, such as linking usersand their managers.

FRAGMENTATION

Fragmentation is moving data in order to fill database pages more efficiently.There are two ways to deal with database fragmentation in the AD database.One is online defragmentation, which runs as part of a garbage collectioncycle that runs by default on a 12-hour schedule. Online defragmentation,however, does not shrink the size of the database file; rather, space is simplymade available for use later. This is the same way as it is in Exchange. Thebasic idea is that it requires a lot of processor time to expand the size of thedatabase file, and if it grew once, then it will grow again. Therefore, we canbe more efficient if we do not fool with shrinking the size of the databasefile. However, if you deleted 100,000 users for whatever reason, then whengarbage collection runs it will free up a sizable amount of disk space. If thoseusers will never return, then it makes sense to recover the space.

In order to recover disk space from the AD database, we will have toperform an offline defrag, the second approach. To perform an offline defrag,run the NTDSUTIL.EXE program with the appropriate options, and it will

ch02.qxd 11/5/01 12:01 PM Page 30

shrink the db file. To run the NTDSUTIL on a DC, AD has to be taken offline.To take a DC offline, you reboot into directory recovery mode. This is usefulafter converting a global catalog server domain controller into a normal do-main controller.

The garbage collection process is a housekeeping service that frees upspace in the AD database. There are several functions performed by garbagecollection. One is to tombstone the log files. By default, the tombstones arekept for 60 days to ensure recoverability. Garbage collection also performsdatabase defragmentation, as mentioned earlier. This occurs every 12 hoursby default but is configurable (although in most instances, the defaults seemto work well). One thing to keep in mind is that garbage collection runs oneach domain controller independently.

So what kind of sizes are we talking about with our AD database? Ofcourse it depends, but for ballpark purposes, we could expect an AD size of1.2 gigabytes for around 100,000 users with 30 attributes defined on each ofthe users, and machines with 8 attributes defined, and 10,000 groups with 4attributes defined. When we add Exchange 2000, then AD size will go up toaround 1.7 gigabytes for the same company. AD database growth is very pre-dictable.

HARDWARE PLANNING

In order to select the appropriate servers to run AD on, we need to look at afew factors. The first thing is to find the size of the company:

• Add objects: Print queues, contacts, more groups• Treat security principals like users (add 4,400 bytes per object)• Treat nonsecurity principals like contacts (add 1,700 bytes per ob-

ject)• For string attributes add 100 bytes/attribute. To be safe, then double

the estimated size. The database will grow, and there will be tomb-stones. It is better to overconfigure (and much cheaper) at the outsetthan revisiting the machine.

Best predictions are achieved when you get the profile of your AD ob-jects. Set up a replica of your AD schema on a test machine, and then fill inrepresentative objects with their accompanying attributes. Then make sometests with this profile to get best results for the enterprise. Based upon thenumbers you get from your tests, you will be able to come up with a very ac-curate prediction of the size of your AD.

Global catalog sizing is dependent on the domain design. Remember,the partial replica set in your schema from the other domains in the forest,the number of attributes defined, and group design all affect the size of yourglobal catalog.

AD S iz ing 31

ch02.qxd 11/5/01 12:01 PM Page 31


Do not forget to include directory-enabled applications in the figuresthat you derive from your calculations. For instance, Exchange 2000 will addnearly 40 percent to the size of information that needs to be replicated.

PREDICTING AD TRAFFIC

With AD traffic there are two main areas of interest: AD replication traffic andclient logon traffic. Replication traffic is affected by namespace design, andclient traffic is affected by the number of clients and the features set.

Replication intrasite uses DS-RPC (RPC over IP) and is not compressed.This means that while there is more network traffic generated, it does notincur a processor hit on the servers as they compress and uncompress thetraffic. On the other hand, intersite replication uses DS-RPC (RPC over IP)that is compressed. The compression that is utilized can achieve a 15–20 per-cent compression ratio over the noncompressed variety. However, this comesat the price of additional processor utilization on the servers as they compressand uncompress the network traffic. The idea is that the WAN bandwidth is amore scarce resource than processor utilization.

Intersite replication uses DS-RPC (RPC over IP) or ISM-SMTP (SMTP) forconfiguration and schema replication. When we are looking at the amount oftraffic that needs to be replicated, we can use some of these guidelines tohelp us create an estimate:

• Users: 4k bytes each• Global groups: 2k bytes each + 165 bytes for each member of the

group• Universal groups: 2k bytes each + 1.5k bytes

Group Policy ConsiderationsGroup policy resides within group policy objects (GPOs). They are createdwithin a domain, and can be linked to any number of sites, domains, and or-ganizational units (SDOU). They cannot be linked to a container: Users andcomputers are containers. Multiple GPOs can be linked to a single SDOU.

Group policy gets applied to the computer configuration when thecomputer starts. The user configuration settings get applied when the userlogs on, and are refreshed at periodic intervals. Group policy for clients andmember servers is refreshed every 90 minutes by default with a randomizedoffset of 30 minutes for load balancing. The domain controller’s policy set-tings are refreshed every five minutes. There are some portions of group pol-icy that are not periodically refreshed.

How do we determine where group policy comes from? Group policy isnot assigned to groups. Policy is inherited, and closer settings override onesthat are farther away. So it depends entirely on where the computer or user

ch02.qxd 11/5/01 12:01 PM Page 32

resides in the AD hierarchy (site − domain − OU). It is not like a systems pol-icy, as it really has nothing to do with groups.

We can modify the default inheritance settings with either the no over-ride option, or with the block inheritance option. The no override option is aproperty of the GPO itself. Any settings within this GPO prevent the childcontainers from overriding policies that may be set at higher levels.

Block inheritance, however, is set at the container level. It prevents in-heritance of all policies from the parent container. The highest no overridesetting will take precedence over lower no overrides. No override takesprecedence over block inheritance. So as a domain admin, then your settingson a GPO will take precedence over settings that are made by a delegatedadmin of an OU.

But what if an OU is linked to multiple GPOs? Then the higher GPOsoverride the lower level GPOs. Group policy objects are processed in the re-verse order listed on the tab. You can change the order of processing withthe up and down button.

What if you don’t want everyone in an OU to be affected by a GPO? Re-member, you cannot link a GPO to a security group. You can, however, filterGPOs by changing the default permissions on the GPO by using securitygroups. You need to have the read and apply GPO ACEs to have a GPOapply. You need read and write in order to read or modify a GPO.

If you do not have read permission, then you cannot see the policy;therefore, it will not be applied. In order to filter out a policy from a higherlevel, remove the apply permission, and it will not apply to them. If you wantadministrators to be able to modify a particular GPO, then you must givethem write and read permission to that GPO.

Default permissions to group policy are that authenticated users getread and apply. Local system, domain admins, and enterprise admins by de-fault get all permissions except apply. However, remember that admins areby default members of authenticated users. In order to exempt admins from aparticular GPO, then you must remove the apply permission from them.

So, where is GPO information stored? First, we need to understand thatthey are not real objects; they are virtual objects. They are, however, made upof two real objects: the group policy container that is located in the AD and thegroup policy template that is stored in the sysvol policies folder. The group pol-icy container stores the version, status, and policy information. Unfortunately, itis named by a guid, and not a “friendly” name. The sysvol policies folder storespolicy information and is also named by a guid, and not by a friendly name. Thegroup policy container and the group policy template are replicated separately,as they are in different locations. Containers are replicated using AD replication,and templates are replicated with the file replication system (NTFRS). Individ-ual policies will only be applied if both objects are in sync. The exception to thisis IPsec, which is stored only in the template, not in the container; thereforethere is nothing for it to be in sync with.

AD S iz ing 33

ch02.qxd 11/5/01 12:01 PM Page 33


The group policy container has to be viewed with ADSI edit. In order tofind the group policy container, you need to navigate to the domain namecontext, DC, system, policies section.

DELETING A GPO

In order to delete a group policy object, you need first to remove the link. Youcan remote the link while keeping the policy intact. If you keep the policy in-tact, then it is available for reuse later. If you prefer, you can permanently deletethe GPO. The unlink method is preferred, because a deleted group policy ob-ject must be completely rebuilt if you decide you want to redeploy the policy.In addition, other AD containers might be linked to the group policy object andyou would hose things if you removed the GPO without first checking to see ifit was in use in other locations in the directory.

Be careful when deleting GPOs

Windows 2000 is perfectly content to allow you to delete a GPO that is still in use. Nowarning messages are generated. Ensure that a GPO is not in use prior to deleting it.

The bad thing about this is that there are no error messages generated ifyou delete a GPO that is in use in other places. This is doubly bad becausenormally Windows 2000 is very good about generating warning messages,and consequently many administrators are becoming sloppy in their work. Itis as if they think, “Windows 2000 will tell me before it allows me to make amistake”—and normally it will; just not in this instance. However, all is notlost, because you can check to see if the GPO is in use. All you have to do isto look at the properties of the group policy object, and go to the links tab tosee what they are linked to.

Deployment Scenario GuidelinesNow let’s look at a few guidelines for deploying group policy. Perhaps themost important design principle I can give is to follow the AD planning rec-ommendations. We want to set up OUs based on the delegation of the con-trol model. If it does not meet our needs entirely, then we add OUs as re-quired for desktop management and other purposes. There are multiple typesof OU structures, which we are likely to deploy. These are discussed in thesection below.

FLAT OU MODEL

The easiest model to deploy, and the most prevalent OU model, is the flatOU model. A flat model, perhaps one to two levels deep, is the simplest to

ch02.qxd 11/5/01 12:01 PM Page 34

design, and the easiest to implement. The flat structure is typical of small ormedium-sized organizations (SMORG). The flat structure is used to minimizethe use of block inheritance, and override. In the flat OU model, there is verylimited use of security group filtering through the use ACLs. When the ADnamespace is flat, then the primary method of a flat OU model is to link theGPOs to domains or to the OUs. This allows us to keep it really simple. Anytime we are modifying inheritance, we are introducing complexity and mak-ing troubleshooting more difficult.

NARROW OU MODEL

The narrow OU model will typically nest OUs three to five levels deep. Nor-mally, this type of structure will work out well for medium-sized organiza-tions (MORGs). Because MORGs do not normally have the wide internationalorganization typical of a large company, their directory structure will not beas wide. However, due to their size, they will have all the normal levels ofcomplexity found in a large company—just not to the same extent. This willcause the OU model to be rather deep, but not as wide as that of the largercorporate organizations. As we begin to go deeper with our OU structure, weneed to begin looking at ways to fine-tune the application of group policy. Inthe narrow OU model, the primary method of GPO deployment is to linkGPOs to OUs as needed. The secondary method is to use block inheritance,enforce or ACLs as required to fine-tune the application of group policy.However, it is wise to moderate use of these types of approaches. The bestway to approach a narrow OU model is to use the OU location in the activedirectory to determine the placement of the GPOs.

DEEP OU MODEL

In contrast to the other two principal types of OU models, the deep OUmodel typically has more than five levels of nested organizational units. Thisis the model most often found in large organizations (LORG). Due to thecomplexity of their organizational charts, and their complex reporting re-quirements, LORGs are often forced into intricate, deeply nested organiza-tional units. In fact, just as large corporations do not have one type of report-ing structure, they do not have one type of OU model. In fact, we willtypically see a combination of flat, narrow, and deep OU structures at workin the LORGs.

In a deep OU model, we will use GPO placement to enforce group pol-icy by linking the policy to specific organizational units; but we also will haveto use security filtering to effect the desired outcomes. While we can useblock inheritance and enforce, it behooves us in a deeply nested OU modelto minimize the use of multiple methods when controlling the application ofgroup policy. In a deep OU model, things are complicated enough withouthaving to search through multiple methods of group policy application.

AD S iz ing 35

ch02.qxd 11/5/01 12:01 PM Page 35


Therefore it is best to use as few methods as are required for correct imple-mentation.

BEST PRACTICE

There are several layers in the AD structure that must be considered whenworking with group policy. These scopes are listed below.

• Domains• Multiple domains (if present)• Sites

The question then is, how you want to deploy GPO, and how you aregoing to manage them. These pointers will help:

• Remember that sites are enterprise wide. If you have a site with mul-tiple domains, and you link GPO to the site, then it affects everyuser and computer in the site—including multiple domains.

• Remember that sites are enterprise wide, but GPOs are stored on aper domain basis. By default, only enterprise admins can create ormodify a GPO that is linked to a site.

• What happens when a site is linked to an existing GPO? Now it be-comes possible for nonenterprise admins to make changes to theGPO. In addition, you need to look at the topology and the locationof domains and the domain controllers.

• There is a risk of creating an across-the-WAN fetch of a GPO forcomputers and users. The default when you create a GPO at the sitelevel is it is stored in the forest root domain. You can, however,modify this behavior by pointing it to a different domain.

• Don’t link existing GPOs to the site. If you want to link a GPO to asite, then create a new GPO. This is because it would allow a down-level admin (who owns the GPO) to affect the entire site by modify-ing a GPO that he or she owns.

BEST PRACTICE FOR DESKTOP MANAGEMENT

When you use organizational units and group policy objects for desktopmanagement, often you will need to control the way the GPOs are applied.In a large organization, this can be quite complicated. Here are some of theways you can control the application of group policy to manage the desktop,listed in decreasing order of preference:

1. Use the existing structure.

2. Modify the existing structure.

3. Add and/or split existing OUs.

4. Use block inheritance.

ch02.qxd 11/5/01 12:01 PM Page 36

5. Use a combination of block inheritance and enforce.

6. Use filtering.

Note: Limit mixing multiple methods in any single tree.

Design Models

• In a layered GPO design: Create GPOs as high in the tree as possibleto contain domain-wide settings. Then let subadmins create specificGPOs for their area. Therefore a specific setting will be in as fewplaces as possible. The trade-off is more GPO, which will add totime of logon. This is always a tradeoff.

• Monolithic GPO design: Create one as high as possible, with every-thing in it. Great performance, but very limited control, unless youuse block inheritance, and filtering.

• Single policy type of design: Reflects the different modes that are in aGPO. For each of these nodes, will use only one GPO. One forcomputers, one for software, one for scripts. Downside, length oftime to process this many GPOs will increase the number required.

• Multiple policy type of design: A little more delegated. Want to createthe GPOs as high as possible, then delegate the control at the OUlevel. Is useful for small orgs. Cuts down on amount of filteringbased on ACLs.

• Functional role: If OUs are based on function then only GPO ap-plies to each OU. Then have subadmins create specific to the users.Settings are tailored to needs and people in the OUs. This is a goodcompromise between administration and performance and is aneasy model to delegate to subadmins.

Team DesignVirtual teams: It is more and more common to create a virtual team for spe-cific projects. One may want the virtual team to have a common GPO appliedto them. All those people already have accounts in different groups and OUs.If a team has people from different OUs then there will be a need to makeextensive use of filtering. Take the people and create a security group, thenput the GPO high enough in a tree so that it applies to all the team members;only give that group permission to apply the GPO.

User and machine-specific design: Group policy is divided into user andcomputer configurations. All computer settings are in different GPO than thespecific users’ settings. If a GPO contains only user-specific stuff, then we candisable processing of the computer portion of the GPO, and vice versa.

A public computing environment: Requires users from all over organiza-tion to use common computers. We want to control what that desktop looks

AD S iz ing 37

ch02.qxd 11/5/01 12:01 PM Page 37


like. Suppose we have a kiosk mode. If a user from payroll logs onto thekiosk, they will get different settings. The solution here is to use loop-backprocessing, which says, forget the user settings—process only what applies tothis particular computer. This allows us to take the user settings from thekiosk OU. Normally we would ignore the settings for a user from a differentOU, but this allows processing user settings from that particular computer. Ifwe merge settings, then we combine. If we replace, then ignore the user set-tings from the different account, and process from the kiosk OU.

GROUP POLICY DELEGATION MODELS

We first need to decide how to delegate control of the GPO. There are reallytwo models: centralized and decentralized. In centralized the domain adminhas as much control as possible. The idea is that it will need to use no-override settings quite a bit. In centralized, do we want lower admin blockingyour settings from the higher level?

Distributed control: We want subadmins to have as much control aspossible, but still force out company-wide policy. Use both no-override andblock inheritance. There are still certain domain level policies we need toconfigure.

Use common configurations to lower desktop TCO. Driving costs forTCO: Not all users are knowledge workers. In a typical enterprise, there arehigh performance users (it actually hinders their job when we control theirdesktops), knowledge users, mobile users (we may need ability to installprinter drivers), process users (task oriented; run one or two LOB or produc-tivity apps; don’t need much control over their own computers) and dataentry users (we can really control here).

For most users, computers are simply tools to get another job done.Users spend too much time supporting themselves and each other. They tendto putz around doing things they do not need to do. The solution is changeand configuration management. One image does not work for everyone.

Group policy scenarios are the replacements for ZAK. This ships as aWindows 2000 installer package. It defines six common configurations; it in-cludes prebuilt GPOs and scripts to load the GPOs into active directory. Weonly need to link and modify to suit environment. Run loadpol.bat to loadthem. The six modes are:

1. Kiosk: Public workstation where we want only one application to run.No desktop. Actually uses Internet Explorer as the shell.

2. Task station: Originates from the ZAK kit. Similar to kiosk, and we wantto run maybe one or two apps, save documents, and settings persist.Good for factory floor.

3. Application station: More apps available. Simple start menu. Marketingor finance department. Use four or five apps. Settings persist.

ch02.qxd 11/5/01 12:01 PM Page 38

4. Public computing environment: Different users use this, and configure.When a user logs in, the apps are published to them (university lab, li-brary). Students’ need for class-based apps. Apps are assigned to thecomputer for common base, and then other apps are assigned to the in-dividual through group policy.

5. Knowledge worker: We don’t want lot of control here—it actually mayhinder. However, we want to manage certain parts of environment.Works for knowledge, mobile, and even super users. Use a group pol-icy to publish software. Still use GPO, but to ease administration.

6. Laptop: Two types—road warriors, and the ones who occasionally takeit home to work. Do we assign software all time, or when we are wellconnected?

There are GPOs for each computer and user settings.

THE TECHNOLOGIES

• Group policy• Administrative templates• User data and settings: roaming user profiles and folder redirection• Software installation and maintenance: publish and assign• Remote OS installation: RIS• Security settings• IE maintenance settings• Planning guidelines• Things to think about• Scope of management• Usage of group policy• Design flexibility• The AD structure: users’ and computers’ OU structure. Cannot plan

in a vacuum: need a good understanding of the entire technology.

Performance: Will users tolerate a five-minute wait?

• Keep it simple: Consider the highest TCO issues, and then usegroup policy to address them. The quicker we can show ROI, thebetter.

• Major areas to consider for bang of buck• Desktop management: Registry settings, OS and components, appli-

cations, security settings, folder redirection• Software installation• Scripts• Management model: Centralized, delegated, or both. Delegation of

administration (who can create GPO, who can link GPOs, or who

AD S iz ing 39

ch02.qxd 11/5/01 12:01 PM Page 39


can simply modify), separation of admin duties. Design for flexibility(don’t lock yourself in).

• Delegation of administration: Restrict to as few administrators aspossible the ability to write to GPOs. Use the security tab (ACL edi-tor). The group policy snap-in will not open a GPO that the currentuser does not have write permission to. All current extension snap-ins to gp assume they have write access. Use MMC policies to re-strict certain snap-ins to those administrators who need them.

TIPS FOR SUCCESS

• If using delegation model, then put the GPO there. Leverage the ADand associate GPOs at the level of delegation (typically lower in thetree).

• If AD is flat, then delegation may not allow the granularity desiredfor gp. Use security groups and ACLs to filter the effects of GPOs.

• For performance, limit the total number of GPOs that a given com-puter or user will have to process. Use ACLs and security groups toachieve this design goal.

• Keep it simple: To ease management limit the use of block inheri-tance, enforce, and cross-domain GPO associations.

• When these must be used, avoid using more than one at a time.Each one adds complexity.

DESIGN TIPS

• Disable unused portion of the GPO. Use revision number for user ofcomputer as a hint to its usage.

• Limit how often group policy is updated. Each update will require areplication among all DCs.

• Limit the number of administrators that can edit GPOs.• The scope may be huge. For example: Think of GPOs as regedit for

AD. Application installation and removal for users and computers.Security: Set file system ACLs for thousands of users and computers.

• Use test GPOs first. Make sure you know what the effect will befirst.

• Use the group policy infrastructure for modifying all GPO ACLs.• Whether for filtering the effect of a GPO, or the delegation of ad-

ministration.• The group policy infrastructure handles the inherent differences be-

tween the AD and the file system (sysvol) ACLs. Individually modify-ing ACLs on objects or files that group policy uses may result in un-predictable and undesirable results.

• In general, group similar settings in a given GPO.

ch02.qxd 11/5/01 12:01 PM Page 40

A GPO that publishes Office 2000 should include the registry-basedpolicies for it as well. Monolithic GPOs contain settings for all or many of thepossible snap-ins. There is fast performance and fewer GPOs to process, butdelegation is harder to do; it contains divergent settings. Segmented GPOscontain settings only for an individual snap-in. This requires more GPOs,which will impact performance, but it is easier to delegate.

Domain Design ConsiderationsIn this section we look at some principles of domain design.

AD Designs• Put users into a user’s OU, and then you can assign them group policy.

Maybe do users, machines, and printers and assign group policy.• For remote branch offices, maybe create a branch office domain,

and then you can isolate them from a lot of the replication traffic.• May very well need country domains due to differences in laws and

stuff.• With your OUs, follow your support structure. Can just move con-

tainers around, and do not have to re-ACL, and not redo a lot.• Can rename, reorganize.• All divisions have no more than 3–5 OUs in depth.• If the division is sold, then you can use scripts.• The OU structure follows the support structure (still keeping shal-

low, but deep enough that you will be grouping accounts instead ofhaving a flat user list).

The delegation is used at OU, and ACLs and security groups handle ex-ceptions.

• OU-users: Change sales password group—allow• User—manager: Change sales password—denied• User—manager: Change manager password—allow

Windows 2000 can support 23 languages, and 128 dialects out of thebox. It can also name the machine in local languages, Kanji or simple Chi-nese. Windows 2000 DNS supports Unicode-based characters. It all insertsinto the directory.

What is the support structure? Does it support Japanese? Make sure sup-port staff will be able to find the machine, and the OU. On these, servers canship international English, and install all the language packs, and then thedisplay will appear in English when the support remotes into the machine.You can also install the MUI pack, which allows you to change the tool bars

Domain Des ign Cons iderat ions 41

ch02.qxd 11/5/01 12:01 PM Page 41


of the operating system. It will also change the help files into the local lan-guage. You can use international English when remoting in to a server inFrance, but the local machine is in French. France will not buy an English ap-plication (particularly if it is government).

If you purchase international English, and add the multilanguage userinterface (mui), is one service pack. But if you purchase a localized language,then it is a different service pack.

DEPLOYMENT CONSIDERATIONS

• Number of domains• Domain controllers and GC placement• Amount of data to replicate• Language• Encryption laws• Telecommunication designs• Any political issues• Review current and future support structure, company, divisions,

and departments (help desk, data access, etc.)• Review international requirements• Review current and future telecommunications designs for WAN

support• Best design includes helpdesk, Human Resources, and security in

same room. HR should know the international considerations

INTERNATIONAL CONSIDERATIONS

You cannot just do one domain if international. If there are 300 to 600 sites,Windows 2000 has problems with the KCC: One is for intra, and one is forinter. KCC is responsible for when and how to do this. On inter, it will go outand look at the container, go and see size of the pipe, and dynamically builda replication cycle. If you change phone numbers, or a backup link comesup, then it will change dynamically. The replication cycle is 15 minutes bydefault. If it has to talk to 300 servers or so, it will have trouble talking to all300 in 15 minutes. It uses default 445 new SMB interface; the same type ofthing is used to determine a slow link from the desktop. There are no specialprotocols to monitor. It can use intra KCC alone, and uncheck the automaticinter KCC. Then build the site connector from remote sites, and assign coststo it. It can manually load balance, and provide alternates. But you do notwant the alternate to be the same for all. There are some vbscripts you canuse.

ch02.qxd 11/5/01 12:01 PM Page 42

Using a Single DomainThere are several good reasons to choose a single domain when planningour Windows 2000 migration strategy. These include:

• Flexibility• Easier delegation• Ease of management• Fewer domain admins• Object capacity is the same as multiple domains• Less planning

AD is very flexible, much more so than the NT 4 domain structure. Oneof the elements that contributes greatly to this flexibility is the OU. An OU isreally nothing more than a container within AD that allows us to organize el-ements such as users, groups, and computers. We can, by using OUs, divideour organization into a combination of departments and geography. There isreally no right answer to the organization question in Windows 2000. Thepath we choose is solely dependent upon administration needs, and politicalconsiderations. Perhaps one of the more common implementations is to di-vide things up along departmental and geographical lines (see Figure 2–1).

If our departmental structure or geographical organization changes inthe future, then it is really easy to move objects from one OU to another. If,for instance, our company decides to consolidate its sales efforts, then wesimply move the sales OUs from their geographical counterparts in Figure2–1 to a new sales OU that we created in AD (see Figure 2–2).

If we have a user or group of users that move from one location in theworld to another location—for instance, our company decides to close downa regional office and transfer everyone to a new centralized office—then allIS needs to do is to select the users, right click on them and select move fromthe action menu (see Figure 2–3). If, however, the users were in a differentdomain, then we would have to go through a domain restructuring (read do-main migration) in order to save the accounts and associated ACLs. This is amuch more complicated scenario, and a very good reason for developing asingle domain model in Windows 2000. Even with domain migration, we aremuch more able to handle this scenario than we were in the NT world. Soour goal in designing a Windows 2000 network is to create an infrastructurethat is very flexible, one that will both grow and morph with the dynamic en-vironment of today’s business needs.

EASE OF DELEGATION

In a single domain model, we can easily delegate control to the various OUsin a very granular fashion. We can also limit the membership of the domainadmins group. Since domain admins can take control of every object in the


ch02.qxd 11/5/01 12:01 PM Page 43

Figure 2–1 By using OUs, we can divide our company into a combination of de-partments and geography.

Figure 2–2 If our company restructures, then it is very easy to move objects aroundin AD. In this diagram, we consolidated all our sales efforts into a sin-gle OU.


ch02.qxd 11/5/01 12:01 PM Page 44

domain, and have greatly enhanced power in the domain, we want to controltightly who is a member of that group. By using the OUs, we can delegatecontrol down to the lowest level in our organizational structure. One nolonger needs to be a domain admin to be able to create users, and assignpermissions. We will delegate administrative control to the down level groupsso that we have a decentralized environment. Of course, delegation of con-trol can occur at any level in the AD hierarchy—domain, site, OU, object, andobject attribute level—but it is generally a best practice to delegate at the OUlevel.

EASE OF MANAGEMENT

From a management perspective, a single domain is a lot easier to control.There is only one strategy to plan for administration, security, and support. Witha single domain, all of these functions only have to be done once. This can saveyou a ton of time, as much of the time for a Windows 2000 migration is spenton the planning side of things. If you have multiple domains, then you have tocreate administration, security, and support plans for each domain. This cantranslate into a very complex and unwieldy scenario. It is very important toquestion critically for multiple domains, as there are huge benefits in fitting intoa single domain strategy. There is less hardware to purchase (fewer domaincontrollers); this will lower licensing costs, and means less downtime and fewerupgrades. Each domain will require at least two domain controllers, which


Figure 2–3 In order to move users from one OU to another, we simply right clickon the users affected, and select move from the action menu.

ch02.qxd 11/5/01 12:01 PM Page 45


translates into more down time for upgrades, service packs, and those kinds ofthings. It is true that when compared to multiple domains, you will more thanlikely have bigger machines for single domains; there will be less labor involvedin maintaining fewer servers. There are no trusts to maintain, as it is a single do-main. I ran into one client that had a full time administrator whose main func-tion in life was to maintain trusts among their highly distributed NT 4 domain—talk about an exciting job! In a Windows 2000 environment, that administratorwill get to do something else.

There are fewer numbers of domain admin groups in a single domainmodel than in a multiple domain model. This means there are fewer domainadmin groups to monitor and to keep an eye on. In general, you want toplace a very select number of individuals into the domain admin group, andthen all the other network administrative types are delegated authority at ei-ther the site or the OU level of the hierarchy.

The directory information tree can hold four billion objects. It does notmatter if it is single domain, or multiple domain; a forest can only hold fourbillion objects. For the global view of all these objects, we look at the globalcatalog server. It holds a copy of all the objects in the forest, and a subset ofthe attributes. So what we are concerned about is the size of the global cata-log server, which is a function of the size of the forest as a whole—not thenumber of domains, or the number of trees we have in the forest. So if wehave more than four billion objects then we will have to have more than oneforest. However, it is highly unlikely that a company would reach the four-billion-object limitation.

LESS PLANNING

In a single domain hierarchy, you still have to do a lot of planning, but it isonly done once. This translates into the following advantages:

• Simplified namespace planning• Simplified DNS design• Simplified forest design• One delegation of administration plan• One group policy plan• One security policy plan• One OU hierarchy plan• Simplified maintenance and support plan

Using Multiple DomainsSince we have spent the last few pages harpooning the multidomain modelfor your forest design, let us now look at some of the reasons you mightwant to implement multiple domains in your forest. Remember, when design-ing for multiple domains, there is a very real cost associated with each addi-

ch02.qxd 11/5/01 12:01 PM Page 46

tional domain. These costs come in the form of money for server hardwareand software, management overhead, and increased risk due to complexity.So what we are looking for in the design phase are compelling reasons—jus-tifiable business reasons—such as cost justification and administrative require-ments. There may be legal reasons that require multiple domains, while inother situations, there may be a simple management inclination due to a lackof understanding of how security in Windows 2000 actually works.

There is a need to shift the paradigm from the way things worked in NT4. Then we needed to create divisional domains in order to restrict adminis-trative control, or to delegate control. In addition, if we had a decentralizedadministrative model, it required multiple domains. If we wanted to ensurethe availability of PDCs due to a distributed environment and slow WAN linkswe also needed multiple domains. If the link was unreliable, we would createseparate domains, to make sure the domain was available for our users to beable to change passwords, or for administrators to update access to resources.In Windows 2000 with AD, any domain controller can accept passwordchanges; we are much more reliable across slow WAN links. In NT 4 therewere size limitations of around 40,000 objects in the SAM database. In Win-dows 2000 we can have 4 billion objects in AD so there are not the same sizelimitations we had in the old days. For some large international organizations,language was a problem in NT 4. We did not have multilingual versions avail-able. In order for administrators to work with a Japanese version of NT, it hadto be in a different domain. With Windows 2000 we have multilingual ver-sions. So Japanese administrators can make changes to AD in their native lan-guage, and US administrators can do the same. Since these changes arestored in Unicode, the underlying support is the same.

When add domains are due to political reasons, you have a very realproblem. These domains are the ones most likely to change, as the politicsare constantly shifting. Companies get bought out, or there are mergers, de-partmental lines fluctuate; all of these conditions combine to create a mess.Often, when politics come into play, you are not dealing with the right peo-ple. Political considerations are the most expensive, as they are unnecessary,and do not add value to the overall Windows 2000 design. Combine this withthe fact that these are also the areas most likely to change; it behooves thedesigner to attempt to find ways around these often-inane considerations. Ifsomeone simply wants control of users, hardware, or security, then the Win-dows 2000 AD design can accommodate those concerns without incurringthe added expense of additional domains.

Domain administrators can take ownership of any object in their do-main; they can take control of resources. It is not a good idea to create a sep-arate domain to restrict access to objects because I can take that ability awayby removing their right to take ownership of AD objects. This is not a validreason for creating additional domains. We can control who can take owner-ship of AD objects and resources.


ch02.qxd 11/5/01 12:01 PM Page 47


Then what are some of the real reasons for creating additional domains?For one thing, if we want to create distinct domain level policies, we will needan additional domain. For instance, if we want to have a domain level policywith different password lengths, expiration dates, account lockout, accountlockout length, and user ticket lifetime, then we will need additional domains.This is a carryover from NT 4. These kinds of things are still with us. For in-stance, if you want the most users to have a rather lax password policy, and youhave a division that requires higher security (perhaps the engineering, or re-search and development, departments) then you will need to create an addi-tional domain for them. Account policies cannot be applied through group pol-icy; they are specified at the domain level. In order to have separate accountpolicies, you must create additional domains. Do not be confused by this: Youcan set account policies at the OU level, but nothing happens.

There may be compelling business needs. For instance, there may be legalrestrictions that need to be implemented through different domains. These maybe banks, financial intuitions, military organizations, and the like. You can pro-vide legal boundaries and security boundaries by implementing multiple do-mains. There may be requirements to maintain multiple namespaces.

A DEDICATED ROOT

The dedicated root is the first domain in the forest. It is empty. There is noth-ing in it except for the domain controller objects that you place there, the de-fault group and user accounts, an operations master or two, a couple of DNSservers, the global catalogue server, and the forest-wide administrativegroups. Forest-wide administrative groups are enterprise-wide admins andschema admins. These two groups have forest-wide administrative power.These are very powerful, and so you want to make sure the wrong people donot get put into them. Members of the domain admins in the forest root de-fine the membership of enterprise admins and schema admins. A domainadmin in the forest root can determine who controls the forest. While thismay seem a little scary, the solution is actually very simple. You set up anempty root to the forest. It’s the first domain you create in the forest. Onebenefit of this is it never becomes obsolete. In Windows 2000 you cannot re-name domains without uninstalling and re-doing everything because you loseall of your objects. So this solution is actually pretty elegant. There is a lot ofcomplexity surrounding this. It is very important to make sure that whateverdomains you do define are well thought out, and designed in such a way sothey do not become obsolete. A dedicated root, because there is nothing re-ally in it, is simply a placeholder; therefore, it does not become obsolete.

Use of Additional DomainsAnother reason for creating additional domains is to optimize replication. In-side our domain, we are replicating all objects and their associated attributes

ch02.qxd 11/5/01 12:01 PM Page 48

to all domain controllers in the domain. If the domain spans a wide area net-work that is connected with slow, unreliable links then it could cause prob-lems. Simple directory replication could bring the link to a crawl, and pro-hibit users from accessing a critical line of business applications. Betweentwo domains, however, replication is a lot different. The only things that arereplicated are changes to the global catalog, changes made to the configura-tion container, and changes made to the schema. There will be few changesmade to the schema and to the configuration container. The only reason theschema would change would be if you installed a schema aware application(such as Exchange 2000). The configuration container should stabilize oncethe forest is installed and all the domains are set up. So, most of the trafficwould be global catalog traffic. Therefore, you could just create sites, insteadof multiple domains.

There are some limitations. For instance, while sites allow you to sched-ule when replication occurs, doing this does not modify the number ofchanges that must be replicated. We must use domains to control the amountof traffic that is replicated. If we simply need to control when replication oc-curs, then we can use sites to make sure that replication does not occur dur-ing times of peak link utilization. Of course, the down side to this is currency.By delaying our replication traffic, we can cause users to have out of date in-formation. Just because we have slow links does not mean that we have tohave multiple domains. In order to make an intelligent decision about this,we have to look at both reliability of the link and net available bandwidth—not just bandwidth, but how much bandwidth is available at the time weneed to do replication. It is entirely possible that by scheduling replicationbetween sites at a time when the link is underutilized, we can avoid creatingan additional domain. We can use the AD Sizer to assist us in making thesecalculations. We can also use REPLMON.EXE to work with replication.

Another reason for using multiple domains is for separation or controlof affiliate relationships with other companies, such as might arise out of ajoint venture. This provides users in other companies with access to internalresources in a cohesive and secure manner. Of course, we could achieveabout the same thing by creating a separate OU and then delegating adminis-trative control to it. However, for internal business reasons, we may wish tocreate a separate domain to allow for greater isolation and administration. Ifthe company has the money to spend on a couple of extra servers, then thisis a very acceptable solution. It allows us to isolate administration and pro-vide security (see Figure 2–4).

If we want to restrict administrative control in a high security environ-ment, then we may also wish to consider an additional domain. When itcomes to file resources, file shares, and NTFS permissions that have been as-signed—we cannot take these away from domain admins. AD permissionsare different than NTFS permissions. NTFS permissions are stored in the filesystem, and cannot be controlled through AD: They are two separate things.


ch02.qxd 11/5/01 12:01 PM Page 49


So, if we have really confidential information, and the company is really con-cerned about controlling access and protecting from domain admins, then itmay make sense to create a separate domain. Of course, we need to say, “Itdepends.” There is no single right answer.

Let’s look at the cost of adding additional domains. There are more do-main admin groups that need to be monitored. There is more hardware thatmust be purchased, there are more trusts to manage, and there is the in-creased chance that objects will have to be moved. Moving accounts and re-sources around in multiple domains takes a lot of planning, and there is agreater chance of impact end users. Remember, end users are the reason forproviding network resources in the first place. Group policy cannot flowacross domains, nor can I make delegation flow across domains; therefore,access control management is more complicated and more labor intensive.There is a greater chance of errors when you increase the complexity of ad-ministration. In addition, the DNS infrastructure will need to be more com-plex as well.

There are some restrictions that we need to be aware of in consideringto add additional domains:

• Cannot rename the domain.• Cannot create a parent to an existing domain.

Figure 2–4 Use separate domains to provide for control of relationships with othercompanies.

ch02.qxd 11/5/01 12:01 PM Page 50

• Cannot remove a domain that has children.• Cannot easily merge or split domains.

One huge potential problem is that rogue departments could begin theirown implementation of Windows 2000, and not take into account the com-plexity of the product. Then all of a sudden, users cannot get to their data,computers cannot resolve names, and servers start going down. One way toget around this is to create a new domain, give it the correct name, and thenmove those accounts over to it.

When you create a new domain, and it is the first domain in the forest,then it becomes the root of the forest. You cannot create another domainabove it: It is the root. By the same token, even if you go down the tree, toany level in the organization, you cannot create a parent to an existing do-main. This highlights the need for well thought out planning, and the need tohave a drawing or a diagram of the desired end result. It must take into ac-count existing needs and future expansion plans. This is one migration thatthe IT department probably will not be able to complete entirely on its own.Upper management must be brought into the planning process.

STRUCTURING THE DOMAIN

In view of the restrictions that were listed in the previous section, it is incum-bent upon us to make sure we plan the structure of our domain in advance.To this end, we will look at several items that we need to take into accountduring this process: creating an OU hierarchy, creating OUs to facilitate dele-gation, group policy considerations, and combining delegation and grouppolicy.

OUs can be nested; this allows us to create a hierarchy. Then we canapply group policy and allow it to flow completely through the hierarchy, orwe can apply group policy at every level in the nested structure.

OUs, however, are not security principles. This means that they cannotbe directly assigned permission. Security principles in Windows 2000 areusers, computers, or groups, but not OUs.

Users will not navigate the OU structure. There are two ways the userswill actually see the OU structure. One is if they go into my network placesand get to the directory icon. There is really no reason for end users to go tothis trouble if AD is properly implemented. It is much better for a company tohide this icon from the users, as they do not need to be confused by it; thereare better ways for them to gain access to resources.

The other way users would see the OU structure would be if they actu-ally installed the administrator tools. However, if security were properly im-plemented, the end user would not be allowed to use these tools on the net-work. End users do not come into the picture when the OU structure iscreated. OUs are for delegation, grouping objects, and group policy adminis-tration—it is for network administrators, not for end users. Administrators are


ch02.qxd 11/5/01 12:01 PM Page 51


the ones we worry about when creating the OU hierarchy. End users will betaken care of through many of the new tools and features we will make avail-able to them; the OU is not one of them.

Creating OUs for delegation involves several areas of attention:

• Change container properties.• Create, change, or delete objects.• Update object attributes.• Create new users or groups.• Manage an object class or an object class attribute.

Delegation can be applied at the site, the domain, or the OU level. Youcan allow a user to create user objects only in the OU. They do not have tohave the ability to modify the user attributes, only to create. When devisingthe delegation scheme, break it into small pieces. There are different strate-gies we can use for this. We can create task-based administrators to resetpasswords or to manage printer queues. There can also be object-based ad-ministrators. These admins may have control over a specific OU. Grant theability to reset a password at the highest level of the OU. This keeps youfrom having to dive into multiple levels for troubleshooting. Create OUs tosupport administrative needs or models. OUs can be based on location, de-partment, or resources. This makes delegation easier, and makes group policyeasier to implement. Centralize first level OU support. Grant administrativecontrol at the OU level. Security, if you are delegating at the OU level, thenall the objects at the OU will inherit. Document how security is applied. Thiscan be very complicated when there are 14 different group policies, sharelevel permissions, and NTFS permissions.

Design WalkthroughIn this section we will walkthrough the development of a design.

SERVER HARDWARE EVALUATION

One of the first steps that must be completed before actual deployment is aphysical hardware evaluation. Proper planning at this level can pay great div-idends in helping to ensure a successful migration. This comes into play inseveral arenas. For instance, it can help you to make sure your project comesin on budget. You do not want to be in the middle of your deployment andrealize you do not have enough RAM in your servers. This would cause youto stop deployment, run out to the store, and buy a few hundred GB for your50 servers. In addition to putting your project several thousand dollars overbudget, you can also put yourself behind schedule if the store does not hap-pen to have several hundred GB of RAM lying around (with my luck, itwould be backordered). Here are a few things you want to pay attention towhen doing the physical hardware evaluation:

ch02.qxd 11/5/01 12:01 PM Page 52

• Is the server on the Hardware Compatibility List for Windows 2000?• Does the server have enough RAM?• Does the server have enough free disk space?• Does the server have a powerful enough CPU?• Does the server have a good network interface card?

In addition to these questions, you will want to pay attention to thephysical location of the servers, the users that are defined on the machines,the current role the machines play in the network, and the IP addressingscheme.

NETWORKING ENVIRONMENTAL EVALUATION

You need to look at the following items:

• Network infrastructure• DNS infrastructure• File, print, and Web server services• Line of business applications• Security• Information store• Hardware and software

PHYSICAL NETWORK TOPOLOGY

In order to design our new Windows 2000 network, we must have a physicaltopology map of our existing network. A physical network topology map willinclude the following information:

• Site names• Bandwidth of the connectors between sites• Number of users at each site• Backup links• Type of connector

The network topology map will be crucial for us when we design repli-cation. It is also useful when designing the forest structure, group policy, anddomain structure. It is important that this document is a high level overview.We do not want to mask the layout of our network with too much detail. Thisis not a troubleshooting document, it is a planning document. An example ofa good network topology map is shown in Figure 2–5.

CURRENT DOMAIN MAP

Another map that must be completed prior to the Windows 2000 designphase is a map of the existing NT domain structure. This will include the fol-lowing types of information:


ch02.qxd 11/5/01 12:01 PM Page 53


• Each of the domains that exist in your organization• The number of trust relationships that are in place• The direction of the trust relationships• The number of domain controllers in each domain• The location of the existing domain controllers• The people that are administrators in each domain

More than likely, if your company is large you will be doing some typeof domain restructuring as you move to Windows 2000. How you will carrythis out is a subject for consideration later in this book. At this point, you re-ally need a map that is like the one in Figure 2–6. If you have a very compli-cated domain structure, then you will probably want to flatten out your de-sign for Windows 2000 to enable you to take advantage of some potentialcost savings. Of course, these cost savings come with a price tag: The migra-tion is going to take longer, especially in the planning stages. But the savingswill be real, and the resulting ease of troubleshooting and administration willpay great dividends.

EVALUATING THE LOGICAL STRUCTURE

One item that is often overlooked in preparing for a Windows 2000 deploy-ment is the logical structure. This includes items like the users’ environment

Figure 2–5 A good physical network topology map details site lo-cations, bandwidth of connectors, and users in each lo-cation. This crucial planning document must be com-pleted prior to the Windows 2000 design phase.

ch02.qxd 11/5/01 12:01 PM Page 54

and the placement of trained network administrators. It is possible that someremote locations that had part-time administrators will no longer need to beadministrators. For instance, you may have a resource domain that had apart-time administrator that was responsible for password assigning securityto shares. In a Windows 2000 environment, you may want to make that re-source domain an OU and you may want to administer it remotely. In addi-tion, with the implementation of administrative terminal services, you canperform a lot of administrative tasks remotely. This frees up the part-time ad-ministrators to perform their normal duties (instead of monkeying aroundwith the server). In addition to freeing up personnel resources, you have alsoheightened security on the network by removing someone from the adminis-trators group. Some of the things we need to track:

• User profiles• Desktop configuration• Applications and storage of application data• Administrator locations• Administrator skill set• Administrator assignments

LOOKING AT THE COMPANY ORGANIZATION

We can follow the company organization chart as a guideline to help us cre-ate the OU structure for our Windows 2000 design. We do not want to createdomains based on this structure, as it will change too often. It is very difficultto move and manage multiple domains; however, it is very easy to move and


Figure 2–6 A map of your existing domain structurewill help you evaluate what your domainmigration strategy will be.

ch02.qxd 11/5/01 12:01 PM Page 55


manage multiple OUs. It is also possible that based upon the organizationchart review, some companies may revise their structure.

PUTTING TOGETHER A DESIGN TEAM

A design team will have the following types of people:

• Management sponsor: Someone with single signature authority.Someone to talk to upper management to gain support for theproject.

• Project manager: Someone to guide the project and to watch thetimeline.

• Technology groups: DNS, administrators• Project leads• Windows 2000 proponents: People that are convinced of the value

of Windows 2000.

BUSINESS JUSTIFICATION

Set specific milestones. Do not try to tackle the entire project at one time.There are just too many options to deploy, and too much planning involved.Instead, as you plan the deployment, focus on a specific problem. The spe-cific problem to solve should be something that will improve the businessflow, and something that you can guarantee success with. Nowadays, mostbusinesses are looking to the IT department to provide an ROI. In addition,they are looking at real savings, not just fuzzy intangibles. We must be able todefine the business reasons for making the switch to Windows 2000.

RESTRICT THE SCOPE OF THE PROJECT

In order to help assure the success of the project, it is important to definewhat will not be addressed in the initial phase of the migration. Are thereparts of the company that will not be migrated? Are there projects that willnot be tackled? Are there applications that are reaching the end of their usefullife and therefore will not be upgraded?

DEVELOP THE LOGICAL DESIGN

Once you have completed the evaluation of your existing infrastructure, thenext step is to define the logical design. In this step, we will be utilizing all ofthe information gathered from our evaluation. Steps involved in deriving thelogical design:

1. Namespace design: There are several critical decisions that need to bemade about the namespace: naming issues, single or multiple forests,domain trees, and OUs.

ch02.qxd 11/5/01 12:01 PM Page 56

2. FSMO planning and placement

3. GC placement (authentication and replication issues)

4. Group policy: Aspects of group policy to deploy; applications, security,and the effects of namespace on the group policy design

5. Security: The use of built-in and custom groups; the application of pub-lic key infrastructure and certificates

One way to derive the logical design for your Windows 2000 network isto create a placeholder domain at the top that contains administrator accounts(enterprise administrators, domain administrators, and the like). Below that,you have geographical based child domains (see Figure 2–7).

Inside the child domains, you then create your OU structure. Split outthe user accounts and the computer accounts to reduce the number of grouppolicies you need to create. Under each, you can create OUs based upon ei-ther function or location (see Figure 2–8).


Figure 2–7 By creating a placeholder domain at the top, and organizing the logi-cal domain into geographical child domains, you can vastly simplifythe structure and facilitate application of group policy.

ch02.qxd 11/5/01 12:01 PM Page 57


PHYSICAL DESIGN

After the logical design has been created, the next step is to define the physi-cal design of the new network. Items that must be considered at this stage ofthe game:

• Physical network equipment upgrades• WINS• DNS• DHCP• RAS• IPSEC

One way an organization may want to deploy the infrastructure servicesis to place the WINS and DHCP servers into a centralized network location(see Figure 2–9).

Due to its importance to the performance and reliability of Windows2000, DNS needs special consideration. Many companies already have a DNSinfrastructure in place. In most instances, this will be on Unix boxes runningsome version of BIND. It is easiest to migrate the existing DNS infrastructureto the new Windows 2000 network. However, in most instances this simplywill not fly. For one thing, most NT administrators do not understand DNSwell, and DNS is too important to get messed up while the NT admin team

Figure 2–8 By creating OUs for both users and computers, you can reduce thenumber of group policies you need to create for your organization. Thiswill simplify troubleshooting later on.

ch02.qxd 11/5/01 12:01 PM Page 58

comes up to speed on this crucial technology. For another thing, there is theattitude that if something is not broken—don’t try to fix it. In addition, thereare the internal politics to consider (e.g., I do not want to be holding the bagif something goes wrong). So, perhaps it is best to allow the Unix team tokeep DNS, and we simply work around it. This is, in fact, what I have beendoing with the majority of my medium and enterprise level clients. So howdo we work around it? The solution is amazingly simple. Figure 2–10 illus-trates one approach to the problem. We delegate the ownership of the crucialAD zones: _TCP, _UDP, _sites, and _msdcs. We turn these into AD integratedzones with dynamic updates.


Figure 2–9 By centralizing WINS and DHCP servers, a company can reducehardware costs and simplify infrastructure administration.

ch02.qxd 11/5/01 12:01 PM Page 59


REPLICATION DESIGN

In Windows 2000 you need to design the network topology to reflect the ac-tual physical topology. There are site structure limitations you will need to beaware of, as well as domain structure limitations. Once these are factored in,you will need to examine the scheduling of replication to account for net-work traffic and bandwidth.

There are at least seven different replication topologies you could comeup with, each of which may be more or less applicable to your particularphysical network design. Most of my clients use either the hub and spoketopology or a variation of the hub and spoke design. The hub and spokereplication topology is illustrated in Figure 2–11. In the hub and spoke de-sign, you have a core site where the majority of the domain controllers are lo-cated. Remote sites connect via WAN links to the core site in order to performreplication. The basic premise is that the remote WAN sites have good con-nectivity to the “core site” that enables replication to occur. In addition, it is

Figure 2–10 By delegating ownership of the four crucial AD zones, we can easilycoexist with a Unix BIND DNS server.

ch02.qxd 11/5/01 12:01 PM Page 60

important to realize that Exchange 2000 will cause a need for additionalglobal catalog servers.

There is a practical limitation of around 300 sites in Windows 2000 thatis due in part to the amount of time it takes the knowledge consistencychecker (KCC) to generate the replication topology. What happens is there isa processor spike in the ISMSRV and the LSASS processes that will eat up allthe CPU time while the KCC is running. If there are more than 300 sites, thenit is possible the KCC could never finish. It is possible to mitigate this effectby utilizing multiple processor domain controllers (a good idea anyway.)

There is a concept of a virtual site that can work around the site limita-tion. In this concept, you combine well-connected physical locations into a


Figure 2–11 The hub and spoke replication topologyworks well for a wide variety of network de-signs.

ch02.qxd 11/5/01 12:01 PM Page 61


single logical site. Then from the logical site, you connect one domain con-troller back to the core site location. The well-connected domain controllersare then able to replicate to the other remote physical locations and reducethe KCC load. The important point is to realize that a site does not have to bea physical location. In much of the literature a site is defined as a locationwith good connectivity. We can play with this concept, create our own defini-tion of a site, and then reduce the replication load on our remote links. A sitecan be a region, a campus, or a group of buildings. Sites do not need to bephysically next to one another. With the virtual site concept, we are takingseveral remote locations, creating an ad hoc grouping, and calling it a site.

ADDITIONAL CONSIDERATIONS

• Make sure you obtain updates for tools: backup software, antivirussoftware

• Design your time services: ws32time• File and print services: folder redirection, published shares in AD,

published printers in AD, and maintaining availability during the mi-gration

SAMPLE PLAN

1. Build a small pilot and grow to the corporate infrastructure. You can dothis in a permanent fashion, so that as pilot users are migrated, you arechipping away at the whole. As an alternative to the permanent pilotyou can build a disposable pilot where the machines are rebuilt afterthe pilot phase is complete. This is more labor intensive and costly, butis a safer pilot program.

2. Collapse and consolidate the NT4 resource domains, and import theminto organizational units in AD.

3. Implement Dynamic DNS as the name resolution mechanism for Win-dows 2000 clients.

4. Establish an environment to support the eventual migration of the Ex-change 5.5 global address list into AD. Exchange will make about 162new object classes with attributes to the AD Schema.

In order to migrate the resource domains, perform the following steps:

1. Establish the resource domain trusts to the NT4 master user domains (thesetrusts should already be in place; you just need to verify that they are).

2. Upgrade the domain to Windows 2000 beginning with the PDC. Youwill not be able to name the new Windows 2000 domain the same asthe old NT4 domain due to NETBIOS conflicts. For instance, if you havea NT4 domain named MRED, you will not be able to name the new

ch02.qxd 11/5/01 12:01 PM Page 62

Windows 2000 domain mred.com because Windows 2000 also creates a“NETBIOS compatible” name, which in this case would be MRED.

3. Clone all the local groups to the parent domain.

4. Demote the old BDCs to member servers, by using DCPROMO.exe. Re-member to keep one BDC off line for disaster recovery. You will alsowant to bring the BDC on line every couple of days during the migra-tion plan to make sure the SAM database is updated.

5. Move all member servers to an OU in the parent domain.

6. Run DCPROMO to demote the last BDC, destroying the old NT4 domainand moving the last BDC into an OU in the parent domain.

7. You are now ready to begin the deployment of the users’ workstations.Here is how one client did it: Send the users to class, and when they getback from class send them an email. Have them respond to the emailwhen they are ready for the new OS, and boom using Intellimirrorwhen they get the new desktop. In this way, the end user becomes partof the deployment team.

Evaluating Existing Network InfrastructureAll aspects of the existing network infrastructure will be impacted by a Win-dows 2000 migration. This includes switches, hubs, routers, and other itemsconnected to the network. Windows 2000 generates lots of network traffic.How much traffic, you ask? As an example, the simple act of authorizing aDHCP server in AD generates a ton of network traffic.

So how do we go about evaluating our existing network infrastructure?

Evaluating Existing ServersIt may seem intuitive that your existing servers will need to be evaluatedprior to the upgrade to Windows 2000. What may not be obvious is the ex-tent to which this evaluation needs to take place. In this section, we will lookat the elements of your server which deserve special consideration: hardwareand software.

Server HardwareThere are four main areas on the server which require special attention.These areas are the memory, the drive subsystem, the network interface, andthe processor.

Eva luat ing Ex i s t ing Ser vers 63

ch02.qxd 11/5/01 12:01 PM Page 63


MEMORY

So you subscribe to the old axiom, “The more memory, the better.” That mayhave been ok in the old days. However, in a Windows 2000 environment, youneed to pay a little bit more attention to the memory subsystem. With today’sservers there are several types of memory to choose from. It is important thatthe right memory for the particular server is selected. In addition, there are veryspecific combinations and sequences in which to add memory to the machines.In order to correctly determine the amount of memory the machines will needwhen upgraded to Windows 2000, it is necessary to look at the services the ma-chines will be running. You can also use some of the load simulator tools, setup a similar machine in a lab, and test using a server monitor (the new name forperformance monitor). Remember, the goal of the exercise is to make sure thatthe server has less memory committed, and that it has physical memory. This iseasily identified in task manager (see Figure 2–12). In addition to just addingRAM, it is important to see what the maximum memory used was. In Figure2–12, the peak memory used on the server was 324 megabytes. So we wouldprobably be safe in upgrading it to 512 megabytes. If we anticipate adding extrausers, then we might want to bring it up to a gigabyte.

DRIVE SUBSYSTEM

In addition to physical space, there are several additional items which mustbe examined. Perhaps the most important, from a reliability standpoint, is to

Figure 2–12 If a server has more committedmemory than physical, the mem-ory needs to be upgraded.

ch02.qxd 11/5/01 12:01 PM Page 64

have a very good hardware RAID controller. How the drives need to be con-figured depend on what the server will be doing on the network. The typesof SCSI transfer modes for available devices are listed below.

• Narrow SCSI bus. Denotes 8-bit bus• Wide SCSI bus, 16-bit bus. Doubles transfer rate of the bus. In-

creases supported devices from 8 to 16• Fast SCSI: Denotes a 10MHz bus. When combined with a narrow

SCSI bus, the transfer rate is 10MB/s. When combined with a wideSCSI bus, the transfer rate is 20MB/s.

• Ultra SCSI: Denotes a 20MHz bus. When combined with a narrowSCSI bus, the transfer rate is 20MB/s. When combined with a wideSCSI bus, the transfer rate is 40MB/s.

• Ultra2 SCSI-3: Denotes a 40MHz bus. When combined with a narrowSCSI bus, the transfer rate is 40MB/s. When combined with a wideSCSI bus, the transfer rate is 80MB/s.

• Wide Ultra2 SCSI-3: 80MB/s sometimes referred to as generic Ultra2because the narrow (8-bit) implementation is very uncommon.

• Ultra3 SCSI-3: Expands on Ultra2 SCSI technology. 160MB/s is thelatest SCSI implementation.

Now that we have a feel for the types of SCSI devices, take a look atTable 2–1 for a quick reference to the number of drives and the throughputthat can be obtained using them. Knowledge of SCSI technology is vitally im-portant in server sizing, as typically the bottleneck in a server is the drivesubsystem. Therefore, it is important to get the fastest drives with the besttransfer rates you can afford.

Eva luat ing Ex i s t ing Ser vers 65

Type Transfer Rate SCSI Standard Bus Width

SCSI 2–4MB/s SCSI-1 8

SCSI-2 5MB/s SCSI-2 8

Wide SCSI-2 10MB/s SCSI-2 16

Fast SCSI-2 10MB/s SCSI-2 8

Fast-Wide SCSI2 20MB/s SCSI-2 16

Ultra SCSI-3 20MB/s SCSI-3 8

Wide-Ultra SCSI-3 40MB/s SCSI-3 16

Ultra2 SCSI-3 40MB/s SCSI-3 8

Wide-Ultra2 SCSI-3 80MB/s SCSI-3 16

Ultra3 160MB/s SCSI-3 16

Table 2–1 Different combinations of SCSI technology provide different transfer ratesfor servers

ch02.qxd 11/5/01 12:01 PM Page 65


In real-world configurations, SCSI transfer rates are well below the val-ues presented in the technical data sheets. The following example points towhat are perhaps more realistic SCSI transfer rates.

Example:

Head positioning (track to track): 1msReading one complete track: 8ms (at 7,200 rpm)Reading 1 track including positioning: 9ms

With 150 sectors per track, this yields 150 x 0.5KB or75KB per rotation.

With a 7200 RPM drive, this happens 120 (7200/60) timesper second.

The maximum transfer rate per drive is therefore: 120 x75KB = 9MB/s.

With a 10K drive, it looks like this: 166.66 x 75KB = 12.5MB/s.

With a 15K drive, it looks like this: 250 x 75KB = 18.75MB/s.

NETWORK INTERFACE

The network interface introduces several special considerations. With certainapplications, the interface can become a bottleneck. In these situations, youwill need to consider gigabit network cards. The better servers have 64-bitbuses, that run at 66 mhz. With this kind of bandwidth on the bus, a giga-bit network card can be a very effective solution. One thing to keep in mind,however, is there are two patterns for the network traffic—the user-to-servercommunication, and there is the server-to-server communication. It is some-times effective to put two NICS in the servers and separate the server-to-server communication from the rest of the LAN traffic involved in clienttraffic.

PROCESSOR

Depending on what the Windows 2000 server is doing, a multiprocessor ma-chine is not always required. In general, I prefer dual-processor machines. Attimes, I prefer two dual-processor machines to a single quad processor ma-chine. One thing is certain: Whereas in Windows NT 4.0, the PDC could be arelatively wimpy server, a server that is running AD must be a hefty box. Re-member that AD is essentially a database, and has configuration characteris-tics similar to SQL and to Exchange.

ch02.qxd 11/5/01 12:01 PM Page 66

Server SoftwareEvaluating the server software is a tricky and often unsettling experience. Inthis section, we will look at some of the things that must be looked at prior tothe migration.

TESTING COMPATIBILITY

Testing compatibility of applications, which must be early in the migration,can be a very time-consuming process. In trying to determine compatibility,you will need to develop a list of applications that will be migrated to thenew servers. Checking with the application vendors is just the beginning. Youwill need to find out if software is going to be upgraded, patched, or new re-leases are on the horizon. One thing which could be done is to set up a labenvironment, and to model the existing server configuration as much as pos-sible. In this manner, you will be able to perform the upgrade to Windows2000, simulate normal user activity, and test for potential problems.

TESTING INTEROPERABILITY

Once you determine that the software will actually run on the server, makesure it works with other programs and devices. The interoperability study isquite a bit more complex than the test for compatibility. In a compatibilitytest, you simply need to make sure it runs in Windows 2000. In the interoper-ability, you need to make sure it will work and play with others nicely. Don’tforget: If you upgrade other applications (for Windows 2000 compatibility),make sure that the program you are testing will work with the new version ofthe software. This includes stuff like the Microsoft Data Access Components(MDACs). I have found many programs that rely on a particular MDAC. If youupgrade another application that requires a newer MDAC, make sure theolder application will work with the new MDAC (probably not). This mayvery well necessitate separating the two applications. Extensive testing andcareful planning are required to find this type of information.

Evaluating Existing DesktopsIn order to take maximum advantage of a Windows 2000 environment, it isincumbent upon us to upgrade the existing desktops to Windows 2000. Whilethis may be the most straightforward approach, it hardly qualifies as the easi-est, most cost effective, or least difficult solution. In this section, we will lookat some of the issues which surround the desktop solution.

Eva luat ing Ex i s t ing Desktops 67

ch02.qxd 11/5/01 12:01 PM Page 67


Existing HardwareIf the Windows 2000 server requires a substantial investment in hardware, sodoes the desktop version. In most instances, desktops more than a couple ofyears old will have to be retired. One thing you can do is to run a batch filesimilar to the one listed below to perform a rudimentary inventory of infor-mation, it can easily be included in a logon script to automate the data collec-tion.

rem you can create a network share and redirect the outputto that locationrem as well.rem for instance: >>\\servername\sharename \%computername%.txt

if exist %computername%.txt del %computername%.txtecho %username% >%computername%.txtecho %computername%>>%computername%.txtnet time >>%computername%.txtipconfig /all>>%computername%.txtdir >>%computername%.txtmem >>%computername%.txtnet start >>%computername%.txtnet stats server >>%computername%.txtnet stats workstation >>%computername%.txtnet config server >>%computername%.txtnet config workstation >>%computername%.txtrem the lines below are more valuable for serversnet accounts >>%computername%.txtnet user >>%computername%.txtnet share >>%computername%.txt

echo hosts file contains the following>>%computername%.txt

if exist %windir%\system32\drivers\etc\hosts type %win-dir%\system32\drivers\etc\hosts >>%computername%.txt

echo lmhosts file contains thefollowing>>%computername%.txt

if exist %windir%\system32\drivers\etc\lmhosts type %win-dir%\system32\drivers\etc\lmhosts >>%computername%.txt

Existing SoftwareWhile in most cases Windows 2000 can run the same software that ran onNT, a very interesting wrinkle develops if the previous desktop solution wasa Windows 9.x environment. So if you are upgrading all your desktops to

ch02.qxd 11/5/01 12:01 PM Page 68

Windows 2000 professional (or XP) and you are migrating from Windows 9.xmachines, then you could run into programs that simply will not work in aWindows 2000 environment. At this juncture, you could leave the old ma-chine (not upgrade it at this time), configure a dual boot solution (the userslove to dual boot), or contact the vendor about an upgrade to the software. Ihave seen a few scenarios where the bad application did not have an up-grade because the company went out of business. In this situation, you aresearching for a replacement program (and the users will be upset becausethey love the old application). This can be a real challenge, as desktops aresometimes very unmanaged, and there can be hundreds of dumb little pro-grams that the users have collected over the years. This does give you achance to standardize on applications, and desktops—if you have strongmanagement backing.

Chapter ReviewIn this chapter we looked at many of the things that are involved in planninga migration to Windows 2000. We delved into many DNS considerations, andsome of the planning functions that need to be evaluated at the outset. Afterthat, we moved into some basics of group policy, and looked at how it inter-acts with AD. We ended by looking at some of the things that need to beevaluated with the existing infrastructure.

In the Next ChapterIn the next chapter we look at what happens when it comes time to select amigration strategy. Basically there are three main types of migrations: the in-place upgrade, the consolidation upgrade, and the combination upgrade. Welook at each of these types of migrations and examine their characteristics,strengths, weaknesses, and potential pitfalls.

In the Next Chapter 69

ch02.qxd 11/5/01 12:01 PM Page 69

ch02.qxd 11/5/01 12:01 PM Page 70

Documents

PART TWO Migration Strategies - Pearson Education · 2019-02-20 · Migration Strategies PART TWO • Chapter 2 Planning a Migration • Chapter 3 Selecting a Migration Strategy •