2000 -> 2003 upgrade failure

[Matt Wright]

Hi all,
Due to an order from on high, I attempted to upgrade one of our
Windows 2000 domains today.

This domain basically just supports an appliction that we run, and
thus is very simple. It's in a separate forest that only contains this
domain. The domain consists of 3 W2K SP4 DCs, and a few other servers
(web and SQL). There are roughly 200 user accounts at the moment. It's
never had Exchange installed, and all the servers sit in the same
room, on the same IP range, so there's only 1 site.

I followed the instructions here --
http://support.microsoft.com/?kbid=325379 -- for checking everything
out beforehand and running the upgrade. Everything
checked out fine, so with some small amount of trepidation I started
the update.

It ran for a couple minutes, and then failed and quit with the
following error:

Connecting to "SISDC1"
Logging in as current user using SSPI
Importing directory from file "C:\WINNT\system32\sch18.ldf"
Loading entries........................
Add error on line 333: Unwilling To Perform
The server side error is "Schema update failed: attribute in
may-contain
does no
t exist."
23 entries modified successfully.
An error has occurred in the program
ERROR: Import from file C:\WINNT\system32\sch18.ldf failed. Error file
is saved
in ldif.err.18.

If the error is "Insufficient Rights" (Ldap error code 50), please
make
sure the
current logged on user has rights to read/write objects in the schema
and confi
guration containers, or log off and log in as an user with these
rights
and reru
n schupgr.exe.
Adprep was unable to upgrade the schema on the schema master.
[Status/Consequence]
The schema will not be restored to its original state.
[User Action]
Check the Ldif.err log file in the
C:\WINNT\system32\debug\adprep\logs\200307111
43846 directory for detailed information.

I checked the ldif.err.18 file to find the following:

Entry DN:
CN=inetOrgPerson,CN=Schema,CN=Configuration,DC=doesis,DC=pas
Add error on line 333: Unwilling To Perform
The server side error is "Schema update failed: attribute in
may-contain
does not exist."
An error has occurred in the program

The user I'm logged in as is a Domain/Enterprise/Schema admin, and the
server I'm logged in on owns all the FSMO roles and is a GC.

Fortunately, everyone has gone home for the weekend, so I don't really
need to fix it till Monday. I have system state backups of all the DCs
from before the attempted upgrade, so it shouldn't be terribly
difficult to restore to pre-upgrade-attempt status, but I'd rather not
have to do that. I did some searching around, but didn't find anything
that seemed helpful thus far. SFU isn't installed.

Basically, I'm just wondering if anyone's seen this before, or has
been through it and has a (preferrably easy ) solution. If anyone
has any experience or helpful advice I'd appreciate hearing it.

Thanks in advance for any help.
Matt Wright

 

[Mark Mancini]

I think you may have to run forest prep first.

--
Sincerely,
Mark Mancini, CCA, CCNA, Master CIW&CI, CNE 4&5, MCSE+I 4&2000
www.MCSE2000.com
www.AppLauncher.com

Hi all,
Due to an order from on high, I attempted to upgrade one of our
Windows 2000 domains today.

This domain basically just supports an appliction that we run, and
thus is very simple. It's in a separate forest that only contains this
domain. The domain consists of 3 W2K SP4 DCs, and a few other servers
(web and SQL). There are roughly 200 user accounts at the moment. It's
never had Exchange installed, and all the servers sit in the same
room, on the same IP range, so there's only 1 site.

I followed the instructions here --
http://support.microsoft.com/?kbid=325379 -- for checking everything
out beforehand and running the upgrade. Everything
checked out fine, so with some small amount of trepidation I started
the update.

It ran for a couple minutes, and then failed and quit with the
following error:

Connecting to "SISDC1"
Logging in as current user using SSPI
Importing directory from file "C:\WINNT\system32\sch18.ldf"
Loading entries........................
Add error on line 333: Unwilling To Perform
The server side error is "Schema update failed: attribute in
may-contain
does no
t exist."
23 entries modified successfully.
An error has occurred in the program
ERROR: Import from file C:\WINNT\system32\sch18.ldf failed. Error file
is saved
in ldif.err.18.

