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
- Simply enabling the add-in (works for the current session, not after Outlook restart)
- Repair the Office installation
- 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:
- Run Outlook as administrator (no need to set up a new account/mailbox if your logged-in user is not local admin)
- Navigate to File -> Options -> Add-Ins -> COM Add-ins. Now simply remove the Skype Meeting Add-in from the list.
- 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
- Now close Outlook and restart in your regular user context.
Add-in should be available again.
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. Continue reading
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.
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.
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.
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”.
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?