Outlook Anywhere

Outlook Anywhere (Full Version)

All Forums >> [Microsoft Exchange 2003] >> Message Routing

Message

digeratiTyson -> Outlook Anywhere (23.Jun.2008 10:15:12 AM)
I have an exchange 2007 install running that has worked pretty well so far. One thing that has been making things hard is that right now we are sending email out from our server using the domain emample.com our internal DNS name space is: example.net unfortunately this also happens to be an internet namespace as well (we have control over this) but we keep running into the problem that when we attempt to setup outlook anywhere the server is reporting its internal DNS name when you attempt to hit it from outside the network while setting up an Outlook Anywhere client it keeps reporting its internal name. The other issue is that there is no valid SSL cert for the internal domain name example.net so I am sure that is a problem as well. I have set up our internet DNS (hosted by godaddy) so that exchange.example.net resolves but the best I can do on that end is put a CNAME in place that points it to the proper DNS name exchange.example.com. I have also heard from one person that he is getting bounce backs once in a while because some mail services see the mail coming from example.net when the message says its coming from example.com. I understand why this is happening but short of changing my internal namespace, I am not sure what to do. Does anyone know how to get exchange to report a different DNS name when sending email? Have any other suggestions?

Sembee -> RE: Outlook Anywhere (24.Jun.2008 1:28:29 PM)
First - this is an Exchange 2003 section. You posted in the wrong forum. You need to setup a split DNS system so that the DNS lookups internally resolve to the correct place. You may also have to do something with autodiscover, but that depends on whether your host supports SRV records. The SSL certificate issues needs to be resolved. You should have a UC/SAN certificate that has both the internal and external names in it. That would be the internal name of your Exchange server, both its FQDN and Netbios name. I blogged on this a little while ago: http://www.sembee.co.uk/archive/2008/05/30/78.aspx Simon.

digeratiTyson -> RE: Outlook Anywhere (24.Jun.2008 1:54:01 PM)
First off, oops ;0) Sorry about that! Thanks a lot for replying to my post anyway. You gave me some very good information that gives me another avenue to explore. The wierd thing is that AutoDisover appears to work, you get the first request from "autodiscover.example.com" and it takes the proper credentials but the second request I get comes from the internal server name "exchange.example.net" My firs SSL cert was a Wildcard cert but after looking into why ActiveSync was not working I then just registered one for the server itself. I looks like I have to go a bit further.

Sembee -> RE: Outlook Anywhere (24.Jun.2008 2:05:36 PM)
Wildcard certificates are not really suitable because you are using two different domains. That is where a SAN/UC certificate helps, as you can mix and match the domains being used. Once you get the certificates correct you can then look at URLs that Exchange is handing out. A split DNS system may well be the way to go, which will ensure that you have control over the internal DNS. Simon.

digeratiTyson -> RE: Outlook Anywhere (24.Jun.2008 3:18:15 PM)
Is that UC same thing as UUC? I see that refence in SSL certs from places like GoDaddy

Sembee -> RE: Outlook Anywhere (24.Jun.2008 5:14:09 PM)
Sure you don't mean UCC ? Same thing - Unified Communications Certificate. I use just UC as usually type the word certificate. Simon.

digeratiTyson -> RE: Outlook Anywhere (1.Jul.2008 10:18:03 AM)
Ok, I have the UCC cert installed and have it installed in Exchange and IIS. I can get past the autodiscover but when I attempt to get further after enabling Outlook Anywhere in Outlook it just keeps popping me for credentials. I have tried every combination I can think of and I know I am not fat-fingering anything, it just keeps asking over and over again. It looks like I am close, but I have no idea why its not letting me any further. Have you seen this before?

Sembee -> RE: Outlook Anywhere (1.Jul.2008 11:35:47 AM)
Is Autodiscover giving the right information out? If not then you need to check that and change it. The other common problem is authentication mismatch - using NTLM on one side and basic on the other. Ensure that you are using the same. Basic is guaranteed to pass through firewalls, integrated/NTLM is not. Therefore it could be that element that is causing the problem. Simon.

digeratiTyson -> RE: Outlook Anywhere (1.Jul.2008 11:43:01 AM)
Yeah, that is the really confusing part: Autodiscover gets past the first part of the process (where Outlook says "Search for email address server settings) with no problem. The second (where Outlook says "Log on to server) fails. If i go and set up the connection manually that is when I get the never ending prompt or it tells me that either Outlook cannot resolve the server name (even though i can ping it) or that exchange is not available. I double checked the log in settings in the Exchange control panel and the authentication types match. How do I determine the info that Autodiscover is sending?

