Outlook RPC-HTTP unable to connect to Exchange 2010 server

I have a newly configured Exchange 2010 server.  Everything is working properly with the exception of Autodiscover (which I don't care about--pretty sure it's not working because I have a single-site SSL certificate for mail.domain.com which doesn't have autodiscover.domain.com in it) and Outlook RPC-HTTP connectivity from remote Outlook clients.  OWA and OMA both work fine, and I have resolved the certificate error that was appearing twice when starting local Outlook clients (the error because the Exchange cert is for mail.domain.com but Outlook was trying to connect via server.domain.local).  

I have Outlook Anywhere configured to use basic authentication.  When I test Outlook RPC-HTTP at www.testexchangeconnectivity.com, it actually passes, with warnings.

Testing the SSL certificate to make sure it's valid.
       The certificate passed all validation requirements.
       Validating the certificate name.
       The certificate name was validated successfully.
       Host name mail.domain.com was found in the Certificate Subject Common name.
      Certificate trust is being validated.
       The test passed with some warnings encountered. Please expand the 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.

That seems like just an informational message, stating that computers which haven't had the Root Certificates update might not be able to connect properly.  All of my workstations have had the Root Certificate update so this should be a non-issue.

The second error is:

Testing the Referral service on the Exchange Mailbox server.
       The Referral service was tested successfully.
       Attempting to ping RPC endpoint 6002 (Referral Interface) on server SERVER.
       The endpoint was pinged successfully.
       RPC Status Ok (0) returned in 229 ms.
      Attempting to perform referral for user /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User Name on server SERVER.
       The test passed with some warnings encountered. Please expand the additional details.
       The Referral service returned generic error 0x80004005. This may mean that encryption is required. ExRCA is trying again with encryption.

All subsequent steps are passed with no warnings.

Since it seems like Outlook RPC-HTTP connectivity passes the test, I'm not sure where the problem is.  I am using the following settings:

Connect to http://mail.domain.com
X   Connect using SSL only
X    Mutually authenticate the session when connecting with SSL
      msstd:mail.domain.com
X    On Fast Networks use HTTP first
X    On slow networks, use HTTP first
Basic authentication

I have also tried not specifying the msstd value and using NTLM instead of Basic (and changing the Outlook Anywhere setting on the Exchange server to specify NTLM), with the same results--the Outlook client will not connect to the server.

What should I try next?
LVL 1
SINC_dmackAsked:
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.

cavp76Commented:
In those PCs, when you go to https://mail.domain.com, do you have any certificate errors?? If so, there's a problem with the root certificate installed.

HTH
0
SINC_dmackAuthor Commented:
There are no certificate errors when going to https://mail.domain.com or https://mail.domain.com/exchange.  I haven't seen any certificate errors whatsoever after getting the "two certificate errors when starting Outlook" issue fixed.  I'm pretty sure I've got the certificate set up properly.  
0
MegaNuk3Commented:
Specify the server as https://mail.mydomain.com

Use basic auth with no mutual authentication until it starts working.

If you ping mail.mydomain.com internally does it resolve to the internal IP of your CAS server?
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

SINC_dmackAuthor Commented:
MegaNuk3, When I ping mail.domain.com locally, it resolves to the local private-range IP address of the Exchange server.  

I currently have Outlook set up suggest but still get: "The connection to the Microsoft Exchange Server is unavailable. Outlook must be online or connected to complete this action."
0
MegaNuk3Commented:
Are you trying to get outlook anywhere setup on outlook from the Internet or are you trying from an internal machine at the moment?

Add mail.domain.com to the HOSTs file On the exchange server and point it to it's own IP address (not 127.0.0.1)
0
MegaNuk3Commented:
By the way you can get round the external autodiscover issue by adding a DNS SRV record:
http://support.microsoft.com/kb/940881

Internally the clients will use the AD SCP and you can change that to match your cert with EMs:
Get-clientaccessserver | set-clientaccessserver -autodiscoverserviceinternaluri "https://mail.domain.com/autodiscover/autodiscover.XML"
0

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
MegaNuk3Commented:
Can you also go into EMS and do:
Get-outlookProvider | fl

And look under the EXPR settings at the externalhostname and certprincipalname values...
0
SINC_dmackAuthor Commented:
MegaNuk3,

Local Outlook works with no problems.  I'm trying to get remote Outlook Anywhere working.  I've already configured the local clients to use the mail.domain.com cert when connecting via Outlook.

If I ping mail.domain.com from anywhere on the local network (including the Exchange server itself), it returns the 192.168.xx.xx local IP of the Exchange server.  That IP is being pulled from DNS which is already installed on the Exchange server.  Since it is already resolving properly via DNS, would I still need to create a hosts file entry?

I ran get-outlookprovider | fl.  I don't see a the externalhostname value anywhere.  There is an OriginatingServer value, which is server.domain.local.  The CertPrincipalName value is blank.  I presume that is a problem?  Thanks!
0
MegaNuk3Commented:
can you post the output from get-outlookprovider |fl from under the EXPR settings?

Use
Set-OutlookProvider EXPR -CertPrincipalName:"msstd:mail.domain.com"
to set the CertPrincipalName

What does get-OutlookAnywhere |fl show?

leave the HOSTS alone for now...

open internal Outlook with /rpcdiag to see what it is connecting as, "HTTP" or "TCP"
Use these settings internally (if autodiscover hasn't filled them in for you):
Connect to https://mail.domain.com
X   Connect using SSL only
X    On Fast Networks use HTTP first
X    On slow networks, use HTTP first
0
SINC_dmackAuthor Commented:
Hi MegaNuk3,

I ran Set-OutlookProvider EXPR -CertPrincipalName:"msstd:mail.domain.com".

Here is the output from get-outlookprovider |fl.

[PS] C:\Windows\system32>get-outlookprovider |fl

RunspaceId           : adb8fa39-2df9-4c92-bb4a-7e9000ffeb97
CertPrincipalName    :
Server               :
TTL                  : 1
OutlookProviderFlags : None
AdminDisplayName     :
ExchangeVersion      : 0.1 (8.0.535.0)
Name                 : EXCH
DistinguishedName    : CN=EXCH,CN=Outlook,CN=AutoDiscover,CN=Client Access,CN=First Organization,CN=Microsoft Exchange,
                       CN=Services,CN=Configuration,DC=DOMAIN,DC=local
Identity             : EXCH
Guid                 : 0a17b8f8-2675-430e-9504-ae6ec14cd5c0
ObjectCategory       : DOMAIN.local/Configuration/Schema/ms-Exch-Auto-Discover-Config
ObjectClass          : {top, msExchAutoDiscoverConfig}
WhenChanged          : 3/30/2011 1:19:38 PM
WhenCreated          : 3/30/2011 1:19:38 PM
WhenChangedUTC       : 3/30/2011 6:19:38 PM
WhenCreatedUTC       : 3/30/2011 6:19:38 PM
OrganizationId       :
OriginatingServer    : SERVER.DOMAIN.local
IsValid              : True

RunspaceId           : adb8fa39-2df9-4c92-bb4a-7e9000ffeb97
CertPrincipalName    : msstd:mail.DOMAIN.net
Server               :
TTL                  : 1
OutlookProviderFlags : None
AdminDisplayName     :
ExchangeVersion      : 0.1 (8.0.535.0)
Name                 : EXPR
DistinguishedName    : CN=EXPR,CN=Outlook,CN=AutoDiscover,CN=Client Access,CN=First Organization,CN=Microsoft Exchange,
                       CN=Services,CN=Configuration,DC=DOMAIN,DC=local
Identity             : EXPR
Guid                 : 19484cd8-5ff9-41bf-a434-65e7ac3c2b87
ObjectCategory       : DOMAIN.local/Configuration/Schema/ms-Exch-Auto-Discover-Config
ObjectClass          : {top, msExchAutoDiscoverConfig}
WhenChanged          : 4/10/2011 11:22:18 AM
WhenCreated          : 3/30/2011 1:19:38 PM
WhenChangedUTC       : 4/10/2011 4:22:18 PM
WhenCreatedUTC       : 3/30/2011 6:19:38 PM
OrganizationId       :
OriginatingServer    : SERVER.DOMAIN.local
IsValid              : True

RunspaceId           : adb8fa39-2df9-4c92-bb4a-7e9000ffeb97
CertPrincipalName    :
Server               :
TTL                  : 1
OutlookProviderFlags : None
AdminDisplayName     :
ExchangeVersion      : 0.1 (8.0.535.0)
Name                 : WEB
DistinguishedName    : CN=WEB,CN=Outlook,CN=AutoDiscover,CN=Client Access,CN=First Organization,CN=Microsoft Exchange,C
                       N=Services,CN=Configuration,DC=DOMAIN,DC=local
Identity             : WEB
Guid                 : 3735ab56-3582-4289-836e-d129f07f4da0
ObjectCategory       : DOMAIN.local/Configuration/Schema/ms-Exch-Auto-Discover-Config
ObjectClass          : {top, msExchAutoDiscoverConfig}
WhenChanged          : 3/30/2011 1:19:38 PM
WhenCreated          : 3/30/2011 1:19:38 PM
WhenChangedUTC       : 3/30/2011 6:19:38 PM
WhenCreatedUTC       : 3/30/2011 6:19:38 PM
OrganizationId       :
OriginatingServer    : SERVER.DOMAIN.local
IsValid              : True

[PS] C:\Windows\system32>
0
SINC_dmackAuthor Commented:
I ran Outlook /rpcdiag.  Local Outlook is connecting via TCP/IP.  I changed the settings to force it to use HTTP as you directed and it still connected properly and did indicate that it was using HTTP.  This sure is weird--everything seems to work internally AND since testexchangeconnectivity.com says everything is working (the two informational messages notwithstanding), I'm at a loss.

Here is the output from running get-OutlookAnywhere |fl.

[PS] C:\Windows\system32>get-OutlookAnywhere |fl


RunspaceId                      : d1551287-5f87-4980-a6dc-f764d1aa8f19
ServerName                      : SERVER
SSLOffloading                   : False
ExternalHostname                : mail.DOMAIN.net
ClientAuthenticationMethod      : Basic
IISAuthenticationMethods        : {Basic}
XropUrl                         :
MetabasePath                    : IIS://SERVER.DOMAIN.local/W3SVC/1/ROOT/Rpc
Path                            : C:\Windows\System32\RpcProxy
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags         : {}
ExtendedProtectionSPNList       : {}
Server                          : SERVER
AdminDisplayName                :
ExchangeVersion                 : 0.10 (14.0.100.0)
Name                            : Rpc (Default Web Site)
DistinguishedName               : CN=Rpc (Default Web Site),CN=HTTP,CN=Protocols,CN=SERVER,CN=Servers,CN=Exchange Adm
                                  inistrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First Organization,CN
                                  =Microsoft Exchange,CN=Services,CN=Configuration,DC=DOMAIN,DC=local
Identity                        : SERVER\Rpc (Default Web Site)
Guid                            : 7623ceab-974e-43da-a7b3-f3b72cac8385
ObjectCategory                  : DOMAIN.local/Configuration/Schema/ms-Exch-Rpc-Http-Virtual-Directory
ObjectClass                     : {top, msExchVirtualDirectory, msExchRpcHttpVirtualDirectory}
WhenChanged                     : 4/7/2011 4:15:12 PM
WhenCreated                     : 4/5/2011 10:36:42 PM
WhenChangedUTC                  : 4/7/2011 9:15:12 PM
WhenCreatedUTC                  : 4/6/2011 3:36:42 AM
OrganizationId                  :
OriginatingServer               : SERVER.DOMAIN.local
IsValid                         : True



[PS] C:\Windows\system32>
0
SINC_dmackAuthor Commented:
One thing I did notice is that the Outlook RPCdiag shows that the server name is server.domain.local, not mail.domain.com.  However, I don't think that indicates a problem, since Exchange '03 would change mail.domain.com to server.domain.local under the connection settings after a successful connection via RPC-HTTP.  
0
MegaNuk3Commented:
So, next question is. Do you have a laptop and 3G card or external ADSL connection to test externally?
0
SINC_dmackAuthor Commented:
Yes, I have been using Outlook at another location with a separate DSL account to test RPC-HTTP connectivity.  
0
MegaNuk3Commented:
Ok, so does that external Outlook still not connect?
0
SINC_dmackAuthor Commented:
I brought my laptop onsite where the mail server is hosted.  My laptop is not part of the domain but I connected it wirelessly to the network so it is using the same DNS as all of the domain computers.  I did the following:

Connect successfully to Exchange using server name of SERVER with "connect using HTTP" disabled.

Connect successfully to Exchange using server name of MAIL.DOMAIN.COM with "connect using HTTP" disabled.

Connect successfully to Exchange using server name of SERVER with "connect using HTTP" enabled, using https://MAIL.DOMAIN.COM, no MSSTD, HTTP first for fast and slow networks, and Basic Authentication.

Connect successfully to Exchange using server name of SERVER with "connect using HTTP" enabled, using https://MAIL.DOMAIN.COM, no MSSTD, HTTP first for fast and slow networks, and Basic Authentication.

Connect successfully to Exchange using server name of MAIL.DOMAIN.COM with "connect using HTTP" enabled, using https://MAIL.DOMAIN.COM, no MSSTD, HTTP first for fast and slow networks, and Basic Authentication.

If I disconnect from the LAN and connect my laptop to the internet through my cell phone, I am unable to create a new connection to the Exchange server using any of the above-mentioned settings.  HOWEVER, if I connect successfully to the Exchange server with HTTP enabled while on the LAN and then switch to my cell phone, I am still able to connect to the Exchange server.  It's like once Outlook as successfully connected with the Exchange server once locally, it can connect remotely as well.  Unfortunately, that's not a solution for workstations that are offsite and cannot be brought to the main location to be connected to Outlook.

Once I connect Outlook on my laptop to Exchange, whenever I start Outlook, I get a certificate error that states that Outlook is trying to connect to AUTODISCOVER.DOMAIN.COM and I have to hit Yes to allow it to use the certificate, which is assigned to MAIL.DOMAIN.COM.  However, none of the workstations on the local domain running Outlook with the same settings as the laptop get that certificate error.  Initially when I installed the MAIL.DOMAIN.COM certificate, I would get a certificate error twice when starting Outlook on a domain computer but I fixed that by telling Exchange to use the MAIL.DOMAIN.COM cert instead of SERVER.DOMAIN.LOCAL.  I figure that might matter.

If there are any other configurations you'd like me to test, let me know.  Thanks!
0
MegaNuk3Commented:
Does the cert not contain the autodiscover.domain.com name? If not, then remove autodiscover names (A record CName etc) from external DNS and add a SRV record pointing at mail.domain.com:
http://support.microsoft.com/kb/940881
0
MegaNuk3Commented:
In all your testing did you have outlook open with /rpcdiag to confirm it was indeed connecting over HTTP and not TCP?
0
SINC_dmackAuthor Commented:
Correct, the cert did not have autodiscover.domain.com.  I deleted the autodiscover CNAME and replaced it with an SRV record per the Microsoft link you provided.  

I didn't use /rpcdiag during my testing today.  I'll repeat the testing tomorrow with /rpcdiag and post the updated results.

Thanks for all of your help!
0
SINC_dmackAuthor Commented:
Apparently I didn't set up the SRV record correctly because testexchangeconnectivity.com returns this:

Attempting to contact the Autodiscover service using the DNS SRV redirect method.       ExRCA failed to contact the Autodiscover service using the DNS SRV redirect method.      

Attempting to locate SRV record _autodiscover._tcp.domain.com in DNS.
       The Autodiscover SRV record wasn't found in DNS.

I'm not sure what I did wrong, since I followed the guidelines provided by MS.  I'll troubleshoot tomorrow.
0
MegaNuk3Commented:
Maybe your DNS change hasn't replicated around fully yet...
0
SINC_dmackAuthor Commented:
I retested Outlook /rpcdiag using a laptop on the LAN and connected remotely via cell phone.  When connecting locally, it uses HTTPS when configured as such and TCP when HTTPS is not specified, so that much appears to be working properly.  

When I specify HTTPS over the internet via the cell phone, rpcdiag indicates that Outlook is unable to connect to the server.  But when I switch that Outlook profile back to the LAN, let it connect to the Exchange server, and then switch it back to cell phone internet, rpcdiag indicates that Outlook successfully connects via HTTPS.  What I don't understand is why Outlook can connect remotely via HTTPS only AFTER it connects locally via HTTPS.  

The SRV record still isn't working according to testexchangeconnectivity.  The registrar is Godaddy, which is usually ridiculously fast (nearly instantaneous, believe it or not) at propagating DNS changes, and it's already been about 16 hours.  

I removed my CName for autodiscover.domain.com.  I set up the SRV record like this:

service: _autodiscover
protocol: _tcp
name: autodiscover
priority: 0
weight: 65535
port: 443
target: mail.domain.com

Did I get something wrong there?  Thanks!
0
MegaNuk3Commented:
Change your 'name' to '@' and the Weight to '0' then you should be good to go on that SRV record as per:
http://msmvps.com/blogs/bradley/archive/2008/12/18/autodiscover-and-dns.aspx
0
SINC_dmackAuthor Commented:
I've updated the zone file and will report back with the results this weekend.  Thanks!
0
MegaNuk3Commented:
Fingers crossed
0
SINC_dmackAuthor Commented:
No dice.  testexchangeconnectivity.com reports that autodiscover using SRV works properly now (thanks!) but I still can't connect with remote Outlook.  
0
MegaNuk3Commented:
Does www.testexchangeconnectivity.com complete an Outlook anywhere (with autodiscover) test successfully?
0
SINC_dmackAuthor Commented:
Yes, the test passed when I ran Outlook Anywhere RPC over HTTP with Autodiscover enabled.  The informational certificate warning appeared twice: "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."

The referral service test returned the following informational warning:  "Attempting to perform referral for user /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User Name on server SERVER.DOMAIN.local.
  The test passed with some warnings encountered. Please expand the additional details.
  The Referral service returned generic error 0x80004005. This may mean that encryption is required. ExRCA is trying again with encryption."
 
This just sounds like the server is set to require encryption on referrals.  The next step, where the referral service tries again using encryption, is passed with no notifications.  

Hopefully there's something helpful here!
0
MegaNuk3Commented:
try increasing the Outlook timeout values:

http://support.microsoft.com/kb/831060
ConnectTimeout = 000493e0 (DWORD) =ms =300000 = 5mins
ConnectTimeoutLow
RFRTimeout

By default Outlook only waits 45 seconds for RPC/HTTP to connect
0
SINC_dmackAuthor Commented:
I checked three computers running Office 2010, and none of them have the RPC key under HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook.  I created the RPC key and added the three DWORD values as directed in the MS article, but it appeared to have no effect on the time-out--it still seems to time out after 45 seconds.  I even searched the registry for "connecttimeoutlow" to make sure the DWORD wasn't somewhere else, and it wasn't--it just plain doesn't exist.  Weird.
0
MegaNuk3Commented:
I take it that you did the usual reboot if the PC etc after setting that reg setting?
0
SINC_dmackAuthor Commented:
Yessir.  

I just rebooted again to be sure, and it still seems to time out after ~45 seconds.  
0
MegaNuk3Commented:
try these:
1.) Put in DefConnects reg entry as per http://support.microsoft.com/kb/913843/en-us
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\RPC
DefConnectOpts (DWORD) 0

2.) Change outlook to NTLM:
In the Mail dialog box, click your Outlook profile, and then click Properties.
Click E-mail Accounts, and then click Change.
In the Change E-mail Account dialog box, click More Settings.
In the Microsoft Exchange dialog box, click the Security tab.
In the Logon network security list, click Password Authentication (NTLM), and then click OK.
Click Next, click Finish, and then click Close two times

