As I’ve done with Lync 2010 and OCS 2007 R2 I’ve decided to write an article on how to deploy Lync 2013. Like in previous years this will be a multi-part post, this being part 1. However; unlike the previous articles I want to call out some things ahead of time:
- This article covers doing a Standard Edition deployment for a small or medium size deployment (under 5,000 users)
- I’ll cover having redundancy in the environment, it is assumed that this redundancy is provided by having a second location with equipment in it and an MPLS connection to the primary location.
- The redundancy focus is specifically around Lync functionality, I won’t be covering how to plan DR or HA for other services/servers
- It is assumed you will have PSTN and Internet connections at both locations
- This series will cover IM, Presence, Voice Resiliency, Conferencing, and Unified Messaging
- Because I don’t have enough subnets in my lab all servers will share the same subnet excluding edge.
- Edge servers will utilize 1 DMZ interface and 1 Internal interface (2 NICs). If you are deploying this to your production environment both edge interfaces should be in separate DMZ subnets from each other and all Lync servers and clients. I’ll cover this more in the Edge section of the article
We’ll begin with a quick overview on the deployment. This is a lab deployment containing 2 domain controllers (1 per location), 2 Lync Standard Edition servers, and 2 Lync Edge servers. All servers in this deployment are utilizing Server 2012. An Active Directory domain named “ocsguy.local” will hold all user accounts and the public SIP and SMTP domain will be “ocsguy.us”.
For server hardware and software specs on Lync 2013 please review the specifications on technet here:
So now that all of that is out of the way, let’s start with the fun stuff. I’ve downloaded the Lync 2013 RTM bits and placed them on what will be my first front end server (FE1.ocsguy.local). I’ll being by logging into the Lync server with an account that is a member of “Domain Admins”, “Enterprise Admins” and “Schema Admins”. Next I install the pre-reqs, I used the command below from an Administrative PowerShell window:
Once this completes, restart the server and then we can start the Lync install, we’ll start by going to the “Setup\amd64” directory on the install media and running setup.exe
As usual you will be prompted to install Visual C++, click Yes here (unless you don’t want to install Lync )
Once the install completes you will see the Core Components Installer, click Install here:
Next we’ll accept the EULA (make sure to read it) and click OK:
And away we go
Once this installer completes the “Lync Deployment Wizard” opens and the real fun begins.
I like to start by clicking “Install Administrative Tools”
Next I’ll click “Prepare Active Directory”. I won’t bore you with all of those screen shots, you’ll just run steps 1, 3 and 5 – each one requires you to do a version of the well-known “Next, Next, Finish” dance. The other steps are just waiting for replication.
Now before we go any further we’ll need to make our administrator account a member of the “CSAdministrators” and “RTCUniversalServerAdmins” groups:
For this to take effect we’ll need to signoff of the server and back on.
Once we’ve signed back in we’ll launch the “Lync Deployment Wizard” again and choose “Prepare First Standard Edition Server”- This time we only do the “Next, Finish” dance.
The wizard will take a few minutes to complete (you’ll notice it taking a while during the SQL parts). It may be a good time to sip on more of that beverage or even get a refill.
Assuming you see “Complete” as shown in the screenshot above we can move on.
Next we’ll create a folder named “Share” on the C drive and share it out. This will be used for our file share for this pool/server:
The default permissions will work for this as the Lync Topology Builder will update them with the appropriate settings when we publish our first topology. Speaking of Topology Builder – now is the time to open it, since we have our shared folder ready we can start on our first topology. When it opens click the radio button for “New Topology” and click “OK”
You’ll be prompted for a file name for the new topology file, I recommend using a descriptive name and storing all copies of topology in one place:
Now the “Create New Topology” wizard appears and we can start defining our topology, we’ll start with the primary sip domain “ocsguy.us”
We won’t be entering any other domains for this article so we can click next on the “Specify additional supported domains” box (Note – no screenshot shown for boxes that don’t require us to enter information). Then we’ll define our site:
Specify the site details and click Next:
Now we’ll click “Finish”, notice the “Open the New Front End Wizard when this wizard closes” box is checked for us.
On the “Define the New Front End Pool” page we’ll click Next and be presented with options for our first pool. Since we are deploying a Standard Edition pool select “Standard Edition Server” and put in the FQDN of our first Front End server (fe1.ocsguy.local) in the “FQDN” box and click Next
We’ll be enabling: Conferencing, Dial-in (PSTN) Conferencing, Enterprise Voce and Call Admission Control
We’ll leave the “Collocate Mediation Server” box check and click next (not shown)
For now we won’t be deploying edge so leave the “Enable an Edge Pool…” box unchecked and click Next (not shown)
SQL information is already populated for us so we can click Next (not shown)
Also, because we used the default file share name of “share” we can click next on the “Define the file store” screen (not shown).
Under Specify the Web Services URL I recommend using a different name than the server name under the “External Base URL” field. I typically add “extws” for “external web service” to the pool name here, this was required when you were doing mobility in 2010 so I’ve stuck with this on the 2013 deployment. Also, since our pool name is an internal domain, we’ll need to change that to an external FQDN, I’ve used “fe1extws.ocsguy.us”
For now we won’t be deploying an “Office Web Apps” server so uncheck that box and click “Finish”
Now we’re ready to publish our topology so we can choose Action>Topology>Publish in Topology Builder
A little more of the “Next,Next,Finish” will happen, notice that during the wizard we will see our Front End server “fe1.ocsguy.local” automatically selected as the “Central Management Server”
You’ll see a bunch of text in the “Publishing Topology” box, as long as there is no Red/Errors the topology will be published and we can open the to do list by clicking on the “Click here to open to-do list”.
Our “To-Do” list tells us to setup our simple URLs and run setup on our new server fe1.
We’ll start by running the Lync Deployment Wizard and choosing “Install or Update Lync Server System”
We’re going to run through steps 1 through 4 in order. Choose “Run” under Step 1 (it will be the only one not greyed out).
On the “Install Local Configuration Store” screen we’ll leave the defaults and click Next
We’ll see the install text fly by again, slowing down for all the SQL services of course (good time to sip on some more of that beverage)
Once it completes click Finish
Now we can click “Run” under Step 2, click “Next” under “Setup Lync Server Components” and the next phase of the install begins. This will take more than a few minutes so be patient…
Now on to Step 3, we’ll start by requesting the “Default Certificate” which is used for most of the Lync services
When prompted choose “Send the request immediately” and click Next, a CA from your environment should show up in the drop down on the next screen
If your CA is there click Next
You shouldn’t need to specify alternate credentials or alternate certificate templates (unless your organization has special requirements around this) so click Next 2 more times
Now give your certificate a friendly name, I like to make sure it is something meaniful like “FE1 Lync Pool Cert” and I usually mark the certificate key as exportable just in case I need it for troubleshooting later.
Now put in your organization info and location info (not shown)
Make sure to place a check next to your SIP domain in the “Configured SIP domains” box, this adds sip.ocsguy.us to our certificate
Finish through the wizard by pressing Next a few more times and the certificate will be requested
The next screen will allow you to assign the certificate you just requested (Make sure the “Assign this certificate” box is checked). Couple more “Next, Next, Finish” presses and our certificate is assigned.
Next we’ll request our OAuth certificate, this will be used for server to server communication for things like Exchange and SharePoint.
For the friendly name I typically use something like “OAuth Cert”, something important to note: This certificate will replicate to all of your Lync servers, so you will only have to request it once.
Notice above the only name on the cert is the sip domain. All other fields you can leave defaults and your settings for organization and location will be populated from the last request.
Once the request completes we can assign it automatically just like we did with the last one.
Now we can run Step 4 to start our Lync services. This is another “Next, Finish” type of thing so I haven’t included screenshots.
Once the Service start completes you can open the Services console (services.msc) and verify everything start with “Lync” is running – “Lync Server Front-End” may take a few minutes to go from Starting to Running. If it doesn’t start check your Event Viewer (eventvwr) for errors.
Now that the Lync install is complete we can move on to DNS. For this portion of the deployment we will create the following A records in the internal copy of our “ocsguy.us” zone (Note these are the internal IPs and will only be used by internal clients):
|A Record||IP Address|
We will also need to create the following SRV record:
This record will be used by our Lync clients for sign in.
Now that DNS is ready, we’ll head over to the Lync Control Panel and enable our first user. You will likely be prompted to install SilverLight (if you hadn’t done so earlier). If you already have Exchange deployed and an email address policy you can allow the SIP Uri for the user to be based on that, otherwise you’ll want to create the SIP Uri as I have below:
Last but not least, since everything is ready all that’s left to do is sign in from a domain joined machine.
Sign in is now complete and we can call it a day. Check back next week for part 2, adding our second front end server and configuring pairing.
H/T to Pat Richard for pointing out a typo above.
Hi Kevin – why are you adding sip. to the FE server, shouldn’t this be on the Edge server as in 2010? The DNS part also seems wrong to me in that regard..
Hi Jonas, I’m not manually adding sip. to the cert, it is done by the wizard automatically when you put the check box in for the configured sip domain. A couple of reasons this is ok:
1. Using split brain DNS means I can have an internal copy of my zone that doesn’t impact the external
2. Having SIP. as a SAN doesn’t mean I have to use it in DNS, but in this case I do
3. The lync client uses SIP. as a fall back record, meaning it will look that up if it can’t find any SRV records to connect to, so this helps in the event of unexpected DNS “administration”.
4. Because the server names on Standard edition match the AD name, and AD names don’t always match SIP domains (as shown in this article) we want to have a record in our SIP domain that points to the pool (SIP. in this case). This keeps users from getting a mismatch error when connecting to the pool and cuts down on help desk tickets and user confusion.
I will still use SIP. externally on the edge as well, but only external clients using external DNS will see the public DNS of that, so there isn’t confusion in this scenario.
Hope that helps explain it.
Excellent comeback Kevin – good stuff! Thanks for the elaboration 🙂
I misread the IP’s as being public, I see now that they are not…
Glad that cleared it up for you! I probably should have called out that they were the private IPs. I’ll do that in the article now.
Straight forward and precise.
I cannot get my Lync 2013 client to sign-in using _sipinternaltls._tcp.domain.com in my lab.
It will only sign-in if I add an A record for lyncdiscoverinternal.domain.com.
Is this a new sign-in process for 2013 where the client looks for lyncdiscover in DNS for auto-config?
Did you by chance install Lync MX on the machine that your current Lync client is on? Also, what version of Lync/OS. I’ve seen this behavior on Lync 2013 on Win8 after installing MX.
No, the client is installed on Windows 7. I found on another blog that the sign in process looks for lyncdiscover and lyncdiscoverinternal now before moving onto the SRV records, but I have not been able to find a reference about that on any official MS documentation.
The CHM says the following:
How Clients Running Lync 2013 Locate Services
During DNS lookup, SRV records are queried in parallel and returned in the following order to the client:
_sipinternaltls._tcp. For internal TLS connections
_sipinternal._tcp. For internal TCP connections (performed only if TCP is allowed)
_sip._tls. For external TLS connections
Where is the SIP domain used by your internal clients. The last two queries are for clients that are connecting from outside your internal network. When creating SRV records, it is important to remember that they must point to a DNS A and AAAA (if you are using IPv6 addressing) record in the same domain in which the DNS SRV record is created. For example, if the SRV record is in contoso.com, the A and AAAA (if you are using IPv6 addressing) record it points to cannot be in fabrikam.com, also it must be in contoso.com.
The first time a user signs in, the client running Lync attempts to connect to a Front End pool using each of the three SRV records in order, regardless of whether the user is signing in from inside our outside your network. After the client running Lync makes a successful connection, it caches the DNS entry and continues to use it until it is no longer successful. If the client running Lync cannot use the cached value, it queries DNS for the SRV records again and repopulates its cache. For example, this process is used if the user has signed in to the internal network during the day, and then takes his laptop home and signs in externally.
After the SRV record is returned, a query is performed for the DNS A and AAAA (if you are using IPv6 addressing) record of the server or Front End pool associated with the SRV record. If no records are found during the DNS SRV query, the Lync client performs an explicit lookup of sipinternal.. If the explicit lookup does not produce results, the Lync client performs a lookup for sip..
In my testing I haven’t seen Lyncdiscover queried unless MX is installed on the machine as well as the regular Lync desktop.
Excellent, like always. I was curious to find out if you are going to do an edge and xmpp gateway part also. I am interested in finding out how federation is different in Lync 2013. Thank you.
I will be covering edge in a coming article that will include federation.
Thanks for reading!
Hi Kevin, I am configuring lab environment using windows 2008 r2 and running into an issue. When I click on Prepare First Standard Edition Server, it completes without any errors. But, I do not get a check mark next to it. Also, later when I build topology and try to publish it, I get an error.
“Microsoft.Rtc.Management.Deployment.DeploymentException” “Cannot find any suitable disks for database files.
Would you be kind to tell me what could cause this issue.
Can you make sure you have at least 16 gb free space on the install drive of Lync?
I had only 5GB of disk space on a 25GB VM that I had created. I’ll make it larger and try.
Where is the part 2, 3 4 ?
or simply edge part 🙂
in advance thx
I’ve been very busy at work, so I did get Part 2 done but have been so busy with work, Christmas/New Years/Family, training programs, prepping for Lync Users Group events and prepping for Lync Conf (presenting) that I haven’t had the time to move on to the next article. I’ll try to update soon
Thank you for these good articles .
Do you have any plan to do an step-by-step instruction for deploying Lync2013 Mobility service ?
That is really needed for us .
I have migrated my production Lync 2010 to 2013, everything works well except for the PIM! MSN, Skype and AOL are not working..
AOL presence works when I sent a msg from AOL user to LYnc but messages sometime get through and other don’t.
One thing i’ve noticed on the edge side, it’s indicating there’s an issue with TLS connection to federation.messenger.msn.com.
I’m not sure if that would affect the federation with PIM but I have exported the certificates with private keys and imported them to Lync fe and Edge 2013.
I have noticed also that on Lync FE 2013 when you request the external web services, the common name is no longer meet.domain.com, it’s ExternalWebServices.domain.com.
my Lync 2010 used to work perfectly without any issues with meet.mydomain.com and I can’t change the common name unless purchasing new one.
thanks for the article, I am running into an issue when trying to prep the forest im getting multiple error saying that CN=RTC Service, CN=Services, CN=Configuration, DC=……. does not exist but is I use ADSI I can see the object. Any help would be great, this is our first Lync Deployment.
After Looking at it more closely it is actually failing at Creating Active Directory object “Application Contacts”, it says Task Execution Failed and then a long message saying Directory object not found 0000208D……..best match of: ‘CN=Services, CN=Configuration, DC=……. I have looked online and cant find anything that explains the error or how to fix it, your help would be greatly appreciated.
Just had this error myself. I have two DC’s. I noticed that the command is running against DC2, which is not the schema master. I opened up a powershell and ran the command enable-CSADForest -GroupDomainController DC1.domain.internal -GroupDomain domain.internal and it ran without errors. I then just clicked the little green refresh arrows in the setup wizard. Restarting the setup program will do the same trick.
Hope this helps you too 🙂
Hi I have the following error after setting up an Enterprise Edition of Lync 2013 Preview. “The Lync Server Front-End service terminated with the service-specific error%%-1008193021” I found articles related to Lync 2010 that the trial expired, but I’ve only had it for a week. Any suggestions would be great,
Can you check the Lync Server log to see what errors occur around this time? That error is most likely from the System log and won’t tell the actual problem.
Can I implement this without internal CA? I have one internal domain “internal.ad” (without Certificate Authority), two external domains: “external1.com” (which I have a wildcard certificate for) and “external2.com” (email, hosted exchange)
Thinking of implementing an edge server to DMZ with “lync.external1.com”. Any advice?
Good article, I have only question. Is the second cert for the OAuth also issued by the internal CA?
Yes, the OAuth cert is issued by the internal CA and will replicate to all the machines that need it via the CMS replication.