I am experiencing an issue with our Free/Busy availability and Out of Office Assistant access. The free/busy information doesn't appear for some clients using Outlook 2010 scheduling a meeting using the Scheduling assistant. Those users also receive an error contacting the server when they try to access there Out of Office Assistant. The weird part is nothing has changed to my knowledge in the environment and it only happens to some users, not all of them. I've tested problem users on different computers and it works as expected. Doing the Outlook connectivity test from Outlook results in a GetLastError=0; httpStatus = 404. Failed (0x80004005) I've read countless pages of Exchange doc, forum posts and KB articles. None of which seems to have shed any light on my problem. I can provide any additional information as needed if anyone would be willing to assist isolating this issue. Thanks in advance.

Primary reason for autodiscover failing (which also means the availability service fails) is SSL certificate issues. Do you have a trusted SSL certificate on the server? If so, is it a single name, Unified Communications or wildcard? Next reason is DNS isn't working correctly and the autodiscover address is resolving to the wrong place. Finally it can also be an issue with the virtual directory configuration, which is easily corrected by removing and recreating the virtual directory using the various PowerShell commands. Is the server fully up to date? Exchange 2007 SP3 and its latest rollups? Simon. Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

I'm using an Entrust UC cert with SANs. DNS appears to be working correctly. I can nslookup the host name and FQDN of the Autodiscover/Exchange server from the troubled client systems. I have not yet recreated the virtual directories and I'm running Exch2k7 /wSP3. I'd have to confirm the rollups. When I execute Test-OutlookWebServices -clientaccessserver "ServerName" |fl I get the following results with RPC errors too. Id : 1013 Type : Error Message : When contacting https://mail.somewhere.com/Rpc received the error The remote server returned an error: (404) Not Found. Id : 1017 Type : Error Message : [EXPR]-Error when contacting the RPC/HTTP service at https://mail.somewhere.com/Rpc. The elapsed time was 46 milliseconds.

If you open IIS on your CAS boxes do you see the rpc virtual directory there? For 404's it's either the vdir is missing, or the files are missing, likley not a perms issue on the vdir or files otherwise you would get access denied. However I would verify the perms on the vdir anyways or just recreate your vdir. RPC default vdir permissions = windows integ and basic For the file permissions on the rpc directory itself, I would just go to the parent folder and repush the inheritence down again. James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

The RPC errors were because Outlook Anywhere was enabled without the RPC service. I disabled Outlook Anywhere and the errors on gone in the test. I understand that 404 would indicate the files don't exist, but this only happens from a few workstation. The other workstations in the environment work fine.

How many CAS servers do you have, did you check all of them? You will need to look through the IIS logs for the requests generating the 404.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

One CAS server. I'll check the IIS logs. Thanks for your help.

OutlookWebServices and ClientConnectivityTest run in the EMC without any errors. I've recreated both the Autodiscover and EWS virtual directories, then cycled IIS. I confirmed that the Outlook 2010 client in question resolves DNS correctly to our server hostname and autodiscover.showhere.local. I've checked the IIS logs, but don't see anything related to the 404 error. I've checked both the client and server app and system logs, but nothing usefull there either. I'm starting to think that it's something on the workstation? I've enabled Outlook Advanced logging, but I don't see another other than what I get from the Outlook Connectivity test.

On that client, start outlook. Then on the bottom right tray in the outlook icon, ctrl + right click, test email autoconfiguration. Unchek use guest and secure guest.. and click test. Then go to the log tab, does it show any errors?James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Any thoughts? Any additional information I can provide?

If you browse to the URL returned in the message, what happens? Getting a 404 is unusual which would tend to indicate that DNS isn't working correctly, something else is answering the HTTP traffic or the server is pretty badly screwed up. Is the Exchange server exclusively Exchange? Nothing else at all installed on the server? Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

The server is a single Exch2007 with only exchange on it. When I attempt to access the https://servername.domain.local/autodiscover/autodiscover.xml from the workstation in question using IE, I get prompted for a username/password. I enter the client credentials and get the following results below. <?xml version="1.0" encoding="utf-8" ?> - <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> - <Response> - <Error Time="07:25:36.4205558" Id="653509345"> <ErrorCode>600</ErrorCode> <Message>Invalid Request</Message> <DebugData /> </Error> </Response> </Autodiscover>

That is the expected behaviour for autodiscover when browsed to. I would suggest a reset of the autodiscover virtual directory to begin with. Simon. Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Yes when put the autodiscover url in the browser that is the correct expected response which means the resource exists. I'm not sure why only certain clients are getting the 404, are you sure you dont have a bad\duplicate DNS record for autodiscover that these bad clients are going to?James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com