DcGetDcName(TIME_SERVER) call failed, error 1355

September 1st, 2009 by shiraj

——–
Warning: DcGetDcName(TIME_SERVER) call failed, error 1355
A Time Server could not be located.
The server holding the PDC role is down.
Warning: DcGetDcName(GOOD_TIME_SERVER_PREFERRED) call failed,
error 1355
A Good Time Server could not be located.
——–

Quick resolution worked for me changing time server:

The procedure for doing this on a PDC Emulator running Windows Server 2003 in the forest root domain is as follows. Open Registry Editor (regedit.exe) and configure the following registry entries:

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type

This registry entry determines which peers W32Time will accept synchronization from. Change this REG_SZ value from NT5DS to NTP so the PDC Emulator synchronizes from the list of reliable time servers specified in the NtpServer registry entry described below.

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags

This registry entry controls whether the local computer is marked as a reliable time server (which is only possible if the previous registry entry is set to NTP as described above). Change this REG_DWORD value from 10 to 5 here.

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer

This registry entry specifies a space-delimited list of stratum 1 time servers from which the local computer can obtain reliable time stamps. The list may consist of one or more DNS names or IP addresses (if DNS names are used then you must append ,0×1 to the end of each DNS name). For example, to synchronize the PDC Emulator in your forest root domain with tock.usno.navy.mil, an open-access SNTP time server run by the United States Naval Observatory, change the value of the NtpServer registry entry from time.windows.com,0×1 to tock.usno.navy.mil,0×1 here. Alternatively, you can specify the IP address of this time server, which is 192.5.41.209 instead.

Now stop and restart the Windows Time service using the following commands:

net stop w32time

net start w32time

Transferring the FSMO Roles via Ntdsutil

July 22nd, 2008 by shiraj

Transferring the FSMO Roles via Ntdsutil

To transfer the FSMO roles from the Ntdsutil command:

Caution: Using the Ntdsutil utility incorrectly may result in partial or complete loss of Active Directory functionality.

  1. On any domain controller, click Start, click Run, type Ntdsutil in the Open box, and then click OK.

  1. Type roles, and then press ENTER.

Note: To see a list of available commands at any of the prompts in the Ntdsutil tool, type ?, and then press ENTER.

  1. Type connections, and then press ENTER.

  1. Type connect to server <servername>, where <servername> is the name of the server you want to use, and then press ENTER.

  1. At the server connections: prompt, type q, and then press ENTER again.

  1. Type transfer <role>. where <role> is the role you want to transfer.

For example, to transfer the RID Master role, you would type transfer rid master:

Options are:

  1. You will receive a warning window asking if you want to perform the transfer. Click on Yes.

  2. After you transfer the roles, type q and press ENTER until you quit Ntdsutil.exe.

  3. Restart the server and make sure you update your backup

Preparing your Active Directory for Exchange 2007

July 22nd, 2008 by shiraj

When implementing Microsoft Exchange Server 2003 in your Active Directory you had to perform an setup /ForestPrep and setup /DomainPrep. With Microsoft Exchange Server 2007 things get a little more complicating since you now have to perform four steps:

  • setup /PrepareLegacyExchangePermissions
  • setup /PrepareSchema
  • setup /PrepareAD
  • setup /PrepareDomain or setup /PrepareAllDomains

The last two steps bear a certain resemblance with the ForestPrep and DomainPrep command, where the first two are definitely new. Here’s what they do:

PrepareLegacyExchangePermissions

The setup /PrepareLegacyExchangePermissions command must be run if you have any servers running Microsoft Exchange Server 2003 or Microsoft Exchange 2000 Server and you must run it logged in as a member of the Enterprise Admins group.

Essentially, you must run the setup /PrepareLegacyExchangePermissions command so that the Exchange 2003 or Exchange 2000 Recipient Update Service functions correctly after you update the Active Directory schema for Exchange 2007, because of the new Exchange-Information property set. Here’s a detailed description of the changes made by setup /PrepareLegacyExchangePermissions.

