IT based Communications

a different Unified Communications site

SkypeforBusinessUpdater CU1 (and later) installation can perform an unconditional OS restart


During a testing phase of a Lync 2013/Skype for Business 2015 upgrade, I was caught be surprise when the servers restarted at the (final) cumulative update (CU2) phase. Since all the logs are, by default, written on the %TEMP% folder, after the server reboot they are…. gone!😦

I assume that if someone is just applying the CU1 on a Skype for Business 2015 will have the same experience.

22/May/2016: updated content with the cause and final solution


The cause is that when you execute the Stop-CsWindowsService, the Web Server is stopped but there is a  IIS Worker Process that stays in memory (leak issue):
This information can be found on the setup log of the iis rewrite:
“IIS URL Rewrite Module 2. The file C:\Windows\system32\inetsrv\rewrite.dll is being used by the following process: Name: w3wp “

The CU1 (Nov 2015) introduced a new install file (rewrite_2.0_rtw_x64.msi) that it’s a updated version of the ‘IIS URL Rewrite Module 2’. It appears on the SkypeforBusinessUpdater GUI, but it’s not listed on the official list of Updates for Skype for Business Server 2015.
Could not find the reason and why include now this version released on the 1st of May 2015 ? (S4B initial binaries are one month older…)

Fortunally one particular server didn’t restarted, which allowed me to ‘peak’ the installtion logs. It was a quick catch:
* While all updates are executed with parameters REBOOTPROMPT=S REBOOT=ReallySuppress
* The ‘IIS URL Rewrite Module 2’ is executed with REBOOTPROMPT=S IACCEPTEULA=yes

This ‘tiny’ difference make all the difference:
* REBOOTPROMPT=S means that no reboot prompt will be shown to the end user
* REBOOT=ReallySuppress means that even if required a reboot will not be performed.

So the result is that, if the ‘IIS URL Rewrite Module 2’ informs that a reboot is needed to complete the installation (ex: because a file is in use and will be scheduled for the next restart), the Windows installer will automatically reboot the server !!


Fortunally this package is the last of the updates to run, so no other update is skipped, BUT…
…  the server is going to restart and, with him, all the Skype for Business services. And you will not like if:
(1) some of the updates were not sucessfully installed, and you find yourself with differente CU components versions causing unexpected service errors on the event viewer.
(2) you are in the middle of a pool upgrade and:  you find yourself with a (rebooted) server with the RCT service on ‘pending start’ -because the pool might not have enough quorum-
(3 and the bad one) You are in the middle of a Lync 2013 upgrade and you got now a server already started in S4B. If you are still trying to upgrade other Lync 2013 servers, you will get a warning that a FE pool member server is running, and you need to kill the services.

The other unwanted result is that you will probably lose the log files (kept on the user TEMP directory and deleted at restart) that might help to troubleshoot some issue.


Before you install the CU1 update:

  • Stop the S4B services as instructed (powershell command: Stop-CsWindowsServices)
  • Execute the command IISRESET /STOP
    This will force all IIS dependent components to stop

This way we can run the updates withouth an unexpected server restart.

Apr2016 updates can affect SQL mirroring at windows startup

Although is not a direct Lync issue, in a Enterprise deployment pool we use SQL mirroring for database high availability. I’ve found recently a potential issue that affected 1/4 of the SQL servers after applying some of the April 2016 updates from Microsoft. I wasn’t unable to identify precisely the root cause, but here’s some clues and potential workarounds and fix.


After applying several Microsoft OS April 2016 updates, the SQL mirror node might not start correctly after the server reboot (it can also only fail after a second restart).
This as been observed on Windows 2012 Servers.


When you try to get the database mirror state from Lync PS it will show you that the mirror is not enabled/disconnected

Lync-DBmirror-failure4The SQL management studio show the databases with the status ‘In Recovery’.
If you run the SQL query to check the mirror endpoint status it will show you that is started

