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.