If the error is "Insufficient Rights" (Ldap error code 50), please
make
sure the
current logged on user has rights to read/write objects in the schema
and confi
guration containers, or log off and log in as an user with these
rights
and reru
n schupgr.exe.
Adprep was unable to upgrade the schema on the schema master.
[Status/Consequence]
The schema will not be restored to its original state.
[User Action]
Check the Ldif.err log file in the
C:\WINNT\system32\debug\adprep\logs\200307111
43846 directory for detailed information.

I checked the ldif.err.18 file to find the following:

Entry DN:
CN=inetOrgPerson,CN=Schema,CN=Configuration,DC=doesis,DC=pas
Add error on line 333: Unwilling To Perform
The server side error is "Schema update failed: attribute in
may-contain
does not exist."
An error has occurred in the program

The user I'm logged in as is a Domain/Enterprise/Schema admin, and the
server I'm logged in on owns all the FSMO roles and is a GC.

Fortunately, everyone has gone home for the weekend, so I don't really
need to fix it till Monday. I have system state backups of all the DCs
from before the attempted upgrade, so it shouldn't be terribly
difficult to restore to pre-upgrade-attempt status, but I'd rather not
have to do that. I did some searching around, but didn't find anything
that seemed helpful thus far. SFU isn't installed.

Basically, I'm just wondering if anyone's seen this before, or has
been through it and has a (preferrably easy ) solution. If anyone
has any experience or helpful advice I'd appreciate hearing it.

Thanks in advance for any help.
Matt Wright

 

[Deji Akomolafe]

Did you prep the Forest AND the Domain BEFORE you start the upgrade?

The answer is more likely a "no". So, do those 2 first, then redo the
upgrade.

HTH

Deji

Hi all,
Due to an order from on high, I attempted to upgrade one of our
Windows 2000 domains today.

This domain basically just supports an appliction that we run, and
thus is very simple. It's in a separate forest that only contains this
domain. The domain consists of 3 W2K SP4 DCs, and a few other servers
(web and SQL). There are roughly 200 user accounts at the moment. It's
never had Exchange installed, and all the servers sit in the same
room, on the same IP range, so there's only 1 site.

I followed the instructions here --
http://support.microsoft.com/?kbid=325379 -- for checking everything
out beforehand and running the upgrade. Everything
checked out fine, so with some small amount of trepidation I started
the update.

It ran for a couple minutes, and then failed and quit with the
following error:

Connecting to "SISDC1"
Logging in as current user using SSPI
Importing directory from file "C:\WINNT\system32\sch18.ldf"
Loading entries........................
Add error on line 333: Unwilling To Perform
The server side error is "Schema update failed: attribute in
may-contain
does no
t exist."
23 entries modified successfully.
An error has occurred in the program
ERROR: Import from file C:\WINNT\system32\sch18.ldf failed. Error file
is saved
in ldif.err.18.

If the error is "Insufficient Rights" (Ldap error code 50), please
make
sure the
current logged on user has rights to read/write objects in the schema
and confi
guration containers, or log off and log in as an user with these
rights
and reru
n schupgr.exe.
Adprep was unable to upgrade the schema on the schema master.
[Status/Consequence]
The schema will not be restored to its original state.
[User Action]
Check the Ldif.err log file in the
C:\WINNT\system32\debug\adprep\logs\200307111
43846 directory for detailed information.

I checked the ldif.err.18 file to find the following:

Entry DN:
CN=inetOrgPerson,CN=Schema,CN=Configuration,DC=doesis,DC=pas
Add error on line 333: Unwilling To Perform
The server side error is "Schema update failed: attribute in
may-contain
does not exist."
An error has occurred in the program

The user I'm logged in as is a Domain/Enterprise/Schema admin, and the
server I'm logged in on owns all the FSMO roles and is a GC.

Fortunately, everyone has gone home for the weekend, so I don't really
need to fix it till Monday. I have system state backups of all the DCs
from before the attempted upgrade, so it shouldn't be terribly
difficult to restore to pre-upgrade-attempt status, but I'd rather not
have to do that. I did some searching around, but didn't find anything
that seemed helpful thus far. SFU isn't installed.

