Remote users unable to connect to the SBS 2003 Exchange server.

First - close these ports:6001, 6002 and 6004
You do not need to open those to the internet. This feature is designed to work through 443 only.
Second - has it ever worked?

As this is SBS, did you enable the feature with the wizard?

Finally, are you using a commercial SSL certificate or the self signed one?

Simon.

1. What version of outlook are the clients using?
2.  Do these same client computers function if brought to the internal network?
3.  When outside the network, when you open outlook, does it prompt for password?
3.  Are these client computers domain members?  They've been joined to the domain?
4.  Do the clients login using domain credentials or are these machines setup as stand alone?

I am unsure if it was activated via wizard or not as I was not the one that set it up.
It has worked in the past.
It is a single site cert from rapidssl.

The client is using outlook 2010.
It does prompt for the password. After entering the password, it give an error stating that it cannot open your default e-mail folders. You must connect to Microsoft Exchange with the current profile before you can synchronize your folders with your Outlook data file (.ost).
I am trying to connect via my system which is not part of that domain and not on the same network, rather than use the end users system in order to reduce the impact on the end user.
The credentials that I am using are for a member of the domain that is not an administrator.
My machine is a member of a different domain.

If we connect the client via a VPN, it functions fine. However, it does not if it is disconnected from the VPN.

Gotcha. Probably the password is being entered in the wrong format. The user I'd must be entered as such:

Domain\userID

OR:  userid@internal fqdn. Eg contoso.local

Can you confirm the user ID Is being entered like this?

Domain\userID is how it is being entered.
It is the correct password since I can access the OWA with it.
I also at one point tried it with the  userid@internal fqdn format. There is no change either way.

I also tried it as userid@external FQDN.

Run the Connect to the Internet and configure  email wizard in the SBS console and choose Outlook over the Internet when prompted. That will setup the feature correctly for you.

Simon.

OK, so I was looking for the server management console when I realised that this system is not an SBS server. It is actually a Windows 2003 standard server.
I apparently confused this system with another client's server.

The server is running the following roles:
File server
Print Server
Application Server
Remote access/VPN server
Domain Controller (Active Directory)
DNS server
DHCP server

Sorry about the incorrect information.

if it works internally but not externally, then this almost seems like a dns issue - but if the exchange connectivity tester passed then that seems to rule out a DNS issue unless the client is setup incorrectly.  

If you look at the outlook config, on the section where you can supply the server's name and the user's mailbox, what is listed as the server's name?  It should be the INTERNAL fqdn.  Then, under the outlook over http section, the EXTERNAL fqdn should be specified - and this fqdn should also be what the certificate is using.

Confirm?

In the server settings, the server is set to the internal fqdn ie. contosco.local using cached exchange mode.

Under the outlook anwhere section, it is set to connect using http. In the exchange proxy settings, it has the external fqdn ie contosco.com in the proxy server.
It is set to connect using ssl only. The only connect to proxy servers check box is checked with msstd:external fqdn.
There is a check for both fast and slow networks to use http first.
Authentication settings are set to negotiate.

I can ping the external fqdn from my workstation on a different network. It does not respond as the router is set to drop ICMP requests, but it does resolve to the correct IP address.

change the Auth type to basic - the only time I've seen anything else work is if these machines are domain members.

I reset the Auth type to basic (I had it that way at one point, but it did not work), but it did not make any difference.

Interesting.  When you connect to the VPN and ping the external FQDN of the server - does it resolve to a local address?

You're 100% sure the exchange connectivity test worked with no issues?  This just seems odd that it would pass, yet your outlook client has issues.

This might have something to do with the AutoDiscover DNS record.  Have you tried the exchange connectivity tester to test the autodiscover settings for the domain?

Also, when the outlook client was configured, did you let outlook do it for you, or did you select the option to configure manually?

The following are the results from the https://www.testexchangeconnectivity.com test using the activesync option.

