Client Referencing Old Server 1

[cismaxz]

A few months ago we installed 4 new admin servers, a SAN storage unit and upgrade to Netware 6.0. We left our 4 old 5.5 servers in the tree with a plan on taking them out once me made sure everything was working fine. Well, we have managed to get 3 of the servers out without any problems. However on the last one we have issues...

Whenever a user logs in they authenticate and attach to the old server. We do not specify a preferred server in the client options. If I bring down the server when I try to log in my screen goes blank for about 2 minutes and then I get - Login-LGNWNT32.DLL-890: The specified server is unknown. I hit ok and then the login script processes and you can see that it again tried to attach to that server and I log in.

We are running 4.83 post sp2 update E client and older on some machines (I can not upgrade to 4.9 at this time)

This has happened on brand new machines that I set up from scratch that were not even around when all we had were the 5.5 servers.

There is nothing in the login script referencing this server.

I have cleared any reference to the server out of the registry and it still looks for that server.

Any suggestions? Thanks guys...

 

[Provogeek]

with the old server still up, remove any replicas that are on the server and see what happens.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Certified nut case
Senior Network Engineer

http://www.kiscc.com

 

[cismaxz]

there are no replicas on it. I spent over 3 hours today on the phone with gold support and still havent resolved this issue...

 

[terry712]

any nals ?

any items being distributed from the dhcp?

any legacy bindery scripts anywhere?

 

[JRaley]

I have the same problem. We had a 4.11 server in use for 5+ years. I migrated everyting to Windows Servers except for 1 legecy Application which had to run on Novell. 4.11 server - replica removed, removed from NDS with no problems. Now I get the same error as you.

I have even gotton the error down to only certain users. All my users use the same login script, but it only happens with certain ones. Same machine, different user logins produce errors on some while a clean login for some users.

Did you ever find a solution to this?
John

 

[cismaxz]

Yes, I did fix this problem. It was actually pretty simple. Once the server was removed from NDS it took care of the problem on its own.

 

[marvhuffaker]

"I migrated everyting to Windows Servers"

Well, that was your first mistake..



Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting

http://www.redjuju.com

 

[nblinstrub]

Could this result from users having the old server defined as their "Default Server" in the Environment part of their user accounts (in NWAdmin)? That would explain why the error disappeared when the server was removed from NDS.

Just a thought...

 

[HelenSpurgeon]

I was having a problem with some users not connecting properly to the server which was defined as the default server in their Novell client preferences. I checked their properties in ConsoleOne and they had no default server defined. I'm hoping this will now have fixed the problem.

Many thanks for the suggestion (albeit indirect) I was running out of things to try.

 

[terry712]

i prefer to leave these blank
as long as your slp and nds is healthy then to me they are an illogical setting - a hang up from bindery days

 

[Provogeek]

The default server property in the NetWare client does not have any real relation to the default server attribute in NDS.

With in the client, setting the default server with out setting the tree or context will put the client into bindery mode. With the tree and context it only forces the client to attach to the specified server no matter how far or how close or slow or fast or whatever. In a properly configured NetWare 6.x enviroment, you do not need to specify the default server.

The client will use SLP, DNS, and other more reliable and managable means to get the needed resolution.

Also try to remember, Novell distributes their client to work on most if not all networks out of the box. It may not work very good and apear to cause large amounts of network traffic, but it normally works. The traffic that can cause communication issues to apear are mostly from the ?cost? (blanking on actual term right now), but the client pings the network like crazy finding all of the resources and measuring the distance of the response time. I think 99% of the networks out there need this feature TURNED OFF. It's just on by default so that 1% will work (when the other 99% has issues, usually means there is an infrastructure issue).

So as you test the default server idea and find it doesn't really help, go through and verify your SLP, then verify how that SLP info gets to the clients. If you have more than one server, verify they know the scope and of the DA. SLP commands to know;

On server,

DISPLAY SLP DA ; this will show you what DA the server knows about

DISPLAY SLP SERVICES ; this will show you all registered services, all servers should match, if they don't, then someone is not talking to the DA with respect and needs to be beat.

On client,

From DOS prompt, execute SLPINFO and give it the /? switch to find out the functions, or just execute it, you need command switch for the tool to tell you anything. BTW, if you have the client installed, you have this tool on your PC. Start off with the /D switch to see what DA's it knows about.

If the clients do not know about a DA or a scope, then you need to figure out a way to get the info to them. Best is option 78 and 79 in your DHCP server to give out the info. But you can also set it with in the client it's self as static settings.

The server, you will look at the SYS:\ETC\SLP.CFG file to find out if they know about the DA. Only exception, the DA doesn't need to know about it's self, cause it already does.

You can also do an NDS health check (do it anyway, I'm sure you haven't done one for some time).

To find out how to setup SLP and how to perform an NDS health check, support.novell.com, and go to documentation, lots of help in the knowledge base to. And do come back and open a thread if you need help.



=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Certified nut case
Senior Network Engineer

http://www.kiscc.com

http://www.bluegunk.com