Lync 2013 Office Web Apps Server Farm

<Revised 8 Feb 2013>

As Lync 2013 becomes more of a reality to many of us, we must address what is, in my opinion, the biggest change to Web Conferencing:  the requirement for Office Web Apps Server (WAS).  Microsoft has addressed a few display/usability issues in Web Conferencing with the inclusion of  WAS.  WAS is now the PowerPoint presentation rendering engine for Web Conferencing.  You can deploy your pool without it, but your Web Conferences will not do PowerPoint presentations.  Because PowerPoint presentations are a big part of most formal presentations, we need to deploy WAS as part of the pool.  Here are a couple of caveats:

• WAS must be on its’ own server (thank the powers for virtualization, eh?).
• The WAS server cannot have had any office product installed on it, ever.  Do yourself a favor and just make up a new server (see previous comment on virtualization).
• If you want WAS to be highly available, you WILL NEED load balancing in the hardware variety, and this will require HLB w/SSL offloading.

<according to this new documentation on TechNet the comment for requiring SSL offloading appears to have been removed – this may be good news>

• Licensing for this new component is a bit up in the air – once I find out what the final story is going to be, I will update this article.

<As I understand it, using WAS for READONLY does not require a license.  See this, and more importantly, this.  The second link states that “…view-only.  By default, Office Web Apps is view-only.  View-only functionality is provided for free…”  Excellent!  That is all we need for Lync 2013.>

• WAS can be used for Exchange 2013 and SharePoint 2013, so one WAS farm could be used for more than one service.
• WAS is also the rendering engine for external users, so you will need to plan some additional IP and DNS resources.  And don’t forget how you are going to provide Reverse Proxy services because that is the route the external user is going to take to get the PowerPoint content.  Luckily, the client(s) will get the proper URL's via in-band provisioning, so access should be automagic from the user point of view.
• If you are planning a Lync 2010 upwards migration into 2013, then your existing reverse proxy web listener certificate is going to need to have another SAN entry to handle the external WAS traffic.  Alternatively, you can gin up another external, public IP and create a new conduit just for this WAS traffic.

WAS Install Official Instructions

Documentation for this process is NOT contained on the Lync 2013 online help, but rather in the Office Web Apps and SharePoint sites.  Take a look here.  What I found was a fair amount of back-and-forth comparing steps and whatnot, hence this guide which will (hopefully) bring it all into one place.

At any rate, what I am going to show is how to build a WAS farm, complete with HLB.  The tools we are going to use are:  Topology Builder, PowerShell, a squeaky clean set of Windows Server 2012 hosts, an internal PKI CA, and an HLB.  For HLB, I am using my Kemp VLM-100.  Reverse Proxy will be TMG.

A note on the TMG as reverse proxy.  I am making a whole new DNS and IP for this service.  As such, I am going to export the certificate for my LSWASPoolInt which has LSWASPoolExt.tsoorad.net as one of the SAN’s and place it on the web listener.  For a real deployment, I would conserve IP space and just use the existing Lync web listener and add the LSWASPoolext FQDN to the certificate for that listener.  This will require you to plan your external Lync DNS space in advance, along with the IP space.  But you already knew that, right?  DNS and IP planning is crucial to Lync success – this is just another example of that concept.

This is going to have more than a few steps to it, so let’s dive in.

First off, when dealing with WAS, *ALL* WAS related commands are PowerShell.  Here is a handy guide.  Second, and I have not yet figured out how to turn it down, WAS logs a ton of stuff in the event log.  As in 200k entries in one week!!  But, I digress.

If we go along with the official documentation, you are going to need to get into your Lync 2013 deployment plans and define your IP and FQDN requirements because the official documentation says you are supposed to do the HLB setup first.  OK. Here is my WAS setup:

lswaspoolint.tsoorad.net (my internal FQDN for the WAS farm): 1.1.1.45

lswaspoolext.tsoorad.net (my external FQDN for the WAS farm): 10.10.10.58

LS2013WAS1.tsoorad.net: 1.1.1.46

LS2013WAS2.tsoorad.net: 1.1.1.47

WAS Farm HLB

