PDA

View Full Version : Computer peeps..Server 2003 question..


G-Rex
12-05-2008, 07:21 AM
Ok, so I just connected a new Windows 2003 Server, accessing it with Windows XP Pro and Windows 2000 Pro.

I don't have the whole thing online totally yet, as the old NT server is still running, because of a problem I am having.

The main job of the server is file storage. I do have it set up as a PDC, with DNS and DHCP configured.

The problem I am having is file access. When I try to open an AutoCAD file, the system practically locks up. It drags to the point that it tells me the file is invalid. I can copy the same file to my hard drive and it opens quickly and perfect. No troubles.

The cabling is not in question. Connectivity is fine. Even Word and Excel drag a little bit, but at least they open. Although, if i open Explorer and try to double click on the file there, it will lock the system up too. I'm at my wits end and any suggestions would be very welcomed!

I'm going to call Dell this morning and hope that I talk to someone I can understand. I haven't had such good luck with that in the past.

Papa_Complex
12-05-2008, 07:29 AM
It might help the server types if you can say how you're accessing it. Are you using UNC pathnames? Drive mappings? Are there any UNC pathnames or drive mappings that have recently been eliminated? This can result in long delays, while Windows decides whether the dead links are still valid. If you have the "Web Client" service enabled on the XP box (it is by default), then XP will look for web content on any folder that it tries to open. This also slows things down. Then there's the way that Windows looks for Scheduled tasks on every remote folder. I don't have the registry hack handy, but it's one entry that needs to be changed, in order to disable this.

*EDIT* I did a quick search and found that system time settings can also cause issues with remote access speed. Have you matched the time zone on the 2003 server to your location and are both systems time synchronized (or at least close)?

G-Rex
12-05-2008, 07:46 AM
I've tried accessing both ways Rob. Right now, I have a netlogon.bat file setting drive mappings prior to user login. Everything is current and fresh. I don't know if Web Client services are enabled. If it is by default, then it probably is, as the XP boxes are new also.

There's also a line in the netlogon.bat file to synchronize server and desktop times. I hope this helps to start. I spent ALL day yesterday messing with it, as well as a good friend of mine was logged in from home helping me with it. He's confused too, and he has a couple hundred 2003 Servers deployed at his company.

Help!

It might help the server types if you can say how you're accessing it. Are you using UNC pathnames? Drive mappings? Are there any UNC pathnames or drive mappings that have recently been eliminated? This can result in long delays, while Windows decides whether the dead links are still valid. If you have the "Web Client" service enabled on the XP box (it is by default), then XP will look for web content on any folder that it tries to open. This also slows things down. Then there's the way that Windows looks for Scheduled tasks on every remote folder. I don't have the registry hack handy, but it's one entry that needs to be changed, in order to disable this.

*EDIT* I did a quick search and found that system time settings can also cause issues with remote access speed. Have you matched the time zone on the 2003 server to your location and are both systems time synchronized (or at least close)?

Papa_Complex
12-05-2008, 08:10 AM
It's worth manually checking the date, time, and time zone settings on both boxes, just to be safe. As I've frequently found over the last 20 years of desktop support, just because something SHOULD happen, that doesn't mean that it DOES ;)

You would be best off removing the NT box from the network while testing this, so obviously this will have to be done at a time when production isn't necessary.

It's easy to disable Web Client on the XP box. If that doesn't help, then you can always re-enable it later. Go into Control Panel and set it to "classic view", then call up Administrative Tools, then services. Scroll down toward the bottom and find Web Client. Double click it, stop the service, then set it to disabled. Reboot and try again.

