Being able to present a PowerPoint slide deck using Skype for Business or Lync 2013 always adds the wow factor to any demo I have done. It is quite hard to not be impressed. Microsoft have made the Skype for Business meeting experience to feel like everything is exactly where is should be. Using an Office Web Apps Server with Skype for Business, it is possible for PowerPoint slides to be presented in web conferences to their full extent.
Despite the announcement from Microsoft of the end-of-life for Forefront Threat Management Gateway (TMG) 2010, I am finding it is still in wide use and is supported until 2020.
Taking over support for a client, an issue that had been presented when an external Skype for Business user shared a PowerPoint Slide deck, immediately was reported. Symptoms were that it appeared to be copying the slide deck up as normal, displayed a blank slide deck, and then presented the client with an error:
Either the network connection has been lost or the server is busy. Please check your network connection.
Clicking the complimentary Retry button did not resolve.
The internal Skype for Business users were connecting OK to the Office Web Apps Server and displaying the PowerPoint slide decks, which led me to check logs on the Forefront TMG 2010 server as in this instance, was being used.
So in the screenshot above, we have the connection being denied by TMG, as suspected.
As the TMG rule wasn’t created by my own hands for the Office Web App Server traffic, confirmation of the rule was need to ensure it was configured as it should have been.
The TechNet article, for reference, that has the web publishing rule for TMG to allow remote users to access the Office Web App Server and have access to PowerPoint presentation is here
The error was clear when checking the HTTP policy
This check box “Verify normalization” should have been un-checked and wasn’t!
With this removed and the new settings applied in TMG, within a couple of minutes, external users could present and view PowerPoint presentations.
Going back to the error in TMG, I wanted to see why this was being caused.
The TMG error was as follows:
Blocked by the HTTP Security filter: URL normalization was not complete after one pass
TechNet mentioned this statement regarding the setting Verify normalization:
Select Verify normalization to block requests with URLs containing escaped characters after normalization. Web servers receive requests that are URL encoded. This means that certain characters may be replaced with a percent sign (%) followed by a particular number. For example, %20 corresponds to a space, so a request for http://myserver/My%20Dir/My%20File.htm is the same as a request for http://myserver/My Dir/My File.htm. Normalization is the process of decoding URL-encoded requests. Because the % can be URL encoded, an attacker can submit a carefully crafted request to a server that is basically double-encoded. If this occurs, Internet Information Services (IIS) may accept a request that it would otherwise reject as not valid. When you select Verify Normalization, the HTTP filter normalizes the URL two times. If the URL after the first normalization is different from the URL after the second normalization, the filter rejects the request. This prevents attacks that rely on double-encoded requests. Note that while we recommend that you use the Verify Normalization function, it may also block legitimate requests that contain a %.
In a nutshell my interpretation is that TMG will block URLs containing escaped characters after normalization with this option selected and this is what is happening as seen in the TMG error. When this check is removed, the traffic is passed on.
All the best!