About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. The opinions expressed on this blog are mine and mine alone.


Lync 2010 Pool / Lync 2013 Client Coexistence


If you are in a coexistence environment, and you have your LyncDiscover pointing at your 2013 Front End Pool, you may experience some odd behavior.

Your Lync 2013 clients that are still homed on the 2010 pool (why you would do this, I don’t know) will start pitching an error that says they cannot trust the server…


clicking on “Connect” here lets the login continue.  But the next time, this error does not reappear.  It does not reappear because the endpointconfiguration.cache file is holding your information.  However, we don’t want this error to appear at all!

Why is this happening?

Well, it happens the first time because the LyncDiscover.domain.com is the primary discover tool for the Lync 2013 client.  For a more detailed look at this new method, see this. When you click on the “Connect” the endpointconfiguration.cache (c:\\users\username\appdata\local\microsoft\office\15.0\lync\sip_username@domain.com)  file is updated with the proper information.  You can prove this by logging out the user, deleting the endpointconfiguration.cache file, then login again.  The error will reappear.  Worse, if you have a large environment with the Lync 2013 client deployed to users on a Lync 2010 pool, you may see this a lot.  Help Desk calls galore.

How to fix this?

This is happening because the LyncDiscover service is pointing the user at the Lync 2013 pool.  And then that server is doing an AD lookup, discovering that the user is homed on a 2010 pool, and telling the client to talk to that server – at which point the pool name and the cert used by the client for the initial login no longer matches – hence the error.

To fix this, you need to keep your LyncDiscover DNS pointing at the Lync 2010 pool.  Alternatively, if you never deployed Lync 2010 Mobility (where LyncDiscover comes from in Lync 2010) and you don’t plan on using Lync 2013 Mobility, then you can simply not define LyncDiscover at all.  Personally, I do not like this second option – I would go out of my way to deploy the Lync 2010 Mobility just to get the entire suite deployed, and start using LyncDiscover; after all, Mobility is now part of Lync natively, and the 2013 client is looking for this service.



Lync 2013 Migration Process Outline


Do you get frustrated with the online documentation that makes you flip back and forth between pages?  I know I get lost a lot.  And sometimes I would like a nice, easy-peesy layout that will allow me to click on the subject I want without having to go diving in and out.  Accordingly, I assembled all the Lync 2013 migration process pages into one doc.  Links should be clickable.

The following information is taken directly from the latest online Microsoft Lync Server 2013 documentation. Full understanding  the implications of each action inside of each migration project phase will make your Lync 2013 migration much easier.


Lync File Share Size

One of Lync’s great features is Web Conferencing.  With users leveraging Web Conferencing more and more, complete with content uploads, a question of “how big does my share space need to be” comes up.

The Lync File Share, per pool, is an amalgamation of all web services content, address book, and conferencing data uploaded by users. By default, the size limit per conference is 500MB and the Conferencing Server will maintain the conference data for 15 days. In my experience, the uploaded meeting content will be the bulk of any projected Lync share space usage.

I had a project with 60,000 users and the initial decision was to let them ALL have full global conferencing profile status.  Using the numbers above and the projected 60,000 conferencing users would have created a file share need of 450TB.


days to retain

