I've reviewed the topics similar to the issue I'm having but I've yet to solve my problem. Been pulling my hair for over 10 days trying to fix this issue. Currently users within the LAN cannot use out of office or look up the free/busy time within Outlook 2007 and outlook 2010. But users can view this information by accessing the OWA site witin the lan. Users who also VPN in can also view the out of office info and Free/busy info. Whatever change I make users within the office cannot see the info. Here is my setup. I have a DNS entry for autodiscover that points to my CAS I have a dns entry for webmail that points to my CAS (our owa site is https://webmail.domain.com) I have a certificate with "webmail.domain.com", "autodiscover.domain.com" and "srvmail" (last is our exchange server host name) I do not get certificate issues. When I right click on my Outlook 2010 client in taskbar and run the "use autodiscover" test I get the following: Attempting URL https://autodiscover.domain.com/autodiscover/autodiscover.xml found through SCP Autodiscover to https://autodiscover.domain.com/autodiscover/autodiscover.xml starting Autodiscover to https://autodiscover.domain.com/autodiscover/autodiscover.xml Succeeded (0x00000000) My outlook 2007 / 2010 clients are set to use Exchange Proxy Settings with this as the URL : https://webmail.domain.com with NTLM authentication. Connect using SSL only. On my EMC when I right click the OWA or the Autodiscover folder I cannot browse, I get try using HTTPS error instead. -----> I'm not sure what else to try here. It's clearly a permission issue rather then a certificate issue ( or so i think). I get an error 401 with shell: [PS] C:\Documents and Settings\admin>test-outlookwebservices |fl Id : 1003 Type : Information Message : About to test AutoDiscover with the e-mail address admin@domain.com. Id : 1007 Type : Information Message : Testing server SRVMAIL.domain.local with the published name https://webm ail.domain.com/ews/exchange.asmx & . Id : 1019 Type : Information Message : Found a valid AutoDiscover service connection point. The AutoDiscover URL on this object is https://autodiscover.domain.com/aut odiscover/autodiscover.xml. Id : 1013 Type : Error Message : When contacting https://autodiscover.domain.com/autodiscov er/autodiscover.xml received the error The remote server returned an error: (401) Unauthorized. Id : 1006 Type : Error Message : The Autodiscover service could not be contacted. Any help is appreciated it. Thanks guys. I just dont see why when I VPN from outside the office the out of office would work but yet internally it wont.

Check in IIS on Autodiscover and make sure its not on NTLM, it should be Basic. Post the ResultGulab | MCTS-MCITP Messaging: 2010 | MCTS-MCITP Messaging: 2007 | MCC 2011 | Skype: Gulab.Mallah

In Autodiscover, under directory security it's set to integrated windows authentication and basic (anonymous is unchecked)

UPDATE: When browsing to https://webmail.domain.com/autodiscover/autodiscover.xml within IE I get a 600 Invalid Request Witin IIS when i rightclick autodiscover under default web site I get a 404 error page cannot be found The right certificate seems to be issued to Autodiscover as well.

Hi, For internal Outlook users, they do not resolve autodiscover via DNS lookup. As is shown by the Test Email AutoConfiguration result, the Outlook can access the autodiscover url successfully via SCP. So, the autodiscover works properly for them. You can use Get-webservicesvirtualdirectory |FL to check the internalurl for the ews service and accessing the url in IE and see if there are any error. In additional, we can also check the IIS log to see if there are any error code about the autodiscover and EWS. Thanks, Simon

