?
Solved

XP SP2 problems running login script on NetWare 3.2

Posted on 2005-03-03
24
Medium Priority
?
641 Views
Last Modified: 2008-03-10
OK, this is a strange beast to be sure. And before anyone starts flaming me (no names, but I've been reading the posts in the forum from someone whose screen name begins ands ends with P), I *am* an intelligent person who does his homework, been a CNE from 3.10 days, generally knows (and loves) NW. 'k?

Alright here's the scenario:

Brand new WinXP SP2 computer, no hotfixes or programs installed, squeaky clean right out of the box. Windows Firewall is disabled. Installed Client 32, v4.9 SP2, IPX/bindery only, hard set the frame type on the NIC to 802.3. The workstation is in workgroup mode (not part of a domain). When I have this configuration, I have no problem attaching/authenticating to the NetWare 3.2 server and running the login script - life is good.

If I join the workstation to a Win2K3 SBS AD domain, when I come back from the reboot, I can still attach/authenticate to the NW server, but it refuses to run the login script. I do get the default F:=SYS: and Z:=PUBLIC. From Exploder/Explorer, I can see and manually map any drive/directory I have rights to. No rights issues.

If I leave the AD domain, I immediately start running scripts again.

If I do the same scenario to a PC with XP SP1, I do not experience this phenomenon. I have tried it with desktops and laptops. I have tried Client32 v4.83 SP2 (or 3, I forget. The stable one.) I have not been able to try this with a Win2K AD domain (just in case there's something magical about 2K3 SBS AD). I cannot seem to find any hits on Google or Novell for this. Does anyone have any clues? Anyone ever seen this before?

Any positive input is welcome,

Thanks,
Wayne
0
Comment
Question by:eisenbergw
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 6
  • 6
  • 5
  • +3
24 Comments
 
LVL 34

Expert Comment

by:PsiCop
ID: 13455942
Oh, dear. I think he meant me. I guess the Asker isn't a member of my fan club. :-)

Yes, it does sound as if you've run thru all the obvious stuff. Can't be the ertzatz "firewall", since you're strictly IPX for NCP. Mismatched duplex comes to mind, but I'd expect that to be a problem independent of AD.

When you attach to the Domain, do you know if it fiddles with the GINA or with the provider order before the reboot? I'm thinking that something is getting changed in the order of network providers being accessed.

Here's an experiment that might help us eliminate the login script itself as a suspect. Join the workstation to the Domain, reboot. Log in, and of course the logins cript won't run. Now go down to the System Tray and right-click on the red N, and select "NetWare Login". Log in... does the login script run now?

If not, then it may help for you to post the contents of the login script here.

If it does, then I think we've eliminated the login script itself as the problem, and we're back to something on the workstation.

My money is on the workstation, but I have no idea what. Still, it helps to eliminate possibilities.
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 13455944
And Wayne....my bark is much worse than my bite. :-)
0
 
LVL 16

Expert Comment

by:mdiglio
ID: 13455950
Hello,
As you will soon see I'm not a netware guy...

Any errors at all if you set it to display script results ?
any chance the run script checkbox gets reset in the novell client properties?

What happens if you re-authenticate by right clicking the 'Red N' in the systray and choose netware login

Any difference between logging in as local admin vs. user ?

0
New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

 
LVL 16

Expert Comment

by:mdiglio
ID: 13455952
Sorry about the duplicate PsiCop... I didn't hit refresh
0
 
LVL 2

Expert Comment

by:ZENworker
ID: 13455998
I agree with PSI with the GINA and looking at NCP and bindery. I'd also look at Win2K3 SBS supported frame types. I assume the Win2K3 SBS can see and has permissions to the NW box.

Tough one,
ZENworker


0
 

Author Comment

by:eisenbergw
ID: 13456004
As far as the domain fiddling with the GINA or provider order, I have no idea. I see the NW script window before I see the MS script window, but I'll check the provider order in the network cp tomorrow.

If I do the red N login, the script still does not run. There are no errors displayed in the window (I have it set to run scripts and do not close the window automatically so I have time to check it out). It just doesn't do it. The results window shows me the results of a map show command where F: is mapped to SYS: and then come the search drives, with Z: going to PUBLIC. (My login script has no 'map show' command in it, BTW.) It is the hard-coded default behavior of the login process, I believe.

I will put up a copy of the login script tomorrow.

The run script checkbox does not get reset. I double check it at login time (one of the good things with Client32 that CSNW doesn't give you).

Moving to a different box doesn't help if XP SP2 is installed there, too. If it is XP SP1, this never happens. I suspect something in SP2 is screwing it up, but I'm hard pressed to drop the $$ to call either Novell or M$ tech support on it.

No difference for local admin or user.
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 13456015
Does your NetWare login script contain NO_DEFAULT ?
0
 

Author Comment

by:eisenbergw
ID: 13456019
I missed this one. I'm strictly IPX for NCP, but I do have the IP stack as well for the Windows world and Internet access. The Windows 2K3 servers are strictly IP with no access to anything NetWare except for one that has Client32 to run the DSS program (which isn't working the way it needs to, so it's going away. But that's another story.) and it has no problems running the login script. But it's a 2K3 server, not an XP SP2 workstation. The workstations are the only things straddling the fence, so to speak.

0
 
LVL 16

Expert Comment

by:mdiglio
ID: 13456069
This might sound far fetched but here it goes....

Default out of the box installations have a lot of extra software and
and may come with the bloated programs that were installed for NIC drivers.
Like Intel PRO/100 Management Software.

This has happened to me in the past and although there were no problems w/ netware scripts
I was loosing mapped drives intermittently.

Have you tried to install SP2 on an existing SP1 workstation and see if it works? You can always uninstall it.

Perhaps there is just something different with the new machines other than SP2
0
 
LVL 35

Expert Comment

by:ShineOn
ID: 13456092
How about group policies?  Maybe there's a new one for SP2 that doesn't apply on SP1 XP boxes that's affecting the Novell login script.

If I were a conspiracy theory buff, I'd say it's another attempt by Microsoft to make it unpleasant to have NetWare in the mix.  Since I'm not, it's probably a new bug Microsoft unintentionally introduced with XP SP2.

Have you tried joining the workstation to the AD domain BEFORE installing the Novell client?  Maybe the act of joining the domain is futzing up the way the client does its thing during login.

By the way, there's a LOT more good things that Client32 does that CSNW can't besides giving you the option of displaying script results or not.  CSNW is garbage from square one.  It's only useful for people that think moving to all-Microsoft is an upgrade - it helps them "prove" their point.

0
 
LVL 35

Expert Comment

by:ShineOn
ID: 13458326
Expanding on the group policy idea, run a RSOP on the workstation to see what policies it's getting.  The default policies sent the workstation by virtue of joining the domain may well have something that affects the client.  The Novell Client32 fully integrates with Windows, and uses client-related entries in the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion registry branch, among others.
0
 

Author Comment

by:eisenbergw
ID: 13460548
Psi,

Here's the sanitized script:

IF "%LOGIN_NAME"="SUPERVIS" THEN BEGIN
     MAP N:=SYS:USERS\SUPERVIS
     MAP F:=SERVER/SYS:
     MAP H:=SERVER/VOL1:
     MAP INS S16:=SERVER/SYS:PUBLIC
     NO_DEFAULT
     EXIT
END

REM - For everyone else...

MAP INS S16:=SERVER/SYS:PUBLIC
MAP N:=SERVER/SYS:USERS\%LOGIN_NAME
MAP ROOT K:=SYS:SOFTWARE
DRIVE N:
MAP H:=SERVER/VOL1:\AREV

#\\server\vol1\scanner\ezstart.exe /auto

Not much to it.


mdiglio, these are HP D220 workstations and have very little extra outside of the necessary drivers (they didn't even install the Insight Manager agents). They also use Broadcom integrated NICs now, so ProSet isn't in the picture.

Sure, *theoretically* you can uninstall SP2, but I have not seen anyone enjoy the experience. (Maybe I don't see the right people? )

ShineOn, I thought about GPs. I thought I disabled all of the GPO links during my testing, but one can never be too sure sometimes. I'll take a peek at RSOP when I get a chance. I'll see what domain before C32 does.


0
 
LVL 34

Assisted Solution

by:PsiCop
PsiCop earned 180 total points
ID: 13460653
Try inserting "NO_DEFAULT" (minus the quotes, of course) at the top of the script.
0
 

Author Comment

by:eisenbergw
ID: 13462019
OK, joining the PC to the domain and then installing C32 changes nothing.

Putting "No_default" at the top of the script does nothing.

RSOP shows the standard list of policies I would expect (password expiration, remote assistance parameters, etc), with nothing about processing login scripts that I can tell.


Next?
0
 
LVL 35

Expert Comment

by:ShineOn
ID: 13462319
The symptoms tell me that the default login script is running, probably because the client can't find the system login script.  Is it possible that the AD domain is somehow overriding access to the SYS:PUBLIC directory - like, for instance, is there a \sys\public share defined on the 2k3 server?
0
 
LVL 35

Expert Comment

by:ShineOn
ID: 13462348
If there is such a share, you can test by putting a copy of NET$LOG.DAT in there with all user access, and see if the login script suddenly starts running....
0
 
LVL 16

Expert Comment

by:mdiglio
ID: 13462513
Hello,
If you have any imaging software I would create a backup image of an SP1 machine,
install sp2 on that machine and see if the problem remains.
0
 
LVL 5

Expert Comment

by:maques
ID: 13485563
Seems like the system script doesn't run. Can you try a "user" login script, just for the fun? (A simple: MAP ROOT K:=SYS:SOFTWARE would be enough to see if that runs).
0
 

Author Comment

by:eisenbergw
ID: 13492901
maques,

Been there, done that. No scripts run at all. ShineOn, you may have something there, but I'm not sure how to find what it might be doing.
0
 
LVL 5

Expert Comment

by:maques
ID: 13494156
I'd then "escape forward", so try patches after 49psp2_pkd, list seen at:
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10090447.htm
Such as 49psp2_nwgina_12.exe, 49psp2_nwfs_8.exe...
Go to filefinder: http://support.novell.com/servlet/filefinder
type 49psp2 for the list of the downloadables.
0
 
LVL 35

Accepted Solution

by:
ShineOn earned 195 total points
ID: 13494929
User login scripts don't run either?  That would mean the client can't see the user's MAIL directory on SYS: either.   Sounds like something with the domain is overriding access to SYS vol.  The default login script is embedded in LOGIN.EXE so that explains why it can still run even if the SYS vol can't be accessed.

Are they absolutely not running, or are the mappings just not happening?  Have you tried adding a PAUSE statement with some text to display, just to see if they run at all and just don't map anything?  If that's the case, the updates Maqes suggests might help.  TID 10093621 mentions something about adding an ATTACH command to the login script but that doesn't make sense if this is the only 3.x server.
0
 
LVL 35

Expert Comment

by:ShineOn
ID: 13577271
Hello?
0
 

Author Comment

by:eisenbergw
ID: 13642063
Sorry, ShineOn and others, priorities and other such things got in the way of closing this question out. Something is happening with the domain to interfere with access to the SYS vol during login, although there is no problem attaching/authenticating to it. Our workaround/solution is to just move the login script to the Windows side and let it do the mappings from there. I can do either a "map" or "net use" command from the Windoze login script, which is actually ScriptLogic/Kixtart at this point, so I can still keep the logic features of the Netware script. It's not the answer I'd like, and I'd also really like to solve this, rather than just work around it, but I have hit a time wall and have to move on. I will split the points between PsiCop and ShineOn as they had the best suggestions, even though we never found the answer. Thanks for your help.
0
 
LVL 34

Expert Comment

by:PsiCop
ID: 13676008
See? I'm really a nice guy. :-)
0

Featured Post

[Webinar] Lessons on Recovering from Petya

Skyport is working hard to help customers recover from recent attacks, like the Petya worm. This work has brought to light some important lessons. New malware attacks like this can take down your entire environment. Learn from others mistakes on how to prevent Petya like worms.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

What's worse than having your data encrypted by ransomware? Getting attacked by a so-called "wiper," which simply destroys the data and offers you no hope of ever seeing it again.
IF you are either unfamiliar with rootkits, or want to know more about them, read on ....
Monitoring a network: how to monitor network services and why? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the philosophy behind service monitoring and why a handshake validation is critical in network monitoring. Software utilized …
This is my first video review of Microsoft Bookings, I will be doing a part two with a bit more information, but wanted to get this out to you folks.
Suggested Courses
Course of the Month7 days, 20 hours left to enroll

765 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question