SELECT type_desc,state_desc FROM sys.database_mirroring_endpoints

Further log investigation will show that the SQL server at initial startup reports that the mirror endpoint configuration is disable for each database:
Database Mirroring Transport is disabled in the endpoint configuration


A few lines later on the log you will see the mirror endpoint being enabled, but the databases remain at ‘in recovery’ state.

 (Potential) CAUSE

Lync-DBmirror-updatesI was could not pinpoint the exact cause, but it seems related to two updates installed at the same time:
KB3147071 (this is not a security update) – “Connection to Oracle database fails when you use Microsoft ODBC or OLE DB Driver for Oracle or Microsoft DTC in Windows”
* KB3146706 – (this is an important security updates) – “Security update for Windows OLE”
NOTE: the other updates on the pictures were also removed at the same time, but from the update information I don’t see a relation with the main issue


(a) The most effective ‘quick fix’ is to force the mirrror endpoint status to ‘started’ with the SQL query:

(b) Restarting the SQL services will also solve the issue

(c) rebooting the server can sometimes solve the issue (you should only do this if you don’t have rights to manage/restart the SQL server)

The abover workarounds will not (probably) solve the issue the next time you need to reboot the server.

(in test) SOLUTION

(1) Uninstall KB3147071 and KB3146706 and restart the server.

(2) Install KB3146706 again and restart the server.

(3) (optional) install KB3147071

(4) reboot the server (at least) twice to check if the mirror starts sucessfully

Update 17/05: The sugested solution was not effective. After 24 hours I restarted the server and the issue is back😦


Phone number formats that display the click to call icon on IE browser

You might have been asked from you company web developers what number format should they use to display the click to call icon on your intranet corporate directory, or for you customers to be able to dial from a click on your company phones number main contacts. The difficult part is to ‘google-fu’ where that is documented and/or memorize it.

Here’s how to find them.

First of all the, icon is a IE plugin that is installed with the Lync/Skype for Business and reads reads the web page content while is loading. Make sure that the plugins are running before reading this post.

By ‘analysing’ the plugin OCHelper.dll (this is the January 2016 update version, previous or future versions might differ), you will find 4 REGEX strings

by using Jex’s Regulex, let’s analyze the first expression:

The first column of numbers should display the click to call while the second will not.
+1-333-333-4444(you should see the call icon)
+1 333 333 4444
1 (333) 333 4444
+13333334444 (nope: missing separator of 4 groups of digits)
1.22.333.4444 (no 3 numbers on second group)
1.333.22.4444 (no 3 numbers on 3rd group)
1.333.333.333 (no 4 numbers on last group)

 The second expression look long, but it’s easy to understand:

This numbers should show the icon: +1-(800)-click-me, 888.1234open
But more than 9 characters after the tool-free will fail: 1.900.too-long-string

The third expression string looks dedicated to non-US (international prefix + format) numbers

This numbers should show the icon: +41 58 30 1111, +41 503 011 11
But other formats might not work  (when you try to omit your country code for national customers): (+41) 58 301 111, 58 301 111

The 4th and last expression is an attempt to cover other cases of digit grouping

But if you want to really be sure all the times, just embed on the webpage code the universal format of tel:+222222222

Now you have a ‘cheat list’ on how to embedded your telephone number on web pages:)


What you should know about Lync (Skype for Business) updates after Dez/2015

fallback-lynconlineIf you have deployed on your organization a firewall/proxy with Deep Packet Inspection (DPI), some of your Lync (SfB) users might have questioned you about a certificate popup similar to picture on the right. By now they probably are not having it anymore.
You will also get much more similar popup if you like to control/restrict the desktop trusted certificates on your environment (check the last paragraph on the blog)

Here’s the ‘deconstruction’:

If you were an earlier adapter of the KB3114351 – security update for Lync 2013 (Skype for Business): December 8, 2015 (this also applies to security update for Skype for Business 2016: KB3114372), you didn’t find by that time on one ‘functionality’ that was introduced.

KB3114351 was later updated on 23 Dec 2015 – “This security update contains the following improvements: •Adds Cloud-based Discovery •Uses SSO to autodetect SIP address and start sign in” – But no more details.

On the 12 of January, KB3114687 was published:
“”The address type is not valid” error when you sign in to Lync 2013 (Skype for Business) by using domain\username format”.
“This issue occurs because if Lync 2013 (Skype for Business) client fails to detect lyncdiscover and lyncdiscoverinternal services. In this case, the new DNS-less discovery (also known as Cloud-based discovery) redirects you to the Microsoft Lync Online Discovery services in Office 365″

The KB points two other two KB (also initially released on the same date):

What impact does it had to your Lync on-premises environment?

The December 8, 2015 security update added a new ‘fallback/DNS-less autodiscover’. If your client doesn’t resolve any of the lyncdiscover* DNS addresses it will then query and only after an answer (or failure to connect) it will continue the other SRV/DNS fallback discovery.

Besides the issue KB3114687 issue, if your clients don’t receive the lyncdiscover* records (either because you don’t use it or there was some issue connecting to the DNS, they are going to the internet and there’s where the users get warning picture from at the top of the post.
If you don’t get (or the user press the ‘connect’) you might get your user trying to authenticate and query Office365 Cloud. It will fail, and then continue throw the SRV autodiscover and login back to the on-premises Lync.

The January 12, 2016, update for Lync 2013 (Skype for Business) changed (fixed) the previous autodiscovery priority  (1)lyncdiscover* (2)SRV records (3)sip* (4) DNS-less

The probability for a on-premise user to ‘fallback’ to the cloud is now very little. But in any case, if you have a on-premise-only deployment of Lync, my advice is to disable Cloud based discovery on your clients either by a GPO (if it exists) or setting the following registry key:
reg add HKLM\Software\Policies\Microsoft\Office\15.0\Lync /v DisableCloudBasedDiscovery /t REG_DWORD /d 1 /f

After setting this key, the Lync (Skype for Business) client will no longer query (and connect to) the

You will still catch some Lync network traffic going to MS servers, but that’s another story:)

The other ‘Cloud based functionalities also are causing other issue refered on my previous post “Users are being asked for credentials after applying KB3114351 or KB3114502”

Extra info:

If you still have the only the December 8, 2015 security update installed, here’s a ‘quick trick’ to get the certificate popups on your desktop client:
(1) delete the trusted CA installed by Lync client in both user and local machine (might need to restart your PC)
(it seems that Lync will install the certificate when you start it)
(2) point your lyncdiscover* records to a dummy IP. ex: create on the hosts file something like: lyncdiscoverinternal.<yoursipdomain> lyncdiscover.<yoursipdomain>
(3) delete the EndpointConfiguration.cache file from %localappdata%\Microsoft\Office\15.0\Lync\sip<yoursipuseraccount> alternatively you can just press the ‘delete my sign-in info on the main Lync login screen’

 When you login with your user again you should be prompt for a ‘certificate trust issue’

Users are being asked for credentials after applying KB3114351 or KB3114502


It’s ‘reverse engineering’ time, install/remove updates and work for MSFT for free… again.


So… after you applied the KB3114351 -security update for Lync 2013 (Skype for Business): December 8, 2015- or the KB3114502 – January 12, 2016, update for Lync 2013 (Skype for Business) some (if not all) of your users will start complaining that the SfB Client is asking for credentials at startup.

The main clue that something is wrong is when you see the username filled with SIP address (picture on the right) and you know that is not the correct user’s AD login and the user was never asked before for credentials because the client should use the Windows domain logon credentials.


KB3114351 and KB3114502 changed the Client Sign-in algorithm and some particular deployment scenarios were not tested (check ‘affected scenarios’ below).