Simon_wu currently when I run get-webservicesvirtualdirectory | FL I get the following output: [PS] C:\Documents and Settings\admin>get-webservicesvirtualdirectory | FL InternalNLBBypassUrl : https://srvmail.domain.local/ews/exchange.asmx Name : EWS (Default Web Site) InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated} ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated} BasicAuthentication : True DigestAuthentication : False WindowsAuthentication : True MetabasePath : IIS://SRVMAIL.domain.local/W3SVC/1/ROOT/EWS Path : E:\Program Files\Exchange\ClientAccess\exchweb\ EWS Server : SRVMAIL InternalUrl : https://webmail.public-domain.com/ews/exchange.asmx ExternalUrl : AdminDisplayName : ExchangeVersion : 0.1 (8.0.535.0) DistinguishedName : CN=EWS (Default Web Site),CN=HTTP,CN=Protocols, CN=SRVMAIL,CN=Servers,CN=Exchange Administrativ e Group (FYDIBOHF23SPDLT),CN=Administrative Gro ups,CN=First Organization,CN=Microsoft Exchange ,CN=Services,CN=Configuration,DC=ggi,DC=local Identity : SRVMAIL\EWS (Default Web Site) Guid : fbbfc212-d7a7-4de2-ada8-e63c2ff47de0 ObjectCategory : domain.local/Configuration/Schema/ms-Exch-Web-Serv ices-Virtual-Directory ObjectClass : {top, msExchVirtualDirectory, msExchWebServices VirtualDirectory} WhenChanged : 4/29/2010 6:13:15 PM WhenCreated : 7/12/2007 11:34:11 AM OriginatingServer : SRVMAIL.domain.local IsValid : True Note that I cannot access the internalURL that is set, but then again I do not know what to set it to. We use certificates so would I simply need it to set it to a local address instead such as https://srvmail.domain.local/ews/exchange.asmx - I will try setting it to this and post my results.

I have a DNS entry for autodiscover that points to my CAS I have a dns entry for webmail that points to my CAS (our owa site is https://webmail.domain.com) I have a certificate with "webmail.domain.com", "autodiscover.domain.com" and "srvmail" (last is our exchange server host name) I do not get certificate issues. -------------------------------------------- https://webmail.public-domain.com/ews/exchange.asmx -------------------------------------------- "public-domain" is not different from "domain", is it? Is that just the way you edited out the real domain name? If it is the very same domain name, you should be OK there. ++++++++++++ Is... srvmail.domain.local on the certificate? If not, you may have problems here. ++++++++++++ Otherwise, did you check in your client-side Proxy settings to ensure that authentication is now set to BASIC rather than NLTM?

Pivert, Actually I think I may have this all working now. Here is what I have done thanks to the paralel sugesstions from technet and msexchange - My autodiscover service URL was correct, the culprit was my webservicesvirtualdirectory - internal url was pointing to InternalUrl : https://webmail.public-domain.com/ews/exchange.asmx For whatever the reason, the IT guy in charge before me had set it to this address. i changed this address to https://srvmail/ews/exchange.asmx and now my calendar free/busy and out of office works great. BUT now I have a certificate error. Pivert I do have "srvmail" in my certificate but I think I need to insert "srvmail.domain.local" in there as well. Once I get a new certificate from Digicert I will test results and hopefully everything works as it should.

Yes, exactly: srvmail.domain.local That should do it. Let us know what happens once you get the new cert from digicert.

Hello, What’s the error code when accessing the EWS url in IE? Check the IIS log and verify the detailed error code. http://support.microsoft.com/kb/943891 In addition, you can also try rebuilding the EWS VD to it default settings by: [Rebuild Web Services VD] =================== a. Remove the EWS virtual directory in client access server. (Note: If needed, please change the “Default Web Site” to your IIS site name.) Open Exchange Management Shell. Run the command below: Remove-WebServicesVirtualDirectory “CASName\EWS (Default Web Site)” If you get the confirm information, please type “Y” b. Create a new EWS virtual directory. Run the command below in Exchange Management Shell: New-WebServicesVirtualDirectory –WebSiteName “Default Web Site” –internalurl https://webmail.public-domain.com/ews/exchange.asmx c. Do an IISreset /noforce Thanks, Simon

Had to create another LIVE profile, I'm the original poster btw :) here is my conclusion: Setting the internalURL in autodiscover solved my issue. Thank you for all your help.