Basically, I'm just wondering if anyone's seen this before, or has
been through it and has a (preferrably easy ) solution. If anyone
has any experience or helpful advice I'd appreciate hearing it.

Thanks in advance for any help.
Matt Wright

 

[Jimmy Andersson]

Did you run adprep /forestprep and adprep /domainprep?

Regards,
/Jimmy
--
Jimmy Andersson, Q Advice AB
Microsoft MVP - Active Directory
---------- www.qadvice.com ----------

Hi all,
Due to an order from on high, I attempted to upgrade one of our
Windows 2000 domains today.

This domain basically just supports an appliction that we run, and
thus is very simple. It's in a separate forest that only contains this
domain. The domain consists of 3 W2K SP4 DCs, and a few other servers
(web and SQL). There are roughly 200 user accounts at the moment. It's
never had Exchange installed, and all the servers sit in the same
room, on the same IP range, so there's only 1 site.

I followed the instructions here --
http://support.microsoft.com/?kbid=325379 -- for checking everything
out beforehand and running the upgrade. Everything
checked out fine, so with some small amount of trepidation I started
the update.

It ran for a couple minutes, and then failed and quit with the
following error:

Connecting to "SISDC1"
Logging in as current user using SSPI
Importing directory from file "C:\WINNT\system32\sch18.ldf"
Loading entries........................
Add error on line 333: Unwilling To Perform
The server side error is "Schema update failed: attribute in
may-contain
does no
t exist."
23 entries modified successfully.
An error has occurred in the program
ERROR: Import from file C:\WINNT\system32\sch18.ldf failed. Error file
is saved
in ldif.err.18.

If the error is "Insufficient Rights" (Ldap error code 50), please
make
sure the
current logged on user has rights to read/write objects in the schema
and confi
guration containers, or log off and log in as an user with these
rights
and reru
n schupgr.exe.
Adprep was unable to upgrade the schema on the schema master.
[Status/Consequence]
The schema will not be restored to its original state.
[User Action]
Check the Ldif.err log file in the
C:\WINNT\system32\debug\adprep\logs\200307111
43846 directory for detailed information.

I checked the ldif.err.18 file to find the following:

Entry DN:
CN=inetOrgPerson,CN=Schema,CN=Configuration,DC=doesis,DC=pas
Add error on line 333: Unwilling To Perform
The server side error is "Schema update failed: attribute in
may-contain
does not exist."
An error has occurred in the program

The user I'm logged in as is a Domain/Enterprise/Schema admin, and the
server I'm logged in on owns all the FSMO roles and is a GC.

Fortunately, everyone has gone home for the weekend, so I don't really
need to fix it till Monday. I have system state backups of all the DCs
from before the attempted upgrade, so it shouldn't be terribly
difficult to restore to pre-upgrade-attempt status, but I'd rather not
have to do that. I did some searching around, but didn't find anything
that seemed helpful thus far. SFU isn't installed.

Basically, I'm just wondering if anyone's seen this before, or has
been through it and has a (preferrably easy ) solution. If anyone
has any experience or helpful advice I'd appreciate hearing it.

Thanks in advance for any help.
Matt Wright

 

[Matt Wright]

Sorry, I should have been more specific. The error I'm getting is
while running forestprep to upgrade the schema. It imports a bunch of
schema changes from ldf files, and is failing on number 18.
ForestPrep is what's giving me the error.

Thanks again,
Matt

 

[Eric Fleischman [MSFT]]

Hey Matt,

My post was kinda the polite way of me saying "I'm quite sure you do have a
schema extension that is conflicting"

Here's the deal. You have a schema extension that is conflicting with the
attribute we try and extend on line 333. More specifically, that attribute
is part of inetorgperson if I remember correctly.

My suggestion.: look into what applications have schema extensions.
Specifically, do you have any Cisco stuff running that might have done it?
If you want to tackle this further, look in the ldf file you are importing
to line 333, see what it is defining, and search your schema for OID's or
attributes which have the same name. After you find the conflict, it would
depend what sort of conflict you have before we could say how to resolve it.

