New client.. Terminal Server issue..

Edge Tech NY

Member
Reaction score
5
Location
Long Island, New York
Hey Guys,

I have a client with 6 offices in my area. All the offices are VPN'd with a sonicwall 200 series to 1 main office. The main office has 2 servers, one being a terminal server. Every remote office logs in with a generalized login "office2". Throughout the day, PC's from each office will d/c from TS or lag. The TS is 36gb RAM and can easily handle the load. Internet speed in each office is 25mb down 5mb up.I turned off all firewalls on every workstation and made sure they were all up to date etc.

There are VoIP phones at the main office with servers. Could someone have set them up on the same cable line as the computers and it be hogging up bandwidth?

All ideas welcome..

6-10 PC's each office..
 
Last edited:
I'm curious to see what the more experienced people will say, but here are a few off the top of my head.

Also, can you narrow it down to any specific PC/PCs that this happens to?

- Check all network cables & switches; any loose cabling or old switches? Is everything Cat 6 & GigE?

- Check for updated drivers for NICs

- Firmware on Sonicwalls up-to-date?

- Is anyone streaming any media during the day? This will cause problems. Perhaps totally block services like that & see if it helps.
 
You say there are 6 offices but how many PCs are actually connecting to the terminal server?
Have you done any checks to see how much upload bandwidth is being used at the main office? 5mbps doesn't sound like enough for that many VPNs plus voip.
 
I'd add that they probably should have managed switches & business-grade equipment with the VOIP.

The VOIP could also be causing problems for you.
 
Has it always been running this way with 6 offices? My thought is they probably expanded over time. Have you thought about putting the TS on its own Internet circuit? 6 - site to site VPN puts a lot of overhead on the Internet traffic. Otherwise you probably need to track the bandwidth.
 
The key here is "how many computers are logging into the terminal server concurrently".

5 megs upstream at the terminal server host is enough for dozens and dozens. A 28.8 dial up modem is enough to sustain a single remote desktop user.

Sonicwalls have decent horsepower for VPN tunnels...however at the main office I'd want a bigger model than the little 200. When doing WANs...it's fine to have small VPN routers at the satellites, but you want a big V-8 higher horsepower monster at the central office to be the "hub" of the WAN.

Sonicwalls also have a feature to dedicate a % of the bandwidth to the VPN tunnel(s)....so I'd make sure that's been turned on, and work with some different settings. At the central office I'd dedicated a good 50% of the bandwidth to that. If you have 5 megs upstream at the central office....divide by 5 for the 5x satellite office tunnels, that's 1 meg per brand office. Dedicating a percentage of bandwidth to the VPN tunnels ensure that some office worker running pandora internet radio doesn't crush the bandwidth for VPN users.

Make sure netbios isn't enabled in the VPN tunnel configs...that sucks up bandwidth. All you need is internal DNS.

You mention the terminal server gets 70/10 for online tests...but what is the bandwidth package....is the central office on a 50/10 package? Or is it 25/5 and you just see 70/10 due to "bursting" of typical cable.

QoS settings in the sonicwall too.
 
I will check in to all that, thanks stonecat.

What about disabling the outside port for internet browsing and making them go through VPN.. or doing the opposite actually? To help bandwidth.. I might have my wording messed up wit this being im new to vpn's and firewalls..

I also noticed some PC's RDP with a external IP and some with a local IP to the TS...

I also notice the profile path and TS profile path is to the older server.. Does that effect disconnects? The load is supposed to be on new 32gb server and the profile paths are to the older 8gb server..
 
Last edited:
You generally don't want them to do their surfing and internet traffic through the VPN tunnel...it will clog up the pipe even more.

You only want traffic that needs to access resources on the other end of the tunnel..and you want to keep that traffic as minimal as possible.

I've seen many VPN tunnels setup where the lazy guys setting them up enabled netbios through the tunnel, because they couldn't (or didn't know how to ) get DNS setup and working properly, on the inside. But if you're just using the tunnel for RDP to terminal server...you don't even need DNS, just the LAN IP of the TS box. Might need DNS if those workstations at the satellite offices log into active directory at HQ though.
 
The users are only logging in to AD after RDPing to TS.. Otherwise they will minimize the RDP session with TS and browse websites and such locally (not joined in the domain). They dont web surf on the TS, just use 2 apps..
 
If it means anything.. I was just able to connect to TS from my home pc using external IP.. That cant be good.. In the offices they can do local and external.. and the VPN doesnt d/c just the rdp session.

I'm guessing last IT company was trying to see if rdping externally to avoid vpn and see if it still disconnected? FYI it still does, both local and external IP.. Random PC's in each office.. Not the whole office at once. Does that say its not VPN issue?

I raised the Dead Peer limit interval and heartbeat for now.
 
Last edited:
Maybe they punched open 3389 so outside users could connect? I don't see that as bad. (you do have to be mindful to keep the TS box patched and ensure strong passwords, especially for the Administrator account).

Also, yeah maybe A_G caught something.....I interpreted you saying they logged in with 1 account as for the workstations...but do you mean they all log into the terminal server using the same user/pass?
 
Just curious - is it common enough that running a ping or network monitor of some type would detect network issues?

Sometimes we'll break out an old version of whatsup and run a ping all day, with alerts set to email if it misses just a few pings.

I've had a location where RDP would constantly disconnect, it's been a while - I want to say it turned out to be firewall/ISP related..
 
If you're having any kind of DNS bug, it can cause netlogon errors in your RDP host. The machine keeps trying to verify the user and eventually kills that user's connection. It happens at random times with random accounts, but I've fought it in the past. More of a problem with '03 than '08.
 
I just noticed in the DC OU in AD has a old server named hhaserver2 and it was a DC.. There is only 1 DC in this network. I also see FRS errors everyday for last few months. I know they upgraded server and maybe forgot to delete old DC entries or not even demote the thing? There are also A host dns records for this old server..

"The File Replication Service is having trouble enabling replication from HHASERVER2 to HHASERVER1 for c:\windows\sysvol\domain using the DNS name hhaserver2.HHA.local. FRS will keep retrying.
Following are some of the reasons you would see this warning.

[1] FRS can not correctly resolve the DNS name hhaserver2.HHA.local from this computer.
[2] FRS is not running on hhaserver2.HHA.local.
[3] The topology information in the Active Directory for this replica has not yet replicated to all the Domain Controllers. "
 
I'm not sure how you have RDP configured but I would set static ip addresses to only allow connection to the server and block everything else if you can, otherwise it won't take long til the bots find 3389 open and it the server will get hammered at night. I would check out the server log, I know this from experience.
 
I just noticed in the DC OU in AD has a old server named hhaserver2 and it was a DC.. There is only 1 DC in this network. I also see FRS errors everyday for last few months. I know they upgraded server and maybe forgot to delete old DC entries or not even demote the thing? There are also A host dns records for this old server..

Sounds like someone "forgot" to remove the old DC in ADUC. I would check to see that all the roles and global cat are on the remaining DC..., and remove the old one. All the replication errors would be expected if someone forgot to remove the old DC. As well as the remaining DNS record.

Doubt it's the cause of your issue though.
 
The old DC was never demoted it looks like. Still DNS entries etc. I found TermDD 56 errors and TermDD 50 error with it, when a client gets d/c'd. I changed RDP secuirty from Negotiate to "RDP Security Layer" 2 days ago. It seems the TermDD 56 error stopped (could be b/c no one is working on weekend). I am still getting the TermDD 50 error though "The RDP protocol component X.224 detected an error in the protocol stream and has disconnected the client."

I also disabled NIC offloading.

Is this error Benign or will this d.c the user also?
 
Back
Top