Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Remote Connection to your desktop at work - failing

0 views
Skip to first unread message

Jimbo

unread,
Nov 4, 2003, 6:08:29 PM11/4/03
to
Hi again everyone,

We have just tested our test deployment extensively from outside the LAN and
the following is occurring:

Logging into Remote Web Workplace is a breeze. Everything works as expected
(OWA, companyweb etc...) EXCEPT "Connect to my computer at work" It does
connect to the clients on the LAN, but seconds after displaying the remote
desktop, the connection is dropped and cannot automatically be
re-established.

However, using the old Remote Desktop Connection in XP to connect to the
server itself directly works perfectly (ignoring the Remote Web Workplace
altogether and ignoring the clients as well) , meaning the Admin can see his
desktop on the server from afar - which would seem to indicate that this in
not a router/gateway problem wouldn't it. Not to be confusing here, what
does not work is trying to connect to a client computer from the Remote web
workplace. What does work is connecting through the gateway/router directly
to a remote server desktop.

Why would this be the case?

Thanks all,

JS

PS: The VPN client cannot connect either, but I suspect this is unrelated.


Les Connor [SBS MVP]

unread,
Nov 4, 2003, 6:23:05 PM11/4/03
to
Hi Jimbo,

The connection architecture is not the same for the server as it is for the
clients.

Do you use an external router? If so, you may need some additional port
configuration (list follows later).
Is the XP set to accept RDP requests, and does the user have permission?
Were the client machines joined via the automated setup? This could be
important, because the automated setup disables the XP firewall. You can
check this on the clients.

Port list/service information from a previous post:

