What happens when we have many domains?
Note: This post is not intended to be a complete walkthrough or listing of all scenarios or workarounds. It’s intended to be an exploration of some of the boundaries of Lync. If you have employed a different method please reach out and let me know in the comments or on Twitter at @CAnthonyCaragol.
How many SIP domains can you have in Lync? It sounds like an easy question, there’s no limit. Of course if it were that easy, you probably wouldn’t have found this article. Let’s poke around and see if there’s a more practical answer.
Typically, you want your Lync SIP domain to line up with your Exchange email domain. This is a common best practice due to the tight integration of the products and where our practical limits come in to play. If you have many email domains this can get difficult or expensive quickly due to the cost of additional SANs in your certificates.
For fun, let’s look at what happens when we add hundreds of SIP domains to our environment and request a certificate from an internal authority.
In the picture, you can see the error:
Request-CsCertificate : Command execution failed: Error Parsing Request The length of the field exceeds the maximum length. 0xc80005e2 (ESE: -1056)
That error is telling us that our certificate request is just too big. This happens because Windows Certificate Authority has a maximum limit of 4096 characters for the encoded extension. You can check for yourself by running “certutil -schema ext”. I know what you’re thinking, I asked too, but you can’t change this limit.
We might have better luck requesting this certificate from an external authority, but it’s not likely. Running down a few companies in the list of approved authorities from the Certificates for Lync Phone Edition TechNet article we find:
These authorities typically have tighter limitations than your internal authority. There may be some hope, SSL.com seems to have the most at 2000: https://www.ssl.com/certificates/ucc but I have yet to try them out.
What Can We Do About It?
If you’ve hit your practical limit based upon the number of SANs, you’re going to have to reduce the number of SANs. There are a few ways of accomplishing this that we can look at.
Reduce the number of SIP domains
One option you have is to reduce the number of SIP domains by allowing the email address to not match the SIP address. If you decide to go this route, know that there will be difficulties. With this method it will become very difficult for users from other companies to find you for federated chat unless they can discover your Lync address through another method. You’ll also find some client oddities when it comes to Outlook integration. For example, you may not see your conversation history saved. To disable the Lync check that ensures that Outlook and Lync are logged in with the same accounts, run the following command from the Lync management shell:
Set-CsClientPolicy -DisableEmailComparisonCheck $true
There will still be issues, and you should test every feature that’s important to your organization, but this may be an option for you.
Reduce the number of SANs
Another option is to reduce the number of SANs that are used in the certificates by avoiding the wizard and heading right for PowerShell. In this case, Request-CsCertificate is your friend. Running a command similar to the following allows you to control which domains you’ll be adding. In the example below, sipdomain.com and sipdomain2.com account for 95% of our users.
Request-CsCertificate -New -Type Default,WebServicesInternal -ComputerFqdn “lyncpool.ads.caragol.com” -FriendlyName “My Reduce SAN Certificate” -PrivateKeyExportable $True -DomainName “lyncpool.ads.caragol.com,lyncdiscoverinternal.sipdomain.com,lyncdiscoverinternal.sipdomain2.com,sip.sipdomain.com,sip.sipdomain2.com”
Keep in mind that you can limit the SANs used in simple URLs as well by configuring them to use a single common FQDN. See Planning for simple URLs in Lync Server 2013 for more information.
For the SIP domains that haven’t been included in the certificate, we can publish lyncdiscover and lyncdiscoverinternal records only over port 80 avoiding HTTPS and we can point our SRV records for the other domains (ex. sipdomain999.com) to a primary sip domain (ex sipdomain.com) as shown:
There are a few caveats to this method. It’s important to note that when the user’s SIP address does not match the common name on the certificate, you may see an error as seen below. The following screenshot is from a device that is trying to log in as email@example.com when the certificate matches sipdomain.com. If you plan on using this method, you should know how to work around it using the TrustModelData registry value.
Additionally some Lync phone devices may not want to authenticate at all, so plan accordingly if this is a phone deployment as well.
Use Multiple Pools Each With Different Additional SIP Domains
If you’re willing to use the above approach, where we limit the number of sip domains in the certificate, you can also consider dividing the sip domains into pools and sites. For example, you could split the domain names across two or more pools, keeping the default sip domain in both. Using Request-CsCertificate, each pool would be responsible for a handful of domain names. Users would need to exist in their corresponding pool and DNS records for that SIP domain would need to point directly to that pool. You may also need multiple reverse proxies and edge pools to accommodate.
So What’s Our Practical Answer?
Well, as you’ve seen, the limits are mostly based around certificates. Some of these limits are based upon size, and some based upon available SANs. If you’re going the public certificate route, the limits will depend upon the provider you choose. There are workarounds for just about everything however, and nothing is going to provide you with a better shot at the right outcome than careful planning.
Any comments based upon your experience? Please leave them below or find me at @CAnthonyCaragol on twitter to let me know!