Lync External Web Services without Reverse Proxy

PLEASE NOTE:  While the procedures below will work, it is HIGHLY recommended to employ a reverse-proxy solution.  Opening up an internal domain-joined computer to the Internet can be a recipe for disaster. I myself, have only done this procedure once, and have since made a reverse-proxy pretty much mandatory for customers looking for help from me.  Not only that, but I've heard from some that the mobility features do not work using the alternate IP method.  If you find yourself in that situation, please be aware that Microsoft (and any consulting company worth their salt) WILL NOT support this method.  Also, this is not a substitute for deploying an edge server.  If you want external connectivity to work, you MUST deploy an edge server.  There is no other way, supported or not.  Caveat emptor.

And now on with the show....

While working on a Lync deployment for a small customer, it came up during the planning stages that they didn't have a reverse proxy server (like ISA/TMG) to publish the Meet/Dialin simple URLs and web components URL, nor were they planning to. In the past, I had tried to make OCS work without a reverse proxy, but some things just didn't work right. After advising them about the risks involved with opening up an internal domain-joined computer to the Internet, I told them I would try to make Lync work without a reverse proxy, but cautioned that it may not work.

Lync Enterprise Voice Best Practices - Usages and Routes

Over the past while, I've typed some lengthy posts about the importance of E.164 phone number formatting and my take on normalization best practices. Now to pull it all together for the final act, I'll be talking about Lync PSTN usages and routes.

When you look at the Voice Routing section of the Lync Control Panel, you'll see the following "tabs": Dial Plan, Voice Policy, Route, PSTN Usage, Trunk Configuration and Test Voice Routing:

From this section, you can manage most aspects of your Enterprise Voice deployment.

Lync Enterprise Voice Best Practices - Normalization

In my last post, I talked about the importance of using E.164 in your internal Active Directory phone list. Assuming you've got that all straightened out, what's next?  Since users won't always be dialing the wonderfully consistent numbers you've provided them in Active Directory, how do you handle all the different methods used for making calls?  You have to normalize them using normalization rules in Lync.

The end-goal for normalization rules is to ensure you pass a properly formatted E.164 phone number to the appropriate gateway, no matter what the user tries to enter. Call routing and additional number manipulation is much easier when you know you're going to be getting a standard format.

You need to think about the ways users typically dial their numbers. Are they used to excluding the 1 for local calls?  Do they dial 7-digit local numbers without the area code for their specific location?  Do they dial internal extensions?  What do they have to dial to make an international call?

You also have to think about how any PBX you might have in your environment sends numbers to Lync?  Is it capable of sending full E.164 formatted phone numbers, or can it only send extensions?

When you have all the answers to those questions, you can start building normalization rules. Normalization rules are built using regular expressions. If you're not familiar with regular expressions, a good place to learn about them is from regular-expressions.info. Thankfully, the Lync Control Panel has a wizard that handles most typical scenarios. You'll only need to understand regular expressions for more advanced needs.