Spoiler: It doesn’t work.

The behavior you’ll see is that the Lync client will issue the Autodiscover query, receive a successful response, and then never even attempt to contact the EWS URL. No DNS lookup, no HTTP request, nada. Consequently you’ll see “EWS not deployed” in the configuration info or get the red bangs on the conversation history and phone tabs.

The only fix available is to modify your EWS virtual directory URLs to be HTTPS instead of HTTP, which you probably should be doing anyway, but I have run across deployments where this was not the case. After the change to HTTPS the Lync client will begin contacting the EWS URL correctly.

In the last few Lync deployments I’ve done I’ve run into two different instances where the Lync client was failing to login to Exchange Web Services to retrieve the conversation history and user voicemail. In both cases there wasn’t actually the red exclamation mark on those two tabs in the UI like you’d expect if there were an error; the client just hummed along like nothing was wrong. In each scenario if I viewed the configuration information you would see the client report “EWS Not Deployed”, which was odd because Exchange 2010 was most definitely deployed at both customer sites.

Sidenote: The EWS polling takes roughly 30 seconds to reach this state. If you view the configuration info immediately you’ll see “EWS OK”, which is only because Lync has tried yet. So be careful when testing this and thinking everything is just fine.

Solution 1: Verify the InternalURL and ExternalURL for the Web Services virtual directory are entered
The first fix was incredibly easy and after some more digging we determined this was only occurring when a client was external and logging in through an Edge server. When we looked at the Exchange Client Access Server we found this customer had not actually entered an ExternalURL parameter for the Web Services virtual directory. This works just fine for Outlook clients, but Lync is expecting this value to be filled out. If it’s not entered it assumes EWS is not deployed externally and doesn’t attempt a connection, which is a pretty reasonable action. You might argue the Outlook action is incorrect and it should treat it the same way. But anyway, the fix is to just fill out the ExternalURL and Lync will begin using that value to login to EWS successfully.

Sidenote 2: The information discovered by Lync via Autodiscover is cached in the registry at HKCU\Software\Microsoft\Communicator\<SIP URI>\Autodiscovery (Can you tell a Lync dev wrote the regkey name? Autodiscovery instead of Autodiscover?) You’ll see entries for the internal and external URLs for the Availability Service, Exchange Control Panel, Exchange Web Services, and Out of Office Assistant. I’ve been able to delete this entire registry key for quick testing and found it recreated with no issues.

Solution 2: Place https://<Your SMTP domain>/ in the Local Intranet Zone
The second instance of this issue was a little more complicated, and still doesn’t make much sense to me, but I figured I would share. In this case the customer did not have Outlook Anywhere published so we expected it to fail externally, but this error was actually occurring internally. After verifying the InternalURL was filled out correctly we started doing some traces and noticed the Lync client would make a GET request to the /Autodiscover/Autodiscover.xml file on Exchange, Exchange would return a 401 Unauthorized challenging for credentials like we expected, and then the trace died. There were be no more responses from the Lync client IP address sent to Exchange in the logs. We verified this on multiple machines and operating systems and concluded that the Lync client would never respond to the credential request! For what it’s worth, Autodiscover was working fine for Outlook clients and no special configuration had been done to Exchange.

So we put a call into PSS and they told me Lync will not read the SCP for Autodiscover in AD, even if the Lync client is internal and that it will do its own Autodiscover lookup (Can anyone confirm/deny this?). Therefore, it will fall back to https://domain.com/Autodiscover/Autodiscover.xml, and if that fails it should move on to https://autodiscover.domain.com/Autodiscover/Autodiscover.xml like an Outlook client. This is where it got weird – PSS told me from the ETL trace Lync was not falling back to the 2nd option, yet I could clearly see it make a request to IIS and not respond. From what they saw the Lync client was getting stuck on the 1st option which didn’t really exist. In any event, they had me add http://<domain.com>/ to the Local Intranet Zone on the client. Even though we knew this was not the location of Autodiscover and I really didn’t think it would make a difference it did solve the problem. After adding entry this we saw clients then try to resolve autodiscover.domain.com and grab the Autodiscover.xml file correctly from https://autodiscover.domain.com/Autodiscover/Autodiscover.xml. At this point the EWS status in the configuration information returned to EWS OK.

