Autodiscover.domain.com is not on either of the certificates.

The returned URL starts with "https://autodiscover.domain.com...". I'll change to https://hostname.domain.local... later today and report back. thanks again for the help!

Only inside. From what I understand, the outside users all use OWA and are having no problems.

Double checking the settings in the connection test. All of the URLs (except OAB: Public Folder) go to https://hostname.domain.local/... I can ping hostname.domain.local and it resolves to the internal IP of mail server. Hostname.domain.local is in both of the valid certificates. Any other ideas on what I could be missing?

Hi Michael, When starting outlook via start > run > outlook.exe /rpcdiag Under the connection heading what protocol is being used, HTTP or TCP/IP? Regards

Thanks for joining in! Just checked, TCP/IP is being used.

Have you tried holding the Ctrl button, clicking the Outlook icon in the system tray and selecting Test E-mail Autoconfiguration, providing your authenticaiton details and verifying what Autodiscover is returning? It's very possible that one of your InternalURL settings are wrong.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

(Thank you for your help, by the way) I've run the test. The results for Exchange RPC protocol are different than results for HTTP. RPC shows the FQDN of the mailserver. Example: OOF URL: https://hostname.domain.local/EWS/Exchange.asmx HTTP shows the following Example: OOF URL: https://mhost.domain.com/ews/exchange.asmx Get-ClientAccessServer casserver1 | fl *InternalUri* returns autodiscover.domain.com/autodiscover.autodiscover.xml

You want to make sure that all of these are configured the way clients will connect to them and with names that are consistent with the certificate installed on the server(s). That AutodiscoverServiceInternalUri doesn't look right. It doesn't have an https:// on it. Is autodiscover.domain.com resolvable from inside? This URL should be an internal URL. If you're using domain.local internally, then this should be a domain.local URL. (I don't recommend that, however, I like deploying split-brain DNS much better.)Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