ExRCA is testing Exchange ActiveSync.
       Exchange ActiveSync was tested successfully.
       
      Test Steps
       
      Attempting to resolve the host name {external FQDN} in DNS.
       The host name resolved successfully.
       
      Additional Details
       IP addresses returned: {external IP}
      Testing TCP port 443 on host {external FQDN} to ensure it's listening and open.
       The port was opened successfully.
      Testing the SSL certificate to make sure it's valid.
       The certificate passed all validation requirements.
       
      Test Steps
       
      ExRCA is attempting to obtain the SSL certificate from remote server {external FQDN} on port 443.
       ExRCA successfully obtained the remote SSL certificate.
       
      Additional Details
       Remote Certificate Subject: CN={external FQDN}, OU=Domain Control Validated - RapidSSL(R), OU=See www.rapidssl.com/resources/cps (c)11, OU=GT02294205, O={external FQDN}, C=US, SERIALNUMBER={hidden}, Issuer: CN=RapidSSL CA, O="GeoTrust, Inc.", C=US.
      Validating the certificate name.
       The certificate name was validated successfully.
       
      Additional Details
       Host name {external FQDN} was found in the Certificate Subject Common name.
      Validating certificate trust for Windows Mobile devices.
       The certificate is trusted and all certificates are present in the chain.
       
      Test Steps
       
      ExRCA is attempting to build certificate chains for certificate CN={external FQDN}, OU=Domain Control Validated - RapidSSL(R), OU=See www.rapidssl.com/resources/cps (c)11, OU=GT02294205, O={external FQDN}, C=US, SERIALNUMBER={hiddden}.
       One or more certificate chains were constructed successfully.
       
      Additional Details
       A total of 1 chains were built. The highest quality chain ends in root certificate CN=GeoTrust Global CA, O=GeoTrust Inc., C=US.
      Analyzing the certificate chains for compatibility problems with Windows Phone devices.
       Potential compatibility problems were identified with some versions of Windows Phone.
        Tell me more about this issue and how to resolve it
       
      Additional Details
       The certificate is only trusted on Windows Mobile 6.0 and later versions. Devices running Windows Mobile 5.0 and 5.0 with the Messaging and Security Feature Pack won't be able to sync. Root = CN=GeoTrust Global CA, O=GeoTrust Inc., C=US.
      ExRCA is analyzing intermediate certificates that were sent down by the remote server.
       All intermediate certificates are present and valid.
       
      Additional Details
       All intermediate certificates were present and valid.
      Testing the certificate date to confirm the certificate is valid.
       Date validation passed. The certificate hasn't expired.
       
      Additional Details
       The certificate is valid. NotBefore = 11/15/2011 8:30:15 PM, NotAfter = 12/17/2013 7:48:42 PM
      Checking the IIS configuration for client certificate authentication.
       Client certificate authentication wasn't detected.
       
      Additional Details
       Accept/Require Client Certificates isn't configured.
      Testing HTTP Authentication Methods for URL https://{external FQDN}/Microsoft-Server-ActiveSync/.
       The HTTP authentication methods are correct.
       
      Additional Details
       ExRCA found all expected authentication methods and no disallowed methods. Methods found: Basic
      An ActiveSync session is being attempted with the server.
       Testing of an Exchange ActiveSync session completed successfully.
       
      Test Steps
       
      Attempting to send the OPTIONS command to the server.
       The OPTIONS response was successfully received and is valid.
       
      Additional Details
       Headers received: Pragma: no-cache
Public: OPTIONS, POST
Allow: OPTIONS, POST
MS-Server-ActiveSync: 6.5.7638.1
MS-ASProtocolVersions: 1.0,2.0,2.1,2.5
MS-ASProtocolCommands: Sync,SendMail,SmartForward,SmartReply,GetAttachment,GetHierarchy,CreateCollection,DeleteCollection,MoveCollection,FolderSync,FolderCreate,FolderDelete,FolderUpdate,MoveItems,GetItemEstimate,MeetingResponse,ResolveRecipients,ValidateCert,Provision,Search,Notify,Ping
Content-Length: 0
Date: Thu, 20 Dec 2012 20:47:00 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET

      Attempting the FolderSync command on the Exchange ActiveSync session.
       The FolderSync command completed successfully.
       
      Additional Details
       Number of folders: 41
      Attempting the initial sync to the Inbox folder. This initial sync won't return any data.
       The Sync command completed successfully.
       
      Additional Details
       Status: 1
      Attempting to test the GetItemEstimate command for the Inbox folder.
       ExRCA successfully received the GetItemEstimate response from the server.
       
      Additional Details
       Estimate: 33 messages
      Attempting to test synchronization of the Inbox folder.
       The Sync command completed successfully.
       
      Additional Details
       Number of items synchronized: 33



