I am on a clean install of Exchange 2010 SP1 on Windows Server 2008 R2. I created a certificate from our local CA making sure the CN matches the external URL of the exchange server. I installed the CA certificate in the Trusted Root folder on all the machines it will be used on. All the necessary services have been installed (RPC/HTTP) etc. I can send receive and use OWA without any issues. OWA does not complain about an untrusted cert. I have enabled Outlook Anywhere having it negotiate authentication. I have double checked IIS virtual directories to make sure ths SSL setting are correct. After all this outlook anywhere will still not work. My question is two fold. First what steps are needed to make Outlook Anywhere work with an Internal CA, second where in exchange logs can i find where this transaction is taking place so i can better troubleshoot the issue? I have read in an couple of places that outlook anywhere will NOT work with certs from local CA's. I have not found any proof positive evidence to suggest this. If this is ture so be it, we will buy a cert from a Trusted CA, however i just as soon use a local cert as we do not have many machines and deploying our root CA to those machine will be easy. I have put a lot of research into this issue and while i have found numerous other posts about this issue i have yet to find one that resolves my problem. Yes i have searched many forums before posting. Also when i use the exchange connectivity tester, i get an error saying the certificate chain could not be built. Any thoughts? Thanks

If you have spent time researching the issue, then it would have been better to have simply bought a trusted certificate for US$80/year. If you have to touch every machine to install the certificate it doesn't take long before a commercial certificate is more cost effective. With regards to SSL certificate support and Outlook Anywhere, the certificate type that is not supported is the certificate that Exchange generates itself using new-exchangecertificate. A CA issued certificate (whether your own or a commercial) is supported. However if you are using an internal CA just for Outlook Anywhere, I don't see the point myself. Plus the same certificate can then be used for SMTP, ActiveSync, OWA etc all without prompts. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

I have enabled Outlook Anywhere having it negotiate authentication. Hi TrojanMan78, Please try to use another authentication method. "Negotiate Ex authentication is an authentication type that's reserved for future Microsoft use and should not be used. Use of this setting will cause authentication to fail. " Enable Outlook Anywhere http://technet.microsoft.com/en-us/library/bb123542.aspxPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hello i bought a cert and that did not fix the problem. The exchange connectivity tester shows sucessful without any errors but outlook will still not connect. I have tried every combination of authentication, checked the virtual directorys, file permissions, etc and i am clueless. I turned on logging in outlook but it does not show anything. I do not know if this is the intended behavior but when i check the IIS logs i see the following: RPC_IN_DATA /rpc/rpcproxy.dll exserver:6004 443 - MSRPC 401 2 64 109 RPC_OUT_DATA /rpc/rpcproxy.dll exserver:6004 443 - MSRPC 401 2 64 15 It appears to be generating a 401 unauthorized. I checked the rpcproxy.dll file permissions and all seems fine. The RPC virtual directory has pass-through authentication and when i test the settings in IIS i get a warning: The server is configured to use pass-through authentication with a built-in account to access the specified physical path. However, IIS Manager cannot verify whether the built-in account has access. Make sure that the application pool identity has Read access to the physical path. If this server is joined to a domain, and the application pool identity is NetworkService or LocalSystem, verify that <domain>\<computer_name>$ has Read access to the physical path. Then test these settings again. I have checked that the listed account has access to the directory and it does. The RPC directory is using the DefaultAppPool which is using ApplicationPoolIdentity. This is a clean install of both OS and exchange, everything else works fine except outlook anywhere. Thanks

If you have been playing around with the configuration of IIS and the virtual directories, you have problem damaged the configuration. Trying to get it back will be difficult. The easiest way is to disable Outlook Anywhere in Exchange, wait for the Event Log entry to say it is disabled (takes about 15 minutes). Then remove the RPC proxy from Windows Components. Verify that the RPC and RPC-With-Cert virtual directories have gone from IIS and run IISRESET from a command prompt to ensure that the change is written to the IIS metabase. Then reinstall the RPC Proxy component from Windows Components. Once installed, enable Outlook Anywhere. It should then work with no further changes required. Simon. Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

It doesnt work from a clean install with all the defaults and outlook anywhere enabled. And i have tried every variation of permissions i can think of. I have tried uninstalling/reinstalling RPC , IIS, exchange and the OS itself with no luck. When a client tries to connect to outlook anywhere are there Exchange logs that show this transaaction? I am aware the IIS logs will show the transaction on the IIS side, i want to know if there are exchange logs for outlook anywhere. Thanks

Something must be interfering with it. I have never known the feature to fail with a fresh installation. You can test it internally by using test-outlookconnectivity When prompted for the Protocol type in http. If it continues to fail even on that test, then you could be looking at a reinstall of IIS and the CAS role, although you may want to put a call in to Microsoft support for their guidance. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Something worth noting is that RPC works internally when setting outlook to use HTTP on both slow and fast networks. However when i supply the external URL it then turns around and resolves it to the internal URL. I am wondering when trying to connect externally if it connects but then tries to resolve the internal URL and obviously this will fail. Our external: exchange.domain.com Internal: exchange.domain.local Internally outlook will resolve the internal name even though i supplied the external name.

If you enter the external URL in to Outlook manually and it resolves to the server's internal name, then it will be corrected. That is by design. Nothing you can do to stop that. It would either correct it to the CAS server or the CAS Array host name. However it isn't clear what is being changed. Is it the server name or the host name for Outlook Anywhere? If it is the host name for Outlook Anywhere then you must have set the wrong URL in the Outlook Anywhere configuration. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

I have the external hostname set for outlook anywhere.

I have verified that outlook anywhere works internally but not externally. on the Exchange Proxy screen i check both boxes to use HTTP. then i exec outlook /rpcdiag and see the connections being made via HTTPS. Again the hostname resolves to the internal hostname of the server: exchange.domain.local, even thought the external hostname is set for outlook anywhere.

got it working! It turns out i was supplying the external exchange server name in outlook when i should have been supplying the internal exchange hostname in outlook. Obviously in the proxy settings i am still using the external hostname for the proxy. Thanks for the replys