For my load balancer, I decided to just bring all traffic for the WAS straight to the HLB.  So the HLB in my case will only have 1 virtual server and I will bring internal and reverse proxy traffic to 1.1.1.45.

Here is the topology builder viewpoint.

Here is the Kemp HLB virtual server setup.  Note that it is marked as DOWN because we have not yet installed anything!

While you are at it, now would be a good time to envision your external and internal access paths.  Here are the firewall considerations. Ensure that the following ports are not blocked by firewalls on either the server that runs Office Web Apps Server or the load balancer:

• Port 443 for HTTPS traffic
• Port 80 for HTTP traffic
• Port 809 for private traffic between the servers that run Office Web Apps Server (if you’re setting up a multi-server farm)

Host Server Setup

1. Prep your servers.  I used VM’s with 1 CPU core, 1 GB RAM, and 50GB drive space.  YMMV.
2. Install WAS prerequisites appropriate to your host server operating system.

For Server 2008 R2, install the following software:

• Windows Server 2008 R2 Service Pack 1
• .NET Framework 4.5
• Windows PowerShell 3.0
• KB2592525

Next, open the Windows PowerShell prompt as an administrator and run the following example commands to install the required roles and services.  You may find it helpful to set the execution policy in PowerShell to remotesigned or unrestricted.

Import-Module ServerManager

And then run the follow example command:

Add-WindowsFeature Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,Web-Security,Web-Windows-Auth,Web-Filtering,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Console,Ink-Handwriting,IH-Ink-Support –restart

I always tack on the “-restart” so if servermanager wants to reboot it will without asking.

For Server 2012 - Server 2012 already has what it needs so you just need to do the following:

Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices,NET-Framework-Features, NET-Framework-Core, NET-HTTP-Activation, NET-Non-HTTP-Activ, NET-WCF-HTTP-Activation45 -restart

Run windows update to get patched.  Your call on this step, but I always do it just to claim due diligence.

Get a PKI certificate that will be trusted by all players.  I used my DigiCert.com utility to generate the CSR – I wanted to include the internal and external URL’s which means I needed a SAN entry or three.  In my case, I used the following:

CN= LSWASPoolint.tsoorad.net

DNS Name=LSWASPoolint.tsoorad.net
DNS Name=LSWASPoolext.tsoorad.net
DNS Name=LS2013WAS1.tsoorad.net
DNS Name=LS2013WAS2.tsoorad.net

This certificate needs to be on each member server and also the HLB to support the SSL Offloading that is required for a WAS farm.  I am not absolutely sure that the certificate actually needs to be on the farm member servers, but in the interest of simplicity and for future single server farm use, I put it on each – remember that you need to generate the certificate on just one server, then export it for use on the other server and the HLB. 

WAS Install

Finally, we are ready to actually install Office Web Apps Server.  You can get the Office Web Apps server install from here.  There is not a lot to note on this install… I just banged through all the defaults.  However, I will note that I needed to execute the setup.exe as an Administrator to get it to run through properly. 

Once you have your WAS installed, now is a good time to remember that there is NO GUI – this thing is PowerShell only.

Now, the point to this article is to create a WAS farm; but so far, we have not done anything that can’t be used for a single server farm.  So here is the command to run on your first server if you want to create just a single server farm.  Note that there is a dependency on the certificate friendly name.

OK, from a PowerShell prompt:

New-OfficeWebAppsFarm -InternalURL "https://lswaspoolint.tsoorad.net" –ExternalURL “https://lswaspoolext.tsoorad.net” -CertificateName "FRIENDLYNAME"

If you are doing a two server farm, here is what you need.  I ran the first command on ls2013was1.tsoorad.net; this affects the syntax on the second server command!

On the first server:

New-OfficeWebAppsFarm -InternalURL "https://lswaspoolint.tsoorad.net" –ExternalURL “https://lswaspoolext.tsoorad.net” –ssloffloaded

Note that the “–ssloffloaded” is different – which implies that the certificate is not needed.

Then, on the second server:

New-OfficeWebAppsMachine –MachineToJoin ls2013WAS1.tsoorad.net

