Client browsing is very slow

We have a new server which has a dual 2.8 gb Xeon processor, 4 gb of ram and 80 gb scsi drives. This server is running windows 2000 with Active Directory, Terminal services, WINS, DNS and DHCP running with out any probs. EXCEPT...... when you browse clients through explorer although it will find the clients instantly it can take anything up to a minute to drill down to any shared folders or printers.

The server that this replaced, which in spec. is much slower than the new one, is configured the same but WITHOUT Active Directory and can still drill down in an instant.

Can anybody help........

Thanks

 

If the old one still works without AD, then I have to question if you are running an AD domain.

Is the new box your DC (or one of them)?

 

I have posted to you before and found you don't like to report back. Reviewed all your posts and found that to be the norm.

If it don't work. LET US KNOW!

Or let us know if it works, PLEASE!

Or tell us to got H**! BUT TELL US SOMETHING!

Rant over! Your problem.



First! Go into Services and disable Indexing!
----------------------------------------------------------------------------------
Stop windows from searching for scheduled tasks.

Save by export the following registry key
[HKEY_LOCAL_MACHINE_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RemoteComputer\NameSpace]

Find the key with this name:
D6277990-4C6A-11CF-8D87-00AA0060F5BF Delete only this!
----------------------------------------------------------------------------------

Soup up TCP/IP

Same for following save/export then edit to the following

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters

modify these values as shown

BcastNameQueryCount=dword:00000001
BcastQueryTimeout=dword:00000020
NameSrvQueryCount=dword:00000001
NameSrvQueryTimeout=dword:00000020
----------------------------------------------------------------------------------
Disable Network Access Control using IEEE 802.1X

In network Properties.
if you have an Authentication setting then choose it and uncheck the Enable network access control using IEEE 802.1X box.

If you do or do not have the above then check for 802.1X in the NIC properties and disable it. Assuming you do not have Wireless on this machine.

This should definately help but if it did not totally fix the problem then you should look closely at QOS.

One final thing take a look at this. http://www.theeldergeek.com/webclient.htm

Comment: This server is beefed up but terminal services is a heavy load. For casual use and 5 or less active sessions and a light load of fileserver functions in house you are probably OK!

But if you have a heavy load on the file server on the LAN and more than 5 active TS sessions (by active I mean doing processing and file accesses too) even this machine will struggle some. Remenber that the TS client computer is only running the TS client software and is doing no processing. The server is doing all processing. File serving is one thing, Terminal serving is another. put them togather and they get heavy!

And you best have control of these or you will have multiple logins and sessions churning away eating resources totally unnessesarilly.

Have many TS sessions better consider moving TS to a dedicated TS server.

Mike

 

Newt,

The new server is a DC the old server was just stand alone. We have just replaced the new with the old not added the new to the old............. hope this helps....

Mike

am justifyably chastised...... you are quite right, it helps us all if we report back with results.....and thanks again for taking the time to reply....

in answer I had already stopped the server searching for scheduled tasks which didn't help but will certainly try your other suggestions later when I am on-site.

I take your points with regard to the server however we had no probs with the older server except that we will want to add a further 10 or so TS clients in the future via VPN. So at present nothing has changed. Currently there are 15 TS client users running a mixture of Win98 & Xp Pro and only 3 FS users.

The reason we noticed this is that we have a large Access database that has a need to print to a variety of printers. Those printers that have a print server with their own I.P. address have no problem and are found instatntly however those that are shared off the back of a TS client take up to a minute to be found.

This is driving us nuts.........!

Thanks again

 

Are you saying that the only slow down issue is on these printers and not normal network browse?

It should take several seconds to connect to the shared printer but not minutes. THIS IS BROADBAND, correct?

Install Netbeui on those particular 98 machines and on the server.

On the 98 machines after the VPN is connected rt click the system try icon for VPN and acertain that netbeu is running.

If it is not!

I have found that in order to get netbeui to run on VPN is to use add/remove to remove dialup networking. Which will also uninstall vpn. Then go back with it. Even better after uninstall as above go back with the MSDUN 1.4 update it will update DUN which may help in itself and automaticly install VPN and allow netbeui.

Remove IPX/SPX if you are not using it, on both server and remote client. If needed in house then remove it only on remote client.

If not needed at the remote then uncheck logon to network in TS config.

Another help in terminal services client config connection options acertain that enable Data compression and cache bitmaps is checked.

In TS on the server in configuration make sure to use temps an "NOT" to clear.

Mike

 

VPN via broad band is for the future. We are having these problems locally on a 10/100 network. It is actually the printers we want the access to however in order to see them we need to be able to browse into the client and any client with our without a printer is very slow to drill down into.

I will try your earlier suggestions shortly.......... Thanks

 

Hi Tony, but that is what I told him already.

But I do the same thing myself, too much hurry quick scans not reading closely enough. Thanks I need some help here!

Cat

Now I am really confused, why TS locally when you are directly connected?

Any way now that I have dug out enough info, I understand where when and what.

So here is your answer.

Set up the VPN on these stations only as I advised in addition to TS client. Get netbeui active on this connection. This will allow improved network browsing. These stations will have to start the VPN connection before TS. So 2 connections is nessesary.

