Sunday, December 01, 2013

Outlook Lync Integration New Issues and Fixes

Outlook Conversation History folder used to save your Lync Conversations may suddenly stop working and you may also receive error message pertaining to Outlook when you login to Lync client. This is where your user will come to know about the Integration issue with their Lync Client and Outlook and update the Support team for assistance.

Whether you have Lync On premise or Lync Online Outlook connectivity to Lync is possible and it's done using the Autodiscover service by your Lync Client and through EWS it makes the connection with your Outlook and shows your presence based on your availability in Lync and Outlook and also provides you the ability to save your IM conversations in Outlook etc.

Review this article to know more on this, which is explained beautifully.

How Lync 2010 obtains Exchange Web Services (EWS) URL via Autodiscover in Exchange 2010

Once you read the article you will come to know the importance of having proper Autodiscover and EWS configuration to make things work and this would be your starting point of any troubleshooting.

EWS Internal URI and External URI needs to be configured correctly on your CAS Server and also your Autodiscover DNS record should point to the correct CAS server both internally and externally for successful EWS discovery because Lync does not use SCP object like outlook for autodiscover and it only uses DNS based discovery method, which needs to set correct for Integration to work, this is where most of the issue relies and gets fixed, but there are other possibilities too that are discussed further below to give you an idea to get things checked in all possible ways to address the issue.

One more issue apart from the above one, is due to the EWSFindCountLimit reaching the maximum value of 1000 (default) and causes this issue and once user deletes some unwanted folders and reduces their mailbox folder count below the default value this issue will get resolved, but this is an workaround and not a solution so the best one to do if you have On premise Server is to either increase this value to a higher number or set it to null and update the user with the new setting. Below article from Flinchbot website explains this clearly with examples

Review here : Another fix for Lync Conversation History problems

New Issue Begins here:

The above issues mainly occurs in On premise Lync environment and also easily identifiable and fixed, the one which I am going to show you now with Lync Online seems likely to be understood and easily resolvable now for you using this post but it  was actually not the same case when I faced it as it  involved additional troubleshooting steps from the provided ones in the support articles which I have done recently and fixed the Outlook Lync Integration for a large number of users in a Global environment which I support.

Below is the Microsoft Article which speaks about the sign-in issue or the error message you would receive when you login to Lync client which generally talks about the Outlook integration and updates you that your Lync Sign-in address and Outlook profile address is not matching as shown below

Review the article to know more in detail : There was a problem connecting to Microsoft Office Outlook" error when you sign in to Lync Online

As stated in the article this generally happens when you use Lync Online and your SIP address matches your E-mail address but your UPN is different, though Microsoft updates us that all three of them needs to be the same for the configuration to work, it is not a easy task for Organizations to update UPN of users to match their E-mail address on a larger scale and Major Organizations use the Hybrid Exchange model and this change is not possible at ease and not a preferable one as it may cause other potential impact and moreover users tend to change their SMTP addresses on the fly and the only possible change we can do is to ensure that the E-mail address matches the SIP address and this is suffice to make things work and it was working for a large crowd and broke suddenly.

As stated in the article the WindowsEmailAddress property plays a vital role in making the connectivity work and this property gets updated when user updates their E-mail address in  On premise Exchange through Dirsync to the Cloud Azure directory (MSODS) and corresponding change replicates to the Exchange Online, Lync Online and SharePoint Online. This is a pretty straight forward process which MS does on their Backend and works seamlessly, Unfortunately this updation might broke on their end due to unexpected events and trigger this issue which I am going to explain now through my self experience and will show you how I identified the issue and fixed it with Microsoft Team.

When this issue started we were unable to identify at the early stages as the outlook configuration is setup correctly and also users are having no issues in accessing Lync or Outlook and nothing much revealed to us after we analyzed the Lync logs and still the Integration was not working and one fine day we Identified where the issue relies with the help of a user and also using the Lync Online powershell released at that time earlier this year.

One of our user updated when some one searches for her in Lync and select send an email message it was opening the email message with user's old Email address in the To field where in user has updated here Email address while ago and the same is showing up fine in outlook and user Lync sip address is updated to the new one and user uses the same to sign -in but Lync still points to the old address when user use the E-mail functionality from Lync which in turn tied to outlook to process the request.

This throw some light to us and with the help of the Lync online powershell we verified the settings and identified the issue , where user WindowsEMailAddress property in Lync online is showing the old one and in Exchange Online it is showing the updated correct one, this evidently proved us that Lync still uses the old SMTP address and things outlook and Lync sign in address are different and breaks the integration.

After this, we updated Microsoft team and pointed out where the issue is and proceeded with our next steps and when such issue occurs it is always good to identify the total number of affected users altogether in the Environment and create a report and fix them all at one go.

We used the following cmdlet to generate the csv report of the users who are enable for Lync with their SIP Address and corresponding WindowsEmailAddress and did some Excel work and prepared the final report of affected users.

Get-Csonlineuser - Resultsize unlimited | Select Alias, DisplayName, SipAddress, WindowsEmailAddress | Export-csv C:\Report.csv

Check this post to know more on how to install and connect with Lync Online powershell module

Access here : Windows PowerShell Module for Lync Online Available now !

Once the report is generated we found that updating Lync online alone is not possible on the Cloud directory end as attributes are Dirsynced from On premise to Cloud and the solution is to perform a dummy update on the affected accounts like adding an dummy Extension attribute that triggers the change notification via Dirsync to the Cloud Directory (MSODS) and then from there the changes replicate to the internal directories through which Lync online will also gets updated with the correct value and fixes the issue.

Check this below post to see how you can update extension attribute for a user through powershell then you can use your scripting techniques to do the task for all the users affected using the report generated as input at ease, also you can edit the same script to remove the attribute post Dirsync, as our primary task for replicating the changes to Lync online for WindowsEmailAddress attribute updation is already done through our earlier sync cycle and this action can be done to revert the accounts back to normal by removing the additionally added dummy attribute.

Check here: Adding and removing extensionattribute to AD object

Alternatively you can add an Secondary SMTP ( dummy) for the affected users and post dirsync the changes will be replicated as stated above and then you can remove the same from the user mailboxes as needed. Check this below post and use the small script that does this at ease.

Add Secondary SMTP Address in bulk for Exchange Server 2010

We verified the changes via Lync Online PowerShell and also through Lync Client's send email functionality for validation and finally contacted affected users and received update that their issue got finally resolved after a long time. This was really a great experience for me.

I am sharing this here so that you check the Integration issues on this perspective too and fix it at the earliest, easy way is to check using the Send email message functionality from Lync client and then using Lync Online PowerShell to confirm the status and Generate the affected users report proactively and fix it on a larger scale. You can perform this on your own and also update Microsoft team on the same so that they can verify if any issues occurred on their end and also assist you with getting this fixed soon.

No comments:

Post a Comment