programs load slow

Windows Server 2003 enterprise running as a domain controller, file server, DNS server, DHCP server. Latest updates installed.
XP Pro workstations, all with latest updates.

Problem 1
We have a software program that utilizes an Access database which is server based, with workstation setups required. One of my XP Pro workstations takes an incredibly long time to open the database, but once loaded, navigation is normal. Accesses all server shared files at normal speeds as well. I can open the database with Access rather than the software GUI at normal speed. I have already tried re-installing the workstation setup.

Problem 2
I have two other XP Pro workstations that navigate at normal speeds, open the database file at normal speed, but take an incredibly long time to open most any server based Word document, jpg, Excel file, Adobe file, drawing file, etc etc. If I open Word or any of the other programs on the workstation (which open at normal speed), then use File>Open to view the server based files, they open immediately. Opening local based files is normal speed as well.

In all, there are 15 workstations accessing the server at any given time. No others are having problems. Problem #2 is more important a problem to resolve.

TIA for any and all suggestions.

 

Not quite sure what you mean, Steve. Are you saying that if I access the share(s) via \\server\folder\file, I should instead try 192.168.*.***\folder\file? I use both \\server\folder\file and mapped drive with no difference.

I also should have mentioned that on any server based file, right click context menu and file delete is very slow. Right click context on local machine's server based shortcuts are slow as well.

 

As always - check all the workstations are using the server for their primary DNS

 

All are using domain server as primary dns and as dhcp server. ISP as alternate dns and router as gateway.

I've had this setup in place for 3 years. These problems have just occured within the past couple of months. I had thought maybe a Windows update might be the culprit, and feel I could probably rule out an update on the server since only 3 workstations are affected. Maybe not.

All workstations are current with Windows Updates too, so would expect more to be affected, or fewer. The affected machines are not the same build.

1 Dell Intel based approx 4 yr old
1 AMD based custom built, approx 1 yr old
1 Dell AMD based approx 6 mo old << this one loads the database slowly, everything else OK.

I have 2 other Dells in the bunch which remain unaffected. I do not allow OEM software updates either.

 

All connections are TCP/IP

Software GUI is E2 Shoptech

I've cleared all dns caches with no effect. Run disk cleanup/disk check on all machines.

I tried using \\192.168.*.***\servershare\folder\file a few moments ago with no effect.

I'll look into the Browser service info this evening when I have more time.

 

Yes, E2 does use SQL (statements for running tasks, etc). They have an SQL database version too, but we are using the Access version.

TCP and named pipes??

Server has been rebooted and shut down to clean out the real cobwebs several times.

 

Gotcha. Will do.

 

cliconfg made no difference, although TCP and named pipes were not enabled. I'm guessing that was for in the event E2 was running on an SQL server database?

Tony,

Had a look at the Computer Browser service link. The referenced error does not appear in the event viewer, nor does any other event RE: the Browser Service.


Thanks all!

 

I've tried using \\192.168, \\server and mapped drive letter. Behavior with E2 is the same always.

 

Hello Dave

You give so much of your time and do such a good job, that I decided to ReUp to the BBS just to make a few suggestions for your own problem.

I have had these symptoms under 3 or 4 different circumstances.

Here are the ones I remember. You can shotgun by doing them all at once (if you just need to get it over with for your client) but please do them in the order given!

The below applies to the work station not server (to many other work stations work correctly for this to be a Server issue).

1. Disconnect (unmap) the connection.

2. Note static settings if not DHCP, and set to DHCP.