3.) Change proxy to basic authentication:
In the Mail dialog box, click your Outlook profile, and then click Properties.
Click E-mail Accounts, and then click Change.
In the Change E-mail Account dialog box, click More Settings.
In the Microsoft Exchange dialog box, click the Connection tab.
Click Exchange proxy settings button
In the proxy authentication settings list, click Basic Authentication, and then click OK.OK
Click Next, click Finish, and then click Close two times

4.) Enter logon credentials as UPN (user@domain.com)
0
SINC_dmackAuthor Commented:
1) I added the registry entry as directed, except under the 14.0 folder since I'm running Outlook 2010.  

2) Changed Logon to Password Authentication (NTLM).

3) Proxy was already set to basic authentication.  I tried it with and without the MSSTD entry.

4) When attempting to log on using username@domain.com, I would repeatedly get prompted for my credentials.  When I entered just username and the password, it would wait a short time and then return "The action cannot be completed.  The connectino to the Microsoft Exchange Server is unavailable."

So, no luck yet.  
0
MegaNuk3Commented:
Try Start--> Run--> ExBPA
See if it highlights anything, like your RPC endpoints
0
SINC_dmackAuthor Commented:
ExBPA returned a warning for "SSL is enabled on the IIS root directory", which is fine since all this server provides via IIS is Exchange stuff.  Just for the heck of it, I turned off "SSL required" on the default website and restarted IIS--it had no effect on the Outlook connectivity issue.

