A Horizon deployment is always full of the biggest challenges of all: applications. Be it custom designed web applications, or just your standard office applications, there's always some trouble on the horizon (pun intended). The joy of the work does come from solving those pesky, nagging, time consuming problems. In this post, i'd like to share an example of such a nice little issue we had with Skype for Business.
The concerning environment is a Horizon deployment based on Server 2016 RDS, including Office 2016, and ofcourse Skype for Business. With this last application, we hit a bit of a snag. The application itself started fine, but the Meet Now function, as well as trying to schedule a skype meeting through the Outlook agenda plugin, both failed miserably:
Now how would we troubleshoot this? The error itself was sorely unhelpful, as ofcourse Skype for Business was running at the time of testing this functionality. The previous user environment, using the same SFB backend, was still operating without any issues, with the same software, so this would mean that there was a problem with the new setup. But what? As most descent application do, Skype has a log file in which all activity is kept for reference. The default location is found in the concerning user's appdata directory:
C:\Users\%username%\AppData\Local\Microsoft\Office\16.0\Lync\Tracing\Lync-UccApi-0.UccApilog
The logfile logs quite a bit of information and can be hard to look at without proper tooling. To make it easier for you to find information in logfiles like this, get yourself something else than the default windows notepad. Notepad++ is a very nice application for this use case. The latest version can be found here:
In the logfile, I could discern two things from the moment of trying to start the meeting:
WARN :: GenerateSecureRandomBytes - Could not acquire a cryptographic server handle 80090024
and the final result:
ERROR :: HRESULT API failed: 80004005 = hr
The final error is quite a generic error code and doesn't tell us much about what's going on, only that something has gone wrong and the proces was stopped. Not very helpful. The other error code however was more informational. After some searching, it looked like it has something to do with a personal certificate that could not be generated for some reason. We tried, just to make sure, to reinstall the entire office suite followed by a recompose, but the situation stayed exactly the same.
After some more searching, I came across a post that had the same error code, but in a different situation. The person mentioned a difference in the situation when using a roaming profile as opposed to a mandatory profile. /insert "Light bulb"!!! Our newly built environment used a mandatory profile, combined with VMware User Environment Manager. Soon enough it was clear, as I found this article in the VMware Knowledge base:
Be aware, this is a User policy setting, not an Computer policy setting. To help you not having to search for the specific setting, here's a screenshot:
And sure enough, after setting the concerning policy item and creating the default setting from the UEM Management Console (and a gpupdate /force on the concerning RDS servers)... no more error when using the Meet Now or Outlook Scheduling function.
Hope I have saved you some time figuring this one out!