This information is in the SBS2k3 help file. It's not exactly easy to stuble
upon, but if you do a search for appendix you will find it. These are the
port requirements for common services you may want to allow. If you use an
external router, the respective ports must be open. The router is either
configured by ciecw (if it's upnp), or you must do it manually. In a two nic
setup, forward the ports to the ip of the external nic.

Service: E-mail
TCP Port Number: 25

Purpose: Allows incoming and outgoing Simple Mail Transfer Protocol (SMTP)
traffic so Exchange can send and receive Internet e-mail.

Service: Web server
TCP Port Number; 80 (for http://) and 443 (for https://)

Purpose: Allows users on the Internet to access the default Web site or
specific Web site services. Port 80 is required for HTTP requests for your
site, and port 443 is required for HTTPS requests using Secure Sockets Layer
(SSL), which secures communications from your server and a Web browser.

Web site services that use ports 80 and/or port 443 include the following:

Outlook® Web Access, which allows users to access their e-mail from the
Internet using a Web browser. This service requires that users type https://
to connect securely from a Web browser to the Web server.
Server performance and usage reports, which contain detailed information
about the overall health and use of your server. Users can connect to this
service typing either an http:// or https:// connection.
Outlook Mobile Access, which allows users to access their e-mail from a
mobile device.

Web site services that use port 80 include the following:

Business Web site (wwwroot), which allows users to access the company's
Internet Web site from the Internet.
Outlook via the Internet, which allows users to remotely access their e-mail
from a client computer on the Internet using Microsoft® Office Outlook®
2003, without needing to create a virtual private network (VPN) connection.
Outlook connects to an Exchange server through the Internet using remote
procedure call (RPC) over HTTP.

This Web service requires that the client computers meet the necessary
requirements. For more information about configuring the client computers,
click Information and Answers at the Remote Web Workplace. For more
information about accessing the Remote Web Workplace, see "Connect remotely
to the server" in Help and Support Center.

Note

In addition to forwarding the ports for Web server access, you must allow
access to Web sites on the Web Services Configuration page of the Configure
E-mail and Internet Connection Wizard.

Service: Windows SharePoint Services intranet site
TCP Port Number: 444

Purpose: Allows users to access the intranet Web site created by Microsoft®
Windows® SharePointT Services. Port 444 is required to secure communications
from your server and a Web browser. To securely connect to the intranet Web
site from the Internet, users must type https://. If users are on the local
network, users can type http://.

If you create sites below the http://companyweb/ site in Windows SharePoint
Services, the sites will also be accessible to the Internet when you allow
access to the intranet Web site.

Note

In addition to opening the ports for Web server access, you must select to
allow access to Web sites on the Web Services Configuration page of the
Configure E-mail and Internet Connection Wizard.

Service: Remote Web Workplace
TCP Port Number: 4125 and 443

Purpose: Allows designated users to:

Connect to the local network from Outlook Web Access.
Create a direct Remote Desktop Web Connection to client computers on the
local network.
Use the Windows SharePoint Services intranet site.
Download Connection Manager to configure the remote client computer for
remote access.
This service requires that users type https:// to connect securely form a
Web browser to the Web server.

Note

In addition to opening the ports for Web server access, you must allow
access to this Web site on the Web Services Configuration page of the
Configure E-mail and Internet Connection Wizard.

Service: Virtual Private Network (VPN)
TCP Port Number: 1723

Purpose: Allows remote clients to connect securely to the network and then
use resources as if the client were connected locally.

Service: Terminal Services
TCP Port Number: 3389

Purpose: Allows remote clients to connect to the server using Terminal
Services.

Service: File Transfer Protocol (FTP)
TCP Port Number: 21

Purpose: Allows file transfer protocol (FTP) connections to the server.

Note

To use your server as an FTP server, you must first install and configure
the FTP service. For more information, click Start, and then click Help and
Support.


--
Les Connor [SBS MVP]
-------------------------------------
SBS Rocks !

"Jimbo" <so...@nospam.com> wrote in message
news:e0VvPiy...@tk2msftngp13.phx.gbl...

Jimbo

unread,
Nov 4, 2003, 6:49:25 PM11/4/03
to
Hi Les,

Thank you for your quick reply.

We do use an external router - UPnP - and let SBS configure it. That said,
we had to open up 4125 ourselves for some reason, but as I said, Remote Web
workplace works , allowing users to login and access the companyweb and OWA
through that portal. All ports you have listed below are set up correctly
as far as I can tell, in our router/gateway setup pages.

XP is configured to allow Remote Desktop Connections and both users in
question are listed as permitted. No firewalls are running on either XP
client.

It is odd that the user can actually see their desktop before the
"connection is lost, attempting to reconnect" dialogue box appears (That
auto reconnect attempt always is fruitless) - this would seem to indicate
correct port settings and other such configuration parameters. Otherwise, no
connection would be possible at all, never mind authentication and actual
login on the remote client.

The VPN issue I mentioned is odd too, given that the proper ports are open
as well. But this issue is FAR secondary to the first, given that the above
scenarios are the ones necessary.

Thanks again,

JS

"Les Connor [SBS MVP]" <les.c...@cfiveDEL.ca> wrote in message
news:uWNmaqyo...@TK2MSFTNGP12.phx.gbl...

Les Connor [SBS MVP]

unread,
Nov 4, 2003, 8:30:02 PM11/4/03
to
Well I think we'll have to get some help from MS. I haven't yet had the
chance to work with RWW when it doesn't work. Perhaps we'll learn something
in this thread ;-). Sorry it has to be you, but it has to be somebody.

--
Les Connor [SBS MVP]
-------------------------------------
SBS Rocks !

"Jimbo" <so...@nospam.com> wrote in message

news:#61xH5yo...@tk2msftngp13.phx.gbl...

Les Connor [SBS MVP]

unread,
Nov 4, 2003, 8:32:20 PM11/4/03
to
Say, no event errors in either remote or lan client machine? And, are you
using ISA?

--
Les Connor [SBS MVP]
-------------------------------------
SBS Rocks !

"Jimbo" <so...@nospam.com> wrote in message

news:#61xH5yo...@tk2msftngp13.phx.gbl...

Jimbo

unread,
Nov 4, 2003, 9:15:32 PM11/4/03
to
Hi again Les,

We are not using ISA , we did not install ISA server or any compnents
thereof - unless portions of it are installed default with SBS.

There were no errors of note on the server, nor on the particular client to
which we attempted to sonnect.

And, I have NO problem being the thread of first note on this! Let's go!

JS


"Les Connor [SBS MVP]" <les.c...@cfiveDEL.ca> wrote in message

news:uMaJpyzo...@TK2MSFTNGP12.phx.gbl...

Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]

unread,
Nov 4, 2003, 9:22:14 PM11/4/03
to
My guess is that router is quite set up with a 4125 poke through.

