Link to home
Start Free TrialLog in
Avatar of cwsoft05
cwsoft05Flag for United States of America

asked on

Problems with drive mappings, NMAS created problem.

We have a computer that had nc4.91sp2 loaded.  No problems.  Changed the IP address from class C to class D.  This process during login caused the NMAS related internal errors. The tried to remove nmas simply by uninstalling NMAS via Add/remove programs.  Since then, we are getting problems with mapping drives to our 2 server.

Server 1, Drive Mappings
          F: Sys
          G: Vol1
          N: Vol5

Server 2, Drive Mappings
          Q: Sys
          K: GW
          H: Data
          M: Dept

Typically after a computer restart, it all appears to map okay but when you browse my computer, it has F as server2\sys: instead of server1\sys.  Q is also mapped to server2\sys:.  Another scenario is that F may be mapped properly but then the first mapping attempted in the login script to server2 does not work.

We have tried the TID to remove the Windows\system32\novell\nici data, uninstall nici, uninstall nmas.  No system.  We get the groupwise error on file ccwin32.dll or something like that that another TID talks about being an incomplete NICI uninstall.

We also tried reinstalling the 4.91 client with all latest public patches and then as someone recommended uninstall via add/remove programs in this order:  NICI, NMAS.  We received an error when trying to remove NMAS.

We do not need NMAS.  How do we properly and completely remove all remnants of this program.  What registry items need to be removed so it is not seen or used at all.

How do we fix the drive mapping problems.

Windows XPsp2 is on the Dell laptop.

Cliff.
Avatar of ShineOn
ShineOn
Flag of United States of America image

What is the NetWare version/SP?  This is key.
Do you have IPX on the servers and/or client PC's as well as IP?

Have you tried the uninstall/reinstall in this order:

1) uninstall the client via add/remove programs.  Reboot.
2) Uninstall NICI and NMAS.  Reboot
3) Install the client using Custom (NOT "Typical"), choosing one protocol, IP (unless IPX is required for some reason) and deselecting ALL not-in-use features, ESPECIALLY NMAS and NICI (note: you need to have NICI on your admin workstation.)
4) After the reboot, go into the client32 properties, Advanced Login tab, and set "NMAS Authentication" to "No" - while you're there, in Advanced Settings, set File Cache to "Off" and File Commit to "On."


To "fix" the drive mapping issues you have to a) change your login script or b) enforce which server your client authenticates to.   If you are running NetWare 6.0 or better, you shouldn't need to enforce a login server, but if you need to have the F: drive be server1\sys, you have to specify it's that volume specifically in the MAP command, instead of simply saying "SYS:" or using default mappings.

Do you have NO_DEFAULT in your login script?
Are you using the Novell-recommended volume-object syntax in your MAP commands?
ex: "MAP ROOT F: = .server1_sys.myou.myorg:"
not: "MAP ROOT F: = SYS:"  
p.s. - this is not an NMAS-created problem - it's just a coincidence.  I will explain:

My guess is that this is a client-version jump for you from, say, 4.83, which didn't include the NMAS client, and you are running a non-NMAS-integrated version of eDirectory or NDS, which is why you got the NMAS error at login - because the client was looking for NMAS methods and getting something back it didn't like.
Avatar of cwsoft05

ASKER

We do not have NO_DEFAULT in our login script.

Every mapping is in the format of MAP f:=ServerName\SYS: and so forth.

NW65sp5 with post sp5 patches for server.exe and nss (used the combined post5sp patch install)

We have both IPX and IP loaded on servers and workstations (IP is preferred protocol on workstations).  We need IPX for an application.

Have tried different uinstalls, but not with the intermediate reboots and not in that order.  Will try those.
We went from 4.83 quite some time ago, first to 4.9sp2 and now 4.91sp2.  I think 4.9 automatically installed nmas.  We have Edir 87.3.8 and the servers were a 2nd new 6.5sp4thensp5 install.  Original server was an inplace nw51 to nw65 upgrade.