I'm not one to push you to PSS, but I'd encourage you, if you can't figure
out what did this, to contact PSS. I'm nervous giving you scripts or other
sorts of schema modification advise without having an engineer look into
this deeper. My thought from what I've seen so far is that you need to
resolve this schema conflict. It is either an OID or attribute name. My bet
is OID, but tough to say without ldf dumping your schema and picking through
it.

As for proper forest operation (keep in mind schema extensions are a
forest-wide thing, not just domain) a failure like this won't hurt anything.
It just will prevent you from going to 2003.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Eric,
Thanks for the reply. To the best of my knowledge there have been no
other schema extensions in this domain. However I just inherited this
project a few weeks ago, so it is possible that there were previous
changes made that I don't know about. I will try to find out for sure
on Monday.

Do you have any suggestions for how I might go about troubleshooting
this further, or double-checking for improper schema extensions?

Also, do you know if the forestprep failure will affect the proper
functioning of the domain? From glancing through the ldf files, it
looked like it was just a bunch of adds, which I wouldn't think would
cause any problems, but I've never done this particular operation
before, so I didn't know for sure.
Thanks a lot,
Matt

"Eric Fleischman [MSFT]" <[email protected]> wrote in message

Hey Matt,

I'm going to start a new thread off of this post as I'd like to take a
different direction than others who have replied.
I've seen this error several times during the forest prep operation.
It always came down to this: environment had other schema extensions that
used improper OID's.
Are you running another product that extended your schema (Cisco does it
sometimes, Apple has some stuff that does, etc)?

~Eric

rights

 

[Eric Fleischman [MSFT]]

You too Matt.
Basically the troubleshooting methodology I'd use is to use ldifde to dump
the schema of your forest, then look at line 333 of the ldf file the import
is failing on and search your schema to ensure that none of the unique bits
of that line are not in use in the forest.
What is most likely (although not definite....nothing is 100% ) is that
either the OID or attribute name is already in use, so you need to resolve
the conflict.
It is easy to resolve a conflict like that. The only critical part is that
you don't break another app in the envrionment in the process, so you'd want
to probably take a peak in that attribute throughout the envionment and
ensure you don't have critical data of some sort in that attribute.

Feel free to post back to this thread if you'd like more guidance.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights.

Thanks for the quick reply Eric.

Looks like I'll have to do some checking on the schema for this
forest. It is very possible that schema changes were made that I'm
not aware of. It's helpful to know that this is definitely the
problem, so I appreciate your giving me that information.

We're not running anything Cisco, but the application that is running
in this forest is a custom (and beta at the moment) one that the
vendor has spent some time tweaking, so it's possible that they made
some schema changes without telling us. I can check with them about
it on Monday.

Thanks again for your help. Knowing for sure what the problem is will
make it a lot easier to troubleshoot. If I can't track it down by
Monday morning, I'll probably go ahead and put in a call to PSS (we
used up our last prepaid incident this past week, and the PO for our
new ones hasn't gone through yet, so I was putting it off)

Have a good rest of the weekend,
Matt

"Eric Fleischman [MSFT]" <[email protected]> wrote in message

Hey Matt,

My post was kinda the polite way of me saying "I'm quite sure you do have a
schema extension that is conflicting"

Here's the deal. You have a schema extension that is conflicting with the
attribute we try and extend on line 333. More specifically, that attribute
is part of inetorgperson if I remember correctly.

My suggestion.: look into what applications have schema extensions.
Specifically, do you have any Cisco stuff running that might have done it?
If you want to tackle this further, look in the ldf file you are importing
to line 333, see what it is defining, and search your schema for OID's or
attributes which have the same name. After you find the conflict, it would
depend what sort of conflict you have before we could say how to resolve it.

I'm not one to push you to PSS, but I'd encourage you, if you can't figure
out what did this, to contact PSS. I'm nervous giving you scripts or other
sorts of schema modification advise without having an engineer look into
this deeper. My thought from what I've seen so far is that you need to
resolve this schema conflict. It is either an OID or attribute name. My bet
is OID, but tough to say without ldf dumping your schema and picking through
it.

