13 SepHow does Lync 2010 use Exchange calendar information?

I’ve had a few questions come up lately around when Lync 2010 polls Exchange for free/busy information and how/when presence state is updated based on your calendar. I did a bit of digging into it and think I’ve worked a few things out that make the whole situation a bit clearer.

There are two things to consider here. We need to look at how often Lync polls Exchange for the free/busy information, and then how often your calendar state is published to your Lync presence i.e. you change from Available to In a Meeting based on the free/busy data that was retrieved from Exchange.

How is it controlled?

Everything we need to look at here is defined in a Lync Client Policy and there are two parameters that you need to specify interval durations for – either WebServicePollInterval (if you’re using Exchange Server 2007/2010) or MAPIPollInterval (if you’re using Exchange Server 2003) and CalendarStatePublicationInterval. I’ll go into more detail on each of these below.

Lync determines when to change your presence from for example, Available to In a Meeting with this data. This means that if you create an appointment in Outlook in-between when Lync polls Exchange and when Lync applies your calendar state to presence, this won’t be reflected in Lync until the polling interval lapses and Lync retrieve the Free/Busy info from Exchange again.

Retrieving Calendar Data from Exchange

So firstly, we need to look at how calendar data (free/busy information) is retrieved from Exchange Server by Lync.

Exchange Server 2003

If you’re (still) using Exchange Server 2003, Lync will poll the server via a MAPI RPC call for free/busy information. This is controlled in the Lync Client Policy using the parameter MAPIPollInterval.

The default is 30 minutes but this can be changed to anything from 5 minutes to 480 minutes (5 hours). So to set it to 5 minutes, the cmdlet would be Set-CsClientPolicy -MAPIPollInterval 00:05:00.

Exchange Server 2007/2010

Update 28th Jan 2013: Amended to explain that Lync connects to the Exchange Autodiscover service first before being directed to the EWS URL, thanks Marcin Swiatelski. 🙂

For those using Exchange Server 2007 or 2010, Lync will be connecting to your Exchange Autodiscover Service URL and then onto your Web Services URL for free/busy information rather than the local MAPI profile in Outlook.

It builds this Autodiscover URL based on your SIP address, and not by anything you configure in Exchange or from the AD Service Connection Point. So if my SIP address is me@justin-morris.net, the two URLs Lync will attempt to connect on will either be:

https://autodiscover.justin-morris.net/autodiscover/autodiscover.xml or
https://justin-morris.net/autodiscover/autodiscover.xml.

For Lync to connect to the Exchange Autodiscover service, you need one of these URLs to be accessible.

Typically the autodiscover.sipdomain.com option is the most commonly deployed, as this compliments what is already usually deployed for Outlook 2010 to work.

Once Lync has connected to the Exchange Autodiscover service, it will receive EWS URLs to connect to e.g. https://autodiscover.justin-morris.net/EWS/Exchange.asmx or https://justin-morris.net/EWS/Exchange.asmx

The interval in which Lync connects to EWS to poll for free/busy information is controlled in the Client Policy using the parameter WebServicePollInterval. The default is 30 minutes but this can be changed to anything from 5 minutes to 480 minutes (5 hours). So to set it to 5 minutes, the cmdlet would be Set-CsClientPolicy -WebServicePollInterval 00:05:00.

Publishing Calendar Data to Presence

So now once we’ve retrieved that calendar data from Exchange, Lync needs to actually apply it to your presence, and how often this occurs is controlled by the CalendarStatePublicationInterval parameter in the Lync Client Policy.

Unlike the MAPIPollInterval and WebServicePollInterval parameters, the CalendarStatePublicationInterval parameter must be set in number of seconds.
So to set it to 5 minutes, the cmdlet would be Set-CsClientPolicy -CalendarStatePublicationInterval 300. 

Polling and Publication

My understanding from perusing TechNet library articles is that there is a difference between Polling and Publication of calendar information in the Lync client.

I could have interpreted this incorrectly, but I’m pretty sure this is the way calendar information is handled by Lync. If anyone can shed additional light, please let me know in the comments.

TechNet Library References:

Set-CsClientPolicy
http://technet.microsoft.com/en-us/library/gg398300.aspx

Migrating User Settings to Lync Server 2010
http://technet.microsoft.com/en-us/library/gg398814.aspx

13 Responses to “How does Lync 2010 use Exchange calendar information?”

  1. […] calendar information? | Justin Morris on UC Posted on September 13, 2011 by johnacook http://www.justin-morris.net/how-does-lync-2010-use-exchange-calendar-informa… Share this:StumbleUponDiggRedditLike this:LikeBe the first to like this […]

  2. […] Exchange calendar information? | Justin Morris on UC Posted on June 20, 2012 by johnacook http://www.justin-morris.net/how-does-lync-2010-use-exchange-calendar-informa… Share this:StumbleUponDiggRedditLike this:LikeBe the first to like […]

  3. Hi Justin,
    This is a great article and it encouraged me to spend some time on Lync/EWS configuration. I found that Lync 2010 client actually uses Exchange autodiscover service. You are right that Lync does not use SCP record to find autodiscover but it creates autodiscover URL based on SIP domain name. I think that your article is not entirely correct as you wrote that Lync creates EWS URL based on SIP domain. Lync creates autodiscover URL (e.g. https://autodiscover.sipdomain.com/autodiscover/autodiscover.xml) then connects to the autodiscover service and obtains EWS and other URLs (e.g ECP URL for voicemail).
    Kind regards,
    Marcin

    • Justin Morris says:

      Hi Marcin,

      Thanks for the correction. You’re right, Lync does connect to the Autodiscover service first before being directed to the EWS URL. I’ve updated my post to reflect that.

  4. Hi Justin, I think the following urls are still incorrect:
    https://autodiscover.justin-morris.net/EWS/Exchange.asmx or https://justin-morris.net/EWS/Exchange.asmx
    The URLs should point to autodiscover service not EWS directly. Lync uses something like this: https://autodiscover.sipdomain.com/autodiscover/autodiscover.xml then connects to EWS url obtained from the autodiscover service.

  5. Steve Moore says:

    Hi Justin,

    nice article.

    I have been looking at autodiscover at the moment and noticed that when a user’s SIP address and Primary SMTP address do not match, that the Lync client learns the Primary SMTP address for the user when signing in and so then connects to Exchange’s autodiscover based upon the email domain of the user’s email address. I am assuming we learn the email domain from the WindowsEmailAddress attribute (Get-CSUser steve@contoso.com | ft WindowsEmailAddress). In your article I believe you say that autodiscover URLs are built based upon your SIP domain, my experience today with the 2010 client is that the autodiscover URL has been built based upon the user’s Primary SMTP address. So if sip domain was @contoso.au and email address @contoso.com I see connections to autodiscover.contoso.com and not to autodiscover.contoso.au.

    cheers

    Steve

  6. Mehmet Kocak says:

    Hi Justin,

    nice article

    I have also been looking into the EWS discovery for Lync Clients.
    If the very same Lync Enabled AD Account is also Mailbox Enabled, then as above the AD attribute is populated with the users Primary SMTP Address..
    The users Lync Pool will construct the Presence.xml and return to the client, this will contain the users Primary SMTP Address (amongst other stuff), Run Snooper at the time of Login and examine the in band provisioning process.
    Also in a Lab/Test environment, change the Primary SMTP Domain Address for the Lync AD Account that is also Mailbox enabled.
    Run Wire shark and filter on UDP 53
    Then sign in to Lync with the disjoint SIP/SMTP Address account.
    You will see the Lync client performs the Autodiscover Lookups to ONLY the DNS Name space of the users Primary SMTP Address not the SIP address Name Space.

    Lync will NEVER perform SCP lookups internally Like Outlook Clients do, Lync all ways using Autodiscover DNS A and SRV records

    Thanks Guys

    Mem

  7. Korbyn says:

    Seem for Out-of-Office neither of these settings matters. OOF changes seem to take up to 15 minutes regardless.

  8. Dickson Samuel says:

    Excellent article. Read lot of articles but you made it very clear with simple English.

Leave your comment

Please fill your data and comment below.
Name
Email
Website
Your comment