XP Cannot map NDS in a mixed enviornment with 3.12/5.1 through logon script.

We have two Novell 3.12 Server and one Novell 5.1SP5 Server. All of our workstation are Win2000 with Novell Client 4.83SP1 (IP/IPX) and able to map the volumes on 3.12/5.1 servers through Novell logon script without any problem. Recently we add some Windows XP workstations with the same Novell Client, but they are facing mapping issues. On the logon process, it’s able to map all the volumes on 3.12 server (IPX), but failed mapped 5.1 server volumes (IP). It seems to me, it is something wrong with XP, as all of our workstations with Win2000 not facing any mapping issue. On Netware connection window (RED-N), 5.1 server show IPX, which supposed to be IP.

The errors are as follows:

LOGIN-4.22.00-430: The following drive mapping operation could not be completed.
    [ROOT O:=AND730S1/SYS:]
The error code was 8804.

Need help from the Novell Guru’s.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

This is a not uncommon problem in mixed protocol environments, and I think you'll find the Experts here will quite resoundingly tell you that binding both IPX and IP to the NetWare Client is a Bad Idea (tm). You've gotten away with it on the W2K clients, yes, but the problem you're experiencing now was bound to happen.

Is there some reason you're still running NetWare v3.12 (a TEN year-old OS - way past obsolete and not supported any more)? Because my advice would be to eliminate it - upgrade the server to NetWare v5.1 and get rid of IPX. Is there some technical reason that's not possible?

Basically, what's happening is the NetWare Client 32 is "getting confused" and is authenticating on one protocol and trying to do subsequent NCP operations (e.g. mapping a drive) on the other. Is IPX bound to the NIC on the NetWare v5.1 server? If it is, try unbinding IPX and running the NetWare v5.1 server on IP only.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
You are running both protocols on NW5.1 AND both protocols on the client-side.

You can only run IPX on 3.12 (it had "sort-of" IP support but was not worth the effort.)  You need to have IPX on your client in order to access 3.12.
You may NEED to run both IP and IPX on your NW5.1 server, for server intercommunications with the 3.12's, and possibly for products that may be in use on NW5.1 that require IPX.  Although NW5.1 prefers IP, if you run an IPX/SPX-dependent product on your NW5.1 server, you still need IPX, or compatibility mode.

If you have not gone the compatibility-mode route, you may be stuck with the IP/IPX mix on both client and server.  If that is the case, you need to be very careful with how you install and configure your client.

If you want IP to be the primary connection to NW5.1, then you need to make sure that IP is the preferred protocol.  You will want to have either the server and tree in a hosts file on the client, or have SLP configured properly on the server.  If SLP is properly configured, you may need to modify the client's SLPDA properties, to make sure it isn't timing-out on SLP discovery and reverting to IPX/SAP.  You should specify the preferred tree, preferred server and context in the client properties - don't defer to NDS at this point, because the IP SLP discovery timeout with IPX/SAP taking over is more likely to happen if you don't specify everything in a mixed-protocol setup.

I also strongy recommend you update your client to 4.83 SP2 with the latest post-sp2 patch.  It would be a good idea to hold off for a while yet, on upgrading to the 4.90 client, as there are some bugs yet, but you are on a "known-buggy" service release of the 4.83 client.
I concur with PsiCop that you really have to examine why you are still running such an ancient version of NetWare in your environment (ancient in computing terms - acutally, almost antique.)

If you are using a custom application that has not been updated to work on a more modern version of NetWare, that makes some sense to me.  

However, if your NetWare 3.12 servers are solely for file-and-print services, there is no reasonable reason to leave them on a long-unsupported and very obsolete version of NetWare even though the Energizer Bunny is jealous of how NetWare 3.12 "just keeps going, and going, and going..."  