By using an issue-free client connected on the internal LAN (this is important later), when the client starts six  new (there are more) registry key appear:
The bottom one WindowsAccountSipUri came quickly to my attention. “Goggle-fu” didn’t help too much (if MS is reading this: why KB only refers to issues fixed/new but rarely mentions changes on behavior? why a “security update” includes new features?), and after an overnight of tests here’s how the new updates changed the client logon process:
1. At startup if the registry key ServerSipUri has an address, the client will query the active directory for the user’s SIP address and write it on the WindowsAccountSipUri.
2. If both keys match, the client will use the Windows domain user credentials to sign-in (and no one complains about it anymore).
3. If both keys don’t match, it will popup the password prompt for the user. If the user sip address doesn’t match the Active Directory, doesn’t matter if the user put the wrong or right password. The client will fill the username with the SIP address (and also the ServerUsername key). At this point you are screwed up and you need to help.
4. If the user is a ‘techie’ he might know how to manually set the right username and password and will not call you, BUT if he didn’t check the ‘save password’ it will be prompted for credentials the next logon time, and again… and then it will call you:)

Before those updates the SfB Client would attempt to logon the sip username with the Windows credentials. Only if they failed it would popup for different credentials.


Based on the point 3: When both keys don’t match?
> When the client cannot get any SIP address of the user from AD. Then it doesn’t have a value for WindowsAccountSipUri (and to match with the ServerSipUri)

(Here’s where you can confirm if you are affected)
When the Client cannot get the SIP address from AD?:(A) When the client starts (after the patching) accessing remotely from the Internet
(B) When you have a Lync resource forest topology deployment and your user forest doesn’t contain any msRTCSIP-PrimaryUserAddress AD  field (or not have a value)
(C) isn’t the previous one also similar to Office365 with ADFS deployment?

SOLUTION (or workarounds)

(all) clear the registry key ServerUsername if doesn’t match the user’s UPN on AD. Or replace with the NTLM (domain\username), it might solve another additional issue reported that the SfB client prompting for Exchange credentials

(A) if the user can connect to office (go onsite or use a VPN),  and restart the client. As soon as the WindowsAccountSipUri has the SIP address, you will not see the issue (i hope!)

(B) manually configure the username, password and check ‘save password’ box (probably fixes temporarily) and wait for the official MSFT February update

(C) manually add the WindowsAccountSipUri with the sip address of the user if you are sure that it’s your scenario.


Although extensive I didn’t perform all imaginable scenarios. There might (and I saw) be some other conditions or the engine client that will not expose the issue. Here’s some discoveries:

The WindowsAccountSipUri value is not validated once it is created. On a simple Lync server deployment:
1. Login with a user.
2. Change the users SIP address on Lync server
3. If you try to sign-in on the same SfB client, you will not be able to login with the new sipaddress (even with the correct username/password) or will experience the issue. The workaround is to delete/fix that registry key (or delete the windows local user profile).

Another way to have the issue using scenario (B) above:
1. login with a user for on a workstation (the idea is have new userprofile)
2. start SfB, fill the sip username and single sign-on will  work (no username/credentials asked)
3. all next sign-ins SfB will prompt for credentials (except if you click on ‘save password’ option)

Nov2015 client update issue: no Missed call notifications (solved)

KB3101496-issueOne customer end-user reported this issue and after some testing here’s the case.
The Missed Call Notification is… missing in Outlook folder and Lync.

After applying the  KB3101496: “security update for Lync 2013 (Skype for Business): November 10, 2015”, the Lync client will not save the missed calls in Outlook, but:
– All the other calls are registered.
– This will not happen if you have Exchange UM integration configured.


Cause: component update issue

Details: the client will use Exchange Web Servers (EWS) to create a missed call notification message (Itemclass IPM.Note.Microsoft.Missed.Voice, signed on the footer ‘Skype for Business’). Before the KB3101496, you see him connecting to Exchange server
After applying the update, there is no connection attempt.