digeratiTyson -> RE: Outlook Anywhere (1.Jul.2008 1:53:07 PM)
Another wierd thing I notice is that when I run Get-OutlookProvider at the Management Shell I get: [PS] C:\Windows\System32>Get-outlookprovider Name Server CertPrincipalName TTL ---- ------ ----------------- --- EXCH 1 EXPR 1 WEB 1 I would think that there is supposed to be something in there but I am not even sure as to how to alter these entries

Sembee -> RE: Outlook Anywhere (1.Jul.2008 4:23:10 PM)
Start Outlook 2007. Then right click on the Outlook icon while holding down CTRL. Choose the option to test Autodiscover. You can also test it from the internet using Microsoft's tool, which is currently in BETA at https://www.testexchangeconnectivity.com/ Simon.

digeratiTyson -> RE: Outlook Anywhere (2.Jul.2008 8:56:18 AM)
I ran that test at the URL you provided and came up with only one problem. All steps were passed except the last one below: Testing SSL mutual authentication with RPC Proxy server Failed to verify Mutual Authentication Additional Details The certificate common name www.example.com, doesn't match the Mutual Authentication string provided msstd:mail.example.com edit: I checked the cert I bought and all three URLs are in there...perhaps I have the wrong one installed?

Sembee -> RE: Outlook Anywhere (2.Jul.2008 9:17:46 AM)
That is quite common. Run this command in EMS Set-OutlookProvider expr -CertPrincipalName:"msstd:mail.example.net" Changing mail.example.net to match the name on your SSL certificate. Simon.

digeratiTyson -> RE: Outlook Anywhere (2.Jul.2008 9:22:52 AM)
We ccould be close here, after changing using the command from the last post... Attempting to ping RPC Endpoint 6004 (NSPI Proxy Interface) on server www.thedigeratiprocess.com Failed to ping Endpoint [image]https://www.testexchangeconnectivity.com/Images/Minus.gif[/image] Additional Details RPC Status ServerUnavailable (1722) returned in 0 ms. Now that would make sense since I keep getting nailed to authenticate. What I wonder is that even though the server is pingable from the net it says it still cannot get there?

digeratiTyson -> RE: Outlook Anywhere (2.Jul.2008 9:39:19 AM)
what is killing me about this is that I can even telnet into the server using port 6004 from a remote PC with no problem on both the external and internal FQDN

Sembee -> RE: Outlook Anywhere (2.Jul.2008 3:09:27 PM)
Why are you trying to use those other ports? The entire point of Outlook Anywhere is that it works on port 443 only - no other ports are required. Your test to 6004 proves nothing and was a waste of time. Which authentication method are you using? A common issue with this feature is a mismatch. NTLM/Integrated can also be broken by some firewalls, so you need to use basic, at least to begin with. Simon.

digeratiTyson -> RE: Outlook Anywhere (2.Jul.2008 3:13:17 PM)
Using basic auth, I get this: \ Testing Http Authentication Methods for URL https://www.example.com/rpc/rpcproxy.dll Http Authentication Test failed Additional Details Did not find all required authentication methods Methods Found: Negotiate NTLM Methods Required: Basic only on NTLM did I get what you saw on the last post.

digeratiTyson -> RE: Outlook Anywhere (2.Jul.2008 3:17:32 PM)
A little more progress but back to the same place. I went to IIS and made sure both basic and windows authentication were enabled for the Rpc and RpcWithCert sites and now with basic authentication I get the same message about "An error occured while testing the NSPI Interface." edit: Now it gives an identical error about NSPI and "Attempting to ping RPC Endpoint 6004 (NSPI Proxy Interface) on server..." and not getting through regardless of weather or not I use Basic or NTLM authentication.

Sembee -> RE: Outlook Anywhere (2.Jul.2008 5:46:50 PM)
You shouldn't be making changes in IIS manager. The authentication setting needs to be set in Exchange Management Console so that autodiscover is updates appropriately. I have heard of sporadic problems with Outlook Anywhere, which are resolved by disabling Outlook Anywhere in Exchange, then removing RPC over HTTPS proxy. Once removed, ensure the virtual directories are gone and then run iisreset to write the changes to the IIS metabase. Then reinstall the RPC over HTTPS proxy and run iisreset again. Finally enable the feature in Exchange again. Simon.

digeratiTyson -> RE: Outlook Anywhere (7.Jul.2008 9:38:40 AM)
I ran though the steps in the last post and no dice. Using either Basic or NTLM authentication I am running into the same error as before where the only step that will not pass is the very last one: Testing NSPI Interface on Exchange Mailbox Server An error occured while testing the NSPI Interface. Test Steps Attempting to ping RPC Endpoint 6004 (NSPI Proxy Interface) on server mail.example.com Failed to ping Endpoint Additional Details I remember reading in another post somewhere about doing exactly what you described but reinstalling RPC over HTTP has not worked. Any other ideas?

Page: [1] 2 next > >>