More important, however, were the two Certificate SAN mismatch errors that were logged.  

The subject alternative name (SAN) of SSL certificate for https://SERVER.DOMAIN.local/Microsoft-Server-ActiveSync does not appear to match the host address. Host address: SERVER.DOMAIN.local. Current SAN: DNS Name=mail.DOMAIN.net.

The subject alternative name (SAN) of SSL certificate for https://SERVER.DOMAIN.local/owa does not appear to match the host address. Host address: SERVER.DOMAIN.local. Current SAN: DNS Name=mail.DOMAIN.net.

I'm guessing that these errors are because I didn't install the "right" kind of cert.  I used a single site cert for mail.domain.net from rapidssl.com.  If you think that might be the issue, what kind of cert should I purchase, and do you have a recommended vendor?  I've always used rapidssl.com but the wildcard certs have been rather pricy so I've stuck with single-site certs unless otherwise necessary.  Thanks!
0
MegaNuk3Commented:
What flagged the SAN cert mismatch? ExBPA?
0
SINC_dmackAuthor Commented:
Yup, I ran a health check with the BPA.  
0
MegaNuk3Commented:
What Outlook versions are you trying to connect?

From an external Outlook 2007/2010 client van you perform an autoconfig test:
With outlook open/opening/prompting hold down CTRL key and right click on the Outlook icon in the bottom right hand side of your screen, then on the popup menu select the "Test Autoconfiguration". Select that, enter valid credentials and select the "autodiscover" option only and test. See if it OS contacting Autodiscover and finding the correct URls
0
SINC_dmackAuthor Commented:
I was originally trying to connect with Outlook 2010 and Outlook 2003 clients.  I've since upgraded the 2003 clients to 2010.