Sidenote 3: There is a thread on the Technet forums about this issue which suggests editing your applicationhost.config file on the Exchange server. I have to recommend against this and as you can see in the comments it hasn’t really fixed the problem for anyone. The solution is more likely one of the ones presented here.

Some notes on my experience so far with Apple’s 10.6 Snow Leopard OS and Microsoft Exchange Server 2007:

Setup

• It’s brain-dead. It uses Autodiscover, so e-mail and password is all you need. You get prompted if you’d like it to also configure iCal and your address book.

• I haven’t tried from home yet, but the external server path is not filled out. Internal picks up EWS/Exchange.asmx URL just fine, but external is blank. I double-checked our Exchange server and this parameter isn’t filled out so that makes sense. The difference here is Outlook assumes the external is the same as internal if this value is blank, but it appears Apple Mail will not. Be sure to set your –ExternalURL parameters on the virtual directories appropriately.

Mail

• Responses to meetings come across as an .ics attachment, no special functionality here. This is especially bad if someone proposes a new time.

• The Exchange RSS Feeds folder does not integrate with the RSS feeds section in Mail. This would have been nice.

• Name suggestions are offered from the GAL and your contacts.

• Rules do not sync.

• UM voice mails have a built in media control. My codec is set to G.711 and I see embedded QuickTime controls in the message for playback.

• The actually listing of your notes is displayed in the Marker Felt font. It’s horrendous and tough to read.

• No out of office assistant.

• You can add multiple Exchange accounts.

iCal

• You can schedule meetings and invite attendees.

• You can view free/busy details for attendees.

• iCal does not differentiate between people and resources as attendees.

• You can view responses for meetings. Accepted, tentative, declined or unknown.

• Tasks sync to iCal “To-Dos”. The default view shows all completed items. Hit the iCal preferences to change this view.

• You can view Delegate calendars and grant access to your calendars and tasks.

• Name suggestions are offered from the GAL and your contacts.

Address Book

• My contacts came across just fine.

• I can’t see the GAL for some reason. The URL in the account settings looks correct, but the GAL is empty. Really strange considering I get GAL-suggestions when typing names in other applications.

I’m sure there are more to come, but despite some of the caveats this is still a huge improvement over Entourage. I’m looking forward to the Outlook for Mac client coming next year, but until then I’ll be using the native applications.

Hallelujah. Some decent support for Exchange on the Mac side. Significant changes include:

• Enhanced Autodiscover service to keep user account settings up to date after the account setup.
• Synchronization between Exchange Server and Entourage 2008 Notes, Tasks, and Categories.
• Addition of an Enable Logging (troubleshooting) preference, to log all events that can be used as diagnostic information.
• Use of attachments in Entourage for Exchange calendar events.

At a minimum you need Entourage 2008, but what version of update rollups your Exchange server needs to be at is a little confusing. The blogs say Update Rollup 4, but when you fill out the survey to get in the beta it says Update Rollup 5. I guess I’d go better safe than sorry and assume Update Rollup 5 at this point.

You can sign up for the beta here: http://www.microsoft.com/mac/itpros/entourage-ews.mspx

Recently a few of the folks I work with that use Macs noticed Entourage 2008 was having trouble using Exchange 2007 Web Services properly (as it advertised it would). I tried it out from home and verified the same thing, that the Out of Office Assistant and Free/Busy lookups didn’t go so well. I’ve been meaning to get around to building an OS X 10.5 virtual machine so I could hook it into my VM environment and do a packet trace to see what was going on, but it seems like I won’t need to anymore. Just update your friggin’ client to SP1 and EWS works properly. They’ve also added support for Autodiscover. I haven’t had a chance to play yet, but I wonder what kind of lookups and certificate restrictions Entourage has compared to Outlook.

So, moral of the post – problems with Entourage 2008 for Mac and you’ve got an Exchange 2007 environment? Upgrade your clients to SP1.