Jimbo wrote:

--
"Don't lose sight of security. Security is a state of being,
not a state of budget. He with the most firewalls still does
not win. Put down that honeypot and keep up to date on your
patches. Demand better security from vendors and hold them
responsible. Use what you have, and make sure you know how
to use it properly and effectively."
~Rain Forest Puppy
http://www.wiretrip.net/rfp/txt/evolution.txt

Jimbo

unread,
Nov 4, 2003, 9:33:40 PM11/4/03
to
Hi Susan,

I am not sure what you mean? We did, manually, set up 4125. And, as I
said, the client desktop authenticates and loads, only to lose the
connection after several seconds.

JS


"Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]" <sbra...@pacbell.net>
wrote in message news:OvkqBQ0o...@TK2MSFTNGP11.phx.gbl...

Ray Fong [MSFT]

unread,
Nov 4, 2003, 10:39:18 PM11/4/03
to
1. At the server, if you connect to RWW via http://localhost/remote and
logon as a regular user, are you able to connect to the internal machine
using "Connect to my computer at work"?

2. At a different client machine (Machine B), if you connect to RWW via
http://servername/remote and logon as a regular user, are you able to
connect to the Machine A using "Connect to my computer at work"?

3. From the remote location, if you connect to RWW via https://FQDN/remote
and logon as the administrator, are you able to connect to the server using
"Connect to Server Desktops"

4. Have you tried connecting to a different XP machine? Same problem?

5. Have you tried connecting from a different remote location? Same problem?

Ray Fong
Microsoft SBS Product Support

This posting is provided "AS IS" with no warranties, and confers no rights.

David Copeland [MSFT]

unread,
Nov 5, 2003, 12:35:50 AM11/5/03
to
Along that same line.. Is the I'm using a public or shared computer option
selected? Does it seem to make a difference whether it is/is not enabled?

May want to install the support tools on the XP client (XP cd
\support\tools) and then run netcap to get a network trace of it
connecting/failing.. while at the same time running two instances of
Network monitor on the SBS server to get a trace of both the internal and
external sides to try and determine who/why the connection is being
dropped..


--

Hope that helps,
David Copeland
Microsoft Small Business Server Support

This posting is provided "AS IS" with no warranties, and confers no rights.


"Ray Fong [MSFT]" <ray...@online.microsoft.com> wrote in message
news:MqtWp50o...@cpmsftngxa06.phx.gbl...

Jimbo

unread,
Nov 5, 2003, 9:28:52 AM11/5/03
to
Thanks all,

We will look at all these suggestions today and report back what we find.

JS


"David Copeland [MSFT]" <davi...@online.microsoft.com> wrote in message
news:uBszt61o...@TK2MSFTNGP10.phx.gbl...

Jimbo

unread,
Nov 5, 2003, 4:34:58 PM11/5/03
to
OK gang, here's what we have tried so far, based on Ray's help, I'll comment
at the end:

>>> 1. At the server, if you connect to RWW via http://localhost/remote and
logon as a regular user, are you able to connect to the internal machine
using "Connect to my computer at work"? <<<

Yes. This works.


>>> 2. At a different client machine (Machine B), if you connect to RWW via
http://servername/remote and logon as a regular user, are you able to
connect to the Machine A using "Connect to my computer at work"?

Yes. This works.


>>> 3. From the remote location, if you connect to RWW via
https://FQDN/remote
and logon as the administrator, are you able to connect to the server using
"Connect to Server Desktops" <<<

YES ! This works too, which I find baffling.


>>> 4. Have you tried connecting to a different XP machine? Same problem?
<<<

Yes, the same problem occurs whe attempting to connect to both client
machines.


>>> 5. Have you tried connecting from a different remote location? Same
problem? <<<

Yes, We have tried two different remote computers using two different ISP's.
Same issue.


So, since number 3 works, is it safe to say the we have our inbound ports
set up OK? To reitierate again, this is what we just witnessed:

We login from our dial up ISP to the server/remote. A user with normal
privs logs in and can read OWA and access the companyweb. THEN, this user
hits "connect to my computer at work" and proceeds through the options,
selects a desktop (either one produces same result) and the login window
from the client appears. Now, if we just sit there waiting to login, the
connection is fine. Then, we login, authenticate ans see the entire desktop
on the client. Once it finishes loading and we move the mouse, the
connection drops like a rock and attempts to reconnect - failing to do so.