As for proper forest operation (keep in mind schema extensions are a
forest-wide thing, not just domain) a failure like this won't hurt anything.
It just will prevent you from going to 2003.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Eric,
Thanks for the reply. To the best of my knowledge there have been no
other schema extensions in this domain. However I just inherited this
project a few weeks ago, so it is possible that there were previous
changes made that I don't know about. I will try to find out for sure
on Monday.

Do you have any suggestions for how I might go about troubleshooting
this further, or double-checking for improper schema extensions?

Also, do you know if the forestprep failure will affect the proper
functioning of the domain? From glancing through the ldf files, it
looked like it was just a bunch of adds, which I wouldn't think would
cause any problems, but I've never done this particular operation
before, so I didn't know for sure.
Thanks a lot,
Matt

"Eric Fleischman [MSFT]" <[email protected]> wrote in

message

Hey Matt,

I'm going to start a new thread off of this post as I'd like to take a
different direction than others who have replied.
I've seen this error several times during the forest prep operation.
It always came down to this: environment had other schema extensions that
used improper OID's.
Are you running another product that extended your schema (Cisco does it
sometimes, Apple has some stuff that does, etc)?

~Eric

rights

 

[Matt Wright]

Well, since you made the offer

If it's not too much trouble, I wouldn't mind knowing how to fix it.
I'm going to check with the guy who was running the domain before
about just getting rid of the server that's using Access Manager
(maybe move it to a different forest), but if I can't do that, and the
schema problem turns out to be reasonably easy to fix, I wouldn't mind
actually fixing it. If nothing else, it'd make my boss happy and I'd
learn something that could be useful to me later.

Our main forest/domain is going to need an upgrade to 2003 at some
point, so anything I learn along the way could come in handy when that
time comes.

Once again, thanks for your time
Matt

Yup. Cognos extends by conflicting with one of our inetorg person
extensions, and causes this error.
If you want to dig into it further let me know and I can tell you how I
resolved it before.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights

Just thought I'd update this thread with the results, so Google can
archive it and it may help someone else.

It turns out that our problem is caused by Cognos Access Manager.
Access Manager has an option to store it's information AD, which is
how the person who set it up installed it (the other option is
Netscape Directory Server, which comes with the product). When set up
this way, it adds some schema extensions to AD.

What we decided to do for now is just to leave our domain at 2000.
The upgrade to 2003 turned out not to be required by the vendor, so to
save ourselves some hassle, we'll just leave it at 2000 for now, and
at some point in the future upgrade to 2003. Hopefully by then the
various schema compatability issues will have been worked out by other
people, and will be better documented and relatively easy to fix.

Thanks again for your assistance Eric.
Matt

"Eric Fleischman [MSFT]" <[email protected]> wrote in message

You too Matt.
Basically the troubleshooting methodology I'd use is to use ldifde to dump
the schema of your forest, then look at line 333 of the ldf file the import
is failing on and search your schema to ensure that none of the unique bits
of that line are not in use in the forest.
What is most likely (although not definite....nothing is 100% ) is that
either the OID or attribute name is already in use, so you need to resolve
the conflict.
It is easy to resolve a conflict like that. The only critical part is that
you don't break another app in the envrionment in the process, so you'd want
to probably take a peak in that attribute throughout the envionment and
ensure you don't have critical data of some sort in that attribute.

Feel free to post back to this thread if you'd like more guidance.

~Eric

 

[Eric Fleischman [MSFT]]

Sure.
The issue is in sch18.ldf. if you were to open up ldif.err.18 in system32
you'd find the error as well.
I believe in your case they are defining PreferredLanguage with the wrong
OID. If you look in your schema you'll probably see PreferredLanguage with
an attributeID= 1.2.840.114050.1.1.1.1.90 (aka an OID).
That's not a valid OID to be using there.
You'd have to rename the existing preferredLanguage
adminDsiplayName,lDAPDisplayName, RDN, etc. to not be preferredLanguage.
Maybe name it CognosPreferredLanguage or something.

*****NOTE*****
This very well might break your application. I haven't a clue what doing
this might break. You definitely, without a doubt, before doing anything
else, need to check with the software vendor on this first.
*****NOTE******

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights

Well, since you made the offer