Let’s take a look at our new farm.  Note the AllowHTTP, SSLOffloaded, and Machines attributes.

Also note that now the HLB is showing the farm as “up”…

To further test that we have a viable WAS farm, we will hit the following URL in a browser:  https://lswaspoolint.tsoorad.net/hosting/discovery/.  The actual response is a good deal longer than the screen cap I am showing…of course you will want to test your HLB to ensure that each server is actually responding.

Reverse Proxy Setup

Alright, now to configure TMG as our reverse proxy so external users can enjoy the WAS goodness too.

First, get the WAS pool external URL SSL cert installed onto the TMG.  In this case, I am going to use my internally generated certificate; in real life, you will need to have a certificate that is trusted by any and all users – typically that means a public certificate.

Next, if you have a unique IP address for your external services, create a new listener with a new cert just for your WAS pool external URL.  If you are using URL redirects via TMG Website Publishing rule, then you will need to add the WAS pool external URL to the cert you have and re-work your listener just a tad. 

I am using the same listener with a revised certificate.  So, what we need now is a just a new TMG Website Publishing rule that takes the URL “lswaspoolext.tsoorad.net” and send it to our WAS VS on 1.1.1.45:443. Here is a link to the official document for completing this task.  Note that these instructions assume you are going to be making a new web listener – you may have to do a little judicious reading between the lines to accomplish this task for your environment.

Also, note that my rule in TMG did not test “good” but it works “good.” The sharp-eyed reader will also note that my current login does not trust the lab domain CA – hence the certificate error showing here.

Summary

• Office Web Apps Server (WAS) is a required element of Lync 2013.
  
• WAS setup is PowerShell only.
  
• The prerequisite setup is different from Server 2008 R2 to Server 2012.
  
• A WAS farm is one or more servers.  A single server needs to be HTTPS.  A two (or more) server farm is SSL offloaded to a hardware load balancer.  WNLB is not a supported option.
  
• Understand and plan your DNS and IP space before starting.
  
• Reverse Proxy (or something) is strongly suggested to separate the outside world from your WAS farm.  You will need to have a DNS setup to support external access along with certificates that past the public trust test.
  
• Overall process:
  
  
  
  • Lync Topology Builder
    
  • HLB setup
    
  • Server Prep
    
  • WAS Install
    
  • TMG (or some other reverse proxy solution)

As always, YMMV.

Lync 2013 Client Login using LyncDiscover and LyncDiscoverInternal

Perhaps you may not know, but the Lync 2013 client no longer defaults to discovering _sipinternaltls._tcp.domain.com, _sip._tls.domain.com, sip.domain.com, sipinternal.domain.com, or sipexternal.domain.com for automatic login.  What we have now is a default preference for LyncDiscover.domain.com or LyncDiscoverInternal.domain.com.  Should it not find one of those records, Lync 2013 will then start working down the SRV chain, followed by default A records such as SIP.domain.com.  This is different from the default Lync 2010 client behavior, where the client looks for the SRV record first, followed by hardcoded SIP record lookups.  To see the PUBLISHED (as of 30 Oct 2012) Lync 2013 client behavior, reference this link here; to see the published Lync 2010 client behavior, see this link.

LyncDiscover and LyncDiscoverInternal came about when Lync 2010 Mobility arrived to support Lync on mobile devices.  LyncDiscover.domain.com and LyncDiscoverInternal.domain.com are A records for which the Lync Mobility client searches to find the Lync Autodiscover service. Once it finds the Lync Discover service, the client is provided with login resources such as sipserver and href to external web services.

So what’s the Big Deal?

The Big Deal is that if you deploy mobility, you need to have those two records – LyncDiscover.domain.com (for external access) and LyncDiscoverInternal.domain.com (for internal wireless access).  And now that you have those two records, the Lync 2013 client is using them also – and if it finds them, it is reading the sipserver attribute directly and auto-configuring based off of that. 

There are implications to the Lync 2013 client resolving lyncdiscover and lyncdiscoverinternal before resolving SRV records.  If you have a mixed client environment, you COULD have 2013 clients that login correctly and 2010 clients that do not, and if you assume that both discover login sources in the same manner, you would be wrong!  Which could lead to many trips around the troubleshooting circuit.

