What happens to my data after my organization’s Office 365 subscription ends?

What happens to my data after my organization’s Office 365 subscription ends? The most common answer circulated in the community refers to a grace period of 30 days, during which you can still retrieve your data.

The answer’s not wrong, but here’s some more detail about the tenant lifecycle after an Office 365 subscription is cancelled, as it relates to the organization’s data.

During the first 30 days after an Office 365 subscription ends, the Office 365 tenant account is in this grace period, known as expired state. During this period, users can still access data. If the subscription ended unintentionally, a rare event I’d argue given the many alerts you get to prevent termination of subscription due to issues such as non-payment, this is a good time to set things right.

After 30 days, the tenant account enters disabled state for 90 days. During this period, users no longer have access to data. The admin can still log in, backup data if required, or reactivate the subscription. At the end of the disabled state, which is 120 days after your subscription has expired, the account enters the de-provisioning state. This is when the data – from user accounts to email data and documents, is deleted permanently.

There are a few compliance-related questions arising out of end of subscription.

1. 1. How quickly will you delete data after my organization’s Office 365 service ends?
   Some time after 120 days. The jobs that delete data do so based on service load. You can expect data to be permanently deleted in a reasonable timeframe after the 120 days have elapsed.
2. 2. How can I ensure my organization’s Office 365 data is deleted quickly after service ends?
   Many security and compliance-minded organizations want to ensure there’s no residual data in a cloud service after they end service. Office 365 customers can request expedited deprovisioning by calling Support. Expedited deprovisioning ensures your data is deleted within 3 days.
3. 3. Is data immutability maintained after service ends? (In other words, are mailboxes placed on In-Place Hold or Litigation Hold retained after service ends?)
   By far one of the most frequently asked questions. Data immutability refers to the ability to preserve data – in essence, protecting it from destruction and tampering. See links to additional resources on Immutability, In-Place Hold and Litigation Hold below.
   
   No. Microsoft’s responsibility as a service provider ends after your service ends, which is when you stop being a customer/subscriber of the service. As noted above, data is permanently deleted when your tenant account enters the deprovisioning state, within a reasonable time after 120 days of end of subscription, or within 3 days if you request expedited deprovisioning. Mailboxes placed on In-Place Hold or Litigation Hold, including inactive mailboxes, are also deleted as part of deprovisioning.

How Lync/SfB clients authenticates to Lync/SfB Server - Simple explanation

How Lync/SfB clients authenticates to Lync/SfB Server

Internal users

When the user is inside the corporate network and signs in to Lync Server from a domain joined computer using their corporate Active Directory user account, Lync/SfB clients uses the following three protocols to authenticate the user when signing in to Lync/SfB Server:

o   Kerberos v5

o   TLS-DSK

o   NTLM v2

1. If the user has no certificate, Lync/SfB clients attempts to sign-in the user to Front-End Server using Kerberos (SIP traffic).

2. The Front-End Server rejects the authentication request, and redirects the Lync/SfB client to the Web Services (https://lync.contoso.com/CertProv/CertProvisioningService.svc) to request a certificate (SIP traffic)

3. Lync/SfB clients authenticates the user to Web Services using NTLM (HTTPS traffic).

4. Once authenticated, Lync/SfB clients requests a certificate for the user (HTTPS traffic). This client certificate is then stored in the user’s Personal certificate store.

5. Lync/SfB client re-authenticates the user to the Front End Server using TLS-DSK (SIP traffic).

6. For all subsequent sign-in requests, Lync/SfB client authenticates to Server using the TLS-DSK protocol with the user’s certificate instead of using Kerberos or NTLM

Note - This user certificate is valid for a period of 180 days, and is automatically renewed one month prior to expiration regardless of whether the user is connected internally or externally.

External users

For remote users connecting over the SIP channel via the Edge Server, Lync/SfB client can only use the following two authentication protocols:

o   TLS-DSK

o   NTLM v.2

1. If the user does not have a certificate, Lync/SfB client attempts to sign-in the user to Server using NTLM through the Edge Server (SIP traffic).

2. The Edge Server rejects the authentication request, and redirects the Lync/SfB client to the Web Services (https://lyncexternal.contoso.com/CertProv/CertProvisioningService.svc) through the reverse proxy to request a certificate (SIP traffic).

3. Lync/SfB client authenticates the user to Web Services using NTLM v2 (HTTPS traffic).

4. After authentication, Lync/SfB client requests a certificate for the user (HTTPS traffic). This client certificate is then stored in the user’s Personal certificate store.

5. Lync/SfB client re-authenticates the user through the Edge Server using TLS-DSK (SIP traffic).

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.