Skype for Business server 2015 CU appearing in Windows Update again

Looks like Microsoft have started pushing the latest Skype for Business 2015 CU via Automatic Updates:

Even thought the master KB for updates still says that they wont do this:

Seen on Edge, Front End, stand alone Mediation and PChat servers.

A change in policy at Microsoft or someone messing up?

If you do try to install this way then you're going to get a nice error as the CU (as usual) requires that the SfB Services are stopped:

If you do stop the services (Stop-CsWindowsService) prior to running Windows Update, then the update will pop the installer window as if you had manually downloaded the update:

As there is no database update since .281 maybe this is an okay way to install the updates, but just remember to restart the services afterwards if you are not going to be restarting the server!

To be honest anyone who wants to have control over the deployment of the CU wont be allowing this anyway as they would control via WSUS/SCCM etc.

Unable to login to Skype for Business Online with BT Home Hub 6 - part 2

My frustrations with using the BT Home Hub 6 and Skype for Business Online are documented here:

Here's my write up on how I've fixed it:

First thing I tired was contacting BT. My first call was not great, eventually I got through to a team who I was told would be happy to talk to me about the issues but they would want a credit card number..... I made my excuses and left....   ;-)

I tried again and got through to a grumpy lady who (after I asked if she could disable IP6 on the Home Hub 6) literally said:

and said I should send the Home Hub 6 back < sigh > 

I went digging into the Home Hub 6 and found that I have both IP6 and IP4 public IP addresses, meaning things like my Tado which don't support IP6 can continue to work:

However my work laptop has an IP4 and IP6 address:

So the easiest thing to force my SfB client to talk to the O365 homed servers would be to disable IP6 on my laptop. The correct way of doing that is documented here:

But doing so would break Direct Access on my laptop, which would be a Bad Thing (TM)

Instead I forced the laptop to prefer IP4 over IP6 by making the following registry change:

(reg change file here:!Arx7Ss1l4DQIgZSrJsx7M0EtARKBXuI)

After a reboot I'm in business!

Hope that this helps someone out there.

Presence Unknown..... BUT WHY!

Have had a long running issue with a single user at a customer where I was unable to IM them or see their presence:

However they could IM me and see my presence fine.

The customer has on-prem Lync servers. I am on Office 365 which is setup in a Hybrid with our on-prem servers. Other people in Modality who are on-prem (Response Group users) could see this person fine (you want a name - okay, it's Leon).

It should be noted that I used to be able to see the presence and IM with no issue, also, after I moved to O365 I could. Something changed later* Anyway - back to the story....

When Leon IM'd me I would get errors like this in my event logs:

504  Server Time-Out
ms-diagnostics:  27002;reason="From-Uri Domain is not in the receiver-tenant allow list";source="Office365ServerName.INFRA.LYNC.COM";appName="IncomingFederation";OriginalPresenceState="0";CurrentPresenceState="0";MeInsideUser="No";ConversationInitiatedBy="6";SourceNetwork="5";RemotePartyCanDoIM="Yes"

A search on that error didn't really bring anything up of value as it was talking about the whole domain needing white listing and that couldn't be correct as it was a single user issue. We tried moving to different PC's, different networks, investigated policies that Leon had but all came up nil.

The issue wasn't a big enough pain for Leon to want to spend too much time troubleshooting but eventually while discussing about their customers Office 365 plans a light bulb went off.

"Leon, have you got your user account in Office 365 as well"

After confirming he had it was as simple as turning off Skype for Business for his user account in the customers O365 tenant:

and we were back in business:

So what happened?

My account is in Office 365. Leon's account was on-prem. He also had an account in Office 365 but Hybrid was not setup.

Therefore, when Leon IM'd me, his client talked to his on-prem Edge, resolved the DNS for Modality Edge, and got proxied to me in O365.

However, when I attempted to IM Leon, my client talked to O365, who saw that there was a matching O365 tenant for the domain and sent the IM there. Simply turning off Leon from having an Office 365 Skype for Business account allowed the Modality Office 365 tenant to ignore looking up his details in the cloud, I found the customers Edge server and all was well in the world.

Simple when you know how!

*what changed? The customer got Office 365 but had not setup all the hybrid integration (as they didn't want to use it all at that time).

CCE 2.1.0 - Draining Calls

The Cloud Connector Edition system for Skype for Business online is a very impressive collection of scripts and glue and luck that has the ability to build a complete SfB voice infrastructure and patch it automatically. One of the parts of this is not as good as it could be, read on if you get call drops when updating :-)

Environment is 2x CCE hosts in the same site. For the test below I first put the CCE2 into maintenance and make calls. Therefore forcing all calls through CCE1.

I make two calls:

Ensure that both calls are up and running and show on the Sonus:

Logging into the Mediation Server on the CCE1 you can see the calls are running through it:

Take CCE2 out of maintenance so that both CCE's take service calls (both calls are still running on CCE1).

On CCE1 run the command Enter-CcUpdate on an elevated PowerShell session

Based on the documentation ( I would expect this to drain the mediation server, waiting for the two nailed up calls to complete and to then gracefully stop the services.

Instead I get this:

Services are stopped and both calls are dropped. Bit of a fail when the documentation says:

"The appliance is “drained”—that is, all existing calls will complete, but new calls are rejected."


"The Enter-CcUpdate cmdlet will ensure that all running calls on a Cloud Connector appliance will complete, but the appliance will reject any new calls, which are transferred to other production appliances. This cmdlet enables you to update an appliance without affecting end users calls." (my emphasis!)

(Bonus points for the spelling of "Drainning" and "Forceing")

Its now logged as a ticket with Microsoft and I'll update as and when I have a resolution.

Update: 22nd January 2018
Confirmed as a bug and passed to Product Group to address. Workaround is to connect to Mediation Server and perform a Stop-CSWindowsService -Graceful command