My company recently purchased Dell OptiPlex 760 workstations with Windows XP. The workstations are fully patched. We have a Novell network and installed the Novell 4.91 SP 5 client.
The issue we are experiencing is that after a user logs in with their username and password, the Novell Results screen is extremely slow. It takes about 4 to 5 minutes to attach to the Novell server and drives. This never happened before with any of our other workstation running the client on Win XP.
What is the issue? We tried 4.91 SP 3 on the workstation and still the same problem.
Any help and suggestions are greatly appreciated. Thank you!
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Does each line of the login script paint one by one slowly, or does it just take a long time to start?
Do you use the Windows firewall (echh) or another personal firewall? If you have another personal firewall, like one that comes with an antivirus product, did you make sure to disable the Windows firewall so you don't have twice as many firewalls working against you?
TCP/IP is the only protocol being used. IPX and IP6 are not installed. No additional firewall is installed besides the default MS. Below is what is installed in network conenctions:
Novell client for windows
Client for MS networks
File and printer sharing for MS network
QoS packet scheduler
Internet protocol (TCP/IP)
If you have servers that change often, or servers that are added and removed from the system, this will not be the solution for you. If however, you have a static environment, that is the same server(s) are active most of the time, try this:
Under Novell Client properties, select the Advanced settings tab, then:
Set Bad Address Cache Timeout to Zero
Set Bad server name Cache enabled to Off
The default is keep trying for 5 minutes (an eternity in computer time). Which would be important if you had servers coming up and down constantly.
A side note is that when these settings are set, and users try to come up when a server is down, they may have problems finding the server when its back up. This is easily fixed by having the users manually find any volume on the server using Windows Explorer. After which login will pick up the server automatically.
Again, this is only a problem if servers are coming up and down consistently. Otherwise you buy login time over having to work a little harder when a server crashes.
Hope this helps.
I do not have an answer as to why new machines would have this problem. I can only say that when we had this problem (and I don't remember if it was with new work stations), this is what our research turned up.
Microsoft's "updates" have often been a source of trouble with "working" systems. That's one of the reasons I love Novell.
>> We have an exe (TimeSync) that sets/updates the time of the workstation located on one of the Novell drives. Never had an issue before. <<
?
Is this executed via the login script? Where is this from? It's not something that's normally in sys:/public or sys:/public/win32, as far as I can tell. Sounds like a third-party utility. Was there some issue that caused you to want to use this tool?
Why not simply use the feature built into the client? Go into the client properties, advanced settings tab - there's a setting called "Set Station Time" which should be on by default. It should automatically synchronize the client PC's time with the login server's time.
If you have problems with drift, you can push out a registry tweak that will cause the built-in Windows Time service to use NetWare as its NTP time source rather than use a third-party product. I don't know that loading timesync.exe from the server has anything to do with your problem or not, but I thought I'd mention it anyway.
Regarding Windows Updates - do you use WSUS or do you have the workstations connecting to the Microsoft site directly? If you use WSUS, unless the end-users are not letting the updates take place consistently, I wouldn't suspect a Microsoft patch, but if you can see any pattern within the growth of this issue that you can correlate to a particular KB# patch installation, that would definitely point the finger squarely at Microsoft.
They may not intentionally be causing delays in NetWare login - they've won that battle, so they don't need to keep kicking Novell in the nads that way. I'm certain they used to push updates just for the express purpose of hurting NetWare, but they've got other things on their petty little minds now... like Linux.
However, the Windows Firewall may block NCP over IP unless you open the port, and since Linux also uses SLP, I wouldn't be surprised if it also blocks SLP. Third-party antivirus products have firewalls and such that interfere with Novell login processes. Trend Micro is known to cause such issues. If you're using the Windows antivirus whatchacallit thing, it might do the same.
Barring that, just for kicks, put the server IP in the server name box in the NWGINA and see if it logs in faster. If it does, then SLP may be the problem. If you have DNS set up, make sure you have an A record for the tree name, with the IP address of your SLP DA server's address. That often helps with initial name-resolution, and will help the client unicast to the SLP DA.
Also, check your Protocol Preferences tab to make sure you only have NDS, DNS and SLP highlighted in the Protocol component settings box. If you leave Host File highlighted and it's having trouble resolving names, that's one more time-out step.
In your Advanced TCP/IP settings on the DNS tab make sure you have your network's DNS suffix specified in the "DNS suffix for this connection" box, to make sure any accesses that specify hostname only will resolve to FQDN and be resolved to the IP address by your DNS server. If you have any other subdomains in your DNS setup, make a list in the "Append these DNS suffixes (in this order)" box, with the DNS suffix for this connection first in line.
To rule out a SLP issue, on the advanced tab, put the IP address of the master replica server in the Treename box and the IP address of the main server you're logging into in the Servername box.
If it is still slow, confirm that the user has a default server on their Environment page of the General tab in ConsoleOne.
Are you running anything, such as ZENworks without Container Search Policy objects in place?
Scott
See the novell documentation on troubleshooting SLP issues:
http://support.novell.com/
SLP should be setup with one or more Directory Agents. Point all your servers to these directory agents by entering them in SLP.CFG
slp.cfg:
DA IPV4, IP.ADDR.OF.DA
On the Directory Agents configure Service Location Protocol Parameters with a correct SLP Scope List. (the same SLP scope name that is entered in the SLP Scope object)
In eDirectory configure SLP Directory Agent objects for the servers that will act as Directory Agents. Point them to the SLP Scope unit and the server that runs SLPDA
Configure DHCP to hand out the SLP DA addresses.
http://www.novell.com/cool
In your clients, you can use SLPINFO /D to find out if Directory agents are found through DHCP or multicast.
You need to look through your ConsoleOne or NetWare Administrator utility to find what I will guess is an organizational unit called SLP_Scope. In it you will probably find either an object called DEFAULT or UNSCOPED. In that same OU, create a new SLP Scope object called something other than one of the two that may be there. I usually use the abbreviation letters of the company followed with a - and the word Scope.
Next look for objects known as Directory Agent objects. They will have something like SLPDA_V2<servername> and they will be in the same OU as your server objects. If you can delete them, do so. If not, at least try and remove the assignment to the physical server that will be listed.
You may need to go to Novell's download page (www.novell.com/downloads)
Once you create the scope and re-create or create at least one SLPDA (Directory Agent) object and assign that DA to the new scope you need to go into the server that you've assigned as a DA and modify the slp.cfg file adding "DA IPV4, <the IP address of the server>" and then a hard return. Save the file and exit the editor. Next go into the Novell Monitor (MONITOR.NLM) and choose Server Parameters and then Service Location Protocol. Scroll down to the scope list and press enter so you can enter in the name of the new scope object. Put the scope object name into the box and then go back to the list so you can scroll to the DA Discovery Options where you will change from 15 to 4 and press enter.
Escape out of the MONITOR.NLM and then type at the server console SET SLP RESET = ON
Next type DISPLAY SLP DA and look for the new scope, the V2 (for version 2) and for Active
You will need to complete the monitor.nlm and the slp.cfg update on each of your servers as well as the SET SLP RESET and for checking purposes, the DISPLAY SLP DA.
If you need help, I have the ability to provide remote assistance.
Hope this helps.
Scott
One quick-and-dirty way to fix this is to make sure you have your DNS populated with
Business Accounts
Answer for Membership
by: rindiPosted on 2009-10-24 at 00:08:59ID: 25651139
Make sure you only use the tcp/ip protocol, disable ipx etc if they are there. Also, if ip6 is installed, disable that.