And yet... there is very little documentation out there for all the questions people might have about how these two systems work together. Well, it's out there... it's just spread out like not enough marmalade on far too much toast. Consequently, I'm going to throw together a little cheat sheet for people first diving into their Lync Server 2013 install.
The one thing I won't go into is SQL redundancy or high availability. This is just enough marmalade to get you going.
In typical fashion, this post turned into a behemoth. Seriously, there's so much juicy information right after the jump.
Which SQL Server Versions Should I Use?
You can use these:
- SQL Server 2012
- SQL Server 2008 R2
Note that "SQL Server 2008" is not listed there. It is not compatible with Lync Server 2013.
Just use whichever one you have access to. 2012 is going to be better overall for a lab and production, but there won't be any loss of functionality or power using 2008 R2 for Lync in a homelab.
How Many SQL Servers Do I Need?
You need 1 server for each Front End pool. If you have 3 FEs spread across 2 Front End pools, then you need 2 separate SQL servers. If you have 13 Standard Edition servers and 23 Enterprise Front End servers spread across 17 pools, then you need 17 SQL servers.Can I virtualize SQL Server?
Yes. SQL Server 2012 is going to support the fancier virtualization technologies that sprouted up in Hyper-V version 3, but it won't necessarily run much faster than SQL Server 2008 R2.Which Ports Need to Be Opened? What About Windows Firewall?
- UDP
- 1434
- TCP
- Any statically defined ports
- 1433 if using default instance
If you're just using Windows Firewall or also using it on top of a more illustrious security solution, be sure to allow the SQL applications through. Create a new program-specific rule for each of the paths below and set it to "Allow This Connection."
- C:\Program Files\Microsoft SQL Server\MSSQL<Version#>.<MyInstanceName>\MSSQL\Binn\sqlservr.exe
- C:\Program Files (x86)\Microsoft SQL Server\90\Shared\sqlbrowser.exe
The second one on that list I'm not 100% on. I've heard that leaving it as is can lead to very frustrating problems down the road. Yes, it is "x86" even though you installed a 64-bit program.
How Should I Handle Service Accounts?
3 options here, which can be summarily labeled the "easy way," the "slightly harder way," and the "awesome way."
Easy Way
Just click next when you see the permissions. It's really not much harder to do the other two ways, so I don't recommend this. If things start breaking, you're taking a lot of power out of your own hands. So, unless you want to screw over Future You, don't do this.
Slightly Harder Way
Manually create an account in Active Directory to use on the Service Accounts screen. It doesn't need any particular permissions. Make sure to remember the password! Also, don't let it expire! If you don't want to mess with all that, see the Awesome Way below.
Awesome Way
This creates an Active Directory Managed Service Account (MSA) that you can set and forget.
Use this way to never have to change a password, manage permissions, or basically remember anything. And it's way tighter security. You can use the same MSA for all your instances (1 account per server, though) or very easily use the first one as a template to create another.
From the SQL Server, run Powershell as a Domain Admin. If the AD module is not yet installed (or if you're not sure), type:
Install-WindowsFeature RSAT-AD-PowerShell
Then type:
New-ADServiceAccount -Name <SQL MSA Name> -Enabled $true
Then:
Add-ADComputerServiceAccount -Identity <SQL Server Hostname> -ServiceAccount <SQL MSA Name>
Finally:
Install-ADServiceAccount <SQL MSA Name>
When you are specifying the Service Accounts during installation, here's what you put for the Account Name:
Leave the password blank. Make sure to put that dollar sign at the end! The MSA that I'm using looks like this:
hyperi2\SQLMSA01$
And that's it! MSAs are super fun!
Should I Use the Default Insta--
No. Don't use the default instance. Create individual named instances.If you messed up and used the default instance, it will still work. No need to reinstall. Just keep it in mind when things go wrong. The default instance works differently than named instances. Be sure to open TCP port 1433 in your firewall if you've set things up this way.
How Many Instances Do I Need?
1 as a "base", which most people call "RTC", that you point your Front End and mediation services at1 for Persistent Chat, if deployed (CANNOT be colocated with another instance)
1 for Archiving, if deployed*
1 for Monitoring, if deployed*
* You can get away with colocating these. I have an ARCMON instance within my lab.
What Exactly Should I Install?
- Instance Features
- Database Engine Services
- Shared Features
- Management Tools - Basic
- Management Tools - Complete
If you are setting up archiving and monitoring, also install "Reporting Services - Native" for that instance only.
Which Port Is My Instance Using?
You can find this by opening SQL Server Configuration Manager, then:1. Expand "SQL Server Network Configuration"
2. Click "Protocols for <MyInstanceName>"
3. On the right side, double-click "TCP/IP".
4. Click the "IP Addresses" tab. You're now looking for the line that says "TCP Dynamic Ports" that isn't blank and does not just have a 0. You may have to scroll down a bit.
I should note that this port will be auto-negotiated by Lync Server 2013 (over UDP port 1434). However, if that's not working and you're troubleshooting, you may need to open this up.
This, of course, does not apply when the port has been statically configured to something else, but you should see another line in the properties for this.
No comments:
Post a Comment