Additionally it will allow you to map/capture a printer port. (this is the only way you can print if your application was DOS based).

So to map the printer. This has to be done on the work station while logged on with TS. Go to command prompt (in the connected session) remember this is the server command prompt. So you are mapping the to the client and its shared printer.

At the command prompt type the following command:

net use lpt2 \\localtsclientname\localtsclientprintername /persistent:yes

example below

net use lpt2 \\station3\hp5 /persistent:yes

Remember this requires netbeui on both server and ts client machine and it has to be running on the vpn connection.

Mike

 

Interesting Mike. Why do you need NetBeui?

 

Hi Newt

As you know WINS and LMHOSTS lookups and broadcast queries are the 3 different ways to resolve a name.

Any these ways could be made to work I guess, but this proceedure as I outlined does not take as much prep and is fast and stable.

Netbeui opens the path and allows easy network browsing.

Additionally of course it allows files to be copied from from and to both Server and client as easy as accessing a maped drive, or browsing. Which as you know TS itself is not capable of.

Just making connection from outside with TCP/IP does not join the network. A VPN connection does, and Netbeui allows network browsing by name, easy. So that you can map a network device, ie printers. Hence VPN.

In fact using this proceedure is the only way to print from from a dos program to a local TS Client printer. Because most dos programs prints to the port and not the UNC. So it is nessesary to capture a printer port.

Even windows programs (as opposed to dos) printing is problematic in Terminal services and many buy Citrix because it has good printing functions. And maybe because they don't know this proceedure.

I know what Cat needs to do to print and do so at normal speed. But I still don't understand why he has TS clienits on the LAN, as they are already directly connected.

Mike

 

Cat

In posting the response to Newt it occured to me to remind you that you will need to open port 1723 (VPN port). For any of these that are outside the LAN and are coming in thru the router.

mike

 

Hi Mike & Newt,

Thanks again for your efforts and sorry if any confusion has ensued.............

We need to us TS throughout due to the very large size of the Access database that is run. As I say all has been working perfectly up until we introduced this newer faster server which is configured identically to the older server.

I tried your earlier options Mike but to no avail....... So I am going to rebuild the front end again from scratch monitoring this problem all the way looking at which point this problem occurs........ as I expect it to. I will report back later.

As an aside, I would welcome your thoughts as to whether there is anything additional I should be considering with regard to the installation of 2K server bearing in mind it is a dual processor with 4 gb of ram......

Regards,

Rory

 

Well since you asked....

I really don't have enough info to be to specific but you want to be paranoid about unessesary services and startups. Especially the QOS and WebClient already mentioned.

Look very closely at all services and normal auto/startups also.

I won't ask who had this idea to run TS internally to save bandwidth.

But I will ask, are you using a HUB instead of a switch and is it a 10? Or was this TS decision arrived at while on older equipment?

It must be some hoss of a database and it must be being used extremely intensively for it to effect bandwith much. Im talking about several high speed typests going full speed all day, or doing continual querys from multiple stations just as intensively. Normally if the server can handle it the LAN should also.

If there are only a few why not put them on their own switch and route them thru it? Then directly connect them. Thus solving this problem and getting normal support control back.

TS is meant for remotes and usually when I have found it running like this then it was put in as a bandaid fix when someone could not get something to work properly.

Mike

 

One other consideration catsystems. If the dB is that large, using Access for data storage/handling is a bad idea. It is an excellent package for smaller files but never designed for biggies. As the thing grows it gets slow and then it gets shaky and then it breaks.

Much better idea to use MS SQL for the tables and just use Access for the front end. There are a couple of good, free tools from M$ for moving the data from Access tables to SQL tables. And you can continue to do all the development from Access.

 

Now why didn't I think of that???????????

Oh! Must be because you are older and wiser!

Im just younger and a wise a**. Lol!

Mike

 

Thanks Newt,

Yes we realised this about 8 months ago and as we speak the DB will be going live on SQL in about 3/4 weeks time........

 

Glad to hear that because your speed issues may be all or at least partly due to that.

Young mflynn does bring up a good point though. Are you folks using a switched network or do you still have some hubs in the system?

One final note. If this is the first Access-to-SQL data port you've done, you will probably have a few things that no longer work. Some query statements that Access likes won't run in SQL. But there are SQL statements to do the same thing that Access will use so you may have to re-write a few things. Probably not many though.

 

In answer we are using switches not hubs.......

I re-installed the OS and the problem is now solved but with no solution as to why it occured in the first installation.

I re-installed the os on the 1st partition and following each installation step I tested the speed of access to the clients, consitantly getting an access time of between 1 and 1.5 seconds.

The server is now up and running as it should with all the "bells and whistles" installed and working o.k.

The only explaination I can give is that the order in which I loaded the various services and post SP3 hot fixes differed from the first installation. Not very scientific I know but its all I've got and as Mike says "if it works don't fix it "

To date we have done about 20 x 2k server installations with very few problems. This, however, was the first with a Dual Proc. leading us to think we had missed something

Thanks again guys for your contributions.........

Regards

Rory :