After installing the WAC server following this or another guide, we also normally publish the WAC server through the same reverse proxy method as we do the other Lync web services – using the DNS name that we configured when we created the farm.
If you publish the WAC server this way without doing anything else it will work the same way for users on the internet as it does for the internal users and we might be content with that. But should we?
My colleague Marjus made this post a little while back on how to limit the access to the WAC services only to servers from your domain. If you don’t do this you’re basically publishing the WAC server as a public service that anyone can add to topology builder and use as the WAC server in their own Lync environment.
So, if you want to keep your WAC server for yourself, remember to add all domains where you host servers that should be able to use the WAC server to the allow list by using the New-OfficeWebAppsHost Cmdlet. The wildcard * is assumed on all domains in the allow list, so subdomains are supported automatically. You only need to add the server domain(s), not necessarily the same as the SIP domain(s).
New-OfficeWebAppsHost -Domain "contoso.com"
I just had a problem with powerpoint presentations in Lync 2013 that behaved strangly.
All internal users could share and view powerpoints as they should, but all external users and guests could not. It behaved the same way in Lync 2013 clients as in the web app. It would just show “connecting” or “Waiting for the presentation to begin” before failing with a message that the network had gone down or the server was busy. There were no errors logged on the WAC server and no failures recorded on the monitoring database. I could also reach the https://wacserver.contoso.com/hosting/discovery through the TMG rule. Really weird.
After a bit of googling I found a forum post on technet where someone referenced a setting on the HTTP filter called “Verify Normalization”. The setting is found on the “Traffic” tab on the rule, like this:
Unticking this box solved the issue.
The rule is explained here, but it is basically a security mechanism that blocks URLs containing % sign if they are double encoded in the URL, although they can end up blocking legitimate traffic as well which is the case here. I do not know if this is a bug in WAC/OWAS or if it is by design though. Removing “Verify Normalization” from the rule will solve the issue in any case.
The URL the clients were accessing looked something like this, and contains a lot of url encoded characters.