This is a bit nutty. no?

JS


We will also try Davids netcap idea, but I wanted to post this first to se
if it tweaked anyone's mind...

Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]

unread,
Nov 6, 2003, 12:20:34 AM11/6/03
to
You don't happen to have the Internet Connection Firewall enabled on
those XP's do you?

--

Jimbo

unread,
Nov 6, 2003, 9:44:06 AM11/6/03
to
Hi susan,

No ICF is not enabled. I must say, this is quite a mystery here. We will
try to run netcap later today to see if it sheds any light, but I am
baffled. This is really the last piece of the puzzle for us at this end.

JS

"Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]" <sbra...@pacbell.net>

wrote in message news:%23LxuWYC...@TK2MSFTNGP12.phx.gbl...

Les Connor [SBS MVP]

unread,
Nov 6, 2003, 9:49:01 AM11/6/03
to
Yeah, we checked ICF earlier in the thread. Note that using the wizard to
join a client computer will disable the XP icf, manually joining it does not
AFAIK. This is relatively easy to check - either the ICF settings are
available on the client machine, or they're not.

--
Les Connor [SBS MVP]
-------------------------------------
SBS Rocks !

"Jimbo" <so...@nospam.com> wrote in message

news:Olc4yRHp...@TK2MSFTNGP12.phx.gbl...

Jimbo

unread,
Nov 6, 2003, 9:55:11 AM11/6/03
to
Right.

You know, I think we'd feel better if no connections were made - so we could
blame it on the router! I'll report back to this thread later on any netcap
results...

JS


"Les Connor [SBS MVP]" <les.c...@cfiveDEL.ca> wrote in message

news:OM4gfUH...@TK2MSFTNGP10.phx.gbl...

Ray Fong [MSFT]

unread,
Nov 6, 2003, 1:19:57 PM11/6/03
to
One of the difference between regular Remote Desktop client and RWW TS
Proxy is Remote Desktop client will automatically reconnect if the
connection is lost vs RWW will simply disconnect and give you that error.

Let try this as a testing.
On the XP, disable any desktop wallpaper, disable any third party running,
remove the logon script from that particular user. Now, simply Ctrl-Atl-Del
to lock the machine.

Next, logon to RWW and click "Connect to my computer at work". Click
Connect but do not logon yet. At this point, do you got disconnected even
before you logon? Could you verify the logon screen is indeed the XP you
want to logon.

Jimbo

unread,
Nov 6, 2003, 1:37:14 PM11/6/03
to
Hi Ray,

Thanks for the help... especially as this thread gets further down the list!

I mentioned yesterday that we are able to sit at the Login Screen forever.
It is only after we actually login that the disconnect occurs. It then
attempts to reconnect (on its own - automatically) and cannot. So, to answer
your question, we do NOT get kicked before logon.

I will attempt your other idea to rule out any third party problem like NAV
etc... and report back. We are also going to try to run netcap on the
clients and network monitor on SBS later this afternoon as well.

I will report back as soon as I can.

JS


"Ray Fong [MSFT]" <ray...@online.microsoft.com> wrote in message

news:KhsoeKJp...@cpmsftngxa06.phx.gbl...

Jimbo

unread,
Nov 6, 2003, 1:47:26 PM11/6/03
to
PS Ray,

One thing I have noticed when logging in that the little yellowish taskbar
that drops in from the top refers to the server name - not the client name
as I expected from my experiance with XP's RDC. Is this by design - or a
clue??

By the way, when we see the desktop of the client machine for those few
seconds - it IS the client machine's desktop - if you get drift.

JS

"Jimbo" <so...@nospam.com> wrote in message

news:OQUWEUJp...@tk2msftngp13.phx.gbl...

Jimbo

unread,
Nov 6, 2003, 4:23:56 PM11/6/03
to
OK all,

We ran netcap on the client and Network Monitor on SBS and I have to be
honest and say I am not sure I see any smoking guns. Although, this is not
my particular forte, so if anyone wants to take a crack at reading this
data...I'd be willing to fire it to you!

JS


"Ray Fong [MSFT]" <ray...@online.microsoft.com> wrote in message