If it is a hardware thing - "we just don't want to get rid of these 386 servers, because they cost so much 10 years ago and still work" - that is not reasonable.   Today's hardware is so inexpensive in comparison, and so many times more powerful and stable in comparison to what was available back then, the hardware costs should not even be considered - especially since MACRS rules would have those servers fully-depreciated years ago.

The potential cost of running an obsolete, unsupported version of any software should be enough incentive for just about any situation to at least spur a desire to *examine* the costs and benefits of getting to a supported-version status.  In order to be on a supported version, you have to upgrade your 3.12 servers to 5.1 at minimum; all older versions are off support.

Given the relative inexpensiveness of modern hardware and the benefits to be obtained by upgrading to the current version of NetWare (6.5) you might find it more than reasonable, even compelling, to get yourself off the obsolete, bindery-only, unsupported 3.12 platform and onto a new box with NetWare 6.5.  You could probably get away with consolidating your servers, and might even be able to upgrade the entire server plant to two 6.5 servers in a 2-server cluster with everything that was on the other servers being done by the one server-image being presented by the cluster.
Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

By the way, the 8804 error in the login script is often a sign of a corrupt volume object in NDS.

Because it is not consistent across all of your clients, it would be a good idea to run an "unattended" DSREPAIR operation.  If you get errors, run it again.  If you can't get rid of all the errors with multiple runs of the DSREPAIR "unattended" option, let us know and we can give you some help on how to fix it.

If the unattended DSREPAIR won't fix it, it could very possibly mean a corrupted volume object in NDS, which requires more drastic measures.
Yet another possibility is that WinNT, Win2K and WinXP all have the same "character flaw" of wanting to map-root everything, and not properly handling a ROOT mapping in a NetWare login script.  Since you say it only happens with new WinXP PCs and not with previously-existing XP/2K clients, it might be that the MapRootOff = 1 system environment variable was added to the individual clients' environment settings, and the new ones, not having that in their environment, are experiencing the problem..  

Maybe you need to add the system environment variable "@set maprootoff=1" to your container login script, before any drive mapping statements (is that the right syntax, DSPoole?)

When you installed the  client, did you choose custom options  IPX & IP  (Not IPX Compatibility)?
eutaylorAuthor Commented:
Thanks both of your help. I tried with DOS SET MAPROOTOFF=1 at the logon script. I also maprootoff=1 at the XP Workstation at Environment Variables. Our entire client installed with IP/IPX option. I also run DSREPAIR and did not fount any error on it. I also run the health check utilities and found the NDS is healthy. I tested both the client version 4.83SP1 and SP2, but no result.

I can able to ping my 5.1 servers from the XP workstations by with the server name as well as IP address. I also tried to map a drive with server name as well as IP address, its prompt for user logon into the server and its able to map manually.

But my actual problem is not exactly above. I have a logon script which running in 3.12 box, which supposed to map some drives of 3.12 server and some drivers of 5.1 server, And its works fine with all of ours W2K workstations. But its do not working with XP workstations, its drops 5.1 drive mapping. On the XP workstation if I logoff and log back again, then the logon script execute correctly and mapped all 3.12 and 5.1 server drives. (i.e. its works only, while I log off and log back again, but not with Restart).  I unable to trace out any solution.

Will appreciate you advice
To make sure I understand the situation -

You have your 3.12 servers as your primary login servers
Within your 3.12 login script, you have drives mapped to your 5.1 server.

You have a mix of Window 2000 Professional PCs and Windows XP Professional PCs.
All of them are using the 4.83 client with SP1, with both IP and IPX (not compatibility mode)
All of the 3.12 connections are, of course, via IPX.
All of the 5.1 connections are supposed to be via IP.

This setup works for all of the Win2K Pro PCs but none of the XP Pro PCs.  
The only way to get the 5.1 connections to work is to log in a second time using the login option off of the Novell client systray menu.

Does this sound right?  Anything to add, or anything I got wrong?
there is a distinction between IPX & IP  and IP with IPX Compatibility, if you're using the former, ok

