Making Office Web Apps Server private

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 ""

Powerpoint presentations not working externally

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 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:

Verify Normalization

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.<fs=FULLSCREEN&><rec=RECORDING&><thm=THEME_ID&><ui=UI_LLCC&><rs=DC_LLCC&&gt

Handling SimpleURLs and Reverse Proxy during migration

I’ve thought about writing this post for a while, as the topic isn’t really covered very well in the Lync 2013 migration documentation. The issue is also only relevant when migrating from Lync 2010 to Lync 2013.

The scenario is this: You are doing a migration from Lync 2010 to Lync 2013. You are following the migration steps provided in the migration documentation, and have planned and prepared your migration, deployed a pilot pool and moved some pilot users to Lync 2013. Internally everything is working as it should,  all modalities are working and conferencing works via the meeting join page using simple urls regardless of which server the user is on.

Now, most of the deployments I do are not large enough that it is needed to use more than one FE pool and for external access one Edge pool and one reverse Proxy. Because of this, most of the conferencing going on is involving external participants. This means that modalities and meeting join needs to be working for the pilots in external scenarios as well. The next step in the migration documentation covers some of this with the deployment of the Edge server. This will handle the peer to peer modalities, but what about the simple URLs?

If you try to reuse the existing reverse proxy rules, you will end up in one of these situations:

  1. You keep the rule as it is, pointing toward the Lync 2010 pool
    If you do this, simple URLs and meeting join will continue working for meetings created by the Lync 2010 users. But if someone external tries to join a meeting created by one of the pilot Lync 2013 users, they will be met with a page saying “Sorry, something went wrong, and we can’t get you into the meeting.” and if you click on “more info” you will get en error saying “Error:Invalid Conference organizer or Conference ID” like this:
    The Lync 2013 pilot users will also not be able to log in via the mobile client.
  2. You change the rule, pointing it toward the new Lync 2013 pool
    If you do this, everyting will work as it should for the Lync 2013 users. But if someone tries to join a meeting created by one of the Lync 2010 users, they will be met with an ordinary IIS “404 not found” page

Both of these solutions are not really wanted in a normal migration, so what do we do then? The solution is to handle it as a normal multiple pool deployment. This is as it turns out not really well documented in the TechNet library, but on the Request and Configure a Certificate for Your Reverse HTTP Proxy page there is a note saying this:

If your internal deployment consists of more than one Standard Edition server or Front End pool, you must configure web publishing rules for each external web farm FQDN and you will either need a certificate and web listener for each, or you must obtain a certificate whose subject alternative name contains the names used by all of the pools, assign it to a web listener, and share it among multiple web publishing rules.

This means that you will need to deploy a new reverse proxy publishing rule for the new Lync 2013 Pool with a different DNS name for the external services. The rule will also need to use a certificate that contains all the simple URL names in addition to the new name for the external web services and lyncdiscover. This will in most cases create a need for a new public certificate for this new rule.

By doing this Lync is able to redirect the traffic to the webservices between the reverse proxy rules as it does on the inside, and all functionality should be available for both existing Lync 2010 users and the Lync 2013 pilot users.