View products that this article applies to.
This article was previously published under Q325379
On This Page
* SUMMARY
o Domain and forest inventory
o Microsoft Exchange 2000 in Windows 2000 forests
+ Scenario 1: Exchange 2000 schema changes are added after you run the Windows Server 2003 adprep /forestprep command
+ Scenario 2: Exchange 2000 schema changes will be installed before the Windows Server 2003 adprep /forestprep command
+ Scenario 3: The Windows Server 2003 forestprep command was run without first running inetOrgPersonFix
o Overview: Upgrading Windows 2000 domain controllers to Windows Server 2003
+ Upgrading the forest with the adprep /forestprep command
+ Upgrading the domain with the adprep /domainprep command
o Upgrading Windows 2000 domain controllers by using Winnt32.exe
o Dry-run upgrades in a lab environment
o Domain controllers without sufficient disk space
* REFERENCES
Expand all | Collapse all
SUMMARY
This article discusses how to upgrade Microsoft Windows 2000 domain controllers...
This article discusses how to upgrade Microsoft Windows 2000 domain controllers to Microsoft Windows Server 2003 and how to add new Windows Server 2003 domain controllers to Windows 2000 domains.
Back to the top
Domain and forest inventory
Before you upgrade Windows 2000 domain controllers to Windows Server 2003 or before you add new Windows Server 2003 domain controllers to a Windows 2000 domain, follow these steps:
1. Inventory the clients that access resources in the domain that host Windows Server 2003 domain controllers for compatibility with SMB signing:
Each Windows Server 2003 domain controller enables SMB signing in its local security policy. Make sure that all network clients that use the SMB/CIFS protocol to access shared files and printers in domains that host Windows Server 2003 domain controllers can be configured or upgraded to support SMB signing. If they cannot, temporarily disable SMB signing until updates can be installed or until the clients can be upgraded to newer operating systems that support SMB signing. For information about how to disable SMB signing, see the "To disable SMB signing" section at the end of this step.
Action plans
The following list shows the action plans for popular SMB clients:
* Microsoft Windows Server 2003, Microsoft Windows XP Professional, Microsoft Windows 2000 Server, Microsoft Windows 2000 Professional, and Microsoft Windows 98
No action is required.
* Microsoft Windows NT 4.0
Install Service Pack 3 or later (Service Pack 6A is recommended) on all Windows NT 4.0-based computers that access domains that contain Windows Server 2003-based computers. Alternatively, temporarily disable SMB signing on Windows Server 2003 domain controllers. For information about how to disable SMB signing, see the "To disable SMB signing" section at the end of this step.
* Microsoft Windows 95
Install the Windows 9x directory service client on the Windows 95-based computers or temporarily disable SMB signing on Windows Server 2003 domain controllers. The original Win9x directory service client is available on the Windows 2000 Server CD-ROM. However, that client add-on has been replaced by an improved Win9x directory service client. For information about how to disable SMB signing, see the "To disable SMB signing" section at the end of this step.
* Microsoft Network Client for MS-DOS and Microsoft LAN Manager clients
The Microsoft Network Client for MS-DOS and the Microsoft LAN Manager 2.x network client may be used to provide access to network resources, or they may be combined with a bootable floppy disk to copy operating system files and other files from a shared directory on a file server as part of a software installation routine. These clients do not support SMB signing. Use an alternative installation method, or disable SMB signing. For information about how to disable SMB signing, see the "To disable SMB signing" section at the end of this step.
* Macintosh clients
Some Macintosh clients are not SMB signing compatible and will receive the following error message when they try to connect to a network resource:
- Error -36 I/O
Install updated software if it is available. Otherwise, disable SMB signing on Windows Server 2003 domain controllers. For information about how to disable SMB signing, see the "To disable SMB signing" section at the end of this step.
* Other third-party SMB clients
Some third-party SMB clients do not support SMB signing. Consult your SMB provider to see if an updated version exists. Otherwise, disable SMB signing on Windows Server 2003 domain controllers.
To disable SMB signing
If software updates cannot be installed on affected domain controllers that are running Windows 95, Windows NT 4.0, or other clients that were installed before the introduction of Windows Server 2003, temporarily disable the SMB service signing requirements in Group Policy until you can deploy updated client software.
You can disable SMB service signing in the following node of Default Domain Controllers policy on the domain controllers organizational unit:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Microsoft Network Server: Digitally sign communications (always)
If domain controllers are not located in the domain controller's organizational unit, you must link the default domain controller's Group Policy object (GPO) to all organizational units that host Windows 2000 or Windows Server 2003 domain controllers. Or, you can configure SMB service signing in a GPO that is linked to those organizational units.
2. Inventory the domain controllers that are in the domain and in the forest:
1. Make sure that all the Windows 2000 domain controllers in the forest have installed all the appropriate hotfixes and service packs.
Microsoft recommends that all the Windows 2000 domain controllers run the Windows 2000 Service Pack 4 (SP4) or later operating systems. If you cannot fully deploy Windows 2000 SP4 or later, all the Windows 2000 domain controllers must have an Ntdsa.dll file whose date stamp and version is later than June 4th, 2001 and 5.0.2195.3673. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
331161 (http://support.microsoft.com/kb/331161/ ) Hotfixes to install before you run adprep /Forestprep on a Windows 2000 domain controller to prepare the Forest and domains for the addition of Windows Server 2003-based domain controllers
By default, Active Directory administrative tools on Windows 2000 SP4, Windows XP, and Windows Server 2003 client computers use Lightweight Directory Access Protocol (LDAP) signing. If such computers use (or fall back to) NTLM authentication when they remotely administer Windows 2000 domain controllers, the connection will not work. To resolve this behavior, remotely administered domain controllers should have a minimum of Windows 2000 SP3 installed. Otherwise you should turn off LDAP signing on the clients that run the administration tools. For more information about LDAP, click the following article numbers to view the articles in the Microsoft Knowledge Base:
325465 (http://support.microsoft.com/kb/325465/ ) Windows 2000 domain controllers require Service Pack 3 or later when using Windows Server 2003 administration tools
The following scenarios use NTLM authentication:
* You administer Windows 2000 domain controllers that are located in an external forest connected by an NTLM (non-Kerberos) trust.
* You focus Microsoft Management Console (MMC) snap-ins against a specific domain controller that is referenced by its IP address. For example, you click Start, click Run, and then type the following command:
dsa.msc /server=ipaddress
To determine the operating system and the service pack revision level of Active Directory domain controllers in an Active Directory domain, install the Windows Server 2003 version of Repadmin.exe on a Windows XP Professional or Windows Server 2003 member computer in the forest, and then run the following repadmin command against a domain controller in each domain in the forest:
>repadmin /showattr name of the domain controller that is in the target domain ncobj:domain: /filter:"(&(objectCategory=computer)(primaryGroupID=516))" /subtree /atts:operatingSystem,operatingSystemVersion,operatingSystemServicePack
DN: CN=NA-DC-01,organizational unit=Domain Controllers,DC=company,DC=com
1> operatingSystem: Windows Server 2003
1> operatingSystemVersion: 5.2 (3718)
DN: CN=NA-DC-02,organizational unit=Domain Controllers,DC=company,DC=com
1> operatingSystem: Windows 2000 Server
1> operatingSystemVersion: 5.0 (2195)
1> operatingSystemServicePack: Service Pack 1
Note: The domain controller's attributes do not track the installation of individual hotfixes.
2. Verify the end-to-end Active Directory replication throughout the forest.
Verify that each domain controller in the upgraded forest replicates all its locally held naming contexts with its partners consistently with the schedule that site links or connection objects define. Use the Windows Server 2003 version of Repadmin.exe on a Windows XP- or Windows Server 2003-based member computer in the forest with the following arguments:
REPADMIN /REPLSUM /BYSRC /BYDEST /SORT:DELTA <-output formatted to fit on page
DestDC largest delta fails/total %% error
NA-DC-01 13d.21h:10m:10s 97 / 143 67 (8240) There is no such object...
NA-DC-02 13d.04h:11m:07s 180 / 763 23 (8524) The DSA operation...
NA-DC-03 12d.03h:54m:41s 5 / 5 100 (8524) The DSA operation...
All the domain controllers in the forest must replicate Active Directory without error, and the values in the "Largest Delta" column of the repadmin output should not be significantly greater than the replication frequency on the corresponding site links or connection objects that are used by a given destination domain controller.
Resolve all replication errors between domain controllers that have failed to inbound replicate in less than Tombstone Lifetime (TSL) number of days (by default, 60 days). If replication cannot be made to function, you may have to forcibly demote the domain controllers and remove them from the forest by using the Ntdsutil metadata cleanup command, and then promote them back into the forest. You can use a forceful demotion to save both the operating system installation and the programs that are on an orphaned domain controller. For more information about how to remove orphaned Windows 2000 domain controllers from their domain, click the following article number to view the article in the Microsoft Knowledge Base:
216498 (http://support.microsoft.com/kb/216498/ ) How to remove data in Active Directory after an unsuccessful domain controller demotion
Take this action only as a last resort to recover the installation of the operating system and the installed programs. You will lose unreplicated objects and attributes on orphaned domain controllers including users, computers, trust relationships, their passwords, groups and group memberships.
Be careful when you try to resolve replication errors on domain controllers that have not replicated inbound changes for a particular Active Directory partition for greater than tombstonelifetime number of days. When you do so, you may reanimate objects that were deleted on one domain controller but for which direct or transitive replication partners never received the deletion in the previous 60 days.
Consider removing any lingering objects that reside on domain controllers that have not performed inbound replication in the last 60 days. Alternatively, you can forcefully demote domain controllers that have not performed any inbound replication on a given partition in tombstone lifetime number of days and remove their remaining metadata from the Active Directory forest by using Ntdsutil and other utilities. Contact your support provider or Microsoft PSS for additional help.
3. Verify that the contents of the Sysvol share are consistent.
Verify that the file system portion of group policy is consistent. You can use Gpotool.exe from the Resource Kit to determine whether there are inconsistencies in policies across a domain. Use Healthcheck from the Windows Server 2003 support tools to determine whether the Sysvol share replica sets function correctly in each domain.
If the contents of the Sysvol share are inconsistent, resolve all the inconsistencies.
4. Use Dcdiag.exe from the support tools to verify that all the domain controllers have shared Netlogon and Sysvol shares. To do so, type the following command at a command prompt:
DCDIAG.EXE /e /test:frssysvol
5. Inventory the operations roles.
The schema and infrastructure operations masters are used to introduce forest and domain-wide schema changes to the forest and its domains that are made by the Windows Server 2003 adprep utility. Verify that the domain controller that hosts the schema role and infrastructure role for each domain in the forest reside on live domain controllers and that each role owner has performed inbound replication over all partitions since they were last restarted.
The DCDIAG /test:FSMOCHECK command can be used to view forest-wide and domain-wide operational roles. Operations master roles that reside on non-existent domain controllers should be seized to a healthy domain controller by using NTDSUTIL. Roles that reside on unhealthy domain controllers should be transferred if possible. Otherwise, they should be seized. The NETDOM QUERY FSMO command does not identify FSMO roles that reside on deleted domain controllers.
Verify that the schema master and each infrastructure master has performed inbound replication of Active Directory since last booted. Inbound replication can be verified by using the REPADMIN /SHOWREPS DCNAME command, where DCNAME is the NetBIOS computer name or the fully qualified computer name of a domain controller. For more information about operations masters and their placement, click the following article numbers to view the articles in the Microsoft Knowledge Base:
197132 (http://support.microsoft.com/kb/197132/ ) Windows 2000 Active Directory FSMO roles
223346 (http://support.microsoft.com/kb/223346/ ) FSMO placement and optimization on Active Directory domain controllers
6. EventLog Review
Examine the event logs on all the domain controllers for problematic events. The event logs must not contain serious event messages that indicate a problem with any of the following processes and components:
physical connectivity
network connectivity
name registration
name resolution
authentication
Group Policy
security policy
disk subsystem
schema
topology
replication engine
7. Disk Space Inventory
The volume that hosts the Active Directory database file, Ntds.dit, must have free space equal to at least 15-20% of the Ntds.dit file size. The volume that hosts the Active Directory log file must also have free space equal to at least 15-20% of the Ntds.dit file size. For additional information about how to free up additional disk space, see the "Domain Controllers Without Sufficient Disk Space" section of this article.
8. DNS Scavenging (Optional)
Enable DNS Scavenging at 7-day intervals for all DNS servers in the forest. For best results, perform this operation 61 or more days before you upgrade the operating system. This provides the DNS scavenging daemon sufficient time to garbage-collect the aged DNS objects when an offline defragmentation is performed on the Ntds.dit file.
9. Disable the DLT Server Service (Optional)
The DLT Server service is disabled on new and upgraded installations of Windows Server 2003 domain controllers. If distributed link tracking is not used, you can disable the DLT Server service on your Windows 2000 domain controllers and begin deleting DLT objects from each domain in the forest. For additional information, see the "Microsoft Recommendations for distributed link tracking" section of the following article in the Microsoft Knowledge Base:
312403 (http://support.microsoft.com/kb/312403/ ) Distributed Link Tracking on Windows-based domain controllers
10. System State Backup
Make a system state backup of at least two domain controllers in every domain in the forest. You can use the backup to recover all the domains in the forest if the upgrade does not work.
Back to the top
Microsoft Exchange 2000 in Windows 2000 forests
Notes
* If Exchange 2000 Server is installed, or will be installed, in a Windows 2000 forest, read this section before you run the Windows Server 2003 adprep /forestprep command.
* If Microsoft Exchange Server 2003 schema changes will be installed, go to the "Overview: Upgrading Windows 2000 domain controllers to Windows Server 2003" section before you run the Windows Server 2003 adprep commands.
The Exchange 2000 schema defines three inetOrgPerson attributes with non-Request for Comment (RFC)-compliant LDAPDisplayNames: houseIdentifier, secretary, and labeledURI.
The Windows 2000 inetOrgPerson Kit and the Windows Server 2003 adprep command define RFC-complaint versions of the same three attributes with identical LDAPDisplayNames as the non-RFC-compliant versions.
When the Windows Server 2003 adprep /forestprep command is run without corrective scripts in a forest that contains Windows 2000 and Exchange 2000 schema changes, the LDAPDisplayNames for the houseIdentifier, labeledURI, and secretary attributes become mangled. An attribute becomes “mangled” if "Dup" or other unique characters are added to the beginning of the conflicted attribute name so that objects and attributes in the directory have unique names.
Active Directory forests are not vulnerable to mangled LDAPDisplayNames for these attributes in the following cases:
* If you run the Windows Server 2003 adprep /forestprep command in a forest that contains the Windows 2000 schema before you add the Exchange 2000 schema.
* If you install the Exchange 2000 schema in forest that was created where a Windows Server 2003 domain controller was the first domain controller in the forest.
* If you add Windows 2000 inetOrgPerson Kit to a forest that contains the Windows 2000 schema, and then you install Exchange 2000 schema changes, and then you run the Windows Server 2003 adprep /forestprep command.
* If you add Exchange 2000 schema to an existing Windows 2000 forest, then run Exchange 2003 /forestprep before you run the Windows Server 2003 adprep /forestprep command.
Mangled attributes will occur in Windows 2000 in the following cases:
* If you add the Exchange 2000 versions of the labeledURI, the houseIdentifier, and the secretary attributes to a Windows 2000 forest before you install the Windows 2000 inetOrgPerson Kit.
* You add the Exchange 2000 versions of the labeledURI, the houseIdentifier, and the secretary attributes to a Windows 2000 forest before you run the Windows Server 2003 adprep /forestprep command without first running the cleanup scripts.
Action plans for each scenario follow:
Scenario 1: Exchange 2000 schema changes are added after you run the Windows Server 2003 adprep /forestprep command
If Exchange 2000 schema changes will be introduced to your Windows 2000 forest after the Windows Server 2003 adprep /forestprep command is run, no cleanup is required. Go to the "Overview: Upgrading Windows 2000 domain controllers to Windows Server 2003" section.
Scenario 2: Exchange 2000 schema changes will be installed before the Windows Server 2003 adprep /forestprep command
If Exchange 2000 schema changes have already been installed but you have NOT run the Windows Server 2003 adprep /forestprep command, consider the following action plan:
1. Log on to the console of the schema operations master by using an account that is a member of the Schema Admins security group.
2. Click Start, click Run, type notepad.exe in the Open box, and then click OK.
3. Copy the following text including the trailing hyphen after "schemaUpdateNow: 1" to Notepad.
dn: CN=ms-Exch-Assistant-Name,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace:LDAPDisplayName
LDAPDisplayName: msExchAssistantName
-
dn: CN=ms-Exch-LabeledURI,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace: LDAPDisplayName
LDAPDisplayName: msExchLabeledURI
-
dn: CN=ms-Exch-House-Identifier,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace: LDAPDisplayName
LDAPDisplayName: msExchHouseIdentifier
-
dn:
changetype: Modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
4. Confirm that there is no space at the end of each line.
5. On the File menu, click Save. In the Save As dialog box, follow these steps:
1. In the File name box, type the following:
\%userprofile%\InetOrgPersonPrevent.ldf
2. In the Save as type box, click All Files.
3. In the Encoding box, click Unicode.
4. Click Save.
5. Quit Notepad.
6. Run the InetOrgPersonPrevent.ldf script.
1. Click Start, click Run, type cmd in the Open box, and then click OK.
2. At a command prompt, type the following, and then press ENTER:
cd %userprofile%
3. Type the following command
c:\documents and settings\%username%>ldifde -i -f inetorgpersonprevent.ldf -v -c DC=X "domain name path for forest root domain"
Syntax notes:
* DC=X is a case-sensitive constant.
* The domain name path for the root domain must be enclosed in quotation marks.
For example, the command syntax for an Active Directory forest whose forest root domain is TAILSPINTOYS.COM would be:
c:\documents and settings\administrator>ldifde -i -f inetorgpersonprevent.ldf -v -c DC=X "dc=tailspintoys,dc=com"
Note You may need to change the Schema Update Allowed registry subkey if you receive the following error message:
Schema update is not allowed on this DC because the registry key is not set or the DC is not the schema FSMO Role Owner.
For more information about how to change this registry subkey, click the following article number to view the article in the Microsoft Knowledge Base:
285172 (http://support.microsoft.com/kb/285172/ ) Schema update require Write access to schema in Active Directory
7. Verify that the LDAPDisplayNames for the CN=ms-Exch-Assistant-Name, CN=ms-Exch-LabeledURI, and CN=ms-Exch-House-Identifier attributes in the schema naming context now appear as msExchAssistantName, msExchLabeledURI, and msExchHouseIdentifier before you run the Windows Server 2003 adprep /forestprep commands.
8. Go to the "Overview: Upgrading Windows 2000 domain controllers to Windows Server 2003 " section to run the adprep /forestprep and /domainprep commands.
Scenario 3: The Windows Server 2003 forestprep command was run without first running inetOrgPersonFix
If you run the Windows Server 2003 adprep /forestprep command in a Windows 2000 forest that contains the Exchange 2000 schema changes, the LDAPDisplayName attributes for houseIdentifier, secretary, and labeledURI will become mangled. To identify mangled names, use Ldp.exe to locate the affected attributes:
1. Install Ldp.exe from the Support\Tools folder of the Microsoft Windows 2000 or Windows Server 2003 media.
2. Start Ldp.exe from a domain controller or member computer in the forest.
1. On the Connection menu, click Connect, leave the Server box empty, type 389 in the Port box, and then click OK.
2. On the Connection menu, click Bind, leave all the boxes empty, and then click OK.
3. Record the distinguished name path for the SchemaNamingContext attribute. For example, for a domain controller in the CORP.ADATUM.COM forest, the distinguished name path might be CN=Schema,CN=Configuration,DC=corp,DC=company,DC=com.
4. On the Browse menu, click Search.
5. Use the following settings to configure the Search dialog box:
* Base DN: The distinguished name path for the schema naming context that is identified in step 3.
* Filter: (ldapdisplayname=dup*)
* Scope: Subtree
6. Mangled houseIdentifier, secretary, and labeledURI attributes have LDAPDisplayName attributes that are similar to the following format:
LDAPDisplayName: DUP-labeledURI-9591bbd3-d2a6-4669-afda-48af7c35507d;
LDAPDisplayName: DUP-secretary-c5a1240d-70c0-455c-9906-a4070602f85f
LDAPDisplayName: DUP-houseIdentifier-354b0ca8-9b6c-4722-aae7-e66906cc9eef
7. If the LDAPDisplayNames for labeledURI, secretary, and houseIdentifier were mangled in step 6, run the Windows Server 2003 InetOrgPersonFix.ldf script to recover, and then go to the "Upgrading Windows 2000 domain controllers with Winnt32.exe" section.
1. Create a folder named %Systemdrive%\IOP, and then extract the InetOrgPersonFix.ldf file to this folder.
2. At a command prompt, type cd %systemdrive%\iop.
3. Extract the InetOrgPersonFix.ldf file from the Support.cab file that is located in the Support\Tools folder of the Windows Server 2003 installation media.
4. From the console of the schema operations master, load the InetOrgPersonFix.ldf file by using Ldifde.exe to correct the LdapDisplayName attribute of the houseIdentifier, secretary, and labeledURI attributes. To do so, type the following command, where
C:\IOP>ldifde -i -f inetorgpersonfix.ldf -v -c DC=X "domain name path for forest root domain"
Syntax notes:
* DC=X is a case-sensitive constant.
* The domain name path for the forest root domain must be enclosed in quotation marks.
8. Verify that the houseIdentifier, secretary, and labeledURI attributes in the schema naming context are not "mangled" before you install Exchange 2000.
For more information about a related schema conflict with Services for UNIX version 2.0, click the following article number to view the article in the Microsoft Knowledge Base:
293783 (http://support.microsoft.com/kb/293783/ ) Cannot upgrade Windows 2000 server to Windows Server 2003 with Windows Services for UNIX 2.0 installed
Back to the top
Overview: Upgrading Windows 2000 domain controllers to Windows Server 2003
The Windows Server 2003 adprep command that you run from the \I386 folder of the Windows Server 2003 media prepares a Windows 2000 forest and its domains for the addition of Windows Server 2003 domain controllers. The Windows Server 2003 adprep /forestprep command adds the following features:
* Improved default security descriptors for object classes
* New user and group attributes
* New Schema objects and attributes like inetOrgPerson
The adprep utility supports two command-line arguments:
adprep /forestprep: Runs forest upgrade operations.
adprep /domainprep: Runs domain upgrade operations.
The adprep /forestprep command is a one-time operation performed on the schema operation master (FSMO) of the forest. The forestprep operation must complete and replicate to the infrastructure master of each domain before you can run adprep /domainprep in that domain.
The adprep /domainprep command is a one-time operation that you run on the infrastructure operations master domain controller of each domain in the forest that will host new or upgraded Windows Server 2003 domain controllers. The adprep /domainprep command verifies that the changes from forestprep have replicated in the domain partition and then makes its own changes to the domain partition and group policies in the Sysvol share.
You cannot perform either of the following actions unless the /forestprep and the /domainprep operations have completed and replicated to all the domain controllers in that domain:
* Upgrade the Windows 2000 domain controllers to Windows Server 2003 domain controllers by using Winnt32.exe.
Note: You can upgrade the Windows 2000 member servers and computers to Windows Server 2003 member computers whenever you want.
* Promote new Windows Server 2003 domain controllers into the domain by using Dcpromo.exe.
The domain that hosts the schema operations master is the only domain where you must run both adprep /forestprep and adprep /domainprep. In all other domains, you only have to run adprep /domainprep.
The adprep /forestprep and the adprep /domainprep commands do not add attributes to the global catalog partial attribute set or cause a full synchronization of the global catalog. The RTM version of adprep /domainprep does cause a full sync of the \Policies folder in the Sysvol tree. Even if you run forestprep and domainprep several times, completed operations are performed only one time.
After the changes from adprep /forestprep and adprep /domainprep completely replicate, you can upgrade the Windows 2000 domain controllers to Windows Server 2003 by running Winnt32.exe from the \I386 folder of the Windows Server 2003 media. Also, you can add new Windows Server 2003 domain controllers to the domain by using Dcpromo.exe.
Upgrading the forest with the adprep /forestprep command
To prepare a Windows 2000 forest and domains to accept Windows Server 2003 domain controllers, follow these steps first in a lab environment, then in a production environment:
1. Make sure that you have completed all the operations in the "Forest Inventory" phase with special attention to the following items:
1. You have created system state backups.
2. All the Windows 2000 domain controllers in the forest have installed all the appropriate hotfixes and service packs.
3. End-to-end replication of Active Directory is occurring throughout the forest
4. FRS replicates the file system policy correctly throughout each domain.
2. Log on to the console of the schema operations master with an account that is a member of the Schema Admins security group.
3. Verify that the schema FSMO has performed inbound replication of the schema partition by typing the following at a Windows NT command prompt:
repadmin /showreps
(repadmin is installed by the Support\Tools folder of Active Directory.)
4. Early Microsoft documentation recommends that you isolate the schema operations master on a private network before you run adprep /forestprep. Real-world experience suggests that this step is not necessary and may cause a schema operations master to reject schema changes when it is restarted on a private network. If you want to isolate schema additions that were made by adprep, Microsoft recommends that you temporarily disable outbound replication of Active Directory with the repadmin command-line utility. To do this, following these steps:
1. Click Start, click Run, type cmd, and then click OK.
2. Type the following, and then press ENTER:
repadmin /options +DISABLE_OUTBOUND_REPL
5. Run adprep on the schema operations master. To do so, click Start, click Run, type cmd, and then click OK. On the schema operations master, type the following command
X:\I386\adprep /forestprep
where X:\I386\ is the path of the Windows Server 2003 installation media. This command runs the forest-wide schema upgrade.
Note Events with event ID 1153 that are logged in the Directory Service event log, such as the sample that follows, can be ignored:
Event Type : Error
Event Source : NTDS General
Event Category: Internal Processing
Event ID : 1153
Date: MM/DD/YYYY
Time: HH:MM:SS AM|PM
User : Everyone Computer :
Description: Class identifier 655562 (class name msWMI-MergeablePolicyTemplate) has an invalid superclass 655560. Inheritance ignored.
6. Verify that the adprep /forestprep command successfully ran on the schema operations master. To do so, from the console of the schema operations master, verify the following items:
* The adprep /forestprep command completed without error.
* The CN=Windows2003Update object is written under CN=ForestUpdates,CN=Configuration,DC=forest_root_domain. Record the value of the Revision attribute.
* (Optional) The schema version incremented to version 30. To do so, see the ObjectVersion attribute under CN=Schema,CN=Configuration,DC=forest_root_domain.
If adprep /forestprep does not run, verify the following items:
* The fully qualified path for Adprep.exe located in the \I386 folder of the installation media was specified when adprep ran. To do so, type the following command:
x:\i386\adprep /forestprep
where x is the drive that hosts the installation media.
* The logged on user who runs adprep has membership to the Schema Admins security group. To verify this, use the whoami /all command.
* If adprep still does not work, view the Adprep.log file in the %systemroot%\System32\Debug\Adprep\Logs\Latest_log folder.
7. If you disabled outbound replication on the schema operations master in step 4, enable replication so that the schema changes that were made by adprep /forestprep can propagate. To do this, following these steps:
1. Click Start, click Run, type cmd, and then click OK.
2. Type the following, and then press ENTER:
repadmin /options -DISABLE_OUTBOUND_REPL
8. Verify that the adprep /forestprep changes have replicated on all the domain controllers in the forest. It is useful to monitor the following attributes:
1. Incrementing the schema version
2. The CN=Windows2003Update, CN=ForestUpdates,CN=Configuration,DC=forest_root_domain or CN=Operations,CN=DomainUpdates,CN=System,DC=forest_root_domain and the operations GUIDs under it have replicated in.
3. Search for new schema classes, objects, attributes, or other changes that adprep /forestprep adds, such as inetOrgPerson. View the SchXX.ldf files (where XX is a number between 14 and 30) in the %systemroot%\System32 folder to determine what objects and attributes there should be. For example, inetOrgPerson is defined in Sch18.ldf.
9. Look for mangled LDAPDisplayNames.
If Exchange 2000 was installed before you ran the Windows Server 2003 adprep /forestprep command, see the following article in the Microsoft Knowledge Base:
314649 (http://support.microsoft.com/kb/314649/ ) Windows Server 2003 adprep /forestprep command causes mangled attributes in Windows 2000 forests that contain Exchange 2000 servers
If you find mangled names, go to Scenario 3 of the same article.
10. Log on to the console of the schema operations master with an account that is a member of the Schema Admins group security group of the forest that hosts the schema operations master.
Upgrading the domain with the adprep /domainprep command
Run adprep /domainprep after the /forestprep changes fully replicate to the infrastructure master domain controller in each domain that will host Windows Server 2003 domain controllers. To do so, follow these steps:
1. Identify the infrastructure master domain controller in the domain you are upgrading, and then log on with an account that is a member of the Domain Admins security group in the domain you are upgrading.
Note: The enterprise administrator may not be a member of the Domain Admins security group in child domains of the forest.
2. Run adprep /domainprep on the Infrastructure master. To do so, click Start, click Run, type cmd, and then on the Infrastructure master type the following command:
X:\I386\adprep /domainprep
where X:\I386\ is the path of the Windows Server 2003 installation media. This command runs domain-wide changes in the target domain.
Note: The adprep /domainprep command modifies files permissions in the Sysvol share. These modifications cause a full synchronization of files in that directory tree.
3. Verify that domainprep completed successfully. To do so, verify the following items:
* The adprep /domainprep command completed without error.
* The CN=Windows2003Update,CN=DomainUpdates,CN=System,DC=dn path of domain you are upgrading exists
If adprep /domainprep does not run, verify the following items:
* The logged on user who runs adprep has membership to the Domain Admins security group in the domain being you are upgrading. To do so, use the whoami /all command.
* The fully qualified path for Adprep.exe located in the \I386 directory of the installation media was specified when you ran adprep. To do so, at a command prompt type the following command:
x:\i386\adprep /forestprep
where x is the drive that hosts the installation media.
* If adprep still does not work, view the Adprep.log file in the %systemroot%\System32\Debug\Adprep\Logs\Latest_log folder.
4. Verify that the adprep /domainprep changes have replicated. To do so, for the remaining domain controllers in the domain, verify the following items:
* The CN=Windows2003Update,CN=DomainUpdates,CN=System,DC=dn path of domain you are upgrading object exists and the value for the Revision attribute matches the value of the same attribute on the infrastructure master of the domain.
* (Optional) Look for objects, attributes or access control list (ACL) changes that adprep /domainprep added.
Repeat steps 1-4 on the infrastructure master of the remaining domains in bulk or as you add or upgrade DC's in those domains to Windows Server 2003. Now you can promote new Windows Server 2003 computers into the forest by using DCPROMO. Or, you can upgrade existing Windows 2000 domain controllers to Windows Server 2003 by using WINNT32.EXE.
Back to the top
Upgrading Windows 2000 domain controllers by using Winnt32.exe
After the changes from /forestprep and /domainprep completely replicate and you have made a decision about security interoperability with earlier-version clients, you can upgrade Windows 2000 domain controllers to Windows Server 2003 and add new Windows Server 2003 domain controllers to the domain.
The following computers must be among the first domain controllers that run Windows Server 2003 in the forest in each domain:
* The domain naming master in the forest so that you can create default DNS program partitions.
* The primary domain controller of the forest root domain so that the enterprise-wide security principals that Windows Server 2003's forestprep adds become visible in the ACL editor.
* The primary domain controller in each non-root domain so that you can create new domain-specific Windows 2003 security principals.
To do so, use WINNT32 to upgrade existing domain controllers that host the operational role you want. Or, transfer the role to a newly-promoted Windows Server 2003 domain controller. Perform the following steps for each Windows 2000 domain controller that you upgrade to Windows Server 2003 with WINNT32 and for each Windows Server 2003 workgroup or member computer that you promote:
1. Before you use WINNT32 to upgrade Windows 2000 member computers and domain controllers, remove Windows 2000 Administration Tools. To do so, use the Add/Remove Programs tool in Control Panel. (Windows 2000 upgrades only.)
2. Install any hotfix files or other fixes that either Microsoft or the administrator determines is important.
3. Check each domain controller for possible upgrade issues. To do so, run the following command from the \I386 folder of the installation media:
winnt32.exe /checkupgradeonly
Resolve any issues that the compatibility check identifies.
4. Run WINNT32.EXE from the \I386 folder of the installation media, and the restart the upgraded 2003 domain controller.
5. Lower the security settings for earlier-version clients as required.
If Windows NT 4.0 clients do not have NT 4.0 SP6 or Windows 95 clients do not have the directory service client installed, disable SMB Service signing on the Default Domain Controllers policy on the Domain Controllers organizational unit, and then link this policy to all organizational units that host domain controllers.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Microsoft Network Server: Digitally sign communications (always)
6. Verify the health of the upgrade using the following data points:
* The upgrade completed successfully.
* The hotfixes that you added to the installation successfully replaced the original binaries.
* Inbound and outbound replication of Active Directory is occurring for all naming contexts held by the domain controller.
* The Netlogon and Sysvol shares exist.
* The event log indicates that the domain controller and its services are healthy.
Note: You may receive the following event message after you upgrade:
Event Type: Error
Event Source: NTDS Backup
Event Category: Backup
Event ID: 1913
Date: Date
Time: HH:MM:SSAM|PM
User: N/A
Computer: computername
Description: Internal error: The Active Directory backup and restore operation encountered an unexpected error. Backup or restore will not succeed until this is corrected.
You can safely ignore this event message.
7. Install the Windows Server 2003 Administration Tools (Windows 2000 upgrades and Windows Server 2003 non-domain controllers only). Adminpak.msi is in the \I386 folder of the Windows Server 2003 CD-ROM. Windows Server 2003 media contains updated support tools in the Support\Tools\Suptools.msi file. Make sure that you reinstall this file.
8. Make new backups of at least the first two Windows 2000 domain controllers that you upgraded to Windows Server 2003 in each domain in the forest. Locate the backups of the Windows 2000 computers that you upgraded to Windows Server 2003 in locked storage so you do not accidentally use them to restore a domain controller that now runs Windows Server 2003.
9. (Optional) Perform an offline defragmentation of the Active Directory database on the domain controllers that you upgraded to Windows Server 2003 after the single instance store (SIS) has completed (Windows 2000 upgrades only).
The SIS reviews existing permissions on objects stored in Active Directory, and then applies a more efficient security descriptor on those objects. The SIS starts automatically (identified by event 1953 in the directory service event log) when upgraded domain controllers first start the Windows Server 2003 operating system. You benefit from the improved security descriptor store only when you log an event ID 1966 event message in the directory service event log:
Event Type: Information
Event Source: NTDS SDPROP
Event Category: Internal Processing
Event ID: 1966
Date: MM/DD/YYYY
Time: HH:MM:SS AM|PM
User: NT AUTHORITY\ANONYMOUS LOGON
Computer:
Description: The security descriptor propagator has completed a full propagation pass.
Allocated space (MB):
XX Free space (MB): XX
This may have increased free space in the Active Directory database.
User Action: Consider defragmenting the database offline to reclaim the free space that may be available in the Active Directory database. For more information, see Help and Support Center at http://support.microsoft.com.
This event message indicates that the single instance store operation has completed and serves as a queues the administrator to perform of offline defragmentation of the Ntds.dit using NTDSUTIL.EXE.
The offline defragmentation can reduce the size of a Windows 2000 Ntds.dit file by up to 40%, improves Active Directory performance, and updates the pages in the database for more efficient storage of Link Valued attributes. For more information about how to defragment the Active Directory database, click the following article number to view the article in the Microsoft Knowledge Base:
232122 (http://support.microsoft.com/kb/232122/ ) Performing offline defragmentation of the Active Directory database
10. Investigate the DLT Server Service. Windows Server 2003 domain controllers disable the DLT Server service on fresh and upgrade installs. If Windows 2000 or Windows XP clients in your organization use the DLT Server service, use Group Policy to enable the DLT Server service on new or upgraded Windows Server 2003 domain controllers. Otherwise, incrementally delete distributed link tracking objects from Active Directory. For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
312403 (http://support.microsoft.com/kb/312403/ ) Distributed Link Tracking on Windows-based domain controllers
315229 (http://support.microsoft.com/kb/315229/ ) Text version of Dltpurge.vbs for Microsoft Knowledge Base article Q312403
If you bulk delete thousands of DLT objects or other objects, you may block replication because of a lack of version store. Wait tombstonelifetime number of days (by default, 60 days) after you delete the last DLT object and for garbage collection to complete, then use NTDSUTIL.EXE to perform an offline defragmentation of the Ntds.dit file.
11. Configure the best practice organizational unit structure. Microsoft recommends that administrators actively deploy the best practice organizational unit structure in all the Active Directory domains, and after they upgrade or deploy Windows Server 2003 domain controllers in Windows Domain mode, redirect the default containers that earlier-version APIs use to create users, computers and groups to an organizational unit container that the administrator specifies.
For additional information about the best practice organizational unit structure, view the "Creating an Organizational Unit Design" section of the "Best Practice Active Directory Design for Managing Windows Networks" white paper. To view the white paper, visit the following Microsoft Web site:
http://technet.microsoft.com/en-us/library/bb727085.aspx (http://technet.microsoft.com/en-us/library/bb727085.aspx)
For more information about changing the default container where users, computers and groups that earlier-version APIs create are located, click the following article number to view the article in the Microsoft Knowledge Base:
324949 (http://support.microsoft.com/kb/324949/ ) Redirecting the users and computers containers in Windows Server 2003 domains
12. Repeat steps 1 through 10 as required for each new or upgraded Windows Server 2003 domain controller in the forest and step 11 (Best Practice organizational unit structure) for each Active Directory domain.
In Summary:
* Upgrade Windows 2000 Domain controllers with WINNT32 (from the slipstreamed installation media if used)
* Verify the hotfixed files have been installed on the upgraded computers
* Install any required hotfixes not contained on installation media
* Verify the health on new or upgraded servers ( AD, FRS, Policy etc)
* Wait 24 hours after OS upgrade then offline defrag (optional)
* Start the DLT Service if you must, otherwise delete DLT objects using q312403 / q315229 post forest wide domainpreps
* Perform offline defrag 60+ days (tombstone lifetime and garbage collection # of days) after deleting DLT objects
Back to the top
Dry-run upgrades in a lab environment
Before you upgrade Windows domain controllers to a production Windows 2000 domain, validate and refine your upgrade process in the lab. If the upgrade of a lab environment that accurately mirrors the production forest performs smoothly, you can expect similar results in production environments. For complex environments, the lab environment must mirror the production environment in the following areas:
* Hardware: computer type, memory size, page file placement, disk size, performance and raid configuration, BIOS and firmware revision levels
* Software: client and server operating system versions, client and server applications, service pack versions, hotfixes, schema changes, security groups, group memberships, permissions, policy settings, object count type and location, version interoperability
* Network infrastructure: WINS, DHCP, link speeds, available bandwidth
* Load: Load simulators can simulate password changes, object creation, Active Directory replication, logon authentication and other events. The goal is not to reproduce the scale of the production environment. Instead, the goals are to discover the costs and frequency of common operations and to interpolate their effects (name queries, replication traffic, network bandwidth, and processor consumption) on the production environment based on your current and future requirements.
* Administration: tasks performed, tools used, operating systems used
* Operation: capacity, interoperability
* Disk Space: Note the starting, peak and ending size of the operating system, Ntds.dit and Active Directory log files on global catalog and non-global catalog domain controllers in each domain after each of the following operations:
1. adprep /forestprep
2. adprep /domainprep
3. Upgrading Windows 2000 domain controllers to Windows Server 2003
4. Performing offline defragmentation after version upgrades
An understanding of the upgrade process and complexity of the environment combined with detailed observation determines the pace and degree of care that you apply to upgrading production environments. Environments with a small number of domain controllers and Active Directory objects connected over high availability wide area network (WAN) links might upgrade in only a few hours. You may have to take more care with enterprise deployments that have hundreds of domain controllers or hundreds of thousands of Active Directory objects. In such cases, you may want to perform the upgrade over the course of several weeks or months.
Use "Dry-run" upgrades in the lab to perform the following tasks:
* Understand the inner workings of the upgrade process and the associated risks.
* Expose potential problem areas for the deployment process in your environment.
* Test and develop fall-back plans in case the upgrade does not succeed.
* Define the appropriate level of detail to apply to the upgrade process for the production domain.
Back to the top
Domain controllers without sufficient disk space
On domain controllers with insufficient disk space, use the following steps to free up additional disk space on the volume that hosts the Ntds.dit and Log files:
1. Delete the unused files including *.tmp files or cached files that internet browsers use. To do so, type the following commands (press ENTER after each command):
cd /d drive\
del *.tmp /s
2. Delete any user or memory dump files. To do so, type the following commands (press ENTER after each command):
cd /d drive\
del *.dmp /s
3. Temporarily remove or relocate files that you can access from other servers or easily reinstall. Files that you can remove and easily replace include ADMINPAK, Support Tools, and all the files in the %systemroot%\System32\Dllcache folder.
4. Delete old or unused user profiles. To do so, click Start, right-click My Computer, click Properties, click the User Profiles tab, and then delete all the profiles that are for old and unused accounts. Do not delete any profiles that may be for service accounts.
5. Delete the symbols at %systemroot%\Symbols. To do so, type the following command:
rd /s %systemroot%\symbols
Depending on whether the servers have a full or small symbol set, this may gain approximately 70 MB to 600 MB.
6. Perform an offline defragmentation. An offline defragmentation of the Ntds.dit file may free up space but temporarily requires double the space of the current DIT file. Perform the offline defrag by using other local volumes if one is available. Or, use space on a best connected network server to perform the offline defragmentation. If the disk space is still not sufficient, incrementally delete unnecessary user accounts, computer accounts, DNS records and DLT objects from Active Directory.
Note: Active Directory does not delete objects from the database until tombstonelifetime number of days (by default, 60 days) have passed and the garbage collection completes. If you reduce tombstonelifetime to a value lower than end-to-end replication in the forest, you may cause inconsistencies in Active Directory.
No comments:
Post a Comment