If you’re about to run the PrepareSchema step you might skip this step, because the setup /PrepareSchema command can do it for you. If you add a new domain to your forest and you want to install Exchange Server 2003 or Exchange 2000 Server in this domain, or if users in this domain will log on to mailboxes on Exchange Server 2003 or Exchange 2000 Server servers in other domains, you must run setup /PrepareLegacyExchangePermissions again after you run Exchange Server 2003 or Exchange 2000 Server DomainPrep.

PrepareSchema

The setup /PrepareSchema command performs the Schema Updates needed by Microsoft Exchange Server 2007. Here’s a list of all the changes made by this command in a vanilla Active Directory schema. Of course you can extract more information from the ldf files that are used by the setup program. You must run at is a member of the Enterprise Admins and as a member of the Schema Admins group and you must run this command on a computer that is in the same domain and the same Active Directory site as the schema master.

PrepareAD

The setup /PrepareAD command configures global Exchange objects in Active Directory, creates the Exchange Universal Security Groups (Exchange Organization Administrators, Exchange Recipient Administrators, Exchange View-Only Administrators, Exchange Servers and Exchange2003Interop) in the root domain, and prepares the current domain.

You have to be a member of the Enterprise Admins group to successfully perform this command. If you have existing Exchange Server 2003 servers you also have to be a member of the Exchange Organization Administrators group.

If you haven’t performed the PrepareSchema step the PrepareAD command can make these changes. When your also performing the PrepareAD command with an account that is a member of the Schema Admins group is can perform the PrepareLegacyExchangePermissions command as well.

PrepareDomain

The setup /PrepareDomain, setup /PrepareDomain:Domainname and setup /PrepareAllDomains commands all prepare domains other than the domain where your Schema Master is located. The difference between the commands is the scope in which they operate. You have to be a member of the Enterprise Admins group or you must be a member of the Domain Admins group in any domain that you will prepare.

Conclusion

The system requirements for Microsoft Exchange Server 2007 prohibit you from performing an in-place upgrade of existing Exchange servers. There is also no direct upgrade path to it for servers running Microsoft Exchange Server 5.5 or Microsoft Windows Small Business Server 2000. Companies with Microsoft Exchange 2000 Server on Microsoft Windows 2000 Domain Controllers face an overcomplicated migration scenario.

There are four steps to prepare your Active Directory for Microsoft Exchange Server 2007. In a simple Active Directory configuration (where you only have one domain in one forest) you only have to perform the setup /PrepareAD command and perform it with an account that is member of the Enterprise Admins and the Schema Admins group. (assuming members of the Enterprise Admins group are also members of the Domain Admins group, which is default)

Configure the WSUS Server

May 16th, 2008 by shiraj

Configure the WSUS Server and Create Computer Groups for Computers

Next, you configure WSUS for synchronization and approving updates by using the Administrator Console interface and then modifying Group Policy settings in Active Directory.

Modify Synchronization Settings

In this section you synchronize your server with the Microsoft Windows Update servers.

Procedure UM.5: To configure the WSUS server

1. Open up the Windows Server Update Services Deployment Guide downloaded in Install WSUS.
2. From the Table of Contents, navigate to Configure the WSUS Server to learn about the process of configuring WSUS.
3. Perform the following procedures:  

• Access the WSUS Administration Console
• Configure WSUS to Use a Proxy Server
• Select Products and Classifications
• Synchronize the WSUS Server
• Configure Advanced Synchronization Options
• Chain WSUS Servers Together
• Create a Replica Group
• Create Computer Groups for Computers
• Approve Updates

Create a Group Policy for Update Management

This procedure allows you to use Group Policy to manage software updates.

First, add the WSUS Group Policy.

Procedure UM.6: To add the Windows Server Update Services Group Policy

