Help - Non-Developer Troubleshooting NWDSLogin Failure by
Third-Party App - Error 34961 / Shell error: 0x8891

Hi all and please help.

I'm a non-developer trying to troubleshoot a problem with a third-party
application.  Please be gentle.

The app syncs passwords in multiple eDir trees by using a proxy account to
affect the changes for the user. The app logs in with an account that has
rights to certain password-related attributes.  The account uses the same
name and is in the same context in each tree.  The app is a browser-based
application running on Windows 2000 sp3 build 2195  and using NetWare Client
4.90.2.20040617 to login to the eDir trees.

The app's primary server connection is to a server running NetWare 5.1 SP7
with eDir version 8.6.2.  The primary connected server in the other tree is
running NetWare 6 SP5 with eDir version 8.7.1.

We are seeing increasingly sporadic failure of this application, typically
on a Monday morning when password change volume by users is high.  The app
is also starting to fail during the week.   Rebooting the app server used to
fix the problem but that appears to be no longer guaranteed.

The app reports a successful password change operation as:

NWDSSetContext tree edirtree returned 0
NWDSSetContext context [Root] returned 0
generate key as admin OK.

The above is then followed by other messages not germane to this issue.

A failed operation is typically reported as:

NWDSSetContext tree edirtree returned 0
NWDSSetContext context [Root] returned 0
NWDSLogin failed (34961/Requestor / Shell error: 0x8891)

Sorry, but this is all I have on the problem so far. I don't know which
object is attempting to log in on the failure but I suspect it is the proxy
password change agent.

My questions are:

1. What is the nature of this error?  All I can find is
REQUEST_NOT_SERVICEABLE for error 0x8891, which is apparently related to the
Client.  Is error 34961 more descriptive? If so, what does it mean?  Is it
an authentication problem with the proxy password change account or is it a
problem with changing the password of the target user account?  My
understanding is that an NWDSGenerateObjectKeyPair call is being made at
some point in the procedure and my guess is that 'generate key as admin OK'
message is the return from that call.

2. What tracing tools do I need to gather more information on this error?
Pktscan on the NetWare Server?  Would DSTRACE on the server help and, if so,
what should the settings be?  Or should I concentrate on tracing / debugging
on the client rather than the server?  If so, what tool(s) should I use?

3.  Finally, is this a NetWare/Novell problem or the third-party app
problem?  Would a NetWare OS or eDir upgrade resolve this problem,
particularly on the NW5.1 tree?  If it's the app's problem, I want to 'speak
with facts' when bringing this to their attention.  (BTW, the server hosting
the app has gone through an NT4-to-Win2K upgrade and a series of NW Client
32 upgrades since it was installed.  The app upgrade history is sketchy but
I suspect the app is built on an older version of the NDK. Could this be an
issue?)

We expect to see a significant increase in password sync activity in the
near-future due to a merger.  Of course, we want this to go smoothly and
resolving the issue in some fashion will certainly help.

Thanks in advance for any assistance.

Dave Braun
Ameren Services

David,
> I'm a non-developer trying to troubleshoot a problem with a third-party
> application.  Please be gentle.
Well, I'm not a support guy and don't have answers to all your 
questions, but some things that may help you. Btw, did you try the 
support forums?

> 1. What is the nature of this error?  All I can find is
> REQUEST_NOT_SERVICEABLE for error 0x8891, which is apparently related to
the
> Client.  Is error 34961 more descriptive?
Well, 34961dec is 8891hex, so it's the same code.

> My
> understanding is that an NWDSGenerateObjectKeyPair call is being made at
> some point in the procedure and my guess is that 'generate key as admin
OK'
> message is the return from that call.
Judging from the message, your app could not log in. At whichever point 
it was, but see below.

> 2. What tracing tools do I need to gather more information on this error?
> Pktscan on the NetWare Server?  Would DSTRACE on the server help and, if
so,
> what should the settings be?  Or should I concentrate on tracing /
debugging
> on the client rather than the server?  If so, what tool(s) should I use?

PKTSCAN and Ethereal can help you see what goes on on the wire (i.e. 
communication between the client and the server).
IIRC, Ethereal has an NCP decoder and can show you if NCP calls (which 
is, what the client does on behalf of the application) fail or succeed.

> 3.  Finally, is this a NetWare/Novell problem or the third-party app
> problem?  Would a NetWare OS or eDir upgrade resolve this problem,
> particularly on the NW5.1 tree? 

Don't know, I know nothing about specific problems with concrete 
eDirectory versions :-)

David Braun wrote:

> Hi all and please help.
>
> I'm a non-developer trying to troubleshoot a problem with a third-party
> application.  Please be gentle.
>
> The app syncs passwords in multiple eDir trees by using a proxy account to
> affect the changes for the user. The app logs in with an account that has
> rights to certain password-related attributes.  The account uses the same
> name and is in the same context in each tree.  The app is a browser-based
> application running on Windows 2000 sp3 build 2195  and using NetWare
Client
> 4.90.2.20040617 to login to the eDir trees.
>
> The app's primary server connection is to a server running NetWare 5.1 SP7
> with eDir version 8.6.2.  The primary connected server in the other tree
is
> running NetWare 6 SP5 with eDir version 8.7.1.
>
> We are seeing increasingly sporadic failure of this application, typically
> on a Monday morning when password change volume by users is high.  The app
> is also starting to fail during the week.   Rebooting the app server used
to
> fix the problem but that appears to be no longer guaranteed.
>
> The app reports a successful password change operation as:
>
> NWDSSetContext tree edirtree returned 0
> NWDSSetContext context [Root] returned 0
> generate key as admin OK.
>
> The above is then followed by other messages not germane to this issue.
>
> A failed operation is typically reported as:
>
> NWDSSetContext tree edirtree returned 0
> NWDSSetContext context [Root] returned 0
> NWDSLogin failed (34961/Requestor / Shell error: 0x8891)
>
> Sorry, but this is all I have on the problem so far. I don't know which
> object is attempting to log in on the failure but I suspect it is the
proxy
> password change agent.
>
> My questions are:
>
> 1. What is the nature of this error?  All I can find is
> REQUEST_NOT_SERVICEABLE for error 0x8891, which is apparently related to
the
> Client.  Is error 34961 more descriptive? If so, what does it mean?  Is it
> an authentication problem with the proxy password change account or is it
a
> problem with changing the password of the target user account?  My
> understanding is that an NWDSGenerateObjectKeyPair call is being made at
> some point in the procedure and my guess is that 'generate key as admin
OK'
> message is the return from that call.
>
> 2. What tracing tools do I need to gather more information on this error?
> Pktscan on the NetWare Server?  Would DSTRACE on the server help and, if
so,
> what should the settings be?  Or should I concentrate on tracing /
debugging
> on the client rather than the server?  If so, what tool(s) should I use?
>
> 3.  Finally, is this a NetWare/Novell problem or the third-party app
> problem?  Would a NetWare OS or eDir upgrade resolve this problem,
> particularly on the NW5.1 tree?  If it's the app's problem, I want to
'speak
> with facts' when bringing this to their attention.  (BTW, the server
hosting
> the app has gone through an NT4-to-Win2K upgrade and a series of NW Client
> 32 upgrades since it was installed.  The app upgrade history is sketchy
but
> I suspect the app is built on an older version of the NDK. Could this be
an
> issue?)
>
> We expect to see a significant increase in password sync activity in the
> near-future due to a merger.  Of course, we want this to go smoothly and
> resolving the issue in some fashion will certainly help.

Dave

In 15+ years of working with NetWare, I've not seen this error. The 0x88 prefix
indicates that the error is generated at the client workstation rather than
returned by the server. I would guess that the problem lies with the clients
inability todetermine where/how to send a request to the tree that you have
just
made the default. NWDSSetContext does not communicate with the server, but
NWDSLogin does. Are you using IPX or IP and if IP is SLP correctly configured?
Are you experiencing any other issues of this nature? What is the state of the
workstations connections to various servers after this error has been reported?

Probably one of the simplist things to try is a change of client version - add
the latest support pack if not already done, otherwise backrev if you are using
the latest. All the recent client releases and patches have had their quirks
and
this just might be one of them.

Good luck, John
DevServ SysOp 24

John,

Thanks for the reply.

IPX is not in play; we are running IP only.  We have had some issues with
SLP and we'll check the SLP config on the client.  I'm not holding my
breathe with back-revving the client as we've been patching and upgrading it
in an attempt to solve the problem.  We've been struggling with the issue
for some time.

Good news is we have not had problems this (Monday) morning.  Hopefully a
round of dsrepairs on the primary server and some SLP tweaks in the
directory made last week will fix the problem...for a while, anyway.

DB


