Fixing the missing Skype Meeting Add-in for Outlook

This problem has been popping up for our users the last year: Whenever a user would start Outlook (after reboot or simply restarting Outlook) the Skype Meeting Add-in would be missing from the ribbon and had to be manually enabled to show up again.
In my experience the problem is not consistent between users with the same OS version or even local administrator privileges, but the solution was nevertheless easy in the end.

After trying all the official tips of

1. Simply enabling the add-in (works for the current session, not after Outlook restart)
2. Repair the Office installation
3. Verifying the registry key of the add-in “LoadBehaviour” (should be the value “3”)

Situation still persisted, the user would have to manually enable the Add-in via the menu File -> Options -> Add-Ins -> COM Add-ins. Not a permanent solution.

What works in the end, and is covered in other blog posts, is this:

1. Run Outlook as administrator (no need to set up a new account/mailbox if your logged-in user is not local admin)
2. Navigate to File -> Options -> Add-Ins -> COM Add-ins. Now simply remove the Skype Meeting Add-in from the list.
3. Re-add the Meeting Add-in from the same menu. Path to the add-in is dependant on your Office version. The add-in itself is named UcAddin.dll
   • If you are running x86 version then the path is %programfiles(x86)%\Microsoft Office\Office 16 for Outlook 2016 or
     [..]\Office 15 for Outlook 2013
   • If your are running x64 version the path is
     %programfiles%\Microsoft Office\Office 16 for Outlook 2016 or
     [..]\Office 15 for Outlook 2013
   • This may differ if you are running Click-to-run Office version
4. Now close Outlook and restart in your regular user context.

Add-in should be available again.

Advertisement

Certificate tip – enable web enrollment for your SHA256 templates

Ever since version 2008 it has been a well-known “feature” within Windows CA server that some certificate templates would not be available for web enrollment. The reason for this would be that some certificate features would “promote” the certificate schema version from 2 to 3. As of today, where SHA-1 is considered “dead” and Cryptography Next Generation (CNG) templates should be the only rational choice, certificates with schema version below 3 are just not available.

For most Windows based systems this is not a big problem, as certificate requests can just as easily be made from MMC certificate snap-in. But for Linux servers, or legacy appliances, not being able to generate a Certificate Signing Request (CSR) and issue a certificate based on that will imply running several “openssl” commands to “split” your manually issued certificate into private key and public certificate files – and making sure that it matches the server or appliance’s requirements.

I have often been missing the opportunity to just paste the CSR into the web enrollment portal and bring the resulting certificate back to the requesting server, but as I have been told for years that would simply not be possible for newer templates. Until recently, as I once more was facing a “CSR scenario” and came across this article from Microsoft. This was perhaps well-known for you IT pros out there, but for me this was breaking news!

The solution is quite simple, and involves nothing but a little ADSI Edit where you manually define the schema version to be something else. Be careful to test it properly, preferrably on a separate/duplicated certificate template. Because schema version 3 certificates might require data not provided through web enrollment, the workaround might not be completely safe for production environments.

This worked perfectly in my case, which was for a CentOS server, even with an X.509v3 CSR including Subject Alternate Name records.

Jabra headset stops working during Skype calls

This issue has been bugging me, or my Skype user colleagues to be more precise, since the anniversary update of Windows 10. The symptoms goes like this: during a call the user’s microphone will stop working. Most of the times, but not always, there will be an error message within the Skype client stating that “your microphone stopped working”. Other times the other party will just be like “Hello? You there?” and finally hang up.
For some of my colleagues working in the Customer support center the problem was getting really frustrating – as customers would think that she intentionally hung up or left the call intentionally.

Unboxing the Logitech Smartdock

Ever since I first was introduced to the Smartdock during Microsoft Ignite last year I have been anxious to get my hands on one. Our company has been heavy on collaboration since Live Communications Server 2005, mostly with desktop users using audio and screen sharing. Lately the use of video enabled meeting rooms have been asked for, and for someone that thinks traditional Skype Room Systems are too expensive (at least for company wide implementation) the Logitech solution looks really promising.

This week the Smartdock finally arrived, and here are my initial thoughts on it.

Issuing certificates with longer validity

In my previous job as a hired consultant I generally wanted the Lync/Skype for Business servers to have certificates lasting beyond the two year default validity period. Why? Because I, along with the customer, would consider a Lync or Skype for Business solution to have a horizon stretching beyond two years – and therefore issuing a certificate that would expire only after two years would be meaningless.

Skype for Business server update fails with code 1603

Today I was taking advantage of the quiet days between Christmas and New Years eve to do some overdue patching and updates on our Skype for Business 2015 servers. As the blog post title suggests the update would not complete successfully. Keep reading to see my notes on the subject.

Office Web Apps server farm updates – “Unhealthy” over again

The other night I had to do some patching on our Office Web Apps Server (OWAS) 2013 farm. Even though it was only Windows Updates, with some security patches for OWAS as well, I still went for the official update method where the node to be updated is removed from the farm.

Reviewing the update notes I realized that it either must have changed recently or that I have got it all wrong before. I have always thought of it as removing a node from your farm (as well as the load balancer), applying the updates and then adding it back in. Actually, it is quite the opposite: The first node to be updated will be the first node of your new farm. Then, as you update the others, you will join them to your new farm – using the load balancer to decide what farm will take care of the actual traffic. The actual process is like this:

1. Decommission the first node you want to update, using PowerShell cmdlet
   Remove-OfficeWebAppsMachine
   This is run on the actual node. On the same time you will decommission this node on your load balancer.
2. Run updates on your node. Reboot when requested to do so.
3. As the node is up and running again, run the cmdlet to make it the first node of your new farm:
   New-OfficeWebAppsFarm -InternalURL https://webapps.contoso.com -ExternalURL https://webapps.contoso.com -CertificateName “YourCertFriendlyName”
   It will not matter if you reuse the URL’s for your old farm. This info is only used to let your new farm know what URL it will be accepting traffic for, and it will have no knowledge of your old farm/nodes.
4. Continue upgrading the next node in your farm by running step 1 and 2. After you have finished upgrading the node, add it to your new farm using the cmdlet
   New-OfficeWebAppsMachine -MachineToJoin “name-of-first-updated-node”

Depending on the number of nodes in your old farm; at some point you will want to send traffic to the new and updated farm. This is where the load balancer holds the key; when you have upgraded a “sufficient” number of nodes to handle the traffic, this is when you add the updated node(s) to your load balanced service, and removing the other(s).

That aside; during my patching session I realized that my current farm certificate would soon expire – so I would simply enroll for a new web certificate from my domain CA. This is where I made my first mistake; when requesting an OWAS farm certificate, remember to get your farm FQDN both in the certificate subject name as well as in the certicate subject alternate names (SAN) field. Also; remember to add all of the nodes’ FQDN’s (e.g. webapp01.contoso.local etc.) to the SAN fields. Without these, the farm will still work and serve traffic destined to the farm – because it will always be destined for  “webapps.contoso.com”. Nevertheless; the farm health watchdog service will keep complaining that the machine is “Unhealthy”. The most likely reason for this will show up in Event Viewer as “Could not establish trust relationship for the SSL/TLS secure channel“. What this basically means is that name of the actual node is missing from the certificate SAN and as such the server cannot even create an SSL connection with itself, which is what the health watchdogs are actually doing.

To remediate this, simply enroll for another certificate that contains both the farm FQDN as well as all farm nodes FQDN in the subject alternate names fields. And then, there’s still another lesson learned: After I had aquired the new certificate and deployed it to all nodes in the farm I just ran the cmdlet
Set-OfficeWebAppsFarm -CertificateName “NewCertFriendlyName”

After this, all nodes in the farm have to be rebooted to take effect. But, it still seems that only the master node will effectively make use of the new certificate – reporting a “Healthy” status. Even though the cmdlet Get-OfficeWebAppsFarm will report the new certificate being used, try this simple test; using your browser, navigate to https://nodeFQDN/hosting/discovery/ for each node and see whether the certificate being presented is actually trusted – if it is not, then it is most likely still using the old certificate not containing all the SAN fields.

To fix this all you have to do is removing each node (beside the master/first node, which will likely work) from the farm using cmdlet Remove-OfficeWebAppsMachine. Then add it back in once more using the previous cmdlet:
New-OfficeWebAppsMachine -MachineToJoin “name-of-first-updated-node”

Remember to give the node some time to report it’s new status, as it is only being updated during the scheduled watchdog runs every 3-4 minutes or so.

 

 

Persistent Group Chat appears broken after udate

After updating the Skype for Business Persistent Group Chat server I noticed that the Skype client would give me an error message:

Old messages would not load, and trying to enter new ones would simply time out.

Suspecting a back-end connection error (not able to retrieve messages from DB) I ran the Test-CsDatabase -DatabaseType PersistentChat cmdlet, but it completed with success.

Looking into Event Viewer on the Persistent Chat server showed no errors.

A quick search online gave few results, but this blog post had some similarities. Going with the suggestion that this might simply be client related I restarted the client- and voilá, it started working again! The client had been running during server update and probably just needed a kick in the “behind”.

 

Speeding up Invoke-CsComputerFailover

As of Skype for Business server 2015 there is a new cmdlet for the update process if you are running a 3+ server pool, named Invoke-CsComputerFailover, which differs from previous versions. This cmdlet makes sure all services are drained before they are stopped, much like the older cmdlet Stop-CsWindowsService -Graceful. But where the Stop-cmdlet actually would time out if a service would’t drain, say an ongoing conference was hosted on the server, the new cmdlet will keep on forever (or at least an hour, by default).

But what if you are on a clock, maybe a maintenance window closing in?

Latest Skype for Business iOS client is not “foreign friendly” [LOCID]

I just got a new iPhone 6s and upon activating it I noticed the (Skype for) “Business” app being updated (v6.0.1447, released October 22nd).

When I logged in to Skype on the phone I noticed the UI being quite “funny”.

At first I thought that the “LOCID” had some reference to my account being “local” or on-premise (not Office365). But even after logging in several status tags also had text like “LOC ID unavailable” or “LOC ID missed call”. I realized that this had to be reflecting some app code tag where my locale / location (language) settings were not being recognized by the app. So I tried to change the language settings to English.

And voilá! Seems like “Norwegian Bokmål” isn’t Microsoft’s preferred language after all, even though it is listed as one of the supported ones in App Store.

I don’t know if there are other foreign languages (non-English) that are affected by this, and I expect the bug to be fixed shortly. A funny one, though!