I am able to run Test Autoconfiguration from a locally connected Outlook 2010 client, which it passed, but when I tried to run it from a remote client, nothing happens--I click on "test autoconfiguration" from the Outlook system tray icon but the test window never appears.  If I click OK to all of the "Outlook can't connect to the server" prompts, Outlook closes, at which point I obviously can't run the test.  

I then tested with a laptop with Outlook 2010 that I was able to use to connect to Exchange locally.  After authenticating locally, I switched the laptop to connecting to the internet through my cell phone.  I ran the autoconfiguration test and it passed.  So it seems like autoconfiguration works both locally and remotely--but I can only test it remotely after connecting Outlook to Exchange locally first.  
0
MegaNuk3Commented:
So how is the laptop connect to your phone? Bluetooth or cable? Is your phone connected to the Internet over Wi-Fi or 3G?

Does outlook go "offline/disconnected" when you swap from the local connection to the cell phone?
0
SINC_dmackAuthor Commented:
The phone is an iPhone 3GS with a tethering app installed.  The app creates a wireless access point and devices that connect to it can access the internet via the cell phone provider.  It is not tethered via cable or Bluetooth, although those are both options in the tethering app.

I don't have my laptop with me to test with, but when I was testing previously and would switch from the LAN to cell phone internet, I would close Outlook while switching.  When I would re-open Outlook, it would connect properly.  Would you like me to try switching from LAN to cell phone internet without closing Outlook?
0
MegaNuk3Commented:
Have you tested a laptop externally plugged into a proper broadband/internet connection?
0
SINC_dmackAuthor Commented:
Yes, I've tested using the laptop at several remote locations using DSL.  I get the same results.  
0
MegaNuk3Commented:
Can you confirm the
CertPrincipalName    : msstd:mail.DOMAIN.net