The following is the output from the same wenbsite using the Outlook Anywhere (RPC over http) test:

Testing RPC/HTTP connectivity.
       The RPC/HTTP test completed successfully.
       
      Test Steps
       
      Attempting to resolve the host name {external FQDN} in DNS.
       The host name resolved successfully.
       
      Additional Details
       IP addresses returned: {external IP}
      Testing TCP port 443 on host {external FQDN} to ensure it's listening and open.
       The port was opened successfully.
      Testing the SSL certificate to make sure it's valid.
       The certificate passed all validation requirements.
       
      Test Steps
       
      ExRCA is attempting to obtain the SSL certificate from remote server {external FQDN} on port 443.
       ExRCA successfully obtained the remote SSL certificate.
       
      Additional Details
       Remote Certificate Subject: CN={external FQDN}, OU=Domain Control Validated - RapidSSL(R), OU=See www.rapidssl.com/resources/cps (c)11, OU=GT02294205, O={external FQDN}, C=US, SERIALNUMBER={hidden}, Issuer: CN=RapidSSL CA, O="GeoTrust, Inc.", C=US.
      Validating the certificate name.
       The certificate name was validated successfully.
       
      Additional Details
       Host name {external FQDN} was found in the Certificate Subject Common name.
      Certificate trust is being validated.
       The certificate is trusted and all certificates are present in the chain.
       
      Test Steps
       
      ExRCA is attempting to build certificate chains for certificate CN={external FQDN}, OU=Domain Control Validated - RapidSSL(R), OU=See www.rapidssl.com/resources/cps (c)11, OU=GT02294205, O={external FQDN}, C=US, SERIALNUMBER={hidden}.
       One or more certificate chains were constructed successfully.
       
      Additional Details
       A total of 1 chains were built. The highest quality chain ends in root certificate CN=GeoTrust Global CA, O=GeoTrust Inc., C=US.
      Analyzing the certificate chains for compatibility problems with versions of Windows.
       Potential compatibility problems were identified with some versions of Windows.
       
      Additional Details
       ExRCA can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature isn't enabled.
      Testing the certificate date to confirm the certificate is valid.
       Date validation passed. The certificate hasn't expired.
       
      Additional Details
       The certificate is valid. NotBefore = 11/15/2011 8:30:15 PM, NotAfter = 12/17/2013 7:48:42 PM
      Checking the IIS configuration for client certificate authentication.
       Client certificate authentication wasn't detected.
       
      Additional Details
       Accept/Require Client Certificates isn't configured.
      Testing HTTP Authentication Methods for URL https://{external FQDN}/rpc/rpcproxy.dll?{external FQDN}:6002.
       The HTTP authentication methods are correct.
       
      Additional Details
       ExRCA found all expected authentication methods and no disallowed methods. Methods found: Basic, Negotiate, NTLM
      Testing SSL mutual authentication with the RPC proxy server.
       Mutual authentication was verified successfully.
       
      Additional Details
       Certificate common name {external FQDN} matches msstd:{external FQDN}.
      Attempting to ping RPC proxy {external FQDN}.
       RPC Proxy was pinged successfully.
       
      Additional Details
       Completed with HTTP status 200 - OK
      Attempting to ping RPC endpoint 6001 (Exchange Information Store) on server {external FQDN}.
       The endpoint was pinged successfully.
       
      Additional Details
       RPC Status Ok (0) returned in 922 ms.
      Testing the Name Service Provider Interface (NSPI) on the Exchange Mailbox server.
       The NSPI interface was tested successfully.
       
      Test Steps
       
      Attempting to ping RPC endpoint 6004 (NSPI Proxy Interface) on server {external FQDN}.
       The endpoint was pinged successfully.
       
      Additional Details
       RPC Status Ok (0) returned in 172 ms.
      Testing NSPI "Check Name" for user {users email addy} against server {external FQDN}.
       Check Name succeeded.
       
      Additional Details
       DisplayName: Regina Guevara, LegDN: /o=First Organization/ou=First Administrative Group/cn=Recipients/cn=rguevara
      Testing the Referral service on the Exchange Mailbox server.
       The Referral service was tested successfully.
       
      Test Steps
       
      Attempting to ping RPC endpoint 6002 (Referral Interface) on server {external FQDN}.
       The endpoint was pinged successfully.
       
      Additional Details
       RPC Status Ok (0) returned in 140 ms.
      Attempting to perform referral for user /o=First Organization/ou=First Administrative Group/cn=Recipients/cn=rguevara on server {external FQDN}.
       ExRCA successfully got the referral.
       
      Additional Details
       The server returned by the Referral service: server773.local773.local
      Testing the Exchange Information Store on the Mailbox server.
       ExRCA successfully tested the Information Store.
       
      Test Steps
       
      Attempting to ping RPC endpoint 6001 (Exchange Information Store) on server {external FQDN}.
       The endpoint was pinged successfully.
       
      Additional Details
       RPC Status Ok (0) returned in 140 ms.
      Attempting to log on to the Exchange Information Store.
       ExRCA successfully logged on to the Information Store

