Remote Web Workplace Timeouts in SBS2003 SP2.

Hi there,

I am experiencing an issue with RRW on an SBS2003 SP2 machine. The server itself is an IBM x3250 with 4GB of Memory installed. The server idles with around 2GB of memory free.

After a random period of time, could be a couple of minutes, it could be more. The user experiences an issue with the error message: "VBScript: Remote Desktop Disconnected. An Internal error has occurred"

When disconnected, you can click ok on the error message and it will return you to the RWW login page.

The message will happen while the RRW desktop is being used, not when left idle.

The error occurs for all users including the administrator.

The issue is experienced before and after removal of ISA.

The issue occurs when using RWW in the internal network as well as over the internet.

Normal remote desktop over VPN or using Kaseya works flawlessly.

The patch available from is unable to be installed with the error "setup has detected that the service pack version of the system installed is newer than the update you are applying it to".

I have tested without any antivirus software installed on the server and this does not resolve the problem.

I have tested the NIC running at 100Mbps rather than GIG-E as per researched recommendations and problem still occurs.

The server has two NIC's installed and both of them will produce this problem. The latest WHQL drivers are installed from Microsoft (Broadcom NetXtreame Gigabit Ethernet). Different switch ports on different switches have been tried.

Any assistance is greatly appreciated.

I have checked all of the following as per info found on vairious forums etc.

I. Check the tsweb timeout settings for RWW:

1. Go to the following location

2. Copy tsweb.aspx to the desktop as a backup
3. Open tsweb.aspx
4. Change the value of MsRdpClient.AdvancedSettings2.MinutesToIdleTimeout
to 240 from 120
5. Run command 'IISRESET' to restart IIS

II. Please check Remote Web Workplace timeout settings on SBS:

The time out values (in minutes) are configurable in the registry, at:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SmallBusines sServer\RemoteUserPortal\P
REG_DWORD: 20 (Default)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SmallBusines sServer\RemoteUserPortal\T
REG_DWORD: 120 (Default)

The PublicTimeOut is used when the user checks the box for "I'm using a
public or shared computer" on the RWW logon page. The TrustedTimeOut is
used when the user unchecks this checkbox. You can change the time out
settings here.

III. ASP.NET timeout
Edit the C:\inetpub\remote\web.config file.
Look for line:
<forms name="RemotePortalAuth" loginurl="logon.aspx" protection="All"
path="/" timeout="120" />
timeout = value in minutes of your largest timeout value.

The default timeout in SBS 2003 is 120 minutes.

IV. IIS timeout:
1. Go to Server Management -> Advanced Management -> Internet Information
2. Expand [Server Name] -> Web Sites -> Default Web Site.
3. Right click Remote and choose Properties, in Virtual Directory tab,
click the Configuration button and select the Options tab, modify the
session timeout settings. The Default Session timeout in SBS 2003 is 120

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server, create or edit the DWORD value of KeepAliveEnable and set it to 1. This will turn Keep Alives on. This will serve to stabilize the connection by sending 'heartbeat' packets to the client every so often. This will cause an idle connection to be probed every so often just to be sure that the connection is still alive and that the client is still listening on the other side. This will also help prevent disconnects by preventing network devices from killing off sockets that it assumes to be idle. Because terminal services is such a low bandwidth protocol, when a user is idle, no network activity will occur. Some network devices will interpret a connection that is in the idle state for an extended period of time to be a dead connection, and thus will terminate the socket. However, when the user comes out of the idle state, the terminal services client can no longer contact the terminal server because the socket is dead. By turning on Keep Alives, the connection will not appear idle, and therefore the network device will not attempt to terminate the socket.

In the registry at HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, create or edit the DWORD value of TcpMaxDataRetransmissions. By default it is set to 5, but I would recommend doubling that value, to 10. The value of TcpMaxDataRetransmissions is the number of times TCP retransmits an unacknowledged data segment on an existing connection. TCP retransmits data segments until they are acknowledged or until this value expires. Basically, when a client doesn't respond to a packet from the terminal server, the server will attempt to retransmit the packet up to TcpMaxDataRetransmissions number of times. By increasing this value, you are giving the client more time to respond to the server, which will help improve flaky connections or connections with high latency or higher than normal packet loss.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Shreedhar EtteCommented:

Check the MTU settings for the router and server.

Refer this:

I hope this helps,
kylegreigAuthor Commented:
Hi there,

Thanks for the info.

The problem has been replicated within the internal network without any routers as part of the equation. This error occurs when loading RRW from a machine located within the internal network. When doing using mturoute.exe to test within the local subnet where this problem can be replicated, it returns a result of :

C:\>mturoute backup01
* ICMP Fragmentation is not permitted. *
* Maximum payload is 10000 bytes. *
- ICMP payload of 5046 bytes failed..
- ICMP payload of 2569 bytes failed..
+ ICMP payload of 1330 bytes succeeded.
- ICMP payload of 1949 bytes failed..
- ICMP payload of 1639 bytes failed..
- ICMP payload of 1484 bytes failed..
+ ICMP payload of 1407 bytes succeeded.
+ ICMP payload of 1445 bytes succeeded.
+ ICMP payload of 1464 bytes succeeded.
- ICMP payload of 1474 bytes failed..
+ ICMP payload of 1469 bytes succeeded.
+ ICMP payload of 1471 bytes succeeded.
+ ICMP payload of 1472 bytes succeeded.
- ICMP payload of 1473 bytes failed..
+ ICMP payload of 1472 bytes succeeded.
+ ICMP payload of 1472 bytes succeeded.
Path MTU: 1500 bytes.

And from my understanding, this is ok.

Are the users remotely accessing their desktop PC's or a terminal server?

I see you used the work desktop but I'm not sure in what context
10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.

kylegreigAuthor Commented:
Hi there,

Thanks for the reply.

The RRW application has been tested using computers on the internal LAN and from across the internet. The computers from across the internet are generally the staff members home computers which could be XP, Vista, 7 / Home, Pro. All of the computers on the internal network are Windows XP Professional.

The problem is observed when remotely accessing desktop PC's and the terminal server.

Thanks again.
Here is a post with some things to check

When I was having a very similar issue I found logs on the destination PC reported something  similar to - The maximum number      of connections exceeded basically a error message on the computer I was connecting to saying their were to many connections.

Check the logs on the destination PC and let us know....
kylegreigAuthor Commented:
Ok, I have checked the following:

1.    Make sure the port 4125 forward to the SBS if you have a router.
Done, tested can establish connection

2.    Make sure port 4125 is available to the SBS RWW and no other software is using it.
The port is available and dont believe any other application is using it. RRW connections never fail to establish. They only fail once active after a seemingly random period of time as little as 5 minutes up to 30 minutes.

3.    Make sure no firewall or ISA block the port 4125.
Done, tested can establish connection

4.    You may want to test and modify the MTU. Refer to Modify MTU
The problem can be replicated when accessing RRW using a computer that is inside the same network as the terminal server. Not sure what changes would be relevant in this scenario keeping in mind the NIC testing that I had originally done. Please advise.

5. Connectivity issues after ms05-019 and 2003 sp1
If I attempt to install the update described on KB898060, the error message reads: "setup has detected that the service pack version of the system installed is newer than the update you are applying it to".

6. If the OS is Vista, Windows 7 and windows 2008, it could be Large Send Offload issue. Check these links for more details.
The environment is Windows 2003 SBS server with XP clients.

7: Remote Desktop Disconnected - error in data encryption and Large Send Offload Issue in windows Vista, 2008 and 7
There are references on to Large Send Offload in the context of a direct remote desktop connection, would this be relevant for RRW even though a normal remote desktop connection is not affected, only RRW?

7. It could be security or firewall issue.
What could you recommend checking with this?
Is there any logs on the destination machine indicating why the session disconnected?

My guess is the remote machine is causing the disconnection problem not the server. You have already checked for and eliminated a lot of potential issues on the server side. The best strategy moving forward is to replicate the issue (easier to find the logs that way) and find the error messages in the logs. If you cant find anything on the PC review the server logs
Shreedhar EtteCommented:

Run SBS 2003 Best Practice Analyzer tools and fix the errors reported.

After that test the RWW.

Also update the firmware of the router.

I hope this helps,
kylegreigAuthor Commented:
Im not convinced it is not a server related issue due to the number of RRW client machines that experience this same issue on this particular RRW server. I have experienced timeouts from a number of different client machines ranging from Windows XP, Vista and 7 all of which are from different environments (including on the domain that the RRW server is located, home computers for staff members and also computers that are within my own company domain. With those same computers of mine, I am able to use RRW on other servers without an issue.

I have had a look at the event logs on both the clients and the server and there is nothing that looks suspicious. I should maybe look at increasing the logging level on the server for this particular website.

I do notice that the RRW site has had its own application pool created other than the default one which is something that was configured by a third party for the internal SQL application that is used on this server too.

Ill look at increasing the level of logging and see if this reveals anything. Any ideas are appreciated.
kylegreigAuthor Commented:
Disabled Large Send Offload on the network interface and this didnt resolve. Changed setting back. Checked log files for any indication as to why the service is getting disconnected. Established connection to RRW to the server wait for time out and check the logs. Not able to see anything that would suggest what the issue is.

Started investigating the application pool settings and found that a clean up process was set to run every 20 minutes when when the default setting for this was 600 minutes. (Shutdown worker processes after being idle for:) The setting had been configured upon a third parties implementation of a web based application.

Was able to establish 2 RRW connections to both server and server1 without any timeouts for close to 3 hours.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Shreedhar EtteCommented:

As the information was helpful. Then you can select someones comment as Assisted Solution.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Server OS

From novice to tech pro — start learning today.