Solution: To fix this issue, install the February 9, 2016 update (KB3114732) for Lync 2013 (Skype for Business).

(previous) solution: uninstall the KB3101496 update, and don’t apply any newer updates since they also have the issue.

There are more people confirming this issue, and other reporting a Lync not showing any call records on the client.

A much more concerning update issue than my previous one reported previously.

(11.12.2015): December SU 2015 (KB3114351), didn’t solve the issue.
(07.01.2016): Trond Egil also confirmed the workaround
(05.02.2016): January 12, 2016, update for Lync 2013 (Skype for Business) , also didn’t fix the issue
(09.02.2016 ): Issue was documented on KB3136400
(10.02.2016): Issue was solved with KB3114732



(bypassin) Lync/SfB topology limitations

While I was preparing for a customer a PoC of a full redundant solution, I came again across a well-know limitation of attempting to consolidate multiple roles usingn the less amount of servers (less management,less licensing costs,…).
NOTE: the next text also applies to Skype for Business

So for this full redundant and automated solution, the plain idea would be:

  • Pool1 with 3 front-end servers
  • Pool2 with 3 front-end servers
  • 2 Back-end servers, each with:
    • 1 SQL instance for Pool1 (mirror with other server instance)
    • 1 SQL instance for Pool2 (mirror with other server instance)
    • 1 Lync file share storage (DFS between servers)
    • 1 Office WebApp Server (Farm with other server instance)
  • Use existing SQL express on a front-end server of each pool as witness for automatic mirror failover.

You can actually start creating SQL server instances

But when you try to assign one of the instances to a mirror, it will not appear:

The limitation is more visible if you try to create from the ‘New…’ button. Topology builder validates the existence of any existent server FQDN and also prevent the usage of instances named LYNCLOCAL or RTCLOCAL

You will also be prevented to add any other components (Office WebApp, gateways, trunks, edge servers,…)

With this limitations you might think of some Q&A:

  • Question: There’s no technical limitation on the previous design. Is it possible to deploy this solution? Answer: Yes
  • Question: Is it possible to use any existing SQL instance for mirror witness? Answer: Yes
  • Question: Can I deploy Office WebApp components on an existing server in the topology? Answer: Yes
  • Question: In a lab could be possible use only the Front-End servers for a Pool deployment? Answer: It would be radical !, but Y…

The recipe?
If you are not one of those guys that just follow the deployment wizards…
…. you just need to think ‘outside of the box/window’ (and more easy than installing Lync on a Domain controller)😉

To be continued…

Nov2015/Dec2015 Security update – branding issues (solved)

After applying the KB3101496 “security update for Lync 2013 (Skype for Business): November 10, 2015”,  you might start noticing some back-rebranding of the “Skype for Business” skin :)

Here’s some samples:

And if you continue to use the ‘old-fashioned’ skin, they make noticed that it’s the Lync (Lync) one:)


1. Edit the registry key named ‘LyncName‘ in HKLM\SOFTWARE\Wow6432Node\Microsoft\Office\15.0\Registration\{90150000-0011-0000-0000-0000000FF1CE}
2. Restart the client, or just go to help>about and the titles will update on the fly
Notes :
– the product GUID might be different of the installation media (office pro, etc…). just search the registry for the key ‘LyncName’
– If you have installed the 64-bit version, the registry key will be at HKLM\SOFTWARE\Microsoft\Office\15.0\Registration\{GUID}

Update (02.12.2015): There is more concerning issue than this one.
Update (09.12.2015): December SU 2015 (KB3114351), didn’t solve the issue. Is this a Microsoft “rolling back” rebranding:)
Update (14.01.2016): fixed on the  January 12, 2016 update (KB3114502)

Skype for Business (Lync) client crash when add a group to outlook

