SINC_dmack
asked on
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=Recip
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?
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=Recip
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?
ASKER
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.
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?
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?
ASKER
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."
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."
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)
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)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Can you also go into EMS and do:
Get-outlookProvider | fl
And look under the EXPR settings at the externalhostname and certprincipalname values...
Get-outlookProvider | fl
And look under the EXPR settings at the externalhostname and certprincipalname values...
ASKER
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!
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!
can you post the output from get-outlookprovider |fl from under the EXPR settings?
Use
Set-OutlookProvider EXPR -CertPrincipalName:"msstd:
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
Use
Set-OutlookProvider EXPR -CertPrincipalName:"msstd:
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
ASKER
Hi MegaNuk3,
I ran Set-OutlookProvider EXPR -CertPrincipalName:"msstd:
Here is the output from get-outlookprovider |fl.
[PS] C:\Windows\system32>get-ou
RunspaceId : adb8fa39-2df9-4c92-bb4a-7e
CertPrincipalName :
Server :
TTL : 1
OutlookProviderFlags : None
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
Name : EXCH
DistinguishedName : CN=EXCH,CN=Outlook,CN=Auto
CN=Services,CN=Configurati
Identity : EXCH
Guid : 0a17b8f8-2675-430e-9504-ae
ObjectCategory : DOMAIN.local/Configuration
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-7e
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=Auto
CN=Services,CN=Configurati
Identity : EXPR
Guid : 19484cd8-5ff9-41bf-a434-65
ObjectCategory : DOMAIN.local/Configuration
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-7e
CertPrincipalName :
Server :
TTL : 1
OutlookProviderFlags : None
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
Name : WEB
DistinguishedName : CN=WEB,CN=Outlook,CN=AutoD
N=Services,CN=Configuratio
Identity : WEB
Guid : 3735ab56-3582-4289-836e-d1
ObjectCategory : DOMAIN.local/Configuration
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>
I ran Set-OutlookProvider EXPR -CertPrincipalName:"msstd:
Here is the output from get-outlookprovider |fl.
[PS] C:\Windows\system32>get-ou
RunspaceId : adb8fa39-2df9-4c92-bb4a-7e
CertPrincipalName :
Server :
TTL : 1
OutlookProviderFlags : None
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
Name : EXCH
DistinguishedName : CN=EXCH,CN=Outlook,CN=Auto
CN=Services,CN=Configurati
Identity : EXCH
Guid : 0a17b8f8-2675-430e-9504-ae
ObjectCategory : DOMAIN.local/Configuration
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-7e
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=Auto
CN=Services,CN=Configurati
Identity : EXPR
Guid : 19484cd8-5ff9-41bf-a434-65
ObjectCategory : DOMAIN.local/Configuration
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-7e
CertPrincipalName :
Server :
TTL : 1
OutlookProviderFlags : None
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
Name : WEB
DistinguishedName : CN=WEB,CN=Outlook,CN=AutoD
N=Services,CN=Configuratio
Identity : WEB
Guid : 3735ab56-3582-4289-836e-d1
ObjectCategory : DOMAIN.local/Configuration
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>
ASKER
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.c
Here is the output from running get-OutlookAnywhere |fl.
[PS] C:\Windows\system32>get-Ou
RunspaceId : d1551287-5f87-4980-a6dc-f7
ServerName : SERVER
SSLOffloading : False
ExternalHostname : mail.DOMAIN.net
ClientAuthenticationMethod
IISAuthenticationMethods : {Basic}
XropUrl :
MetabasePath : IIS://SERVER.DOMAIN.local/
Path : C:\Windows\System32\RpcPro
ExtendedProtectionTokenChe
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
inistrative Group (FYDIBOHF23SPDLT),CN=Admin
=Microsoft Exchange,CN=Services,CN=Co
Identity : SERVER\Rpc (Default Web Site)
Guid : 7623ceab-974e-43da-a7b3-f3
ObjectCategory : DOMAIN.local/Configuration
ObjectClass : {top, msExchVirtualDirectory, msExchRpcHttpVirtualDirect
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>
Here is the output from running get-OutlookAnywhere |fl.
[PS] C:\Windows\system32>get-Ou
RunspaceId : d1551287-5f87-4980-a6dc-f7
ServerName : SERVER
SSLOffloading : False
ExternalHostname : mail.DOMAIN.net
ClientAuthenticationMethod
IISAuthenticationMethods : {Basic}
XropUrl :
MetabasePath : IIS://SERVER.DOMAIN.local/
Path : C:\Windows\System32\RpcPro
ExtendedProtectionTokenChe
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
inistrative Group (FYDIBOHF23SPDLT),CN=Admin
=Microsoft Exchange,CN=Services,CN=Co
Identity : SERVER\Rpc (Default Web Site)
Guid : 7623ceab-974e-43da-a7b3-f3
ObjectCategory : DOMAIN.local/Configuration
ObjectClass : {top, msExchVirtualDirectory, msExchRpcHttpVirtualDirect
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>
ASKER
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.
So, next question is. Do you have a laptop and 3G card or external ADSL connection to test externally?
ASKER
Yes, I have been using Outlook at another location with a separate DSL account to test RPC-HTTP connectivity.
Ok, so does that external Outlook still not connect?
ASKER
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!
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!
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
http://support.microsoft.com/kb/940881
In all your testing did you have outlook open with /rpcdiag to confirm it was indeed connecting over HTTP and not TCP?
ASKER
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!
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!
ASKER
Apparently I didn't set up the SRV record correctly because testexchangeconnectivity.c
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.
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.
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.
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.
Maybe your DNS change hasn't replicated around fully yet...
ASKER
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!
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!
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
http://msmvps.com/blogs/bradley/archive/2008/12/18/autodiscover-and-dns.aspx
ASKER
I've updated the zone file and will report back with the results this weekend. Thanks!
Fingers crossed
ASKER
No dice. testexchangeconnectivity.c
Does www.testexchangeconnectivity.com complete an Outlook anywhere (with autodiscover) test successfully?
ASKER
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=Recip
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!
The referral service test returned the following informational warning: "Attempting to perform referral for user /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recip
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!
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
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
ASKER
I checked three computers running Office 2010, and none of them have the RPC key under HKEY_CURRENT_USER\Software
I take it that you did the usual reboot if the PC etc after setting that reg setting?
ASKER
Yessir.
I just rebooted again to be sure, and it still seems to time out after ~45 seconds.
I just rebooted again to be sure, and it still seems to time out after ~45 seconds.
try these:
1.) Put in DefConnects reg entry as per http://support.microsoft.com/kb/913843/en-us
HKEY_CURRENT_USER\Software
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)
1.) Put in DefConnects reg entry as per http://support.microsoft.com/kb/913843/en-us
HKEY_CURRENT_USER\Software
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)
ASKER
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.
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.
Try Start--> Run--> ExBPA
See if it highlights anything, like your RPC endpoints
See if it highlights anything, like your RPC endpoints
ASKER
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!
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!
What flagged the SAN cert mismatch? ExBPA?
ASKER
Yup, I ran a health check with the BPA.
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
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
ASKER
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.
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.
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?
Does outlook go "offline/disconnected" when you swap from the local connection to the cell phone?
ASKER
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?
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?
Have you tested a laptop externally plugged into a proper broadband/internet connection?
ASKER
Yes, I've tested using the laptop at several remote locations using DSL. I get the same results.
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?
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?
ASKER
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.
Thanks for sticking it out--I know we are probably getting short on potential causes, since everything looks like it SHOULD be working properly.
When you get prompted for credentials, did you try:
Domain\username
Password
Domain\username
Password
ASKER
Yup, I get the same result no matter whether I try DOMAIN\username, DOMAIN.local\username or just username.
Try disable the windows firewall on the exchange 2010 server to see if Outlook will then connect.
ASKER
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.
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
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
ASKER
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!
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!
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
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
ASKER
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.
What happens if you go to https://mail.domain.net/RPC/rpcproxy.dll
ASKER
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".
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".
Ok, that is what you are supposed to get.
ASKER
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.
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.
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
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
ASKER
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.
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.
What does the Outlook Anywhere test on www.testexchangeconnectivity.com say nowadays anyway?
ASKER
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=Recip
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=Recip
ExRCA successfully got the referral.
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=Recip
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=Recip
ExRCA successfully got the referral.
Remind me, how many exchange servers do you have and how many AD domains?
ASKER
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.
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.
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
ASKER
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!
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
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
ASKER
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.
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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
ASKER
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!
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
mail@domain.com
password
to
domain\username
password
Outlook anywhere immediately connected
HTH