Lync 2013 - Understanding Presence Flow

User presence is key feature of any unified communication solution today. Based user presence that we see in the client software we known if the user we are trying to reach is Available, Busy or Out of the Office even without asking someone.

What is Presence?

 Presence expresses the availability and willingness of a user to join a conversation by using a SIP client such as Microsoft Lync 2010 or Lync 2013. There are two main activities involved in presence:

• Presence Publication
• Presence Subscription

Let look at each of the two activity in detail. For illustration we shall use two Lync user Luser1 and Luser2 both enabled for sip domain @contoso.com

Presence Subscription

Presence subscription is an operation that lets the Lync client know which users that you are interested in seeing refreshed presence information from and what aspect of their enhanced presence you are interested in. When the Lync client creates a presence subscription for a set of users and a set of enhanced presence information, it sends this request or subscription to Lync server. Then the Lync server responds back with the latest information about the user in response back to the Lync client. Presence subscription happens when one user is trying get the update presence information of another user.

Presence Publication

The question here is how the Lync server does some to know of a user’s presence?  Presence publication is the publishing of user local presence information using the Lync Client after the user signs in for the use of other users who have subscribed to this presence. Your application can set the presence of the local signed-in user to such availability as available, busy, do not disturb, be right back, off work, or appear away. Presence publication happens when one user is trying update its own presence information to another user.

Presence Polling

Lync Client manage contact lists for users requires persistent subscriptions to receive the most current presence state of their contacts. For this reason polling for presence is required at regular intervals. Polling is performing Presence subscription at regular interval. In a polling subscription, the Lync client periodically queries the Lync server to obtain the data. The difference between a subscription and a query lies in the fact that the subscription is tied to a period of time whereas the presence query is one-time only. The difference between a persistent subscription and a polling subscription lies in the fact that a SIP dialog is involved in a persistent subscription whereas it is not in a polling subscription.

For a polling subscription, the Lync Server client repeats the process at a given time interval. For a persistent subscription, the Lync Server pushes the publication down to the subscribers by sending them a NOTIFY or BENOTIFY request containing the presence data is created, modified, or removed. For the NOTIFY request, the server expects the client to respond with SIP response. For the BENOTIFY request, a client response is not needed. The process continues until the subscription is terminated, at the request of the subscribing client or when the subscribing user logs off.

User Presence Change

When user Luser2 changes his or her presence. The Lync Client for user Luser2 send out Presence publication to the Lync server. Lync serve send out Notify or Benotify request all users who have Luser2 added as a contact for presence update.

Lync server 2013 DNS records and Auto discover

One of the critical components for Lync to work is the DNS Entries. Lync uses two kind of DNS entries:

1.         A record

2.         SRV record

Internal DNS records:

Record Type	Value	Points to	Purpose
A	Lyncdiscoverinternal.domain.com	FE server or pool	For the Autodiscover service on the internal Web services
A	Sipinternal.domain.com	FE server or pool	For the Front End pool or Director
A	Sip.domain.com	FE server or pool	For the Front End pool or Director on the internal network
A	Dialin.domian.com	FE server or pool	For the dial-in conferencing
A	Meet.domian.com	FE server or pool	For the web conferencing URL
A	Admin.domain.com	FE server or pool	For the Lync control panel
SRV	_sipinternaltls._tcp.domain.com	Sip.domain.com	For internal TLS connections
SRV	_sipinternal._tcp.domain.com	Sip.domain.com	For internal TCP connections (performed only if TCP is allowed)

External DNS records:

Record Type	Value	Points to	Purpose
A	meet.domain.com	ReverseProxy	For the external web conferencing
A	dialin.domain.com	ReverseProxy	For the external dial-in conferencing
A	Sip.domain.com	ReverseProxy	For the Access Edge service when the client is external
A	lyncdiscover.domian.com	ReverseProxy	For the Autodiscover service on the external Web services
A	Sipexternal.domain.com	ReverseProxy	For the Access Edge service when the client is external
A	Access.domain.com	ReverseProxy	Access edge
A	Av.domain.com	ReverseProxy	AV edge
A	Webconf.domain.com	ReverseProxy	Web conf edge
SRV	_sip._tls.domain.com	Sip.domain.com	For external TLS connections
SRV	_sipfederationtls_.tcp.domain.com	Sip.domain.com	For the federation

Lync Auto discover process

Lync Client and Lync Mobile will attempt to resolve DNS records in the following order:

1.      Lync client will try to resolve lyncdiscoverinternal.(sip-domain) , this is an internal record so the client need to be inside the network to be able to resolve this records, if the client couldn’t resolve the record it knows it is outside the corp network and goes to step two

2.      Lync client will try to resolve lyncdiscover.(sip-domain)

Note - If above two steps fails, only Mobile / Windows App Lync clients will fail to login and stop trying.

DNS SRV discovery process