An end user found this issue and I was able to replicate on other environments.
If you have Outlook (2013 version tested) installed you are able to search on Lync for Users or Distribution Lists (DL) and add them to your personal contacts address list.
But for DL, the Skype for Business (Lync) client will crash:

  1. Search for an DL and right-click on the ‘see contact card’
  2. Click on the ‘add’ option
  3. The Outlook contact card management window will open, but S4B/Lync client will crash and restart
  4. The Outlook window will still be open, so you can still add the DL to your personal contacts

Additional notes:
– It will also happens by right clicking on any existing DL that you have on the Lync contacts;
– The issue occurs with the Lync or S4B skins. In either cases the error windows will display ‘Microsoft Lync has stopped working…’
– If you add the DL on Outlook, the contact card option changes to ‘Edit’ and you can successfully change the DL using the Lync interface without any issues;
– Adding an user doesn’t causing any problem (maybe because only the Lync client interface is used?).

(UPDATE 11.11.2015 1:05am) CAUSE
After dump analysis and a lot of KB add/remove sequence I found the reason(s).
Turns out that Outlook updates and Lync/SfB updates are ‘not tested together’:

  • if you install KB3085495 (Outlook Set2015) with KB3085581 (Lync/SfB Oct2015) already installed you will get the issue;
  • (Not fully tested) you will also have the issue if you install previous Outlook updates and/or with KB3085500 (Lync/SfB Set2015) installed

I haven’t found yet a decent solution or workaround and several KB repairs/remove, really change the behaviour of the issue:

  • sometime it doesn’t crash but the add button doesn’t work anymore.
  • Warning: uninstalling the outlook update can make Outlook client unable to connect to Exchange😦

Error uploading pictures to group chat (again the cookies)

– A Lync enterprise deployment (with one or more servers), with persistent chat;
– Web Services behind a Hardware Load Balancer (HLB);
– the HLB is configured for cookie affinity (persistent);
– you try to upload a file greater than ~50kb, but it fails with an ‘Error in transfer’ message (as the picture on the right).

File upload to group chats was introduced February 2014 Update for the Lync Desktop Client (CU5/SP1). Mastering Lync has a great description on how the process works.
What I have found is that the Lync client (or just the group chat component) doesn’t honour/supports the set-cookie sent by the HLB. Since no cookie is sent the HTTP Post requests, the HLB might send some file chunk packets to the next available front-end server (depends on the balancer algorithm) and the server will drop with an 500 error.

Change the HLB internal Web Service VIP address to ‘IP source’ affinity. This way the HLB will send all client traffic to the same Front-end server.

Considerations and notes
There is some confusing documentation about Load Balancing internal services:

  • The main MS reference identifies the Ports if Using Only Hardware Load Balancing, but not the affinity type;
  • The Hardware load balancer requirements for Lync Server 2013 is not quite clear about External and Internal settings and how it supports cookie affinity:
    > forcing the cookie to MS-WSMAN will not change the observed client behaviour;
    > but then we find a line stating: ‘for internal Web Services VIPs, set Source_addr persistence (internal port 80, 443) on the hardware load balancer
    > Barracuda ADC doesn’t specify this particular MS requirement. F5 overcomes HTTP persistence with a technique called OneConnect.

Since most of the companies provide private IP for each user client, there’s no issue on load distribution and this configuration is acceptable.
But if a lot of your user clients are behind NATed subnetworks, this configuration is not so much preferable (and that’s the reason to user cookie-based affinity).

As a final thought: Could the MS ‘requirement’ regarding HLB IPsrc persistence be a workaround to a client limitation? It would not be the first cookie handling issue found…

Skype for Business for iOS: missing features

If you are thinking about updating your iOS to the newest Skype for Business client here a list of the features that are (still) not currently available from the previous Lync 2013 version.
If you have auto update enabled, then you might find out a little too late.