I'm looking at the results of Get-ExchangeCertificate. I'm seeing the same OOF URL (that's listed under RPC protocol) listed under CertificateDomains, is this what I was looking for? If I'm looking in the wrong place could you please point me in the right direction? Thanks!!

Let me show you what's being returned.

If the issue shows up with free-busy, and the clients are Outlook 2007 or higher, then Outlook is trying to connect to the Availability Service, which is provided by Exchange Web Services. Are your users' machines domain-joined? You have just a single Exchange 2007 server, correct? When you run: Get-WebServicesVirtualDirectory | FL what do you see for the InternalURL, ExternalURL and various authentications settings? Do they look correct?Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

The issue does show up with free-busy as well. The machines are domain joined. You're right, just the single Exchange 07 server. Authentication results are as follows (I would think the WindowsIntegrated would make this work...) InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated} ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated} BasicAuthentication : True DigestAuthentication : False WindowsAuthentication : True InternalUrl is https://hostname.domain.local/EWS/Exchange.asmx (internal domain) ExternalUrl is https://mhost.domain.com/ews/exchange.asmx (this is the same URL for OWA)

From a web browser, enter the InternalURL string and then authenticate. Do you get a bunch of XML stuff?Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Just tested and yes, I can see the XML stuff. I was prompted for authentication and then I had to click "Show All Content" button at the bottom of the screen.

By "all of these" you mean the URLs for Availability Service, OOF etc..., right? For the RPC protocol (in the connectivity test) they all start with https://hostname.domain.local/. There seems to be two valid certificates on the server (only one server) and they both list the FQDN of the email server that shows up in the connectivity test. Re: the AutodiscoverServiceInternalUri...I was careless when I copied and pasted...the https:// is present. I can ping autodiscover.domain.com from inside, but only when I have it listed in my HOSTS file. I tried changing the AutodiscoverServiceInternalUri to https://hostname.domain.local/autodiscover.autodiscover.xml. The users started getting prompted for their credentials, but this time they were not trying to get to Out of Office or free/busy data. If they supplied their correct credentials, Out of Office worked but if they exited and went back into Outlook they were prompted again.

Ultimately you must determine whether the URLs are the correct ones especially since you redacted so much.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

All of them, yes. Any of the URL hostnames you list must be resolvable in DNS, must route to the correct host or load balancer, and must be in the certificate. Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Hi Michael, In the test results please look at section: Protocol RPC > OOF URL The URL value specified here is something.brandt.local. Please confirm that something.brandt.local is listed as common name on your Exchange SSL certificate? Regards

Not sure if this is pertinent, but I'm throwing it out there. Looking at attributes of the autodiscover service connection point via ADSI Edit. The serverBindingInformation is https://autodiscover.domain.com/autodiscover/autodiscover.xml. From a few other posts, I'm reading that it should start with the FQDN of the exchange server, rather than "autodiscover". Do you think there's any danger in trying to modify that value to hold the FQDN or should I just leave it alone for now?

Hi Michael, https://autodiscover.domain.com/autodiscover/autodiscover.xml is just fine as long as you have a DNS record internally that resolves autodiscover.domain.com to your CAS server's internal IP. Perhaps more importantly or perhaps not but worth checking for sure... Is "autodiscover.domain.com" on your Cas's SSL certificate? Regards

When you run Test E-mail Connectivity, you'll see what Autodiscover gives you for external and internal. Check: Get-ClientAccessServer | FL Name,AutodiscoverServiceInternalUri If the returned URL is for external, change it to the internal URL using Set-ClientAccessServer.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Sorry for the delay, I've been tied up in a few non-related issues. I tried using Set-ClientAccessServer to change the AutodiscoverServiceInternalUri to https://hostname.domain.local/autodiscover/autodiscover.xml. Users are still prompted for their credentials once per (Outlook) session when they try to access Out of Office or free/busy data. i've since changed it back to https://autodiscover....

Based on the results of your Autodiscover test, you need the following names in your UCC certificate: mhost.[BLACKED_OUT].com autodiscover.[BLACKED_OUT].com [BLACKED_OUT].brant.local My instructions would be clearer if you hadn't redacted domain names. Really, there's no security issue. The first one should probably be your CN on your certificate, and the other two SANs. I assume that your users don't have user@brant.local as e-mail addresses, so you shouldn't need autodiscover.brant.local as a SAN. I am assuming that [BLACKED_OUT].brant.local is your Exchange server's name. I recommend that you do one, or preferably both, of the following. 1. Instead of using [BLACKED_OUT].brant.local, you create an internal DNS name of mhost.brant.local as an A or CNAME record pointing to your Exchange server, and change all InternalURL settings to point to it, as well as Set-ClientAccessServer's AutodiscoverServiceInternalUri property instead of the server name. That way, if you ever have to change anything, you don't have to switch everything over. Plus, your users can use mhost inside or outside and don't have to rememver the servername. Of course, if your server name is mhost, all of this is moot. 2. Deploy split-brain DNS so that users refer to mhost.[BLACKED_OUT].com whether they're internal or external. This is way more convenient for users and a lot easier to manage, particularly when it comes to certificates. Just create an internal DNS zone for [BLACKED_OUT].com, and add A records for services like mhost with internal IP addresses. If you've properly configured DNS, then users will use the correct DNS depending on whether they are connected interanlly or externally and will point to the correct server network-wise. They don't have to remember to use brant.local hostnames inside and [BLACKED_OUT].com hostnames when outside. This way, you can quit using brant.local hostnames for services, even if this is your Active Directory domain name. There is no requirement that you use your Active Directory domain name for web services. Hope this helps. Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

OK, thanks! I'll double check when I get back to the office in the morning, but I thought that all the URLs that show up in the connectivity test (at least for the RPC protocol) had the FQDN that was resolvable from the machine I'm testing with (with the HOSTS entry).

Hello all, THANK YOU for taking the time to read this. I'm troubleshooting issues that I believe are connected to DNS and autodiscover. Clients run Outlook 2007 and server is Exchange 2007. All users connect via VPN. Any users trying to get email outside the domain use OWA. Initial issue was that a user would get an error message stating that the server was not available when trying to access Out Of Office or free/busy. I did a bit of research and added autodiscover.domain.com with the exchange server's internal IP to the user's hosts file. Now when he tries to access Out of Office or free/busy info, he is prompted to enter his domain credentials. After successfully entering his credentials, Out Of Office and free/busy both work successfully. New problem is that the user is prompted again if/when they close and reopen Outlook and try to access Out of Office or Free/Busy info. Does anyone have advice how I could keep the uesrs from getting prompted for credentials each time? Thanks in advance! -Michael

To GB's questions. 1. Network connected machines can ping/resolve that FQDN. 2. I checked the directories, and they are set to "accept". Thanks Ed, for the detailed steps. I'm out of the office until Tuesday. I might sneak in Monday and work through, but most likely I'll report back after Tuesday. THANKS AGAIN GUYS AND MERRY CHRISTMAS!

You should set it to the URL that domain-joined machines use when connected to the internal network, whatever that is. What matters more is what's being returned, which you can find by holding Ctrl while clicking on the Outlook icon in the system tray and clicking Test E-mail Autoconfiguration.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Is this a problem inside your network or outside?Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Good news, well done! Please let us know how it goes. Regards

Yes your looking in the correct place. This indicates that your certificate includes the FQDN required for RPC connected clients to authenitcate (SSL) in relation to OOF features. From a VPN connected client can you ping/resolve that FQDN? Regards

Also, on your exchange server open IIS and locate the exchange related virtual directories (under the default web site). On the relevant directories security tab click edit (secure communications section) and ensure that the client certificates is set to "accept". Your issue can occur when clent certificates is set to "ignore". Regards

Hi Once you have enabled windows authentication on the rpc virtual directory you should not need to do anything else for that to remain enabled. Have you tested the issue since enabling that? This is enabled in my lab environment. Thanks for being honest about the correction, please can you ensure/confirm that the autodiscover entry exists on the SSL certificate that is being used and has the exchange related services assigned to it? Regards

Hi GB. All have kernel-mode enabled, but I think that Windows Authentication for RPC was disabled. Do I need to do anything to make that setting stick (like restart a service or something?) SP1 for Exchange. I've been going back through this thread and I'm finding that I've given you guys some incorrect info. Correction: The "autodiscover" entry is indeed in one of the valid certificates. THANKS FOR YOUR HELP!

Hi Michael, M Xmas! Please open IIS manager and focus on the following virtual directories... Autodiscover, EWS, RPC, OAB Now highlight one of those virtual directories and in the right hand pane open the "authentication icon" > right click "windows authentication" and select "advanced settings" > Place a check in the box for "Enable kernel-mode authentication" > Do this for each virtual directory listed above. Please let me know if this helps? In addition, what exchange server service pack level is installed? Many Thanks

Hi Once you have enabled windows authentication on the rpc virtual directory you should not need to to anything else for that to remain enabled. Have you tested the issue since enabling that? This is enabled in my lab environment. Thanks for being honest about the correction, please can you ensure/confirm that the autodiscover entry exists on the SSL certificate that is being used and has the exchange related services assigned to it? Regards

Microsoft Support helped me resolve the issue this afternoon. The fix was to set SSL to ignore for the following default web site EWS Autodiscover OAB No more prompts for authentication!

Oh, my! You never said that you had configured HTTP redirect and I didn't think to ask.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

All's well that ends well. On to the next project! Thank you both very much for your input, I really appreciate your time.