Inside Windows Server 1002003 [Electronic resources] نسخه متنی

In-Place Upgrade of a Windows 2000 Forest

If you are in the fortunate position of having already finished your Windows 2000 deployment, the upgrade to Windows Server 2003 should not involve too much work. Servers that are suitable for Windows 2000 domain controllers should be adequate for Windows Server 2003, although you should think about upgrading hardware if you have a server skating near the minimums. Microsoft recommends a 550MHz processor, 256MB of RAM, 4GB of storage for the operating system, and sufficient space on the data drives to hold the Active Directory database files.

The Active Directory database in Windows Server 2003 is somewhat larger than Windows 2000, but not enough to make a difference for storage calculations. If you are within 20 percent of filling the drive containing your current Active Directory files, you should be thinking about getting larger drives, whether or not you choose to upgrade.

If you have multiple domain controllers in a site, you can do the upgrade during working hours, assuming that you have no other applications running on the server. Use caution not to disable the site bridgehead server, the sole Global Catalog server, or any FSMO role master during working hours.

Probably the most exciting Active Directory feature in Windows Server 2003 is the ability create transitive, Kerberos-based trusts between two forests. To see how this works, the examples in this topic walk through an upgrade of two Windows 2000 forests with domains that share an External trust such as that shown in Figure 9.23.

In this diagram, users in the two domains share access to resources in their respective domains. A typical example is an extranet connection between a manufacturer and a vendor. Another example is a hospital on a university campus where the doctors are also members of the faculty and therefore need access to the main campus domain.

The domain hosting the servers and the domain hosting the users have been configured with a two-way External trust. This mimics a classic NT trust in that it is really two, one-way trusts that use NTLM authentication, not Kerberos, so they are not transitive. This is why the domains trust each other directly and do not use trusts between the root domains.

Upgrading the domains and forests in this configuration to Windows Server 2003 involves these major stages:

1. Upgrade the schema and prepare the domains for upgrade.




2. Upgrade the domain controllers in the root domains and shift the domain functional level to Windows Server 2003.




3. Upgrade the domain controllers in the child domains and shift the domain functional level to Windows Server 2003.




4. Shift the forest functional level to Windows Server 2003.




5. Replace the External trust between the child domains with a Forest trust between the root domains.

Schema Upgrade

Before you can upgrade a Windows 2000 domain controller to Windows Server 2003, or introduce a Windows Server 2003 domain controller into a Windows 2000 domain, you must first upgrade the Windows 2000 schema. Windows Server 2003 makes over 400 changes to the schema, including new classes and attributes, changes to indexing, and changes to the attributes published in the Global Catalog. This last item requires a rebuild of the Global Catalog, which is then replicated to every GC server in the forest.

In addition to big changes in the schema, Windows Server 2003 requires a few nips and tucks in the domains, as well. These changes support inter-forest connections and help to track domain updates.

The utility that performs these schema and domain updates is called ADPREP. It is located in compressed form in the \I386 folder on the Windows Server 2003 CD.

The simplest way to install ADPREP is to run winnt32 /checkupgradeonly from the Windows Server 2003 CD. This extracts ADPREP to the \WINNT\System32 folder and copies over 11 LDIF files, numbered Sch14.ldf through Sch24.ldf, that hold the new schema entries.

The number assigned to these Sch

## .ldf files correspond to schema version numbers. The Windows 2000 schema is version 13, which is why the Sch

## .ldf files start at 14. Exchange 2000 also upgrades the schema, but it uses a separate set of LDAP Data Interchange Format (LDIF) files that do not change the schema version number.

The ADPREP utility has two switches, both of which must be run prior to upgrading a Windows 2000 domain controller to Windows Server 2003 or installing a new Windows Server 2003 domain controller in an existing Windows 2000 domain:

• adprep /forestprep .
  This switch performs the schema upgrade. It calls another utility, SCHUPGR, and feeds it the Sch

  ## .ldf files in sequence. The /forestprep switch also updates Active Directory permissions and makes changes to the display specifiers to support the new classes.




• adprep /domainprep .
  This switch applies new attributes to the Domain object that are used for maintaining trust quotas. It also adds a new container under System for tracking domain updates.

You must be running Windows 2000 SP2 or later on all domain controllers in the forest prior to updating the schema. You must have administrator rights in the root domain of the forest along with membership in the Schema Admins group.

Run adprep /forestprep at the Schema role master for the Windows 2000 forest. You can identify this server using the DUMPFSMOS command script from the Resource Kit. The syntax is dumpfsmos <

dc_name >.

The /domainprep switch must be run on the Infrastructure role master in each domain. You must have administrator rights in the domain. No changes are made to the schema. The /domainprep switch simply adds support for inter-forest trust quotas and adds a new container under the System container to track updates.

Upgrade Windows 2000 Root Domains

After the ADPREP changes have propagated to all domain controllers in the forest, you can begin upgrading the domain controllers in the root domains. Figure 9.24 shows the end result. Unlike upgrading an NT domain controller, the operating system and the directory service are upgraded at the same time in Windows 2000. The process can take quite a while, well over an hour in some cases, depending on the processor speed and any Registry translations that might need to be done.

You have the option of simply promoting a Windows Server 2003 member server as a domain controller rather than upgrading the existing domain controllers. If you decide to use this route, you must transfer all five FSMO roles to the new domain controllers prior to decommissioning the Windows 2000 DCs.

[View full width]
ntdsutil roles Connections "Connect to server %1" Quit "select 
Operation Target"
"List roles for connected server" Quit Quit Quit

Ntdsutil r c "co t s %1" q "sel o t" "l r f c s" q q q

If you decide to upgrade, it is a good idea to start with the PDC Emulator. This is not a requirement, but the PDC Emulator is the default server for editing group policies as well as the time standard and the Domain Master Browser, so you might as well get it out of the way first.

As soon as you finish upgrading all domain controllers in the root domain, shift the domain to Windows Server 2003 functional level. Verify that the trust relationship to the child domains remains intact. Verify that administrators can still log on to the root domain and retain their enterprise privileges in the child domains.

Upgrading Child Domains

Now that the root domains have been upgraded, you're ready to start upgrading the child domains. Remember that you must prepare the domain with adprep /domainprep before upgrading the first domain controller. Figure 9.25 shows the final configuration with the forest functional level set at Windows Server 2003.

As with the root domain, you should start the upgrades with the PDC Emulator. When you've completed upgrading all Windows 2000 domain controllers, shift the domain functional level to Windows Server 2003 then shift the forest functional level to Windows Server 2003.

At this point, you can create a Forest trust between the forests. When this trust is in place, you can remove the External trust between the child domains. Verify that users can access resources in all domains through the Forest Root trust.