Contacts screen
• Search your contacts from the Contacts screen.
• Search for Distribution Groups.
• Send an IM to all members of a Group.
• Use Group contact cards.

In-call screens
• Use Call Transfer.
View Microsoft PowerPoint presentations.

• Set Call Forwarding and Simultaneous Ring options.

Chat screen
• Send the chat transcript as an email message.
• Access a participant’s Contact Card from the Participant List.

Meetings List screen
• Visually identify meetings that are currently in the Tentative acceptance state.
• Access the meeting organizer’s Contact Card from the Meeting detail view.

Voice Mail screen
• Delete a voice mail message.
• Use quick options to return a call and navigate to the Contact Card from a Voice Mail message.
• Use Accessibility features.
• Use Speed Controls for faster and slower Voice Mail playback.

According to Microsoft KB3102247: “We are working to address this difference in feature sets and to update the capabilities of Skype for Business for iOS as quickly as possible“.

If you don’t really have problems with this limitations, here’s a good look of the client.

You can’t record after you install MS15-097, or… can you?

Microsoft just added the following known issue regarding the latest September 2015 Security Update (SU):

  • You install security update 3085500 that is documented in security bulletin MS15-097 Security Update for Lync 2013 (Skype for Business) that was released on September 8, 2015.
  • You join a meeting by using the Skype for Business client (version: 15.0.4753.1000).
  • You click the More Options button, and then you click Start Recording.

In this scenario, nothing happens. You don’t see any notification or visual indication that recording has started. Additionally, when you open the recording manager, you don’t see any file or progress status.

This problem is scheduled to be fixed in the October 2015 update for Lync 2013 (Skype for Business).”

I try to check for this, but on the several clients, in different update levels (ex: update directly from April 2014 CU), I can still successfully record meetings.

There is no more explanation on the KB3099414, but there might be some pre-conditions to be meet before you to experience this issue. You might still want to apply the Set2015 SU (there are some of important fixes) and test if you’re enterprise users are affected.

The only reference so far is on a post in the Office365 community, where Microsoft Support confirms the issue.

Lync Server 2013: install (or not?) July 2015 CU before installing September 15 SU

These Microsoft KB documents where updated on the last 24 hours, got me puzzled:

KB3080353 (25/09/2015): Description of the security update for Microsoft Lync Server 2013 (Web Components Server): September 8, 2015
To install this security update, you have to install the latest July 2015 update Lync Server 2013.

KB3098577 (24/09/2015): Sign-in and query errors after you install MS15-104 Security update for Microsoft Lync Server 2013 (Web Components Server)
After you install security update 3080353 …, you experience one or more of the following symptoms in Microsoft Lync Server 2013:

  • Users can’t sign in to your dial-in page.
  • Lync Mobile clients can’t sign in.
  • External clients can’t sign in.
  • Address book web queries fail.
  • Users are prompted for credentials for some web services after they sign in internally to Lync desktop clients.”

But below on the KB text:

“If you install Lync security updates by using the Cumulative Server Update Installer (LyncServerUpdateInstaller.exe), the installer should prompt you to install the correct prerequisites
Security update 3080503 (MS15-104: Security update for Microsoft Lync Server 2013 (Web Components Server): September 8) can be installed without previously installing the required July 2015 cumulative update 5.0.8308.920 for Lync Server 2013.”. A new version of LyncServerUpdateInstaller.exe is shipped together with the security update.

My concerns are:

  • The issue is applying the September “WebComponents.msp” (you can find it separately on the download details) on the download patch without updating the one from July (ex: using windows update)
  • The “LyncServerUpdateInstaller.exe” is basically a package of the most recent released .msp files for each components
  • So, what WebComponents.msp version is inside the September LyncServerUpdateInstaller ?

Just for the safe side (since I have a large deployment with 4 pools and 28 Lync Servers), I will apply the July 2013 LyncServerUpdateInstaller and after that the September one.