You're doing:
Attach nw312
map h:=nw312/sys:

In which login script?

If you are logging into 3.12 first, how do you have your client configured?  Do you specify a tree or context?  Tree and context only apply in an NDS environment, so if the primary login is 3.12, that should not be specified in the client, but rather in the 3.12 login script.

I don't know why, if you have Win2K and WinXP workstations, you'd want to login to 3.12 first.  It would make more sense to login to 5.1 first, and then attach to the 3.12 server(s) for the bindery access, from the 5.1 container login script.

Why it works that way with Win2K Pro but not with XP Pro, I'm not sure, but I believe it would work the other way around, logging into the tree first, and then attaching your bindery-only objects.

I'll let you know if I find anything...  otherwise, you may want to reconsider your login order.
Do you get a second login prompt on your Win2K PCs when the login script hits the mapping to the 5.1 server?
You might want to read this TID:

It talks about how the Novell clients use the IP and IPX protocols.  You may get a clue to your problem from that.

I still recommend that you change your login order to login to the tree first, then attach your bindery-only objects from your container login script.
I agree you should log into the tree and attach/map in the ou or user script.
eutaylorAuthor Commented:
The Win2K PCs does not prompt for second login in prompt. It’s straightway map two server drives. I am still working through with the TID. Thanks,
eutaylorAuthor Commented:
Comment Time 6:38 am,
All sounds right except the last line, if I log off from start>shut down>log off  and log back, its work fine (Not from client systray menu).

Comment Time 6:46 am,
On the Client Installation, selected IP/IPX both protocol, no the IP/IPX capability.
The way of the set up is, logon into the 3.12 server first and the logon script is like:

Comment Time 10:00 am,
We logon in 3.12 server first and its map the 5.1 server drive through logon script in 3.12 server.

The start/shutdown/log off process is like a system reset without resetting the hardware.  It could have something to do with how the WinXP PC is being recognized by the server, which could have something to do with client provider order.

It Seems like somehow the setup on the Win2K Pro clients is authenticating to the 5.1 server transparently, but not so for the XP Pro clients.

Do you have all of the NetWare client properties set identically between the Win2K Pro clients and the WinXP Pro clients?  Protocol preference, preferred tree, preferred server, context, etc?

If all of those client properties match, go into My Network Places, Properties, and select the "advanced" menu.  Select "Advanced Settings."

It starts out on the Adapters and Bindings tab.  Make sure that under "Bindings for Local Area Connection" that for the Novell Client for Windows, both TCP/OP and IPX/SPX are checked, and place the IPX/SPX protocol above the TCP/IP protocol.
Then, Click on the Provider Order tab.

Make sure that NetWare services is on top, above Microsoft Windows Network, within the Network Providers section.
Sorry, miskey.  I typed TCP/OP when I meant to type TCP/IP.
>We logon in 3.12 server first and its map the 5.1 server drive through logon script in 3.12 server
I think you should turn that round, log into the tree and attach to the bindery servers, unless you want bindery logins to the 5.1 servers.
What is the big deal of not using IPX on both servers?
Unless you are running a cluster,running all IPX is not going to break anything(except rconj,which sucks anyway).Uninstall IP from Novell client(NOT the TCP stack)and run IPX only.It will be faster and more reliable.
I have had more issues running an IP only envionment than you can shake a long stick at,
(Backup sofware not working,database issues,printing problems,duplex mismatches,SLP not finding resources,timesync)and the list goes on.
Don't let ANYBODY at Novell tell you that IP works better on a Novell file server than IPX.It just ain't so.
IPx may, in smaller networks, have a speed advantage over IP for simple data transfers, but don't let anyone tell you that IPX is a technologically superiour transport protocol for ALL the things that NetWare environment needs.

For example, switching to TCP/IP lets you get rid of router-clogging SAP broadcast, because you can implement SLP.