It does fail on the autodiscover test, but I do not believe that was ever set up for their domain.

Configured manually.

If I ping while connected to the VPN, it responds with a local non-routable IP address.

Weird.  Weird that the exchange connectivity test passes but outlook won't cooperate.  Do you have a copy of outlook 2007 or 2003 for testing?  2010 should work - but this is just weird.

Pinging while disconnected shows the correct external address?  You don't have any custom entries in your HOSTS file do you?

Pinging the external FQDN from my computer (separate network) resolved to the correct external routable IP address.

I can install an older version of Outlook, but I will do that tomorrow.
Which system are you asking about in regards to the hosts file?
This disconnect is happening on more than one location, so the hosts file being an issue doesn't seem very likely on the client end, but I went ahead and checked mine out (since I am testing their email from my workstation). My hohsts file has no entries (besides localhost). I checked the server and its host file is the same.

Ok.  Sounds reasonable (regarding the hosts file).  I was talking about the client as you correctly guessed.

How are your smart phones doing with this?  Do you have droids / iphones, and do they connect with no issues?

I was told that the iphones are working correctly. I have not verified this personally though.

Any events in your client's appliication log that might give you a hint?

Nothing in the logs in regards to this issue.

I don't know why phones are being mentioned, as ActiveSync uses something completely different for connectivity (Straight HTTPS in to a web site). It also isn't complex to configure.

RPC over HTTPS fails for very few reasons in my experience.

1. Not meeting the requirements (still get people trying to do it with Windows 2000).
2. SSL issues - not using a trusted SSL certificate, or putting the wrong name in the configuration - certificate for host.example.com, but entering mail.example.com.
3. DNS issues - things don't resolve where they should.
4. Registry configuration issues - as this is Exchange 2003, manual configuration of the registry is required.

Autodiscover isn't a feature of Exchange 2003, so can be ignored.

Personally I would remove the entire feature and reconfigure it.
That means removing the RPC Proxy from add/remove programs, then removing the two RPC virtual directories from IIS Manager. Run IISRESET to write the change to the IIS metabase. Reinstall the RPC Proxy and reconfigure:
http://exchange.sembee.info/2003/rpcoverhttp/default.asp

Simon.

Simon - you are also helping ME out with my exchange issue.. some good advice here too.  Yes, you're right about the phones.  I mentioned it just as an info gathering step.  You're right about it not being completely relevant.

Also, correct exchange 2003 doesn't use autodiscover.  

But Simon.. isn't it odd that the excange connectivity analyzer passes with no issues?  That should rule out lots of things.  DNS, Firewall config, Certificate, etc.  Did you see the output above from the external exchange connectivity test?

This leaves the client.. something isn't right with the client.  

Sinc - can you post screenshots of your outlook configuration screens?

 - Tim

I resolved the issue by doing something that was not suggested by others.
Although their suggestions did help narrow down what I was looking for, they were not the answer to the problem.