We help IT Professionals succeed at work.

Remote Desktop Error - "Because of a protocol error, this session will be disconnected"

38,640 Views
Last Modified: 2013-12-01
Remote Desktop SettingsWeird CharactersI have a Terminal Server (W2008 32bit Std. / one of Virtual Machines in a VMWare box) in one city running Industry specific application software and have a group of users in another city where they have been using Remote Desktop to connect to the Terminal Server to  run that application software for more than a year w/o a problem.

All of sudden starting a few weeks ago, ALL the users from another city (who uses remote desktop) is complaining that they are kicked off the session once or twice a day with the message "Because of a protocol error, this session will be disconnected".
I googled this message and found numerous solutions to try, so I decided to post the question because I can't possibly try/apply all of those remedies.

I am wondering if un-checking check boxes for "Visual styles" and "Persistent bipmap caching" will resolve the problem ... but then no user has changed the settings in remote desktop or know how to make these kind of changes.

So that leaves one possibility - something happened to my terminal server settings.
One  thing that I did a few weeks ago was to set up another Virtual Machine (on VMWare box) to run Norton End Point Protection Management Center. Perhaps this new virtual machine took away some of the resources from TS virtual machine?
Maybe not likely ... but I am just thinking out loud.

 In the office where we host Terminal Serve, our internet connection is cable internet with 50 mbps down /5 mbps up which is pretty good.

Can you help?
Comment
Watch Question

Andrew Hancock (VMware vExpert PRO / EE Fellow)VMware and Virtualization Consultant
CERTIFIED EXPERT
Fellow
Expert of the Year 2017

Commented:
Would it be possible to deploy a test terminal server, at your datacentre, and get a remote connection to this server, to see if the connection is terminated during the day.

This seems like a firewall, internet, connection issue.

Author

Commented:
I can set one up. Since it involves a lot of work (creating OS, Configuration, installing App, User profiles ... etc), for now I would like to approach it from different angle.
Do you have strong suspicion that somehow Terminal Server is damaged or corrupted?
Andrew Hancock (VMware vExpert PRO / EE Fellow)VMware and Virtualization Consultant
CERTIFIED EXPERT
Fellow
Expert of the Year 2017

Commented:
Very little additional work is required to test you have a good connection between your remote site, and this site.

An RDP connection to an existing Terminal Server (Administrator Access to any Server), from this remote location, will prove if there is an issue with the network.

Protocol errors are usual if the RDP connection is disrupted.
piyushranusriSystem Cloud Specialist
Top Expert 2012

Commented:
could you please confirm me this.

users from another city (who uses remote desktop)

are these user are from different geographical region or based on the city..i am pointing to regional settings.

1. access same RDP from user profile from terminal server
2. access same RDP by your credentails from their location

keep in mind ...RDP should be same

i dont think..its internet connection, firewall issue..


please share the output

Author

Commented:
@piyushranusri
"are these user are from different geographical region or based on the city..i am pointing to regional settings" ---> Yes the remote desktop users are located in a different city about 100 miles from the terminal server location.

"keep in mind ...RDP should be same" ---> Remote users have not changed any settings. I have not changed any settings on my Terminal Server.
Andrew Hancock (VMware vExpert PRO / EE Fellow)VMware and Virtualization Consultant
CERTIFIED EXPERT
Fellow
Expert of the Year 2017

Commented:
is RDP still disconnecting regularly?

does it only do it when this application is being used?

Author

Commented:
"does it only do it when this application is being used?" - Yes and that is only application that they run.

"is RDP still disconnecting regularly?" --> After I removed the W2008 virtual machine running Norton) on 11/5/2013, I only had three reported disconnects.
User1  11/6/13  3:48PM,  11/7/13 11:11AM
User2  11/7/13  12:33PM

So far today I have not heard from anyone yet. It could be they have NOT been disconnected or they have not simply reported incidents to me.
** Come to think of it, I have not rebooted the VMWare box since the problem has been reported although I rebooted Virtual Machines (Terminal Server and App Server). Maybe I should do that just to refresh everything?
Andrew Hancock (VMware vExpert PRO / EE Fellow)VMware and Virtualization Consultant
CERTIFIED EXPERT
Fellow
Expert of the Year 2017

Commented:
How many users run this application, and our connected at one time?