I cut my teeth on NetWare v2.12a and IPX and I have as much respect for that as anyone. But there is NO WAY I would want to go back to running a mixed-protocol IPX/IP environment on any scale. TCP/IP is an all-around better protocol suite, much more versatile, and the slight performance benefits from IPX do not outweigh the added management difficulties of running a dual environment.
TCP is a superior WAN protocol.

However,it's implementation on NW 5.x and 6.X can get ugly.The following are examples if issues I have run into using TCP as opposed to IPX:

1.SMP and TCP stack causes issues with ECB count and dropping connections(this one gets fixed and broken with every sp release)

2.Try Ghost or PowerQuest imaging in an IP only env .Not pretty.

3.IPX dependencies with Backup Exec and Arcserve .(they keep on fixing this,but ...)

4.SLP not registering services (NDPS)in a cluster situation.I had to load SCMD to fix this.The folks at Novell are less than helpful in resolving this issue.

5.Duplex mismatch problems on switches.IPX is a whole lot more forgiving if somebody screws this one up.

6.As for RIP/SAP,NLSP if done right ,works just fine in reducing broadcast packets.

7.IPX is plug and play and secure.TCP is not (right out of the box).You got to set up PKI to get a decent level of security.

8.IP only- NDPS or else.I have had some wonderful problems with abends and NDPS.(and that wonderful gateway HP released a year or two back)Better now ,but still suspect.. Lots less problems when running IPX.

Depending upon my enviornment(and looking at this one)running IPX only would not be a bad idea..
1) I've seen similar issues with IPX and ECBs over the years (since 1989)

2) We use ZENworks. Works great.

3) That's not Novell's fault nor a reason to run IPX. NetWare has natively supported TCP/IP for over FOUR YEARS.

4) Which version of Cluster Services? I recall this being an issue in v1.0 - current is v1.7

5) If someone doesn't know what they're doing, they shouldn't be doing this. IPX being "forgiving" merely means the real problem was masked. I'd rather see people use unforgiving TCP/IP and be forced to get it right.

6) I'd rather eliminate them.

7) This doesn't make the slightest sense. IPX is no more (or less) secure than TCP/IP. The data payloads are still transmitted in the clear in IPX. You also ignore IPSec, which has no IPX equivalent.

8) When a vendor makes a crappy NDPS gateway its going to fail no matter what the transport protocol.

Here's a free Clue: Novell is leaving IPX. TCP/IP is pretty much the de facto standard for networking communications. Its no more or less secure than IPX, and there's a helluva lot more work being done in TCP/IP to provide security services than you'll find IPX.

You advocate IPX, let's see you set up a webserver for your company to communicate with its clients over IPX. Or an E-Mail server to send E-Mail to other companies over IPX. Or do anything else in IPX except in your little LAN.
eutaylorAuthor Commented:
Thanks everyone for your valuable time and comments. I tied the following and it’s worked with me.

1.      I installed the Client installed IP/IPX and selected IP as preferred protocol in the
Client protocol.

2.      On the Local Area Connection/NWLink IPX/SPX/NetBIOS  Property, Entered
INTERNAL NETWORK NUMBER as Server ID of 5.1 server and Selected Frame Type as Ethernet II and its mapping all the drives without any problem.
I know this is way over a year old, but I was perusing old unclosed Questions and thought I'd mention that the problem's cause is probably how the login processing was changed for WinXP.  There's a registry tweak that probably would've fixed this from the get-go, but it wasn't widely known at the time.

The tweak has to do with processing login scripts synchronously, or some such.  If this is still an issue for some odd reason, over a year-and-a-half later, I'd be glad to post the tweaks in detail.

Otherwise, eutaylor, you should post a free Question in Community Support, with a link to this Question, asking for this Question to be PAQ'ed with a refund, saying you solved it yourself (but I think it was a workaround rather than a solution), OR you should close it yourself and spread the points around to the Experts that you found helpful.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Novell Netware

From novice to tech pro — start learning today.