If those steps fail, and Lync clients couldn’t find them, then it will fall back to the DNS SRV records in the following order:

1.      Lync client will try to resolve _sipinternaltls.tcp_(sip-domain) using TLS

2.      Lync client will also try to resolve _sipinternal.tcp.(sip-domain) using TCP

3.      Lync client will also try externally to resolve _sip._tls.(sip-domain) using TLS

4.      sipinternal.(sip-domain) , internal A record of the Frontend / Director pool

5.      sip.(sip-domain) , Internal A record of the Frontend / Director pool (Internally) , or Access Edge Service (Externally)

6.      Sipexternal.(sip-domain) , A record for the external Access Edge services

NOTE: also that, the Lync Mobile cannot download the certificate and need the Autodiscover URL to locate the Frontend, so either you can install the certificate manually on all of your mobiles (headache) or what is commonly used is making a Forward lookup from your internal DNS to external DNS so that the lyncdiscoverrecord is resolved to the IP of your reverse proxy allowing the Lync mobile client to use the 3rd-party installed SSL certificate.

The DNS record that got resolved by the Lync Client will tell the Lync client the FQDN and port of the SIP register server (either the Lync Front end or the Director server). If you using DNS load balancing, then the client will get all the IP-address of the servers in the pool in a random way, and will try to connect to them and after registration most probably the client will be redirected to the correct front end.

What is Mailbox Anchoring

Mailbox Anchoring

In mailbox anchoring, CAS locates where the mailbox resides by querying Active Directory for the user's mailbox GUID. As soon as we obtain the GUID, HTTP Proxy refers to Active Manager to locate the database containing the user's mailbox. Once CAS knows where the user's mailbox is located, the protocol request is then proxied to the appropriate mailbox server. If that server goes down and the database is a part of a DAG, the Client Access Proxy will proxy the session to the new active mailbox server for the corresponding database. This process is utilized currently for most client protocols, such as OWA, ECP, and EWS with the exception of Remote PowerShell.

This is great for the client but what about the Exchange Management Shell (EMS)? In Exchange 2013 RTM through CU10 and Exchange 2016 (RTM), we do not use the mailbox anchoring logic to proxy the PowerShell session we just connect to the local server or proxy to another available server in the Exchange Organization. This means if I log into an Exchange 2013 Server I cannot manage any new cmdlets that became available in Exchange 2016. For that I would have to logon directly to an Exchange 2016 Server.

EMS changes

Starting with Exchange Server 2013 CU11 and Exchange Server 2016 CU1, the Exchange Management Shell (EMS) session will also be using mailbox anchoring. If the aforementioned environment has all servers upgraded to Exchange 2013 CU11 and Exchange 2016 CU1 the behavior of Exchange Management Shell changes. Now when a user logs on to the Exchange Server and open up EMS, the session will be proxied to the server where the user’s mailbox is located. If the user does not have a mailbox, we will utilize the arbitration mailboxes for the mailbox anchoring logic. Wherever the arbitration mailbox is mounted is where the EMS session will be proxied.

December 2015 Quarterly Exchange Updates

The Exchange team is announcing the availability of our latest quarterly update for Exchange Server 2013 as well as updates for Exchange Server 2010 Service Pack 3 and Exchange Server 2007 Service Pack 3.

Cumulative Update 11 for Exchange Server 2013

A complete list of customer reported issues resolved can be found in Knowledge Base Article KB3099522. Customers running any previous release of Exchange Server 2013 can move directly to Cumulative Update 11. Customers deploying Exchange Server 2013 for the first time may skip previous releases and start their deployment with Cumulative Update 11 directly.

Cumulative Update 11 does not include updates to Active Directory Schema, but may add additional RBAC definitions to your existing configuration. PrepareAD should be executed prior to upgrading any servers to CU11. PrepareAD will run automatically during the first server upgrade if Setup detects this is required and the logged on user has sufficient permission.

Update Rollup 12 for Exchange Server 2010 Service Pack 3 (KB3096066). The Exchange Server 2010 update includes a DST update as well as a collection of important fixes. Update Rollup 18 for Exchange Server 2007 Service Pack 3 (KB3078672) is also being released. Update Rollup 18 is primarily a DST fix with an additional opportunistic fix. 

We would like to call attention to two particularly important changes included in these updates: 

• Cumulative Update 11 and Update Rollup 12 each contain a time zone calculation fix to resolve the issue reported in KB3048372 – Exchange Calendar Items are shifted incorrectly when some Windows DST updates are applied. Customers in impacted time zones are encouraged to deploy these updates to address the issue identified after the release of the OS time zone changes in KB3039024. 
• Cumulative Update 11 also includes a change in behavior when deploying/administering Exchange Server 2013 in a co-existent manner with Exchange Server 2010 or 2016. These changes are outlined in the following blog article: Exchange Management Shell and Mailbox Anchoring.