less than 10, or 100s?

Author

Commented:
The number of con-current logins fluctuates between 10 and 15.
The Terminal Server (Virtual Machine) has 3GB RAM and 60GB HD Space (32GB Free) assigned.
Andrew Hancock (VMware vExpert PRO / EE Fellow)VMware and Virtualization Consultant
CERTIFIED EXPERT
Fellow
Expert of the Year 2017

Commented:
if they do not run the app, do they stay connected?

and all 15 users have been affected and submitted a Service Request of disconnection?

have they all been disconnected together?

Author

Commented:
"if they do not run the app, do they stay connected?"  ---> I noticed that they simply close the Remote Desktop while leaving App open & running. I asked the users to close the APP AND LOGOFF (not just click [x] on Remote Destkop title bar). They have been better, but at the same time I don't check to see who left the session and app open every night.

"all 15 users have been affected and submitted a Service Request of disconnection?" --> only five core users seem to be complaining. But they have been doing this for 2 years and no problem all this time. As to the time of the beginning of the problem coinside with the time that I created another virtual machine to run Norton EndPoint Protection Management program and started receiving "lack of resource" email alert from it.

"have they all been disconnected together? " ---> Not sure. I can ask, but that was the reason that I asked the users to email me whenever they get this error in the future so that I can keep the log.
You  mention initially that this disconnect issue started all of a sudden. Were there any changes on the server OS, Vmware VM or network???

Were Windows updates installed recently?

Any updates to your AV software?

Is it possible you app has a memory leak? Did you check the event logs of memory related errors?

have you checked the Vmware VM performace charts for the VM?

Try to run procmon on the TS server to see what EXE/services are active when the diconnect occurs.

When the TS session drops is the TS session just dropping out or is networking to the VM dropping out as well?

Author

Commented:
@compdigit44
(1) You  mention initially that this disconnect issue started all of a sudden. Were there any changes on the server OS, Vmware VM or network???  ---> I created a new virtual machine with Windows 2008 Std. in order to run Symantec EndPoint Protection Management software that manages about 10 workstations on the network. What I gather from users was that they started having a disconnection issue about the same time when I created the last virtual machine. Based on that feedback, I shutdown the server 2008 virtual machine to see if that improves the situation.  No user reported "disconnect" issue today yet. I will have to monitor it thruout the week to see if, in fact, creation of new virtual machine was the problem. I have not done anything to TS. Windows updates are disabled on this TS.

Before answering all other questions, let me talk to the users tomorrow to see if they really have not ran into any "disconnect" issue (since I have received any email from them with this problem TODAY). We will go from there.

I will keep you posted.
piyushranusriSystem Cloud Specialist
Top Expert 2012

Commented:
waiting for reply on these points...did you check these

1. access same RDP from user profile from terminal server
2. access same RDP by your credentails from their location



please share the output

Author

Commented:
@piyushranusri
It is rather difficult to do those tests even if I can log in with users credentials to the Terminal Server from my home (for example).
The reasons are:
(1) I don't know how to use their application software
(2) I guess I can run some modules to poke around, but if I use their credentials, I will kick them out of their RDP sessions. Furthermore they say that they get kicked out once or twice during 8 hour span. So I don't know how I can act like actual users for several hours only to see if I would get kicked out.
piyushranusriSystem Cloud Specialist
Top Expert 2012

Commented:
to solve the issue dear friend, we need to look these parts also..is it possible that you take remote of user system and do this testing..and same share your system with user to login and ask him/her to check


please share the output
VMware and Virtualization Consultant
CERTIFIED EXPERT
Fellow
Expert of the Year 2017
Commented:
This problem has been solved!
(Unlock this solution with a 7-day Free Trial)
UNLOCK SOLUTION
You stated the issue happen after you create a two Vm to host Symantec. How was the second Vm created? Cloned, template etc.. Was the TS server created the same way orginally? Do the both you the same vSwitch? Do they same the same physical uplinks?

Author

Commented:
@compdigit44
Sorry about not answering your question promptly ... a kind of crazy week it was.
(1) How was the second Vm created? ---> created from ISO. Not cloned. I don't have a template.
(2) Was the TS server created the same way orginally ---> I assum so. When I took over this customer account, TS1 was already there. The important thing about the time table is that the users started having this problem around the time I created a new VM (W2008) to run Symantec Endpoint Protection Management software. But then what is puzzling is that I shutdown that VM (TS2) and it is still happening.

Should I erase the TS2 VM from the inventory all together?

(3) Do the both you the same vSwitch ---> Yes.  One network adapter is being used.
(4) Do they same the same physical uplinks ---> Yes. No structural change I have made.
Did any part of the Symantec product get install on the TS server? Are you seeing any dropped network connects to the VM? Have you review the VM log files for this VM? Where any windows updates installed recently

Author

Commented:
Did any part of the Symantec product get install on the TS server? ---> NO
Are you seeing any dropped network connects to the VM? ---> I don't know because I would not know where to go to check it out.
Have you review the VM log files for this VM? ---> where do I go to check the log?
Where any windows updates installed recently ---> it is set for "Never Check for updates".
Andrew Hancock (VMware vExpert PRO / EE Fellow)VMware and Virtualization Consultant
CERTIFIED EXPERT
Fellow
Expert of the Year 2017

Commented:
use ping to the VM from remote location.
This problem has been solved!
(Unlock this solution with a 7-day Free Trial)
UNLOCK SOLUTION

Author

Commented:
@hanccocka
Here is the result from my computer pinging IP address of VM.

C:\Users\>ping xxx.mine.nu

Pinging xxx.mine.nu [24.123.xx.xx] with 32 bytes of data:
Reply from 24.123.xx.xx: bytes=32 time=41ms TTL=51
Reply from 22.123.xx.xx: bytes=32 time=46ms TTL=51
Reply from 24.123.xx.xx: bytes=32 time=180ms TTL=51
Reply from 24.123.xx.xx: bytes=32 time=41ms TTL=51

Ping statistics for 24.123.xx.xx:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 41ms, Maximum = 180ms, Average = 77ms

C:\Users\>
Andrew Hancock (VMware vExpert PRO / EE Fellow)VMware and Virtualization Consultant
CERTIFIED EXPERT
Fellow
Expert of the Year 2017

Commented:
Yes, did you do this from remote site?

and does it fail from the users desktop, at time of error.

indicating a network fault, which could also be internet, routing failure.

Author

Commented:
I just opened Event Viewer and saw one error and one warning in APPLICATION repeating itself thru out the day and every day on TS. There was no error in SYSTEM. I don't know if these are creating problems...
Event-Log---APP.doc

Author

Commented:
Yes, did you do this from remote site? ---> yes
does it fail from the users desktop, at time of error. ---> I have not asked users to do it. They are hard to get response. They said that they can usually get right back to TS.
It seems that they get kicked out once or twice a day on average.
I have no way of knowing their network or routing ... so on so forth.

Assuming that there has been no change in remote user environment, it is happening too often.
Let me gather user's response as to how it went entire last week. That will tell me if NAV VM shutdown was any help.
Andrew Hancock (VMware vExpert PRO / EE Fellow)VMware and Virtualization Consultant
CERTIFIED EXPERT
Fellow
Expert of the Year 2017

Commented:
you need to establish if the ping stops, at the same time, they disconnect to rule out any network issue, or internet issue.
This problem has been solved!
(Unlock this solution with a 7-day Free Trial)
UNLOCK SOLUTION

Author

Commented:
ping -t <tsservername> >c:\tsping.txt ---> this is a good idea. I will run it at the same time for comparison. Too bad it does not keep the date/time.

have you check your network switch for packet errors?  ----> I have not and don't know how

Did you review the Vmware log files: host, VM etc...?  ---> I have not.  

I am still waiting for remote users to get back to me with last week's statistics. I will keep you posted.
Andrew Hancock (VMware vExpert PRO / EE Fellow)VMware and Virtualization Consultant
CERTIFIED EXPERT
Fellow
Expert of the Year 2017

Commented:
You can download a trial of pingplotter that does log graphs with time and date!

Author

Commented:
pingplotter ---> that is good to know. Thanks.

Author

Commented:
Pingplotter is not "Free"?
Andrew Hancock (VMware vExpert PRO / EE Fellow)VMware and Virtualization Consultant
CERTIFIED EXPERT
Fellow
Expert of the Year 2017
Commented:
This problem has been solved!
(Unlock this solution with a 7-day Free Trial)
UNLOCK SOLUTION

Author

Commented:
Thanks. I found it at the bottom of the page.
Sglee, could you upload the text file results of the ping test, vmware log or switch logs please so we can help you further. ;-)

Author

Commented:
@compdigit44
I am running ping test on a remote computer. I will post TXT file tomorrow morning.
Just for the comparison, I will run from my office too.
I will keep an eye out for your reply today..

Author

Commented:
@compdigit44
I just got two "ping test" results instead of one.
One thing I need to  tell you is that these remote users subscribe to cloud-based Terminal Server service. So first thing they do when they turn on their computer in the morning is connecting to off-site TS using Remote Desktop where they run Office Apps and other Apps. From that remote desktop session, they launch another Remote Desktop session to connect to my Terminal Server... so that you know.

I attached twoTXT files.
(1) From User computer - tsping_LisaPC.txt
(2) From User's remote desktop session - tsping_LisaTS.txt
tsping-LisaPC.txt

Author

Commented:
Sorry, I pressed the wrong key after uploading one of two ping test files.
Here is the second one.
tsping-LisaTS.txt
Andrew Hancock (VMware vExpert PRO / EE Fellow)VMware and Virtualization Consultant
CERTIFIED EXPERT
Fellow
Expert of the Year 2017

Commented:
so they have nested Terminal Server connections, not the best implementation!

which disconnects?

A ---> B --- C ?

A to B?

B to C?

Were they any disconnections during this record of pings?

Author

Commented:
Were they any disconnections during this record of pings?  ---> I ran PING late in the evening after users have gone home. I should really run this test during the hours when they are connected to my Terminal Server, isn't it?

which disconnects? ---> They really do not connect to my Terminal Server directly because their printers are not setup on my Terminal Server. So they connect to my TS from their cloud based TS.
Ok, if I am understanding your setup. From workstation a user open a session to your cloud TS. From her they lauch another TS session???

Here is only remote possibility, I noticed the TTL value on your ping test were low at 56. Usually a windows destop ttl value is 128. My thought is since the user are connecting to a service over the internet they could be incurring delays in contacting the service. If the responce delay exceeds 56 ms. Then this could cause a drop out.

Just a thought...

Can you please run the following command and upload results:

pathping <tsconnectionname> >c:\pathping.txt
Commented:
This problem has been solved!
(Unlock this solution with a 7-day Free Trial)
UNLOCK SOLUTION
Andrew Hancock (VMware vExpert PRO / EE Fellow)VMware and Virtualization Consultant
CERTIFIED EXPERT
Fellow
Expert of the Year 2017

Commented:
Any manner of things, such is IT!

Connecting back to a Disconnected Session can give a Protocol Error!

But hey, it's fixed, gone away, until next time....

if IT was perfect, we would not have jobs!

Author

Commented:
So you think their rdp habit (leaving apps open, clicking X and reconnecting to the same session with apps already open) was the source of the problem?
If that is the case, they have been doing that for 2 years.
They started to complain about the same time when I set up a cm for Symantec.
Andrew Hancock (VMware vExpert PRO / EE Fellow)VMware and Virtualization Consultant
CERTIFIED EXPERT
Fellow
Expert of the Year 2017

Commented:
It would be very difficult for us to confirm for sure, and even more difficult without a site visit.

Our Terminal Service setups for clients are disconnect and logoff at 60 minutes, this allows for users to be away for lunchtime for at least 60 minutes.

This also forces idle users off, and maintains licenses, we also reboot terminal servers daily, at 3AM.

Many different circumstances can cause the error message, in our Experience, users often never complain about issues, never log them, and then are not prepared to work with us with long standing issues (seem familiar) and then at the end of the year, SLA are missed anf fail, because a user complains to Management!

If they started to complain at the same time Symantec was implemented, this could be the issue.

Glad it's fixed, and that's what counts!

Author

Commented:
True that!
BTW what is SLA?
Andrew Hancock (VMware vExpert PRO / EE Fellow)VMware and Virtualization Consultant
CERTIFIED EXPERT
Fellow
Expert of the Year 2017

Commented:
SLA = Service Level Agreement

Author

Commented:
To be honest, I don't know what fixed the problem, but one of these two: playing with session timeout settings on the Terminal Server or Shutting down another Virtual Machine recently setup to run Symantec End Point Protection Software.