Clear the "recent documents" list from the XP box. Make sure that there are no links in My Network Places that point to resources that no longer exist. Turn off the antivirus, or uninstall it completely. See if you can access the shares faster via IP address than by name (I've seen this more than a few times).

I looked around and found the registry entry for Scheduled Task searches on remote computers. It's in this location in the registry, on the XP box:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Explorer\RemoteComputer\NameSpace\{D627 7990-4C6A-11CF-8D87-00AA0060F5BF}

First export it so that you can restore it later, if you want to. After that, delete that registry entry and reboot. There's another entry in the same group for printer searches that can be deleted too, with the same recommendation to back it up first. This used to be a HUGE speed issue here, when we had a mixed Windows/Novell server environment.

*Another EDIT* I forgot to ask what service pack level the server was at.

G-Rex
12-05-2008, 08:39 AM
Ok Rob, I verified the time stamp is the same on both system.

I also disabled Web Services on my XP system, and deleted the two registry keys you suggested.

I am still having the problem. Although now, I'm confident it's a network issue and not an AutoCAD or Office issue only. I tried to open a file across the network using Notepad, and it locked that up also. Ridiculous I say.

Off to the net for more google! Any more suggestions are greatly appreciated. I'll try not to be too much of a pain in the ass today. :idk:

Edit: The Server is Windows 2003 Server R2 with Service Pack 2.

Papa_Complex
12-05-2008, 08:43 AM
OK, so the fact that it's at SP2 confirms that the known folder access speed issues that I was able to find have been dealt with. I've got a coupl eof work orders to take care of first thing this morning but Fridays are usually slow around here, and it's exam time, so I'll have some more time later to dig into it for you.

G-Rex
12-05-2008, 08:52 AM
Thanks Rob! I'm still searching, so I'll update as things happen.

Papa_Complex
12-05-2008, 10:28 AM
A few more questions:

When you copy the file locally in order to test whether it will open faster locally than it does over the network, does it hesitate in the same way when you start the copy? Does the copying take place quickly?

Do you have another system with a different OS (Vista, Linux w/SAMBA, etc) that could be used to verify that this behaviour is specific to WinXP and Win2K?

Did you try the idea I posted about using IP instead of system name? Perhaps mapping the drives by \\###.###.###.###\{share_name} would work better, if the issue has to do with name resolution?

If you set up a temporary share on one of the Win2K/WinXP systems and then access it from another, do you get the same results?

What other services are being run from the server. It's acting as PDC, DHCP server, and file server, but is it also the mail server or internet gateway? The more that you have the one system do, the more it'll bog down.

G-Rex
12-05-2008, 11:13 AM
1) If I put the files I want to open on my desktop, they copy quickly, they open quickly, just the way they should.

2) I have only XP and W2K in the office. I accessed the server a couple of days ago with W2K, and as I recall, it seemed fine, but I don't recall for sure.

3) I cannot map via IP either.

4) The server is only configured with DNS, DHCP, PDC, and file server. That's all it does. It's a 2.0ghz, Dual core pentium with 4gb of ram. It should be up to the task.

In speaking with my resident tech guys, they think it's a hardware issue, as I noticed this morning I'm getting a Hard Disk 0 Seek Failure on boot up. The machine does have a raid card in it, so I don't know where the issue is. But, I'm about to call Dell and see about getting some hardware replaced.

So that's where I'm at so far. I'm open to more ideas though!

Thanks again for your help!

A few more questions:

When you copy the file locally in order to test whether it will open faster locally than it does over the network, does it hesitate in the same way when you start the copy? Does the copying take place quickly?

Do you have another system with a different OS (Vista, Linux w/SAMBA, etc) that could be used to verify that this behaviour is specific to WinXP and Win2K?

Did you try the idea I posted about using IP instead of system name? Perhaps mapping the drives by \\###.###.###.###\{share_name} would work better, if the issue has to do with name resolution?

If you set up a temporary share on one of the Win2K/WinXP systems and then access it from another, do you get the same results?

What other services are being run from the server. It's acting as PDC, DHCP server, and file server, but is it also the mail server or internet gateway? The more that you have the one system do, the more it'll bog down.

Rsv1000R
12-05-2008, 11:34 AM
Something that I've found helpful is opening the task manager/network tab and have it display both transmit and receive data while you're testing, you can easily see delays, and poor bandwith usage issues.

I've also seen some wierdness with transmit rate when the network card defaults are set to Auto, you might want to specify 100base T or whatever your backbone supports.

Papa_Complex
12-05-2008, 12:42 PM
1) If I put the files I want to open on my desktop, they copy quickly, they open quickly, just the way they should.