2010 Client Login Sequence

So, let’s take a look at a 2010 Client login, and see how it looks up where to go.   Here is a segment of a 2010 communicator-uccapi-0.uccapilog file (for the purposes of this test, I forced all my DNS lookups to fail).  First, the client looks for the SRV records:

INFO  :: domainName:tsoorad.com: serviceName:sipinternaltls: transportName:tcp:
:: domainName:tsoorad.com: serviceName:sip: transportName:tls:
:: QueryDNSSrv - DNS Name[_sipinternaltls._tcp.tsoorad.com]
:: QueryDNSSrv GetDnsResults query: _sipinternaltls._tcp.tsoorad.com failed 8007232b
:: DNS_RESOLUTION_WORKITEM::ProcessWorkItem ResolveHostName failed 8007232b
:: QueryDNSSrv - DNS Name[_sip._tls.tsoorad.com]
:: CUccDnsQuery::UpdateLookup - error code=80ee0066, index=0
:: CUccDnsQuery::CompleteLookup - index=0
:: QueryDNSSrv GetDnsResults query: _sip._tls.tsoorad.com failed 8007232b

…then it proceeds to look for the SIP.domain.com, sipinternal.domain.com, and sipexternal.domain.com A records…

ResolveHostName - getaddrinfo failed for sip.tsoorad.com
ResolveHostNameUsingGetAddrInfo - getaddrinfo(sipinternal.tsoorad.com) failed
ResolveHostNameUsingGetAddrInfo - getaddrinfo(sipexternal.tsoorad.com) failed

Pretty straightforward and inline with the aforementioned documentation from Microsoft.

2013 Client Login Sequence

Here is a Lync 2013 client, trying the same process, same user account, same domain.  Note that the DNS query looks pretty much the same. 

In the interest of total disclosure, the Lync 2013 uccapilog file is different, and has a new section in it that summarizes activity for login, so I cut up the first section so that we can see like-to-like comparison.

:: QueryDNSSrv - DNS Name[_sipinternaltls._tcp.tsoorad.com]
:: QueryDNSSrv GetDnsResults query: _sipinternaltls._tcp.tsoorad.com failed 8007232b
:: DNS_RESOLUTION_WORKITEM::ProcessWorkItem ResolveHostName failed 8007232b
:: CUccDnsQuery::UpdateLookup - error code=80ee0066, index=0
:: CUccDnsQuery::CompleteLookup - index=0
:: QueryDNSSrv - DNS Name[_sip._tls.tsoorad.com]
:: QueryDNSSrv GetDnsResults query: _sip._tls.tsoorad.com failed 8007232b
:: DNS_RESOLUTION_WORKITEM::ProcessWorkItem ResolveHostName failed 8007232b
:: CUccDnsQuery::UpdateLookup - error code=80ee0066, index=1
:: CUccDnsQuery::CompleteLookup - index=1
:: Function: CUccServerEndpoint::OnDnsQueryCompleted

…and the 2013 client proceeds to try to find the SIP.domain.com, sipinternal.domain.com,  and sipexternal.domain.com records also…

ResolveHostNameUsingGetAddrInfo - getaddrinfo(sipinternal.tsoorad.com) failed ResolveHostNameUsingGetAddrInfo - getaddrinfo(sip.tsoorad.com) failed ResolveHostNameUsingGetAddrInfo - getaddrinfo(sipexternal.tsoorad.com) failed

And now, here is the Lync 2013 client logging in, but this time it found a LyncDiscover record and the Lync Autodiscover service to use.  Vastly different.  It never looked for the SRV or A Records at all.  It simply announces that it connected to a server.

TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete[0F50DFC0] Entered host Lync15Edge.tsoorad.com
TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete get DNS result server: Lync15Edge.tsoorad.com IP: 10.10.10.61:443
TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete get DNS result server: Lync15Edge.tsoorad.com IP: 10.10.10.61:443
INFO  :: Use proxy server cache:1
INFO  :: Remote Addr: 10.10.10.61
INFO  :: Verification Flags: 1
INFO  :: Interface Index: 12
INFO  :: Interface Type: 0
INFO  :: GetAdaptersAddresses Succeeded.
INFO  :: Identified local Ipv4 address: 10.10.10.104
INFO  :: Found local routable Ipv4 address for SIP proxy server from proxy address list
INFO  :: SockMgr: Create New Connection:DestName:(Lync15Edge.tsoorad.com)DestPort:(443)Transport:(2)httpTunnel:(0)TLS RemotePrincipalName:(Lync15Edge.tsoorad.com)
TRACE :: DestAddr :10.10.10.61:443

See what I mean?  Blammo, straight to the (in my case) edge server!  And here is the fancy new section in the uccapilog file… notice that is shows NOTHING in the way of SRV records or A records like it did before. The conclusion I reach is that it never looked for them after it found the Lync autodiscover (This has been confirmed by contacts within Microsoft).

<!DOCTYPE ProgressReport>

