Upgrading 2000 AD to 2003 1

[WANguy2k]

I ran adprep /forestprep in preperation for adding new Windows 2003 servers to my Win2k network. As I have an Exchange 2000 server running, I wanted to make sure there are no mangled LDAPDisplayNames, as per PDID 325379. I ran LDP and I'm doing a search on CN=Schema,CN=Configuration,DC=mydomain,DC=com; for (ldapdisplayname=dup*).

I cut and pasted the SchemaNamingContext into the search field, but I'm still getting

Error: Search: Invalid DN Syntax. <34>
Result <34>: 0000208F: NameErr: DSID-031001AA, problem 2006 (BAD_NAME), data 8350, best match of:
'CN=Schema,CN=Configuration,DC=mydomain,DC=com;'

Any help would be appreciated.

 

[aftertaf]

AFAIK, you need to upgrade to exch 2003 too... i heard that exch 2000 dont work with windows 2003 AD schema.


silly question, did you run adprep /forestprep on your schema master?

Aftertaf

"Solutions are not the answer." - Richard Nixon

 

[basst]

This Winnt magazine article describes the problem.
May be of help to you:

Q. I have Microsoft Exchange 2000 Server installed and want to run the Windows Server 2003 Adprep /Forestprep command. What must I do to avoid corrupting Active Directory (AD)?

John Savill
InstantDoc #44063
John Savill's FAQ for Windows
A. When Exchange 2000 is installed, it modifies the AD schema. Three of these modifications are additions of the houseIdentifier, Secretary, and labeledURI attributes for the InetOrgPerson class. However, these Exchange 2000 attributes don't adhere to Internet Engineering Task Force (IETF) Request for Comments (RFC) 2798. When the Windows 2003 Adprep /Forestprep command runs, it redefines the attributes so that they conform to RFC 2798. This renaming causes Windows to rename the existing definitions for other attributes so that they're RFC-compliant and will cause future problems for your Exchange environment. (If you installed Exchange 2000 after running Windows 2003 forestprep, these problems won't occur.)

The Microsoft article "Windows Server 2003 adprep /forestprep Command Causes Mangled Attributes in Windows 2000 Forests That Contain Exchange 2000 Servers" describes solutions to a variety of problems related to Exchange 2000 schema changes and renamed attributes. Here, I discuss the procedure for changing the attribute names so that the Windows 2003 Adprep /Forestprep process doesn't mangle the attributes. This procedure addresses the most common scenario, in which Exchange 2000 is installed and you haven't yet run the Windows 2003 Adprep /Forestprep command. Before you perform the following steps, you need to enable schema modifications, which I discuss in the FAQ "How do I allow modifications to the schema?"

Log on as a Schema Admin (the Administrator of the forest root domain has this role by default).
Paste the following text into a file named Inetorgpersonprevent.ldf in the %systemroot%\IOP folder. You'll need to create the IOP folder. (You can copy and paste this text from the Microsoft article I mentioned earlier instead of typing it.)
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
-
Start a command prompt (Start, Run, cmd.exe).
Change the current folder to the IOP folder.
Run the Ldifde command (the following line shows an example):
ldifde -i -f inetorgpersonprevent.ldf -v -c DC=X "DC=SAVILLTECH,DC=COM"
The command should be on one line, and you need to replace DC=SAVILLTECH,DC=COM with the distinguished name (DN) of your forest. After you enter the command, messages similar to the following are displayed on screen:

Connecting to "OMEGA.savilltech.com"
Logging in as current user using SSPI
Importing directory from file "inetorgpersonprevent.ldf"
Loading entries
1: CN=ms-Exch-Assistant-Name,CN=Schema,CN=Configuration,DC=SAVILLTECH,DC
=COM
Entry modified successfully.

2: CN=ms-Exch-LabeledURI,CN=Schema,CN=Configuration,DC=SAVILLTECH,DC=COM

Entry modified successfully.

3: CN=ms-Exch-House-Identifier,CN=Schema,CN=Configuration,DC=SAVILLTECH,
DC=COM
Entry modified successfully.

4: (null)
Entry modified successfully.

4 entries modified successfully.

The command has completed successfully.
You could use the ADSIEdit tool (adsiedit.msc) to check whether the attribute renaming worked--for example, the lDAPDisplayName attribute of the ms-Exch-LabeledURI class should now be renamed msExchLabeledURI instead of LabeledURI. If necessary, you can disable the schema changes that you enabled to perform this procedure.

 

[aftertaf]

ouf!

Aftertaf

"Solutions are not the answer." - Richard Nixon

 

[WANguy2k]

I must have misread the document I was using, because I ran adprep /forestprep already. This doesn't mean the attributes are mangled, but they could be. That's why I was trying to use the procedure in scenario 3 in document #314649 to see if I need to repair active directory using InetOrgPersonfix.ldf. Unfortunately I can't even properly search for the mangled attributes, which was my original question. (Sorry, I'm new at this AD stuff.)