"John Baird" <john@jrbsoftware.com> wrote in message
news:4206C678.FCD004B5@jrbsoftware.com...
>
>
> David Braun wrote:
>
> > Hi all and please help.
> >
> > I'm a non-developer trying to troubleshoot a problem with a
third-party
> > application.  Please be gentle.
> >
> > The app syncs passwords in multiple eDir trees by using a proxy
account
to
> > affect the changes for the user. The app logs in with an account that
has
> > rights to certain password-related attributes.  The account uses the
same
> > name and is in the same context in each tree.  The app is a
browser-based
> > application running on Windows 2000 sp3 build 2195  and using NetWare
Client
> > 4.90.2.20040617 to login to the eDir trees.
> >
> > The app's primary server connection is to a server running NetWare
5.1
SP7
> > with eDir version 8.6.2.  The primary connected server in the other
tree
is
> > running NetWare 6 SP5 with eDir version 8.7.1.
> >
> > We are seeing increasingly sporadic failure of this application,
typically
> > on a Monday morning when password change volume by users is high. 
The
app
> > is also starting to fail during the week.   Rebooting the app server
used to
> > fix the problem but that appears to be no longer guaranteed.
> >
> > The app reports a successful password change operation as:
> >
> > NWDSSetContext tree edirtree returned 0
> > NWDSSetContext context [Root] returned 0
> > generate key as admin OK.
> >
> > The above is then followed by other messages not germane to this
issue.
> >
> > A failed operation is typically reported as:
> >
> > NWDSSetContext tree edirtree returned 0
> > NWDSSetContext context [Root] returned 0
> > NWDSLogin failed (34961/Requestor / Shell error: 0x8891)
> >
> > Sorry, but this is all I have on the problem so far. I don't know
which
> > object is attempting to log in on the failure but I suspect it is the
proxy
> > password change agent.
> >
> > My questions are:
> >
> > 1. What is the nature of this error?  All I can find is
> > REQUEST_NOT_SERVICEABLE for error 0x8891, which is apparently related
to
the
> > Client.  Is error 34961 more descriptive? If so, what does it mean? 
Is
it
> > an authentication problem with the proxy password change account or
is
it a
> > problem with changing the password of the target user account?  My
> > understanding is that an NWDSGenerateObjectKeyPair call is being made
at
> > some point in the procedure and my guess is that 'generate key as
admin
OK'
> > message is the return from that call.
> >
> > 2. What tracing tools do I need to gather more information on this
error?
> > Pktscan on the NetWare Server?  Would DSTRACE on the server help and,
if
so,
> > what should the settings be?  Or should I concentrate on tracing /
debugging
> > on the client rather than the server?  If so, what tool(s) should I
use?
> >
> > 3.  Finally, is this a NetWare/Novell problem or the third-party app
> > problem?  Would a NetWare OS or eDir upgrade resolve this problem,
> > particularly on the NW5.1 tree?  If it's the app's problem, I want to
'speak
> > with facts' when bringing this to their attention.  (BTW, the server
hosting
> > the app has gone through an NT4-to-Win2K upgrade and a series of NW
Client
> > 32 upgrades since it was installed.  The app upgrade history is
sketchy
but
> > I suspect the app is built on an older version of the NDK. Could this
be
an
> > issue?)
> >
> > We expect to see a significant increase in password sync activity in
the
> > near-future due to a merger.  Of course, we want this to go smoothly
and
> > resolving the issue in some fashion will certainly help.
>
> Dave
>
> In 15+ years of working with NetWare, I've not seen this error. The 0x88
prefix
> indicates that the error is generated at the client workstation rather
than
> returned by the server. I would guess that the problem lies with the
clients
> inability todetermine where/how to send a request to the tree that you
have just
> made the default. NWDSSetContext does not communicate with the server, but
> NWDSLogin does. Are you using IPX or IP and if IP is SLP correctly
configured?
> Are you experiencing any other issues of this nature? What is the state of
the
> workstations connections to various servers after this error has been
reported?
>
> Probably one of the simplist things to try is a change of client version -
add
> the latest support pack if not already done, otherwise backrev if you are
using
> the latest. All the recent client releases and patches have had their
quirks and
> this just might be one of them.
>
> Good luck, John
> DevServ SysOp 24
>
>

Christian,

Thanks for the reply.

I'm familiar with both Pktscan and Ethereal. I also have Sniffer available
for tracing.

Any suggestions on a tool for tracing the client's internals?

DB


"Christian Hofstaedtler #55" <devforums@novell.com> wrote in
message
news:JlTMd.11$jd1.6@prv-forum2.provo.novell.com...
> David,
> > I'm a non-developer trying to troubleshoot a problem with a
third-party
> > application.  Please be gentle.
> Well, I'm not a support guy and don't have answers to all your
> questions, but some things that may help you. Btw, did you try the
> support forums?
>
> > 1. What is the nature of this error?  All I can find is
> > REQUEST_NOT_SERVICEABLE for error 0x8891, which is apparently related
to
the
> > Client.  Is error 34961 more descriptive?
> Well, 34961dec is 8891hex, so it's the same code.
>
> > My
> > understanding is that an NWDSGenerateObjectKeyPair call is being made
at
> > some point in the procedure and my guess is that 'generate key as
admin
OK'
> > message is the return from that call.
> Judging from the message, your app could not log in. At whichever point
> it was, but see below.
>
> > 2. What tracing tools do I need to gather more information on this
error?
> > Pktscan on the NetWare Server?  Would DSTRACE on the server help and,
if
so,
> > what should the settings be?  Or should I concentrate on tracing /
debugging
> > on the client rather than the server?  If so, what tool(s) should I
use?
>
> PKTSCAN and Ethereal can help you see what goes on on the wire (i.e.
> communication between the client and the server).
> IIRC, Ethereal has an NCP decoder and can show you if NCP calls (which
> is, what the client does on behalf of the application) fail or succeed.
>
> > 3.  Finally, is this a NetWare/Novell problem or the third-party app
> > problem?  Would a NetWare OS or eDir upgrade resolve this problem,
> > particularly on the NW5.1 tree?
>
> Don't know, I know nothing about specific problems with concrete
> eDirectory versions :-)
>
> /Chris.