<root>

  <Login><![CDATA[Created DefaultCredential: CManagedCredential[DEFAULT this=0A80D210]]]><![CDATA[Adding new managed cred CManagedCredential[DEFAULT this=0A80D210]]]><![CDATA[GetBestManagedCredentialByType return the cred: 00000000, type:specific, userId:PHO]]><![CDATA[Certificate 0x0FA300A0:
UPN:
Subject: lync15testuser@tsoorad.com
Issuer: Communications Server
Serial number: 08ca2c4e949cc0c9dcc7
Valid from: Wednesday, October 24, 2012 14:46:44
Valid to: Monday, April 22, 2013 14:46:44
]]><![CDATA[Created CManagedCredential[CERT this=0A80E180, PCERT_CONTEXT=0FA300A0]]]><![CDATA[Adding new managed cred CManagedCredential[CERT this=0A80E180, PCERT_CONTEXT=0FA300A0]]]><![CDATA[GetBestManagedCredentialByType found a matching cred: 0A80E180, type:certificate, userId:OCS]]><![CDATA[Bootstrap task queued]]><![CDATA[Starting bootstrap task: baseUrl=, pinBased=0, forceDownloadRootCert=0, deviceId=F87F107C-13E9-531A-8FC9-AA148ABE1C3A, credType=0, cert=0FA300A0]]><![CDATA[Changed CBootstrapper status [10000] -> [10000]]]><![CDATA[Bootstrap task completed with hr=0x1]]><![CDATA[GetBestManagedCredentialByType return the cred: 0A80D210, type:default, userId:CER]]><![CDATA[GetBestManagedCredentialByType found a matching cred: 0A80E180, type:certificate, userId:OCS]]><![CDATA[Created CManagedCredential[CERT this=0A80E250, PCERT_CONTEXT=0FA300A0]]]><![CDATA[Adding new managed cred CManagedCredential[CERT this=0A80E250, PCERT_CONTEXT=0FA300A0]]]><![CDATA[Changed CBootstrapper status [10000] -> [10006]]]><Lync-autodiscovery><![CDATA[GetBestManagedCredentialByType return the cred: 00000000, type:specific, userId:LAD]]><![CDATA[Discovery request sent to URL http://lyncdiscoverinternal.tsoorad.com?sipuri=lync15testuser@tsoorad.com, txn (0F6BE5F0)]]><![CDATA[GetBestManagedCredentialByType return the cred: 00000000, type:specific, userId:LAD]]><![CDATA[Discovery request sent to URL https://lyncdiscoverinternal.tsoorad.com?sipuri=lync15testuser@tsoorad.com, txn (0F6C2708)]]><![CDATA[GetBestManagedCredentialByType return the cred: 00000000, type:specific, userId:LAD]]><![CDATA[Discovery request sent to URL https://lyncdiscover.tsoorad.com?sipuri=lync15testuser@tsoorad.com, txn (0F6C2720)]]><![CDATA[GetBestManagedCredentialByType return the cred: 00000000, type:specific, userId:LAD]]><![CDATA[Discovery request sent to URL http://lyncdiscover.tsoorad.com?sipuri=lync15testuser@tsoorad.com, txn (0F6C2738)]]><![CDATA[

Clearly, the Lync 2013 client is using both LyncDiscover and LyncDiscoverInternal for automatic connections.  While the 2013 client can use the traditional methods, it appears to look for the autodiscover records first and if it cannot find them, then it falls back to the previous versions’ methodology.

Is there any downside to NOT defining LyncDiscover/LyncDiscoverInternal?

Not for the Lync 2013 client – but not doing so will negate the ability of the Lync Mobility client to perform automatic logins.  Having just the LyncDiscoverInternal and LyncDiscover records will result in Lync 2010 (and lower) clients that cannot perform auto-login.  The take-away for me? Yet another enforcement of the lesson “get your name space and DNS figured out before you begin.”

Summary

With Lync 2013, the client has a new (improved?!) automatic login search mechanism that demonstrates as preference to LyncDiscover.domain.com and LyncDiscoverInternal.domain.com.  Support for N-1 Lync client environments will still need to configure DNS SRV and A records to support the down-level automatic logins.

Lync Basic 2013 Client

Lync Basic 2013 downloads

This client essentially maps directly to a Lync 2013 Standard Client Access License.  English only.  Localized (read modified for other languages) releases will be coming in November.

32 Bit - http://www.microsoft.com/en-us/download/details.aspx?id=35451

64 Bit - http://www.microsoft.com/en-us/download/details.aspx?id=35450

Details:

Lync Basic 2013 provides all the basic functionality that’s available in the full version of Lync (Lync 2013). However, if you want to use any of the following features, talk to your workplace technical support about upgrading to Lync 2013:

• Advanced call features (not available with all Office 365 subscriptions); advanced call features include team ring, call forwarding, simultaneous ring, voice mail, call park, call delegation, response groups, and remote call control
• Calendar delegation
• Gallery video view
• OneNote sharing
• Recording
• Skill search (not available with Office 365)
• Virtual Desktop Infrastructure (VDI) (not available with Office 365)

YMMV

Lync Server DNS Pinpoint zones

Edited 10.29.2012 1535 PST – thanks to Jeremy!

Scenario

I recently did a project where the client wanted to use their email address domain for their SIP domain – fairly common – but they did not have an internal DNS zone for that domain.  Their internal AD structure was domain.local – not something we can publish for external or federation access.  Furthermore, the client did not want to establish split-DNS – which is the common solution for this type of environment.  But, the client also wanted external users, mobility, and federation. 

What the client was doing was using an external DNS provider to resolve their SMTP domain lookups.  When the external name resolution directed an internal client to an external IP that was NAT to an internal resource, the firewall did an automagic redirect to the proper internal target.

Clearly, this will not work for Lync – even if mobility needs to always achieve the same connection regardless of location, using the firewall to execute fancy footwork won’t work due to how an Edge server works, or how TMG works.  TMG would see those packets as spoofed and simply drop them.  Edge will work, after a fashion, but when the client starts connecting internally and externally at the same time, the combination is guaranteed to produce inconsistent user experience and outright failures.

Remember that Lync 2010 does an automatic lookup for _sipinternaltls._tcp.<domain.name> where <domain.name> is the SIP domain that provisioned for the user who is logging in with a SIP enabled AD account.  Therefore, in our test case, we want the Lync 2010 Client to find _sipinternaltls._tcp.domain.com.

What to do?

The answer is to create “pinpoint” DNS zones.  This type of DNS zone is a single record that is represented by the zone itself.  For instance, if you need/want to have SIP.domain.com, but you don’t want to have to double manage a lengthy list of A records in two places (split DNS) then you can create a pointpoint zone that looks like this:

When the client goes looking for SIP.domain.com, it can certainly find it, yes?  But name resolution for anything else in domain.com other than that specific name (SIP.domain.com) will need to go somewhere else for resolution.

Let’s take a look at how to create a pinpoint DNS zone record.

Start with your DNS Manager…Right-click the “Forward Lookup Zones” and choose “New Zone.”

Click NEXT in the “Welcome to the New Zone Wizard” and then choose Primary Zone.
 

Choose the Zone Replication Scope option that makes sense for your environment…

 

And then name your zone.  We want SIP.domain.com. I always only allow secure dynamic updates

 

Select Finish, and you have created the new zone.

After you get your new zone, you need to add a host record so your DNS server can reply to DNS queries with an IP address.  To do that, right-click your zone and choose “New Host (A or AAAA)…”  Leave the NAME blank, input the IP, and I always adjust internal A records downwards.  In this case, I used a five minute TTL because I am forever whipping my Lync lab into some different configuration and I want the client connection points to be updated quickly.

 

Voila!  Now we look like the first picture. 

Pretty slick.  But, perhaps you know that the Lync 2010 client looks for SRV records by default?  How to construct an SRV record using this pinpoint technique? 

Get yourself to a command prompt…You will have a seriously hard time doing this in the GUI as this action is not supported in the DNS Manager GUI.  See this reference.

and enter the following:

dnscmd . /zoneadd _sipinternaltls._tcp.domain.com. /dsprimary

(creates the actual pinpoint zone)

&

dnscmd . /recordadd _sipinternaltls._tcp.domain.com. @ SRV 0 0 5061 sip.domain.com

(adds the SRV record to that zone)

Here is the final client lookup flow. We resolve to an SRV record that the Lync 2010 client looks for (_sipinternaltls._tcp.domain.com) and pointed that to another pinpoint zone (sipinternal.domain.com) with the FE pool having a cert that included that name in the SAN.  We did this to get around the strict DNS naming issue that would have caused login issues  due to the difference between the FQDN (tsoorad.net) and the SIP domain name (domain.com).

Remember to add the SIP domain to the Lync Front End Server (or servers) as shown.

YMMV!

Lync Server 2010 DNSLB with Kemp HLB

One of the things that has always bugged me about blogs on “how to” is that most of them (mine included) are derived from lab environments – and while that is great, they don’t always show “real” life for a “real” environment.  Close, but not really.

I recently did a project with Lync Server 2010 where DNSLB was used internally.  And HLB, of course, was used for the web services – both internal and external access feed through the HLB.  Most of the examples you find out there in the blogosphere show DNSLB, or they show how to setup with all the load-balancing going through the HLB.  So, what I am going to demonstrate here is DNSLB for the Enterprise Pool, along with HLB for just the web services (internal and external) AND use a live environment.  I have redacted the actual domain name, and I changed the actual external IP.  But other than that, this is a working environment supporting all workloads.

Environment Notes

The environment has split-dns, and uses the same name internally as externally; that is, domain.net is the AD DS name as well as the SIP domain name internally and for remote access and federation purposes.

The final architecture was two Enterprise Edition FE, with a SQL cluster.  Only one Edge was used as the remote access/federation was not seen as business critical.  An Archiving/Monitoring server was deployed to support IM history and compliance.  A pair of Kemp VLM-100 appliances provide Load Balancing for the FE pool. All servers are virtual.

Internal DNS

Here is what the Internal DNS and IP layout looks like.  Note that two of the entries are actually pointing internal clients to the outside – specifically, internal wireless Lync clients need to be able to find and route to the external side of the Reverse Proxy.

 

External DNS

Hardware Load Balancer

The client chose to use a pair of Kemp load balancers.  They proved to be very easy to configure for High Availability.  Literally, mere minutes.  We used this document here for the configuration of the units into HA, and this document for the configuration of the load balancers for Lync.

Here is the main setup from member HA1.

If you read the documentation, you will be told to setup some miscellaneous options for the Layer 7 work…

Here is all you need to get a DNSLB pair of Lync Enterprise Edition pool with two members load balanced from the HLB perspective.

Each virtual server get’s these options:

and

The virtual server that handles the traffic from the reverse proxy (Lync external web services) needs to have a certificate – you can export the certificate from one of the Enterprise pool members.  Import that into the load balancer.  The aforementioned documentation does a good job of walking your through that.

Also note that for Lync Mobility, you need to have a cookie set.  In Kemp parlance, the settings on the :4443 virtual server look like this:

And finally, because the traffic is coming in from the reverse proxy and is destined for the Lync Web External site on port 4443, there would be no point in checking for the service being available on port 443, so the virtual server for 4443 gets a minor change in the “checked port” section of the virtual server.

Summary

Lync Server 2010 can use DNSLB very effectively, but the Lync Web Services still need a Load Balancer.  The Lync Server 2010 documentation presents all the information you need.  The Kemp load balancer documentation does a great job of helping you configure their products.  Interestingly, support for the products is also important; if you need help with a configuration there is nothing like a knowledgeable engineer on the phone to help you figure things out.  In this case the Kemp support folks patiently helped my client discover that the original virtual server address we were using was already in use by an undocumented network device which, of course, made the HLB look like it had something wrong.

Lesson learned from that?  In addition to planning out the IP space(s), the DNS (internal and external), the physical network in terms of devices and addressing needs to be nailed also.

YMMV.

Lync 2013, Exchange 2013, Office 2013, SharePoint 2013 RTM

Microsoft announced today that Office 2013, Exchange 2013, Lync 2013, SharePoint 2013 have reached the RTM milestone.

I am psyched.  In particular, I have been part of the TAP for Exchange 2013 and Lync 2013.  Participation in both has been very educational.  I have also been using Office 2013 components in my everyday work for the last six months or so and I can say that I am quite pleased.

In conjunction with Server 2012, this upcoming year looks to be very exciting.

YMMV

Lync 2013 Calling Party Number Translation Rules

Situation

You have internal users that are Enterprise Voice enabled, and they possess sufficient power/position to not want their DID to be advertised when they call out.  What to do?

With Lync 2010, you can manipulate ALL outbound calls from Lync to have a common Calling Party inserted into the call setup – but this manipulation occurs at the trunk level for every call no matter who is placing the call or from where in your environment.  One rule covers it all.

With Lync 2013, we can now manipulate the trunk action based on the Calling Party number.  For instance, let’s say the CEO calls out for some reason, but does not want their DID to be advertised.   Instead, they want the call to appear to be coming from the executive secretary. With Lync 2013 we can now provide this functionality and apply this to only specific numbers while the remainder of the calls go out as provided for in the general configuration.

Let’s take a quick look at how this is done.

The Solution

First, we assume that there is a valid Lync 2013 topology that includes at least one mediation server or mediation pool, and at least one valid trunk out to somewhere.  I also encourage a little test as shown – just to make sure that things are working as expected.

The sharp-eyed reader will note that I am using fellow MVP Ken Lasko’s LyncOptimizer.  No point in reinventing the wheel!

For our example, let’s stipulate that the CEO wants to dial out from his assigned DID number, but have it appear to the called party that the call is coming from the CEO’s secretary.  For this we will have:

CEO number (calling party): 503-312-1234

Secretary number:  999-234-9000

You may want to run a quick test on your trunk, just to make sure your calls behave properly.  Note that when you are testing at the trunk level, you need to consider what the normalization rule is going to add or subtract to the digits entered by the user.  From above, see that the dialed number: 5033121234 normalized to +15033121234, so this is the value to use for testing at the trunk.

---

NOTE:  My trunk needs to strip the “+” before sending the call out, and usually this happens on the default “Called number translation rule” that I put into place.  This new calling party translation rule will go around that other rule, so we need to be careful and take the “+” out when creating the new rule.

---

To start making the new outbound calling party rule, go to the “Calling number translation rules” and select “New.”

Name your new rule

Build the translation rule – see how the built-in logic gives you a mini-tutorial on the pattern match.  Slick. Remember the normalization will change what digits the user enters, and that you need to have the translation rule see the number as it trunk will get it from the route.  The length is also important as that can change how the TRUNK’s translation pattern works.  Digits to add is literally what you want to change the calling party into. 

Click on “OK” to finish.  And let’s test our work. At the bottom of the trunk configuration under “Associated translation rules”  there is another testing area. Be sure to select “Calling number.”

Remember to commit your changes!

Last Thoughts

I used an extreme case here to show the possibilities.  Your carrier may have some logic that will only accept numbers within your DID block as calling party numbers – if that is the case, you will need to confine yourself to using those numbers or have the CO potentially replace your carefully crafted calling party translation with a generic Caller ID value.

YMMV.