1. Log on to AD01 using an account that is a member of the Domain Administrators group.
2. Click Start, click Administrative Tools, and then click Group Policy Management.
3. Expand Domains, and then expand your domain (for example, fabrikam.com).
4. Expand Group Policy Objects.
5. Right-click Group Policy Objects, and then select New.
6. Type a name for the GPO (for example, Windows Server Update Services), and then click OK.

Import the Security Template into the New GPO

You will need the WUAU.adm file that describes the new policy settings for the Automatic Updates client. WUAU.adm is automatically installed into the %windir%\inf folder when you install Automatic Updates.

Procedure UM.7: To import the security template into the new GPO

1. Right-click the newly created Windows Server Update Services GPO, and then click Edit.
2. From the Deploying Microsoft Windows Server Update Services document, perform the steps from the Update and Configure the Automatic Updates Client Compoment section to configure the following procedures:  

• To add the WSUS Administrative Template
• To configure the behavior of Automatic Updates
• To redirect Automatic Updates to a WSUS server  

In step 3, enter http://wsus01 for the server name.
• To enable client-side targeting  

In step 3, type the group name created earlier (Hosting Servers) in the box.
3. Close the Group Policy Object Editor.

Apply the GPO to an Active Directory OU

Finally, apply the Windows Server Update Services settings to all domain servers by linking the GPO to the Servers OU. Once all servers obtain the policy information from the domain controller, they will then check for and install updates from WSUS01 based on the configurations.

Procedure UM.8: To apply the GPO to the Servers OU

1. Open the Group Policy Management Console.
2. Expand Domains, and then expand your domain (for example, fabrikam.com).
3. Expand Group Policy Objects.
4. Click the previously created Windows Server Update Services GPO, and then drag it onto the Servers OU, to which it should be linked.
5. In the Group Policy Management dialog box, click OK to confirm the creation of the GPO link.
6. Click the previously created Windows Server Update Services GPO and drag it onto the Domain Controllers OU, to which it should be linked.
7. In the Group Policy Management dialog box, click OK to confirm the creation of the GPO link.

upgrading 2000 dc with exchange 2000 to 2003

May 3rd, 2008 by shiraj

http://support.microsoft.com/kb/325379
How to upgrade Windows 2000 domain controllers to Windows Server 2003

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:

a. In the File name box, type the following:

\%userprofile%\InetOrgPersonPrevent.ldf
b. In the Save as type box, click All Files.
c. In the Encoding box, click Unicode.
d. Click Save.
e. Quit Notepad.
6. Run the InetOrgPersonPrevent.ldf script.

a. Click Start, click Run, type cmd in the Open box, and then click OK.
b. At a command prompt, type the following, and then press ENTER:

cd %userprofile%
c. 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.

a. On the Connection menu, click Connect, leave the Server box empty, type 389 in the Port box, and then click OK.
b. 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.

a. Create a folder named %Systemdrive%\IOP, and then extract the InetOrgPersonFix.ldf file to this folder.
b. At a command prompt, type cd %systemdrive%\iop.
c. 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.
d. 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 <X> is a case-sensitive constant and <dn path for forest root domain> is the domain name path for the root domain of the forest:

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:

a. You have created system state backups.
b. All the Windows 2000 domain controllers in the forest have installed all the appropriate hotfixes and service packs.
c. End-to-end replication of Active Directory is occurring throughout the forest
d. 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:

a. Click Start, click Run, type cmd, and then click OK.
b. 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 : <some DC>
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:

a. Click Start, click Run, type cmd, and then click OK.
b. 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:

a. Incrementing the schema version
b. 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.
c. 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.

Upgrading Windows 2000 DC to 2003

April 30th, 2008 by shiraj

Inventory the domain controllers that are in the domain and in the forest

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 http://support.microsoft.com/kb/331161/

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
The DCDIAG /test:FSMOCHECK command can be used to view forest-wide and domain-wide operational roles.
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.
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
Disk Space Inventory
DNS Scavenging (Optional)
Enable DNS Scavenging at 7-day intervals for all DNS servers in the forest.
Disable the DLT Server Service (Optional)