Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
Remote users unable to connect to the SBS 2003 Exchange server.
I am working on a Windows 2003 SBS server issue with Exchange.
The problem is that remote users cannot open their mailboxes. Local users are able to open their mailboxes without issue. ActiveSync and OWA both work correctly. https://www.testexchangeconnectivity.com shows no errors on either the RPC test or the activesync test (with the exception of a warning that windows phones older than version 6 may not trust the cert). There are no cert errors. Port 443, 25, 80 all forward to the internal IP of the server. I aslo added port forwards for port 6001, 6002 and 6004 to the router and another tech added port 1723 for a VPN.
The IIS virtual directories are set with the following authentication and access control:
Exadmin - Integrated Windows authentication
Exchange - Integrated windows authentication, Basic authentication.
ExchWeb - Anonymous access
Microsoft Server ActiveSync - Basic Authentication
OMA - Basic Authentication
RPC - Integrated Windows authentication, Basic authentication
RPCwithCert - Integrated Windows authentication
I deleted and recreated the virtual directories in IIS. I set up the users account on a remote workstation that I have access to. It will not work via the RPC over http, but if I connect via a VPN, it works fine.
The settings on the client system are set up as follows: Cached mode enabled (also tried without), encrypt data between outlook and exchange is turned on (also tried with off), Negotiate authentication (also tried with NTLM and keberos). Set to connect using http, the FQDN is used as the proxy server, connect using ssl only is selected, set to basic authentication
This is a single server set up, the registry entries have been made to point to the correct ports, the Kaspersky firewall has been disabled (to rule out the possibility that it was blocking it). Any assistance or suggestions in this matter would be greatly appreciated.
The problem is that remote users cannot open their mailboxes. Local users are able to open their mailboxes without issue. ActiveSync and OWA both work correctly. https://www.testexchangeconnectivity.com shows no errors on either the RPC test or the activesync test (with the exception of a warning that windows phones older than version 6 may not trust the cert). There are no cert errors. Port 443, 25, 80 all forward to the internal IP of the server. I aslo added port forwards for port 6001, 6002 and 6004 to the router and another tech added port 1723 for a VPN.
The IIS virtual directories are set with the following authentication and access control:
Exadmin - Integrated Windows authentication
Exchange - Integrated windows authentication, Basic authentication.
ExchWeb - Anonymous access
Microsoft Server ActiveSync - Basic Authentication
OMA - Basic Authentication
RPC - Integrated Windows authentication, Basic authentication
RPCwithCert - Integrated Windows authentication
I deleted and recreated the virtual directories in IIS. I set up the users account on a remote workstation that I have access to. It will not work via the RPC over http, but if I connect via a VPN, it works fine.
The settings on the client system are set up as follows: Cached mode enabled (also tried without), encrypt data between outlook and exchange is turned on (also tried with off), Negotiate authentication (also tried with NTLM and keberos). Set to connect using http, the FQDN is used as the proxy server, connect using ssl only is selected, set to basic authentication
This is a single server set up, the registry entries have been made to point to the correct ports, the Kaspersky firewall has been disabled (to rule out the possibility that it was blocking it). Any assistance or suggestions in this matter would be greatly appreciated.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
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.
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?
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.
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
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.
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.
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.
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.
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?
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.
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?
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-Act
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
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?{ex
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=rgu
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=rgu
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.
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-Act
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
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?{ex
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=rgu
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=rgu
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.
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.
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?
How are your smart phones doing with this? Do you have droids / iphones, and do they connect with no issues?
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.
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
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
Sorry for the delay in response.
I uninstalled and reinstalled RPC over HTTP, then configured it again so that it would pass the MS exchange connectivity tool. Tested and saw absolutely no change.
All of the client settings are right, I am setting up a test account on my workstation and am confident that the settings are all correct.
So after all of this, it still was not working correctly.
So, I decided that I would ping the server from itself, just to see what it came back with.
It came back with an IPv6 address, which was odd since IPv6 was unchecked in the adapter properties. So, I rechecked the box, then uninstalled the IPv6 protocol. As soon as I did that, it started functioning correctly.
I appreciate all of your help, which greatly assisted me in resolving the issue (by eliminating a number of possible causes).
I uninstalled and reinstalled RPC over HTTP, then configured it again so that it would pass the MS exchange connectivity tool. Tested and saw absolutely no change.
All of the client settings are right, I am setting up a test account on my workstation and am confident that the settings are all correct.
So after all of this, it still was not working correctly.
So, I decided that I would ping the server from itself, just to see what it came back with.
It came back with an IPv6 address, which was odd since IPv6 was unchecked in the adapter properties. So, I rechecked the box, then uninstalled the IPv6 protocol. As soon as I did that, it started functioning correctly.
I appreciate all of your help, which greatly assisted me in resolving the issue (by eliminating a number of possible causes).
Premium Content
You need an Expert Office subscription to comment.Start Free Trial