max data (MB

provisioned users

file share size (MB)





So we had to do something.  450TB of data storage, even thin-provisioned and potentially spread across multiple servers, represents a considerable cost and commitment. 

One Solution

Let’s take a look at the default  CSConferencingConfiguration:


Identity                           : Global
MaxContentStorageMb                : 500
MaxUploadFileSizeMb                : 500
MaxBandwidthPerAppSharingServiceMb : 375
ContentGracePeriod                 : 15.00:00:00
ClientMediaPortRangeEnabled        : False
ClientMediaPort                    : 5350
ClientMediaPortRange               : 40
ClientAudioPort                    : 5350
ClientAudioPortRange               : 40
ClientVideoPort                    : 5350
ClientVideoPortRange               : 40
ClientAppSharingPort               : 5350
ClientAppSharingPortRange          : 40
ClientFileTransferPort             : 5350
ClientFileTransferPortRange        : 40
ClientSipDynamicPort               : 7100
ClientSipDynamicPortRange          : 3
Organization                       :
HelpdeskInternalUrl                :
HelpdeskExternalUrl                :
ConsoleDownloadInternalUrl         :
ConsoleDownloadExternalUrl         :

From here is it fairly easy to see that we can use a few of these attributes to make some changes:

Set-CsConferencingConfiguration -identity global -MaxCon
tentStorageMb 200 -MaxUploadFilesize 10 -ContentGracePeriod 7.00:00:00

This gives us a totally different outcome:


Identity                           : Global
MaxContentStorageMb                : 200
MaxUploadFileSizeMb                : 10
MaxBandwidthPerAppSharingServiceMb : 375
ContentGracePeriod                 : 7.00:00:00
ClientMediaPortRangeEnabled        : False
ClientMediaPort                    : 5350
ClientMediaPortRange               : 40
ClientAudioPort                    : 5350
ClientAudioPortRange               : 40
ClientVideoPort                    : 5350
ClientVideoPortRange               : 40
ClientAppSharingPort               : 5350
ClientAppSharingPortRange          : 40
ClientFileTransferPort             : 5350
ClientFileTransferPortRange        : 40
ClientSipDynamicPort               : 7100
ClientSipDynamicPortRange          : 3
Organization                       :
HelpdeskInternalUrl                :
HelpdeskExternalUrl                :
ConsoleDownloadInternalUrl         :
ConsoleDownloadExternalUrl         :

days to retain

max data (MB

provisioned users

file share size (MB)





Still not great, but much better.  You will notice that in the previous command, I also restricted the size of the maximum upload, which will help also. What they ended up deciding was that only 10k users would have the ability to create a web conference with 100MB of storage for a retention period of 7 days. even so, the projected need at that point was 7TB. 

While that one project is LARGE in terms of users, a more recent project with only 200 users calculated out to needing 600GB projected storage for 15 days of 200 users at 200MB.  This project team will want to use policies to control the ability to create conferences and control content also.  After all, even in the days of multi-terabyte drives, throwing drive space at the issue is not a substitute for understanding and planning. Here is a handy chart that might help visualize the issue:

days to retain

max data (MB

provisioned users

file share size (MB)






200 200 600,000
10 300 200 600,000
10 400 200 800,000
15 500 200 1,500,000
7 200 60,000 84,000,000

Clearly, there may be other methods to control the size of the file share, this is just one.  Remember that in your efforts to be concise in capacity planning that the file share holds the uploaded conference material and plan accordingly.  A few questions come to mind:

  1. How much uploaded material will there be for the typical user?
  2. Can the users be segregated in terms of capacity?
  3. If #2, can we safely place users in distinct pools to help control size?

This list can go on for a long time, but I think you get the idea.



Project Guidance

This article was written with Lync in mind; however, it also applies to Exchange and almost any other IT project as well.


As a modest disclaimer, I wrote it.



IIS AAR hotfix

With TMG on the verge of no longer being sold, we need to find some reasonable alternatives to Reverse Proxy solutions for both Exchange and Lync.

IIS Application Request Routing is one such solution that may work for you or your client’s environment. If that is the case, then you will want to be aware of this hotfix: MS KB 2785586




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

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




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

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:

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



  • 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:
TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete get DNS result server: Lync15Edge.tsoorad.com IP:
INFO  :: Use proxy server cache:1
INFO  :: Remote Addr:
INFO  :: Verification Flags: 1
INFO  :: Interface Index: 12
INFO  :: Interface Type: 0
INFO  :: GetAdaptersAddresses Succeeded.
INFO  :: Identified local Ipv4 address:
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 :

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>


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


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


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)



Lync Server DNS Pinpoint zones

Edited 10.29.2012 1535 PST – thanks to Jeremy!


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.
image image

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

image image

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.

image image

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.




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:




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.



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.



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.



Lync 2013 Calling Party Number Translation Rules


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.



Private Domain Certificates

Today, you can get a public Certificate Authority  - DigiCert, Entrust, etc – to issue you a trusted certificate for your internal domain.  For instance, if you have an internal AD name such as domain.local, or domain.tld, or any other that is not registered according to the governing body, then your certificate provider will issue you a certificate for the FQDN of your internal servers and your devices will trust that certificate providing your devices trust the issuer – standard fare for most of the public CA issuers.

In an effort to tighten security on the Internet by creating more stringent standards, the CA/Browser Forum recently formulated new guidelines in their Baseline Requirements for issuing SSL certificates.

One of the new changes is the elimination of certificates using internal names. This change makes it impossible to obtain a publicly trusted certificate for any host name that cannot be externally verified as being owned by the organization that is requesting the certificate.  According to this CA/Browser  document:

Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Server Name.

In addition, it appears that internal name certificates will NOT be issued after 1 Nov 2015.  Or, at least DigiCert will not issue them after that date:

In accordance with this new standard, DigiCert will no longer issue certificates to these internal names with expiration dates after November 1, 2015.

If you fall into this category, you should begin planning now to: a) deploy internal PKI and figure out how that action will change your environment(s); or b) change your internal AD DS name (yuk!).

Interesting note:  www.digicert.com is already planning ahead to help you out!  See this nifty tool.



Assign Lync Policies to Users According to AD Group


Fellow MVP Pat Richards just published an extremely nice bit of work to automate the granting of CS policy by AD groups….


It looks very comprehensive and well done.  I will be giving this a whirl in the next few days – and I hope to never have to write my own bits of script to accomplish this again.




As we know, we can limit/control what clients we allow to login to our Lync Servers.  However, if you look at the Client Version Policy, it can be a bit cryptic:


What the heck is an RTC or a UCCP? How to determine that?  Well, chapter 3 of the Lync 2010 Resource Kit – Client Administration – has a handy chart:

Client Name

User Agent

Lync 2010, Office Communicator


Lync Web App, Communicator Web Access


Lync 2010 Phone Edition, Office Communicator Phone


Communicator Phone Edition Platform


Unified Communications Platform


Lync 2010 Attendee


Live Meeting Add-In


Office Live Meeting


Windows Messenger


Real-time Communications Client


That explains a lot, but I notice that there are no MAC clients listed – and maybe I want to allow the newer MAC 2011 client to connect, but not the older one??  How to do that?

Well, as it turns out, the User Agent for Mac is "MC" and Communicator for Mac 2011 is 13.* and Lync for Mac 2011 is 14.*  I assume (BIG ASSUME) that a newer MAC client may be forthcoming in the next Office for MAC rev, and it will be a 15.* – at any rate, now that we know this, we can write a new filter to trap for the 13.* but allow the 14.* – something like this.  You may wish to change your rules order, they are evaluated from the top down.



test 02 Feb

this is a test it’s only a test this should be a picture