news:KhsoeKJp...@cpmsftngxa06.phx.gbl...

Ray Fong [MSFT]

unread,
Nov 8, 2003, 11:02:52 AM11/8/03
to
That drop down bar is fine.

Did you get a chance to disable third party software running, wallpaper,
and logon script at the client? If you just lock the workstation (Not
logoff), can you still TS via the RWW?

Do you have ISA on the SBS and the remote location? What kind of network
configuration you have on both location? I mean two nic with or without
ISA? Hardare firewall?

To comfirm, you can actually logon, then see the client's destop for a few
seconds before you got disconnected, correct?

Could you email me the trace captured at the remote machine? Please
include the "IPconfig/all" of the remote machine, server, and the LAN
client.

Ray Fong
Microsoft SBS Product Support

This posting is provided "AS IS" with no warranties, and confers no rights.


>

David Copeland [MSFT]

unread,
Nov 10, 2003, 7:04:39 PM11/10/03
to
Jimbo,

Just wanted to check to see if you were able to get this working? If not,
could you email me a copy of the traces.. (will need to remove "online."
from my address)

--

Thanks,
David Copeland
Microsoft Small Business Server Support

Jimbo

unread,
Nov 10, 2003, 7:25:52 PM11/10/03
to
Hi David,

We are running late here today - and I promised Ray some traces today! Sorry
Ray!!

I will email them to you both tomorrow around mid-day. Thanks again for all
of your help. I hope I can repay someday.

JS


"David Copeland [MSFT]" <davi...@online.microsoft.com> wrote in message

news:8%23E%23rd%23pDH...@cpmsftngxa06.phx.gbl...

Jimbo

unread,
Nov 11, 2003, 5:04:49 PM11/11/03
to
Hi guys, Tried to email you the info below, but it got bounced:


Hello Ray,
Hello David,

We captured 3 files for you both today while testing the remote desktop
portion of our SBS test setup as you so generously asked us to do.

However, I am happy (and rather stunned) to report that we are no longer
getting kicked from the session.

Trust me when I tell you that we changed nothing on the SBS machine or
client machines - but - we did put the setup on a new gateway/router. We
"upgraded" from an old Linksys BEFSR41 to a new BEFSX41. Both have the
latest firmware.

This did not solve the problem on its own, but we decided to use the free
dyndns service to assign an FQDN to the IP we were using, and I am guessing
this may have done it? We were using the actual IP number as the connection
address from the SBS server (input using the wizard) and perhaps this caused
this odd anomaly. I REALLY wish we knew for sure, as some of our clients
who may be interested in this would want only to point to an IP - with no
domain name - for privacy reasons.

I sincerely thank you both for your help and hope that I may repay you and
the community one day.

Sincerely,

Jim


Les Connor [SBS MVP]

unread,
Nov 12, 2003, 12:52:22 AM11/12/03
to
I use ip only and it works fine. Linksys are inexpensive but about 50%
flakey. I would find it easy to lay blame there ;-).

--
Les Connor [SBS MVP]
-------------------------------------
SBS Rocks !

"Jimbo" <so...@nospam.com> wrote in message
news:#o5H9#JqDHA...@TK2MSFTNGP12.phx.gbl...

Ray Fong [MSFT]

unread,
Nov 13, 2003, 10:23:11 AM11/13/03
to
I am glad it is working right now, however, David and I would still like to
take a look at the trace.
Please include the IP address of the server, the remote client, and the
local client to the email.

Our email address is
ray...@online.microsoft.com and davi...@online.microsoft.com
<Take out "online" before you send it>

Ray Fong
Microsoft SBS Product Support

This posting is provided "AS IS" with no warranties, and confers no rights.

>

Jimbo

unread,
Nov 14, 2003, 7:35:30 PM11/14/03
to
OK Ray,

I'll do another one over the weekend and send it along. Youe email was
kicked to me on the last attempt however - is there a better way to email to
you?

JS


"Ray Fong [MSFT]" <ray...@online.microsoft.com> wrote in message

news:IROLSofq...@cpmsftngxa06.phx.gbl...

Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]

unread,
Nov 14, 2003, 7:48:52 PM11/14/03
to
Remove the "online"

--
http://www.sbslinks.com/really.htm

0 new messages