When I remove Novell Client 4.91.5. Cannot get an IP address after reboot

This is a Windows environment. We were using the Novell Client for Windows. There is a Windows 2003 server handing out the IPs.

More information:

On the Workstation, check the files located under C:\WINDOWS\system32\drivers\etc   Specifically the hosts file.

You can also do a Regedit and search for traces of the client in the regsitry, that might be causing your problems.

Hope this helps

If memory serves, you're supposed to remove the Novell client from within the Network connection panel where you see it along with the IP stuff, perhaps the NWLINK stuff, etc.  and not from the Control panel/add-remove or using the /ACU option.  While this would be the manual way to remove the Novell client, perhaps try this method and if you still have network connectivity after reboot post back and we can try to help script things for you.

Novell installs the IP and/or the IPX stack when it installs the client. If you rip it out by the roots, I can see it happening the way you describe. Zenguy's right, I beleive - just get into the Local Area Connection properties, highlight the Novell Client for Windows item and click UNINSTALL. It should leave everything else intact...

Obviously Netware hasn't needed IPX in years, but the custom install of EVERY client up til Vista has allowed it to be installed BY THE CLIENT as an option, along with IP. Some of us are still running 4.x systems that need IPX installed.

I stand by saying that a simple uninstall of the client from the Local Area Connections properties will most likely take care of your problem.

The Novell client installer does not provide the protocol stacks.   Microsoft provides the protocol stacks - they come with Windows.

Up until Vista, the Novell client installer would simply  allow the Microsoft IPX/SPX protocol to be installed if it's not already there, and would additionally offer to uninstall the Microsoft IPX/SPX protocol for you.

The client doesn't provide it, the client installer just calls the Microsoft installer for the IPX/SPX protocol,  the  same installer you get if you go to My Network Places/Network Neighborhood (or whatever it's called on your flavor of Windows) properties and click the "Install..." button, and choose "Protocol" off the list of Network services to install, but does it silent, behind the scenes.   It's the exact same IPX/SPX protocol that Windows installs when you install the brain-dead crapware(tm) client for NetWare (whatever name they chose to call it for your version of Windows) that Microsoft shipped with pre-Vista Windows.

Novell does not now ship and has not  ever shipped any protocols with their client for Windows NT/2000/XP.  They did with earlier clients - the NetX and VLM clients and even the later DOS-based clients like Client32 for Windows for Workgroups and Client32 for Windows 95, because Microsoft didn't provide their own.  Networking wasn't their thing back then (and a lot of us think it still isn't, but that's another day's discussion.)

It is recommended by Novell to uninstall the client from Windows XP using add or remove programs.  http://www.novell.com/documentation/noclienu/noclienu/data/btx7oeb.html  

If you have Windows 2000, sure, you should uninstall it from Network Properties, but not if you have Windows XP.

No luck tying to fix the protocol stack, etc... This really appears to be registry issue...

This is what I'm seeing after 10's of installs and uninstalls.

- Install the client, DHCP works and talks on the network fine
- Uninstall client, TCP/IP works, reboot machine
- Machine cannot get IP address, Wireshark shows NO activity from the adapter at all
- Reinstall the client, TCP/IP STARTS working even before the reboot.

This leads me to be there is an entry in registry that is not getting changed during uninstall to stop relying on the Novell Client code.

Could it be the NWGINA vs the MSGINA.DLL? This entry is completely removed during the uninstall.

Thanks!

<sigh> No matter who provides the stack, the client installs and uninstalls it.

Take a look at http://support.novell.com/docs/Tids/Solutions/10017336.html

I wonder if there's any chance this might still be valid enough to be of use?

I mean, since you are messing with the client pretty deep anyhow, it's not like UNC32 is going to mess it up any worse, right?

Also, in XP the "quick switch" user control is running around in there someplace. Have you looked at the CONTROL PANEL | User Accounts to see what is hiding there so far as requiring CTRL-ALT-DEL and so on? I realize we are wandering far afield, but I'm running out of intelligent suggestions! Or even semi-intelligent ones...

The client doesn't install and deinstall protocols. The custom install options for IP and IPX simply denote how the client is configured and which protocols it will use in order to access network resources.

I've never seen this behaviour following client deinstallation and suspect the issue may be specific to your workstation build, but you say it starts working again if you reinstall the NIC? In that case I'd download devcon and push it to all your workstations, the write a little script which a) deinstalls the client, b) uses devcon to deinstall the NIC and c) reboots. The NIC will reinstall automatically after reboot and everything works again. Not a fix per se, but a workaround which will make the problem go away whilst you remove the client from all your machines.

NothingSirius, that document is not valid for this situation.  There's no chance it is valid, because it's for an entirely different OS with an entirely different client.  It almost makes one wonder if you read my post explaining at which point Novell stopped providing protocols with their clients.

You can sigh all you want, but the fact remains that this is a Windows XP computer, not a Windows 95/98 computer, and the protocols are all Microsoft's.

The only bit that may have relevance is Unc32.  Not for the version of the client they're running, and certainly not the unc32 for any 95/98 clients, but maybe if they direct-upgraded their client from an old one for which an unc32 was provided.  I think there was an unc32 for the 4.7 client, and may have been one for the 4.8 client, I don't recall offhand.

-------------------------

halhillnc, I agree with alextoft, by the way, that this is not normal behavior (or behaviour if you're from the UK) following a client uninstall, but the fact remains that you should uninstall it using add or remove programs with Windows XP, and that protocols and NICs should remain untouched.  The old unc32 program, however, had an incarnation for NT-based clients as well, as I allude to above, which was why I asked about the 4.91 SP5 client perhaps being a direct upgrade from an older client version.  Some of those older client versions did have problems (unrelated to NIC or protocol) with cleanly uninstalling, and the installer for the 4.91 client wouldn't necessarily go back and clean up after stuff it didn't install.

Barring that, there is something else going on here, for example, there are 802.1x wireless supplicants that have hooks into the Novell client.  There are antivirus products that have hooks into basic networking funcitonality.  The Cisco VPN client adds hooks into networking functionality.  Firewalls and other security apps can also add their own twist.  These are just a couple of things that could be in that category of "something specific to your workstation build."

Can you give us a rundown of all of those sort of things that are installed on your workstations?

I used to have that happen on a few client from time to time but it appeared to be triggered by anti-malware apps, FWIW.

On some machines, I'd do a quick command line entry of "netsh winsock reset" and then restart and all was fine again.

If it didn't work, in small cases, then I'd use www.snapfiles.com/get/winsockxpfix.html and that would take care of it.  I'm not saying it's your solution, or if it will even help - but I've been through similar things.

But I'll admit; I'm quite tired and about to head home after working 20 hours so I could even be posting to the wrong thread.

Maybe it helps you out - but it sounds like it could, and shouldn't do anything wrong (LSP's will need to be reinstalled if you are using them, but it does get you a bit closer to what's causing the issues maybe) so maybe you can test them out on a machine.