Time to compare to the July and September 2015 updates. It all comes to the WebComponents.msp content. Beyond the ~1500 files with some date differences, we have this:

Filename Date July 2015 CU September 2015 SU
WebComponents.msp comparison 1511 Files total 1507 Files total
[Lync_Install_Dir]\Web Components\LWA\Ext\SWF\

[Lync_Install_Dir]\Web Components\LWA\Int\SWF\

expressInstall.swf 29.04.2015 included in .msp Not included in .msp
NAPImessage.swf 29.04.2015 included in .msp Not included in .msp
Swfobject.js 29.04.2015 included in .msp Not included in .msp
[Lync_Install_Dir]\Web Components\Web Scheduler\Ext\Scripts
jquery.js 21.07.2015 Not included in .msp included in .msp

These file are part of the puzzle, especially if they are not part of the first release of Lync. They ‘swf’ were introduced on the December 2014 CU, and update on May 2015 CU and July 2015 CU (check the file information section on each KB). This means that applying the Lync servers with September 2015 SU without the  May 2015 CU, you will have any old version or even none (if you didn’t applied nothing before December 2014)

KB3055014 and KB3085500 introduces an unknown xml “400 Bad Request” issue

I noticed recently on several client troubleshooting (using the Snooper tool) on a particular “400 Bad Request” message that appears on the end calls.
After several cumulative updates (CU) history regression testing, I found that this behaviour started appearing with the latest two CU (or correctly, the security updates):

  • KB3055014 – security update for Microsoft Lync 2013 (Skype for Business): August 11, 2015
  • KB3085500 – security update for Microsoft Lync 2013 (Skype for Business): September 8, 2015

If you have any of those updates, you will find the 400 error message on every call (PSTN or Skype) when the called party disconnects. Here’s an example of the same call I made to a PSTN number:

  • Until the July 2015 update, the client will send an “error” report in xml format for the front-end server
  • After the August/September 2015 updates the same report is now different (similar response as a Skype-to-Skype)
    There’s a <progressReport/> ending without any initial <progressReport>
  • The server detects this incorrect xml format and that’s why you see the “400 Bad request” and a “Client.BadCall” fault

For the end-user there is no visible or functional impact.
I still don’t know if there are any impacts for the backend services. The call diagnostics for CDR and QoE diagnostics are correctly sent on another SIP message.

iOS9 breaks Lync and S4B meetings URL

iOS9-noOpenmeetingURLThere is one more issue when you upgrade your iPhone or iPad to iOS9: Looks like when try to open a meeting url on Safari (ex: received through a webmail server), the Lync client is not launched and you stay on the meeting webpage (like the picture on the right).

Looking at the behaviour and some initials traces, looks like there’s some update on the Safari web browser that is not allowing the Lync javascript https://<meetingurl>/JavaScript/Launch.js?lcs_w15_onprem5.0.8308.726 from lauching the client.


  • workaround: install/use  the Opera mini web browser on the iPhone/iPad
  • Microsoft confirms the issue on KB3097592 and has another workaround.
  • 25.09.2015 – iOS 9.0.1 update doesn’t resolve the issue
  • 01.10.2015 – Microsoft just released Set2015 CU13 (don’t get confused with Set2015 SU) that contains a web component update to address the issue (web pages and scripts) were updated and safari can now launch the Lync client.
  • 29.10.2015 – After some testings, I noticed that it’s not working for iPad devices with iOS 9.1, released 3 days before which includes 24 security updates (details here)
  • 13.11.2015 – Microsoft confirmed that the iPad 9.x is still not working. Those users still need to use the workaround described on KB3097592 to join meetings urls or my workaround :).
  • 14.01.2016January 2016 cumulative update 5.0.8308.945 for Lync Server 2013 web components server fixes the problem with iOS 9.1 and iOS 9.2

Get every new post delivered to your Inbox.

Join 144 other followers