Is that the common name of your cert and does it resolve internally to the internal IP of your CAS server?
0
SINC_dmackAuthor Commented:
The certificate is issued to mail.domain.net.  When I ping mail.domain.net locally, it resolves to the local IP address of the Exchange 2010 server.  

Thanks for sticking it out--I know we are probably getting short on potential causes, since everything looks like it SHOULD be working properly.  
0
MegaNuk3Commented:
When you get prompted for credentials, did you try:
Domain\username
Password
0
SINC_dmackAuthor Commented:
Yup, I get the same result no matter whether I try DOMAIN\username, DOMAIN.local\username or just username.  
0
MegaNuk3Commented:
Try disable the windows firewall on the exchange 2010 server to see if Outlook will then connect.
0
SINC_dmackAuthor Commented:
Turning the firewall off on the Exchange server had no effect on the ability of remote workstations to connect--they still fail to do so.
0
MegaNuk3Commented:
On your CAS properties in EMC set Outlook Anywhere external hostname to not contain "msstd:" and ensure Basic auth is set.

On the Client connect to the owa site and install the certificate locally in your trusted root CA store. Add the cert / http proxy name to your IE exclusions/exceptions list

Then test Outlook anywhere again
0
SINC_dmackAuthor Commented:
Under EMC -> Server Configuration -> Server Properties -> Outlook Anywhere tab, the external host name is set to mail.domain.com.  Msstd: is not present.  Basic authentication is bulletted and Allow SSL offloading is unchecked.

