Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 643
  • Last Modified:

XP SP2 problems running login script on NetWare 3.2

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
eisenbergw
Asked:
eisenbergw
  • 6
  • 6
  • 5
  • +3
2 Solutions
 
PsiCopCommented:
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
 
PsiCopCommented:
And Wayne....my bark is much worse than my bite. :-)
0
 
mdiglioCommented:
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
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

 
mdiglioCommented:
Sorry about the duplicate PsiCop... I didn't hit refresh
0
 
ZENworkerCommented:
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
 
eisenbergwAuthor Commented:
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
 
PsiCopCommented:
Does your NetWare login script contain NO_DEFAULT ?
0
 
eisenbergwAuthor Commented:
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
 
mdiglioCommented:
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
 
ShineOnCommented:
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
 
ShineOnCommented:
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
 
eisenbergwAuthor Commented:
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
 
PsiCopCommented:
Try inserting "NO_DEFAULT" (minus the quotes, of course) at the top of the script.
0
 
eisenbergwAuthor Commented:
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
 
ShineOnCommented:
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
 
ShineOnCommented:
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
 
mdiglioCommented:
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
 
maquesCommented:
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
 
eisenbergwAuthor Commented:
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
 
maquesCommented:
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
 
ShineOnCommented:
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
 
ShineOnCommented:
Hello?
0
 
eisenbergwAuthor Commented:
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
 
PsiCopCommented:
See? I'm really a nice guy. :-)
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 6
  • 6
  • 5
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now