If it's not too much trouble, I wouldn't mind knowing how to fix it.
I'm going to check with the guy who was running the domain before
about just getting rid of the server that's using Access Manager
(maybe move it to a different forest), but if I can't do that, and the
schema problem turns out to be reasonably easy to fix, I wouldn't mind
actually fixing it. If nothing else, it'd make my boss happy and I'd
learn something that could be useful to me later.

Our main forest/domain is going to need an upgrade to 2003 at some
point, so anything I learn along the way could come in handy when that
time comes.

Once again, thanks for your time
Matt

"Eric Fleischman [MSFT]" <[email protected]> wrote in message

Yup. Cognos extends by conflicting with one of our inetorg person
extensions, and causes this error.
If you want to dig into it further let me know and I can tell you how I
resolved it before.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights

Just thought I'd update this thread with the results, so Google can
archive it and it may help someone else.

It turns out that our problem is caused by Cognos Access Manager.
Access Manager has an option to store it's information AD, which is
how the person who set it up installed it (the other option is
Netscape Directory Server, which comes with the product). When set up
this way, it adds some schema extensions to AD.

What we decided to do for now is just to leave our domain at 2000.
The upgrade to 2003 turned out not to be required by the vendor, so to
save ourselves some hassle, we'll just leave it at 2000 for now, and
at some point in the future upgrade to 2003. Hopefully by then the
various schema compatability issues will have been worked out by other
people, and will be better documented and relatively easy to fix.

Thanks again for your assistance Eric.
Matt

"Eric Fleischman [MSFT]" <[email protected]> wrote in

message

You too Matt.
Basically the troubleshooting methodology I'd use is to use ldifde

to
dump

the schema of your forest, then look at line 333 of the ldf file the import
is failing on and search your schema to ensure that none of the

unique
bits

of that line are not in use in the forest.
What is most likely (although not definite....nothing is 100% )

is
that

either the OID or attribute name is already in use, so you need to resolve
the conflict.
It is easy to resolve a conflict like that. The only critical part

is
that

you don't break another app in the envrionment in the process, so

you'd
want

to probably take a peak in that attribute throughout the envionment and
ensure you don't have critical data of some sort in that attribute.

Feel free to post back to this thread if you'd like more guidance.

~Eric

 

[Eric Fleischman [MSFT]]

BTW: I've been told that Cognos is providing a script to fix this
automatically. I would contact them before making any changes.

~Eric


--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights

Sure.
The issue is in sch18.ldf. if you were to open up ldif.err.18 in system32
you'd find the error as well.
I believe in your case they are defining PreferredLanguage with the wrong
OID. If you look in your schema you'll probably see PreferredLanguage with
an attributeID= 1.2.840.114050.1.1.1.1.90 (aka an OID).
That's not a valid OID to be using there.
You'd have to rename the existing preferredLanguage
adminDsiplayName,lDAPDisplayName, RDN, etc. to not be preferredLanguage.
Maybe name it CognosPreferredLanguage or something.

*****NOTE*****
This very well might break your application. I haven't a clue what doing
this might break. You definitely, without a doubt, before doing anything
else, need to check with the software vendor on this first.
*****NOTE******

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights

Well, since you made the offer

If it's not too much trouble, I wouldn't mind knowing how to fix it.
I'm going to check with the guy who was running the domain before
about just getting rid of the server that's using Access Manager
(maybe move it to a different forest), but if I can't do that, and the
schema problem turns out to be reasonably easy to fix, I wouldn't mind
actually fixing it. If nothing else, it'd make my boss happy and I'd
learn something that could be useful to me later.

Our main forest/domain is going to need an upgrade to 2003 at some
point, so anything I learn along the way could come in handy when that
time comes.

Once again, thanks for your time
Matt

"Eric Fleischman [MSFT]" <[email protected]> wrote in message

Yup. Cognos extends by conflicting with one of our inetorg person
extensions, and causes this error.
If you want to dig into it further let me know and I can tell you how I
resolved it before.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights


Just thought I'd update this thread with the results, so Google can
archive it and it may help someone else.

It turns out that our problem is caused by Cognos Access Manager.
Access Manager has an option to store it's information AD, which is
how the person who set it up installed it (the other option is
Netscape Directory Server, which comes with the product). When set up
this way, it adds some schema extensions to AD.

What we decided to do for now is just to leave our domain at 2000.
The upgrade to 2003 turned out not to be required by the vendor, so to
save ourselves some hassle, we'll just leave it at 2000 for now, and
at some point in the future upgrade to 2003. Hopefully by then the
various schema compatability issues will have been worked out by other
people, and will be better documented and relatively easy to fix.

Thanks again for your assistance Eric.
Matt

You too Matt.
Basically the troubleshooting methodology I'd use is to use ldifde to
dump
the schema of your forest, then look at line 333 of the ldf file the
import
is failing on and search your schema to ensure that none of the unique
bits
of that line are not in use in the forest.
What is most likely (although not definite....nothing is 100%

)
is envionment

and

ensure you don't have critical data of some sort in that attribute.

Feel free to post back to this thread if you'd like more guidance.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no
rights.

 

[Matt Wright]

Hi,
Just wanted to say thanks again for your help on my problem. You were
exactly right about the OID of those attributes. We unfortunately
have cognos support through our vendor rather than directly, so I'm
waiting to hear back from them on the issue. Hopefully we'll get a
script from them to fix the problem.
Matt

BTW: I've been told that Cognos is providing a script to fix this
automatically. I would contact them before making any changes.

~Eric


--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights

Sure.
The issue is in sch18.ldf. if you were to open up ldif.err.18 in system32
you'd find the error as well.
I believe in your case they are defining PreferredLanguage with the wrong
OID. If you look in your schema you'll probably see PreferredLanguage with
an attributeID= 1.2.840.114050.1.1.1.1.90 (aka an OID).
That's not a valid OID to be using there.
You'd have to rename the existing preferredLanguage
adminDsiplayName,lDAPDisplayName, RDN, etc. to not be preferredLanguage.
Maybe name it CognosPreferredLanguage or something.

*****NOTE*****
This very well might break your application. I haven't a clue what doing
this might break. You definitely, without a doubt, before doing anything
else, need to check with the software vendor on this first.
*****NOTE******

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights

Well, since you made the offer

If it's not too much trouble, I wouldn't mind knowing how to fix it.
I'm going to check with the guy who was running the domain before
about just getting rid of the server that's using Access Manager
(maybe move it to a different forest), but if I can't do that, and the
schema problem turns out to be reasonably easy to fix, I wouldn't mind
actually fixing it. If nothing else, it'd make my boss happy and I'd
learn something that could be useful to me later.

Our main forest/domain is going to need an upgrade to 2003 at some
point, so anything I learn along the way could come in handy when that
time comes.

Once again, thanks for your time
Matt

"Eric Fleischman [MSFT]" <[email protected]> wrote in message

Yup. Cognos extends by conflicting with one of our inetorg person
extensions, and causes this error.
If you want to dig into it further let me know and I can tell you how I
resolved it before.

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights


Just thought I'd update this thread with the results, so Google can
archive it and it may help someone else.

It turns out that our problem is caused by Cognos Access Manager.
Access Manager has an option to store it's information AD, which is
how the person who set it up installed it (the other option is
Netscape Directory Server, which comes with the product). When set up
this way, it adds some schema extensions to AD.

What we decided to do for now is just to leave our domain at 2000.
The upgrade to 2003 turned out not to be required by the vendor, so to
save ourselves some hassle, we'll just leave it at 2000 for now, and
at some point in the future upgrade to 2003. Hopefully by then the
various schema compatability issues will have been worked out by other
people, and will be better documented and relatively easy to fix. )

Thanks again for your assistance Eric.
Matt

"Eric Fleischman [MSFT]" <[email protected]> wrote in

message

You too Matt.
Basically the troubleshooting methodology I'd use is to use ldifde

to
dump

the schema of your forest, then look at line 333 of the ldf file

the
import

is failing on and search your schema to ensure that none of the

unique
bits

of that line are not in use in the forest.
What is most likely (although not definite....nothing is 100%

)
is

that
either the OID or attribute name is already in use, so you need to resolve
the conflict.
It is easy to resolve a conflict like that. The only critical part

is
that

you don't break another app in the envrionment in the process, so

you'd
want

to probably take a peak in that attribute throughout the

envionment
and

ensure you don't have critical data of some sort in that attribute.

Feel free to post back to this thread if you'd like more guidance. -)

~Eric

no
rights.

 

[Eric Fleischman [MSFT]]

Glad it's moving forward. Post back if there is anything further that can be
done to help from the MS angle.

Good luck!
~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights

Hi,
Just wanted to say thanks again for your help on my problem. You were
exactly right about the OID of those attributes. We unfortunately
have cognos support through our vendor rather than directly, so I'm
waiting to hear back from them on the issue. Hopefully we'll get a
script from them to fix the problem.
Matt

"Eric Fleischman [MSFT]" <[email protected]> wrote in message

BTW: I've been told that Cognos is providing a script to fix this
automatically. I would contact them before making any changes.

~Eric


--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights

Sure.
The issue is in sch18.ldf. if you were to open up ldif.err.18 in system32
you'd find the error as well.
I believe in your case they are defining PreferredLanguage with the wrong
OID. If you look in your schema you'll probably see PreferredLanguage with
an attributeID= 1.2.840.114050.1.1.1.1.90 (aka an OID).
That's not a valid OID to be using there.
You'd have to rename the existing preferredLanguage
adminDsiplayName,lDAPDisplayName, RDN, etc. to not be preferredLanguage.
Maybe name it CognosPreferredLanguage or something.

*****NOTE*****
This very well might break your application. I haven't a clue what doing
this might break. You definitely, without a doubt, before doing anything
else, need to check with the software vendor on this first.
*****NOTE******

~Eric

--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights


Well, since you made the offer

If it's not too much trouble, I wouldn't mind knowing how to fix it.
I'm going to check with the guy who was running the domain before
about just getting rid of the server that's using Access Manager
(maybe move it to a different forest), but if I can't do that, and the
schema problem turns out to be reasonably easy to fix, I wouldn't mind
actually fixing it. If nothing else, it'd make my boss happy and I'd
learn something that could be useful to me later.

Our main forest/domain is going to need an upgrade to 2003 at some
point, so anything I learn along the way could come in handy when that
time comes.

Once again, thanks for your time
Matt

"Eric Fleischman [MSFT]" <[email protected]> wrote in

message

Yup. Cognos extends by conflicting with one of our inetorg person
extensions, and causes this error.
If you want to dig into it further let me know and I can tell you

how
I

resolved it before.

~Eric

no
rights

Just thought I'd update this thread with the results, so Google can
archive it and it may help someone else.

It turns out that our problem is caused by Cognos Access Manager.
Access Manager has an option to store it's information AD, which is
how the person who set it up installed it (the other option is
Netscape Directory Server, which comes with the product). When

set
up

this way, it adds some schema extensions to AD.

What we decided to do for now is just to leave our domain at 2000.
The upgrade to 2003 turned out not to be required by the vendor,

so
to

save ourselves some hassle, we'll just leave it at 2000 for now, and
at some point in the future upgrade to 2003. Hopefully by then the
various schema compatability issues will have been worked out by other
people, and will be better documented and relatively easy to

fix.
)

Thanks again for your assistance Eric.
Matt

"Eric Fleischman [MSFT]" <[email protected]> wrote in

message

You too Matt.
Basically the troubleshooting methodology I'd use is to use

ldifde
to
dump

the schema of your forest, then look at line 333 of the ldf

file
the
import

is failing on and search your schema to ensure that none of

the
unique
bits

of that line are not in use in the forest.
What is most likely (although not definite....nothing is 100% )
is
that
either the OID or attribute name is already in use, so you

need to
resolve

the conflict.
It is easy to resolve a conflict like that. The only critical

part
is
that

you don't break another app in the envrionment in the process,

so
you'd
want

to probably take a peak in that attribute throughout the envionment
and
ensure you don't have critical data of some sort in that attribute.

Feel free to post back to this thread if you'd like more

guidance.
-)

~Eric

confers
no
rights.