3. In device mgr un-install the NIC, reboot to let it reinstall. (I've seen damaged NIC drivers cause similar problems several times). Updated NIC drivers would be good!

4. Reset TCP, Paste following to command prompt then reboot again:

netsh int ip reset c:\resetlog.txt

4. Paste the following to the command prompt:

netsh interface ip delete arpcache
ipconfig /flushdns
ipconfig /release *
ipconfig /renew *
ipconfig /registerdns
nbtstat -RR

5. Remap share and test.

6. Restore any Static settings if cleared as directed above to use DHCP.

Mike

 

Hi Mike!

First, your ReUp (on the up and up) to WindowsBBS in an effort to help me is appreciated. I am often still in awe of your depth of knowledge into the workings of Windows, and your willingness to share that knowledge, as well as your ability to share it on a level that's understandable for the user.

Thank you!


I never even thought to do anything with the NIC drivers, since 2 (3) different workstations with different hardware were affected at approximately the same time. Nor had I considered doing anything with the IP addresses. (all PCs in the network are static BTW) I had assumed that since network browsing and internet access/speeds were all normal, that was an indication the problem would lie elswhere. I will implement your suggestions asap.


FYI
Today I checked binding on the server and found the LAN was first in order.

I configured this server with the RRAS role about a year ago. I removed the role just prior (maybe a month) to these problems surfacing, due to;
(1) a couple of unresolved internal application connectivity issues (network copier/scanner/printer document manager software and an RS232 communications software license manager which resides on the server)
(2) the need for remote access didn't outweigh the problems presented in #1
The server has two NICs ..... a gigabit for WAN and a 10/100 for LAN.
The WAN is used for server internet access only (all workstations are configured to use the router for gateway) with an IP of 210.
The LAN has an IP of 212 and that is the address the workstations use for primary DNS.
It has been my intention to disable the 10/100 and set the gigabit IP to 212 since removing the RRAS role ..... just haven't gotten to it, nor do I know if it's advisable. I was just going to do it and see what happens

 

Good!

OK if using static ip's. Then are you also using static dns setting in Local area connection?

As an aside if you are using static ip and dns on local area connection then in services you could disable DHCP and DNS client. I would also turn off windows media sharing (unless this required for this business). If they are not web developers then also turn off Web Client.

Also it may be another share on those work stations that may be causing this problem. If the user has mapped other shares to say other work station drives or printers I would disconnect the share to these while testing the primary share to the server.

If there are Auto printer shares in the printers folder then I would turn off network crawling and delete all Auto mapped printers and directly map only the printer the user needs.

In a case like this I usually clear the event logs (makes them easier to read) reboot and immediately recheck the logs. And after the issue recheck them again. Have you noticed any events?

Mike

 

Yes, static dns as well.

I will disable dns, dhcp, media sharing and web client tomorrow. None are needed. Should I still do the above steps RE: static-dhcp-remap-reset too? (NIC uninstall/re-install and driver updates are a given To Do task)

Only one mapped share, and it's the server share. No shares on any workstations.

The only printers shared on any of the workstations are the ones that have been added manually. One problem workstation is mapped only to the network scanner\copier\printer, the other is mapped to that and one other shared printer on another workstation.

One workstation has some events consistent with a separate issue that I cleared on several other workstations by disabling a service. Cannot remember the particulars at the moment, and only saw those events earlier today, yet didn't have a chance to address it. I'll take care of that tomorrow as well and see if that makes any difference. I will post that info when I have it in front of me too.

The other workstation had only one event error showing up, which I didn't even look into yet. Think it was 1517, but it's late and I could be mistaken.

 

Yes I believe I would do all.

I have never been able to pinpoint the exact cause as I am always trying to get my client working asap so usually shotgun it with all of the above. Especially since it is so simple and fast to do.

A thought occcured that you might just try the share under DHCP while it is enabled to see if there is any difference before going back to Static.

If OK under DHCP but not Static or not would be good to know and be helpful for further trouble shooting.

On the sharing of the scanner disable it also and test with just the disk/folder share. If OK then add back the scanner share and see if the problem is related to the scanner.

Mike

 

Update

(did I mention that this network is at my place of employment? I took over administering it a short time after being employed as the maintenance guy, which I still am. I handle the admin responsibilities by default, when I find time between my other duties, because I'm the only one there with a clue about computer configuration and troubleshooting.)

Today I did all of the suggested things not previously done, on 1 workstation.

1. Unmapped network drive
2. Set IP to DHCP
3. Uninstalled NIC and updated drivers
4. Reset TCP
5. Flushed arp and dns, renewed IP, registered dns
6. Removed network scanner/printer/copier
7. Remapped share and reset static IP
8. Disabled dns, dhcp and web client services

Not at any time during the process was there any change. I had previously understood that this workstation was only affected with the documents, drawings, right click, etc issue, but found today that it is also suffering the same issue with loading the E2 database.

This workstation has application event errors 1054, 1030 and 1005, which a separate couple of workstations had a few months ago. They never suffered from any noticeable issues, and although I don't remember the steps I took to resolve the errors (I failed to make note of it), I know that it did involve disabling a non-essential service. I spent a bit of time researching those errors again today as well, following a few steps outlined in a kb article that included accessing the sysvol\domain.name share using the dns address (which was successful), running the netdiag command (which was not a recognized command), and the gpupdate command (which did not reproduce the errors and reported successful). Errors are still produced upon restarting the machine.

Now, after all of that, I went to the workstation who's only issue is the slow loading of the E2 database (we're talking 2+ minutes after selecting the database to load) and started uninstalling Windows Updates. After removing everything back to Dec 12, except for the netframework updates I applied on the same day, with no change in behavior, I checked for available System Restore points. The earliest was dated Oct 29, and I rolled back to it. Problem with E2 was resolved. Other than Windows Updates, the only changes to the system since then was the updating of a locally installed document viewer used by E2. I re-installed that software update already and E2 loading remains normal. In the days to come, I will be one-by-one re-installing all of the Windows Updates in an attempt to pinpoint one as the cause.

I thank you all for your assistance and I will update this topic with any new developments.

 

I want to start out this update with a summary.

First off, I only learned of these problems 3 days ago, reported by 1 user on 1 workstation, and was informed the problem had been present for near 2 months That was the 4 year old Dell, having a serious delay when opening server based documents, jpgs, drawing files, right clicks, etc. User reported that E2 opened normally. First thing I did on that machine was to disable the antivirus/firewall to check for conflict there ..... no help. I was then told the custom built 1 yr old amd based pc was experiencing the same delay (user said E2 logon was fine), and that is the one I started doing most of the diagnosing on, as it was easier to free up. I then was told about the 6 mo old amd based Dell having issues with E2 logon, and subsequently did the system restore.

Today, back on the custom build, I attempted to logon to E2 to find it too was delayed, despite the user telling me it was fine. The delay was not as long as on the other, but it was noticeable to me. For some reason, despite having dismissed antivirus/firewall as culprit based on the other machine's behavior, I shut it down. The E2 database loaded blazing fast, no delay opening server based files, no right click delay. Hmmmm ....... I'm running Zone Alarm Pro on all of the workstations, and this is the only one running the newer version ( I didn't upgrade any others). This version has the embedded ScanningProcess.exe running. So, I renamed ScanningProcess.exe to prevent it from running to see if it had any effect. It did not. I then stopped the zlclient.exe process, to no effect. Only when I stopped the TrueVector service, effectively stopping all Zone Alarm processes, was E2 loading and all other behavior normal. So, I uninstalled Zone Alarm and re-installed the previous version. E2 logon was again delayed. Shut down ZA and all was fine.

Now, I go to the 6 mo old Dell with E2 logon problem, the one I felt has normal load time after the system restore, and shut down ZA. The E2 database loaded not what I previously felt was normally, but blazing fast.

I took a few minutes on both machines to check Zone Alarm's settings for program and component access, making sure all E2 componets had full trust and unrestricted access, and found nothing I did helped.

I have yet to determine if the problem lies in a Zone Alarm definitions update, a conflict with something running on both machines, or what. If/when I get it sorted, I'll post it here. If anyone has suggestions, let em fly.


I still have not been able to touch the machine that was originally brought to my attention. When I do get another shot at it, rather than disable Zone Alarm, I'm going to uninstall it and see what happens.