Delayed initial connection to mapped drive
I started asking about this in a different post, which dealt with a different issue; I figured it'd make sense to ask it in a separate post. We have all clients connecting to mapped network drives upon logging in, using a script.
I started asking about this in a different post, which dealt with a different issue; I figured it'd make sense to ask it in a separate post.
We have all clients connecting to mapped network drives upon logging in, using a script. Currently, we use NetWare 6.5 as our file server and have several mapped drives pointing towards directories on the Novell server. When a user selects that drive, the connection is instantaneous at all times. However, when connecting to a mapped drive that points to a Windows server, there is a delay (around 15-20 seconds). If you keep searching through that drive, there isn't a problem afterwards. But if the drive is not used after a while, the initial connection experiences the same delay.
While normally this wouldn't be a big deal, we're migrating the file server from NetWare to Windows Server 2008 and the Windows server is still having this delay upon the initial connection. This is going to drive users insane and we're going to be bombarded with support calls complaining about the delay.
To clarify, when I say initial connection, I do not mean mapping the drive when logging in. Rather, I mean opening up Explorer and opening the drive.
How do you get rid of, or at least significantly shorten, this delay on the initial connection? Thanks in advance.
We have all clients connecting to mapped network drives upon logging in, using a script. Currently, we use NetWare 6.5 as our file server and have several mapped drives pointing towards directories on the Novell server. When a user selects that drive, the connection is instantaneous at all times. However, when connecting to a mapped drive that points to a Windows server, there is a delay (around 15-20 seconds). If you keep searching through that drive, there isn't a problem afterwards. But if the drive is not used after a while, the initial connection experiences the same delay.
While normally this wouldn't be a big deal, we're migrating the file server from NetWare to Windows Server 2008 and the Windows server is still having this delay upon the initial connection. This is going to drive users insane and we're going to be bombarded with support calls complaining about the delay.
To clarify, when I say initial connection, I do not mean mapping the drive when logging in. Rather, I mean opening up Explorer and opening the drive.
How do you get rid of, or at least significantly shorten, this delay on the initial connection? Thanks in advance.
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
Think I've made progress with this. Because we were using 2 systems to authenticate on the network (NDS/AD), the clients needed IPX/SPX installed in order to browse to other machines on the network; however, simply typing in \\machine_name in Windows Explorer or Run would bring that machine up without a problem. Through trial and error in the past, I found that only having the Novell Client installed didn't fix that problem; IPS/SPX had to be installed to allow browsing of Windows-based machines in any application.
I used a test machine and removed Novell Client for Windows, along with the IPX/SPX protocol(s). Upon reboot, connecting to the Windows-based server was pretty quick, almost instant. Using additional and unneccessary networking protocols slows down network access, so I belive that is what was causing this god aweful delay.
In short, I believe the problem is solved. Thanks to anyone who read the post and tried to help.
I used a test machine and removed Novell Client for Windows, along with the IPX/SPX protocol(s). Upon reboot, connecting to the Windows-based server was pretty quick, almost instant. Using additional and unneccessary networking protocols slows down network access, so I belive that is what was causing this god aweful delay.
In short, I believe the problem is solved. Thanks to anyone who read the post and tried to help.