I manually imported the certificate into the trusted root CA store via OWA on a remote computer.  I'm not sure where to add the cert / http proxy name to the IE exclusions/exceptions list.  Please clarify.  Thanks!
0
MegaNuk3Commented:
What version of Internet Explorer do you have?
Under Tools --> Internet options -->connections--> LAN Settings
Make sure you are not using a 'Automatic configuration script' and if you have a 'proxy server' defined then click the 'Advanced' button and add your cert name to the list of 'Exceptions' at the bottom
0
SINC_dmackAuthor Commented:
I'm using IE8 or IE9 on the computers I've tested with.  No automatic configuration is specified on any of the test computers, and no proxy server is in use.  
0
MegaNuk3Commented:
What happens if you go to https://mail.domain.net/RPC/rpcproxy.dll
0
SINC_dmackAuthor Commented:
Hi, sorry for the delay in response.  

When I go to https://mail.domain.net/RPC/rpcproxy.dll, I am prompted for logon credentials.  When I enter my domain username and password, I am taken to a blank IE window (no error, no text, no anything) and the status bar at the bottom indicates "done".
0
MegaNuk3Commented:
Ok, that is what you are supposed to get.
0
SINC_dmackAuthor Commented:
EE prompted me to return to this question since it's been a few weeks.  I'm pretty confident that this issue has something to do with the certificate I purchased for mail.domain.net--when I bought the certificate, I did it in the same way that I would for a single site cert for a Windows Server 2003 environment.  I've since did a little reading and it looks like I should have used a SAN certificate instead of a single-site certificate.  http://exchangeserverpro.com/exchange-2010-ssl-certificates