We would just like to get these corrected.  We have stopped loading NMAS but have this what appears to be one remaining problem.
There are very few instances where you should stray from the recommended volume-object mapping syntax.  One is clustering.

Outside of a clustered environment, 99% of the time using volume object names in your MAP command works best.

I was wondering - did you mean you changed from class C to class B, not class D?  I'm not aware of class D addressing...
Yes, when we had a single server, we used the straight map f:=sys:, but changed when we added a 2nd server.

I meant Class B addressing (if only the fingers always worked correctly).
Just a thought.  When you changed IP addresses on the servers, did you do a dsrepair/imanager repair process to repair server addresses?  If not, eDirectory can be pointing to the wrong address for services and confuse things for authenticated users.  

Further, did you verify that all instances of the old address on the SYS volume of both servers was changed to their new addresses?

Do you use DHCP for your clients, using the DHCPSRVR.NLM, with DHCP doling out tree, server, slpda, slp scope and so on?  Did you change those DHCP options to the new server addresses if you used IP and not DNS?

Did you change DNS to make sure all references to the old IP addresses have changed for all A records?  Did you create new reverse-lookup zone(s) (in-addr-arpa zones) for the new addressing or is the old reverse zone still there?
Note:  this is affecting only one single computer.  We had a similar problem with our citrix server even before the IP address change.  We could not uninstall nmas.  That appears to now be okay after we reinstalled the client.

We did a dsrepair and limber per the TID and used remote manager to do the changes.  We changed all addresses that we are aware of that remote manager did not.  DHCP was modified.  DHCP does not dole out the tree, server, slpda, slp scoe at this time.  It never did before.  

We do not use Novell DNS at this time.  We currently point to the ISP's dns and some workstations, due to an application point to the IP address of the windows 2003 domain controller which also provides DNS. for those workstations only.  The address were changed her but this workstation does not point to this address for DNS.

I tried the procedure you provided.  NMAS was automatically deleted when the client was deleted.  I delete NICI separately thereafter.  I changed the novell client settings with a workstation only first login.  Then restarted and F: was mapped to Server2 incorrectly.  I then went to login script and added NO_DEFAULT.  It appears to currenty work properly after two restarts.  I am monitoring this.

Again, this is affecting only one computer.  My computer is a basically identical Dell laptop (I have different things loaded) but it has not had any problemes since I uninstalled NMAS.  I still have nici.

Hmmm.  You added NO_DEFAULT.  So you were using the default login script which has some mappings, including, IIRC, F:

Do you have errors and details display turned off in the login script?  I wonder if you're getting errors that aren't showing up because errors are turned off...

If you don't have any NMAS nethods installed, the NMAS client can cause problems, but since installing NMAS on the servers I haven't had problems with the NMAS client piece accidentally being installed.

It sounds like you did all you're supposed to do when you change IP addressing.

Do you by any chance have a Windows 2000 Pro (or server) PC on the network (not WinXP or 2K3 server)?
If so, use it to search your SYS volumes for the old IP address.  Win2K's search isn't crippled like WinXP's is.  I don't know that the IP address change is the cause, but it seems like too much a coincidence to me that the 4.9 client worked without NMAS errors before the address changes.

How about local HOSTS files, do you have any of them populated with any server addresses/hostnames?
It is only on one computer.  And we had the same problem prior to the IP address change.  It is just that some of the internal error's reoccurred .  We originally had the internal error during login on some computer with the 4.91sp1 client.  They went away with the 4.91 sp2 client but reoccurred on a selection of clients when we did the IP change.  We went from workstation to workstation to do an initial login to make certain they worked on some had the internal error.  Reinstalling the client with NMAS turned on, NICI on, eliminated the problem except for these lingering issues.  

Again, we were already mapping F: to server1\sys:  We do not have errors or display turned off.  We see the errors if one occurs from time to time (i.e. no security for a user to a drive mapping).  

What does it take to install NMAS on the server and what are the advantages, caveats.  I have not researched this at this time.

We had some host files on some computers, like for arcserve, but we changed all those but could have missed one.
ASKER CERTIFIED SOLUTION
Avatar of ShineOn
ShineOn
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial