asked on

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 http://support.microsoft.com/kb/821438 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
C:\InetPub\Remote\tsweb.aspx

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
ublicTimeOut
REG_DWORD: 20 (Default)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SmallBusines sServer\RemoteUserPortal\T
rustedTimeOut
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
Server.
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
minutes.

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.

Shreedhar Ette

Hi,

Check the MTU settings for the router and server.

Refer this:
http://howtonetworking.com/VPN/mtu1.htm

http://howtonetworking.com/VPN/mtu4.htm

I hope this helps,
Shree

kylegreig

ASKER

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.

Thanks
Kyle

JParker505

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

kylegreig

ASKER

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.
Kyle

JParker505

Here is a post with some things to check

http://www.chicagotech.net/sbs/rwwvbscript11.htm

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....

kylegreig

ASKER

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 http://chicagotech.net/netforums/viewtopic.php?f=2&t=8909&start=0&sid=dc77725be74798f676d479ac4737b47c 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?

JParker505

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 Ette

Hi,

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,
Shree

kylegreig

ASKER

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.

ASKER CERTIFIED SOLUTION

kylegreig

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Shreedhar Ette

Hi,

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

---------
Shree