2) I have only XP and W2K in the office. I accessed the server a couple of days ago with W2K, and as I recall, it seemed fine, but I don't recall for sure.

3) I cannot map via IP either.

4) The server is only configured with DNS, DHCP, PDC, and file server. That's all it does. It's a 2.0ghz, Dual core pentium with 4gb of ram. It should be up to the task.

In speaking with my resident tech guys, they think it's a hardware issue, as I noticed this morning I'm getting a Hard Disk 0 Seek Failure on boot up. The machine does have a raid card in it, so I don't know where the issue is. But, I'm about to call Dell and see about getting some hardware replaced.

So that's where I'm at so far. I'm open to more ideas though!

Thanks again for your help!

I was wondering more about the speed at which the copying over from the server initiates, rather than opening the file once the copying is complete.

Is this box running a RAID-5 config, or is it just mirroring? Striping? If it's mirrored and one drive has gone dead, then that could account for why it's so slow.

RSV is right about connect speeds. I've seen Dell units get confused about the link speed and try to push 1Gb, though the switch is only able to handle 100Mb. This gives a dog slow network performance that you can even see in IE/Firefox.

Avatard
12-05-2008, 01:40 PM
A few more questions:

When you copy the file locally in order to test whether it will open faster locally than it does over the network, does it hesitate in the same way when you start the copy? Does the copying take place quickly?


Guys, I forewarn all that I am about to say with the disclaimer that I am a computer dinosaur, and perhaps am not up on the latest, but this sounds familiar.

I think the question asked above is crucial. Furthermore, do other apps suffer from the same access problems? In the very same network folders?

If not, consider this:

Some apps just don't like their shit on a netshare, and kinda freak out, because internally, they don't handle path shit correctly.

my $.02

G-Rex
12-05-2008, 01:43 PM
Rob, it doesn't hesitate when I start the copy. BAM it starts and goes. It's quick.

The server is running Mirrored with 2 drives. I'll have to verify the NIC, but I think it's set to Auto.

Online with Dell tech support now. More to come.

Papa_Complex
12-05-2008, 01:43 PM
Guys, I forewarn all that I am about to say with the disclaimer that I am a computer dinosaur, and perhaps am not up on the latest, but this sounds familiar.

I think the question asked above is crucial. Furthermore, do other apps suffer from the same access problems? In the very same network folders?

If not, consider this:

Some apps just don't like their shit on a netshare, and kinda freak out, because internally, they don't handle path shit correctly.

my $.02

That's why I asked the earlier question about mapped drives having been tried; some apps just don't like UNC pathnames. If Windows takes care of the mapping and presents it like a local drive, then they usually do OK.

If even copying the files results in a delay, then the issue is more likely server side. If it's when the file is opened, then it's probably client side. No guarantees, but on average...

Papa_Complex
12-05-2008, 01:44 PM
Rob, it doesn't hesitate when I start the copy. BAM it starts and goes. It's quick.

The server is running Mirrored with 2 drives. I'll have to verify the NIC, but I think it's set to Auto.

Online with Dell tech support now. More to come.

After you try what they recommend and if it doesn't work, try locking all of the NICs at 100/half duplex and see if it helps.

Aero 1
12-05-2008, 01:52 PM
are both the NT server and the new 2003 server acting as DNS servers? there could be your conflict. Also, you didnt set DFS shares on the 2003 did you?

Papa_Complex
12-05-2008, 01:56 PM
are both the NT server and the new 2003 server acting as DNS servers? there could be your conflict. Also, you didnt set DFS shares on the 2003 did you?

That's why I suggested testing by file copy. That didn't have any issues, so a DNS conflict shouldn't be the issue. It's also the reason that I suggested trying it with the NT box disconnected.

G-Rex
12-05-2008, 02:01 PM
are both the NT server and the new 2003 server acting as DNS servers? there could be your conflict. Also, you didnt set DFS shares on the 2003 did you?

The 2003 Server has DNS running, but not the NT server. I'm 'bout to kill this whole damn thing! Demoted the 2003 Server from a PDC to a workgroup too.