I don't have confirmation of this at the moment, as my certificate is only a few months old and works okay for just about everything except remote Outlook RPC-HTTP.  Once I replace the cert, I'll report back as to whether or not that fixed my problem.  
0
MegaNuk3Commented:
Under here:
Under EMC -> Server Configuration -> Server Properties -> Outlook Anywhere tab, the external host name is set to mail.domain.com.  Msstd: is not present.  Basic authentication is bulletted and Allow SSL offloading is unchecked.

The hostname should be mail.domain.net
It should match the common name on your cert, single name Certs work fine with Outlook Anywhere
0
SINC_dmackAuthor Commented:
Yup, Outlook Anywhere settings are:
Status: Enabled
External Host Name: mail.domain.net
Basic Authentication: bulleted
Allow SSL offloading: unchecked

The single-site cert is assigned to mail.domain.net, which matches the external host name under the Outlook Anywhere settings.  
0
MegaNuk3Commented:
What does the Outlook Anywhere test on www.testexchangeconnectivity.com say nowadays anyway?
0
SINC_dmackAuthor Commented:
Hi,

Here are the most recent results.  The overall test passed, and the following are the only notifications that appeared.  (With the exception of the "some versions of Windows must have the root certificates update in order to use SSL with this server" message.)

Attempting to test potential Autodiscover URL https://DOMAIN.net/AutoDiscover/AutoDiscover.xml
Testing of this potential Autodiscover URL failed.
       
Attempting to test potential Autodiscover URL https://autodiscover.DOMAIN.net/AutoDiscover/AutoDiscover.xml
Testing of this potential Autodiscover URL failed.
       
Attempting to contact the Autodiscover service using the HTTP redirect method.
The attempt to contact Autodiscover using the HTTP Redirect method failed.

Attempting to contact the Autodiscover service using the DNS SRV redirect method.
ExRCA successfully contacted the Autodiscover service using the DNS SRV redirect method.

And later, when testing referral:

Attempting to perform referral for user /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User Name on server SERVER.DOMAIN.local.
The test passed with some warnings encountered. Please expand the additional details.
Additional Details
The Referral service returned generic error 0x80004005. This may mean that encryption is required.

ExRCA is trying again with encryption.
Attempting to perform referral for user /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User Name on server SERVER.DOMAIN.local.
ExRCA successfully got the referral.
0
MegaNuk3Commented:
Remind me, how many exchange servers do you have and how many AD domains?
0
SINC_dmackAuthor Commented:
The configuration is Windows Server 2008 R2 running Exchange 2010, all service packs and updates (at least as of last week) applied.  This server is the only domain controller for the only domain, and it is also the only Exchange server.  Pretty much about as simple of an Exchange setup as possible.
0
Glen KnightCommented:
I've requested that this question be deleted for the following reason:

This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
0
SINC_dmackAuthor Commented:
I'm not sure deleting this question would be the best course of action--certainly there's info here that could be helpful to people in a similar situation.  I haven't resolved the issue yet but I am just about positive that I should have used a SAN cert instead of a single-site cert.  Once my single-site cert expires, I'm going to replace it with a SAN cert to see if that solves the problem.  Of course that'll be a few months before that happens since the current cert is good until April, but I plan to report back at that point.  So if there's no dire need to delete or close the question now, I request that it be left open so I can follow up.  Thanks!
0
NELMOCommented:
SINC_dmack:

I have EXACTLY the same issue as you except that I used the 'multiple domains - for exchange servers' rather than a single domain cert.

Did you solve the problem or are you still waiting?

Regards

Neil
0
SINC_dmackAuthor Commented:
Hi Neil,

No I haven't resolved the issue yet.  I've got a couple months left on my cert and I've been so busy that I haven't had a chance to look into replacing it with a SAN cert.  I probably won't wait for the existing cert to expire, but it may be a couple of weeks before I have the free time to get a new cert.  I'll post back with my results.
0
SINC_dmackAuthor Commented:
Here's my followup and solution--it actually works!

A month ago or so, I renewed my SSL certificate.  And being hard-headed and unwilling to spend $200 for a wildcard cert, I renewed it as a single site cert for mail.domain.net.  When I created the cert request in Exchange, I told it to use "mail.domain.net" for everything that it asked me for an FQDN for.  Afterward, I still couldn't get Outlook to connect remotely via RPC-HTTPS.  

Fast forward to a couple of days ago.  We had a client which had previously been using a single-site cert on their Exchange 2003 server.  We were in the process of deploying a new SBS11 box and migrated the single site cert.  Of couse we couldn't get Outlook RPC-HTTPS to work and it was a bit stressful as the client has several remote users who needed that access.  I couldn't figure it out and was about to buy a wildcard cert for the client.  

One of my techs said "hey, you've got it working at our shop with a single site cert--just figure out what's different between here and there."  I said "no friggin' way".  He said "yeah, I set it up at home and just filled in the email address, username and password, and Outlook figured out the rest".  

So I fired up Outlook 2010 and set up a new profile.  I left the bullet next to "E-mail Account" and filled in the Your Name, E-mail Address, and Password fields.  Lo and behold, Outlook autodiscovered the settings and connected successfully!  I got a certificate error for autodiscover.domain.net since the cert is for mail.domain.net, but I installed it and it continued without complaining.  

When I checked under "configure settings manually" to see what Outlook had set up, the checkmark was present next to "Connect to Microsoft Exchange using HTTP".  Under the Exchange Proxy Settings were the following:

Connect to https:  mail.domain.net
Checkmark - Connect using SSL only
Checkmark - Only connect to proxy servers..
msstd:mail.domain.net
No checkmark - On fast networks connect using HTTP first, then TCP/IP
Checkmark - On slow networks connect using HTTP first, then TCP/IP
Basic authentication

I remembered having set up an autodiscover on the Godaddy.com domain control panel for my domain, so I logged on to check it out.  It is configured as:

A-record for autodiscover points to public IP of mail server
SRV record for autodiscover configured as:
Service - _autodiscover
Protocol - _tcp
Name - @
Priority - 0
Weight - 0
Port - 443
Target - mail.domain.net

I created the same settings for our client and let a remote Outlook client autodiscover.  Sure enough, it worked!  The moral of the story?  Apparently autodiscover is important, and letting Outlook do things the "dumb" way is better than manually configuring the mail server settings.

Thanks to everyone for their assistance!
0
SINC_dmackAuthor Commented:
One more thing--I'm going to change our Exchange from Basic Authentication to NTLM so it quits prompting me for the password every time.  Our client is already set up for NTLM so I don't foresee that causing any problems.
0
SINC_dmackAuthor Commented:
I assigned 350 points to Meganuke since his suggestions pointed me most of the way to the solution, although letting Outlook autodiscover was the final piece of the puzzle which I figured out myself.  (Or at least with the input of my tech.)  Thanks again!
0
llhuffCommented:
In my case when the enter password box came up I had to "switch user" and changed from

mail@domain.com
password

to

domain\username
password

Outlook anywhere immediately connected
0
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
Exchange

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.