Check out the most comprehensive, actively managed Lync blog roll in the known universe, your one-stop source for links to over 100 of the very best Lync blogs. Here you will also find weekly blog highlights and a feed for a dozen of the top blogs.
Lync Server Support Home
Top Lync Solutions RSS Feed
Microsoft Senior Support engineers walk you through real-life support cases, giving you an insider’s view into the systematic approach they use to troubleshoot Lync Server issues.
These short videos focus on specific tasks and show you how to accomplish them for Microsoft Lync Server 2010.
When deploying Lync Server 2010 in a large organization, you are likely to encounter custom Microsoft SQL Server network configurations, such as running the SQL Server back-end instance on a non-standard static SQL port or the requirement to run with the SQL Server Browser service disabled. This article describes how you can set up a SQL Server instance to listen on custom ports, and how to configure Microsoft Lync Server 2010 to operate in such a configuration.
Author: Peter Schmatz
Publication date: April 2011
Product version: Microsoft Lync Server 2010
When Microsoft SQL Server is running in an Enterprise, you frequently find a number of security policies or other SQL Server best practices in place, for example:
There are several options available that will enable you to successfully deploy Microsoft Lync Server 2010 communications software in such a SQL Server environment. This article describes how Lync Server 2010 components can access the SQL Server back-end databases, and what can be done to work around restrictions. This article will give an overview of the following topics:
How to run Lync Server 2010 if the SQL Server Browser service is not permitted.
In previous releases, the setup was easier: The front-end servers connected to the SQL Server back-end databases, and the Monitoring and Archiving Servers connected to their respective SQL Server stores. Configuration data was stored in Active Directory Domain Services, SQL Server, and local Windows Management Instrumentation (WMI) and was accessed through a WMI provider that was installed on each server and administrator station.
With Lync Server, the SQL Server access is more complex: Configuration is now in the Central Management store and every setting must have access to the Central Management store. Other cmdlets, such as Set-CsClientPin, set user-specific runtime data. This user-specific data is stored in the SQL Server back-end databases of the Front End pool that homes the user.
Table 1 gives an overview of the tasks that require access to the SQL Server back-end database or Central Management store.
Table 1. Overview of configuration tasks and the database access required
Most Get -Cs/Set-Cs cmdlets
Central Management store
Move-CsUser and move conference IDs
Back-end database of source and destination pool of the moved object
Client personal identification number (PIN) cmdlets
Back-end database of the pool that homes the user
Lync Server 2010 Control Panel cmdlet Runspace
Central Management store and multiple back-end databases in the Front End pool
Cmdlets for local setup
Cmdlets for handling certificates
Local database only
Quality of Experience (QoE), call detail recording (CDR), and Archiving Server
SQL Server back-end stores for the Monitoring database or Archiving database
Note. While running the Lync Server Control Panel, the Web Services component (running on all Front End pools) creates a PowerShell Runspace that runs cmdlets. The cmdlets require database access. The client computer that is running the Web Browsers does not require database access.
When you are running Lync Server in a locked-down SQL Server environment, the access to the SQL Server back-end databases and Central Management store is restricted to the least possible number of servers. The following list outlines the server options and the limitations of each option. To implement the access restrictions, use custom Firewall rules for SQL Server access.
Subsequent configuration updates are replicated to each server and do not require access to the Central Management store.
There are several ways to set up SQL Server networking, such as dynamic ports or named pipes. This article does not go into detail about all options, but focuses on two typical SQL Server network configuration scenarios. The SQL Server example FQDN used in this article is sql-ps1.cs.contoso.com, the named instance is RTCINST.
This article does not cover the scenario where the SQL default instance is not running on the default port 1433, because the SQL default instance does not use SQL Browser for discovery.
This is the default configuration. In this configuration the SQL Browser service is listening on port UDP 1434. Any SQL Server client (such as the Lync Server components) that connects to the SQL Server is using the connection string sql-ps1.cs.contoso.com\RTCINST when connecting to the SQL Server. The SQL Browser service returns the port 1414 to the client, and the client will connect successfully. No further settings on the client and Lync Server side are required.
In this configuration the SQL Browser service is disabled, and the client does not know which port it must connect to get access to RTCINST. This setup reduces the attack surface of the SQL Server because the attacker would have to scan and probe all ports versus having the port number resolved by the SQL Browser service.
Note. Lync Server 2010 does not support setting up a custom port number when connecting to the SQL back-end; the connection strings contain only the SQL Server FQDN, and (in the case of a named instance) the instance identifier.
To enable Lync Server 2010 to run without the SQL Browser service, configure each SQL Server client individually by using the SQL Server Client Network Utility. Create a server alias that contains the port configuration as described later in this article.
By default, SQL Server does not create any firewall exceptions, and the administrator who sets up SQL Server must create these firewall exceptions manually.
There are the following options for creating these exceptions:
A best practice for SQL Server is to listen on a static port and use a port- or protocol-based firewall exception rule.
Note. If you are running SQL Server with dynamic ports, you must use the program-based exception rule. If you are running a static port, both exception rule types can be used.
To create a custom firewall rule for the SQL instance RTCINST listening on port TCP 1414, do the following:
1. On your SQL Server, run Windows Firewall with Advanced Security, select Inbound Rules, and then select New Rules.
2. Under Rule Type, select Custom, and then click Next.
3. In Program, select All Programs, and then click Next.
4. In Protocols and Ports, configure the following:
a. Protocol type: Select TCP
b. Local Port: Select Specific Port
c. Specify 1414
d. Remote ports: All Ports
5. Click Next.
6. In Select Scope, configure the following:
a. Local IP address: Any IP
b. Remote IP address: These IP Addresses
c. Specify a remote IP addressed individual, a specific subnet, or an IP address range
Note. This page lets you to select which remote computers can access the SQL Server back-end, for setting up each Lync Server components. To see what access is required, see Table 1.
7. Select Allow connection, and then click Next.
8. In Specify the Profile, select Domain, and then click Next.
9. Select a name for the rule you created, such as "SQL RTCINST CMS 1414."
Repeat this procedure for SQL Browser service (if applicable). Change the settings for Protocol Type to UCP and Local Port to 1434.
To configure SQL Server to listen to a specific TCP port, do the following:
1. On your SQL Server, run SQL Configuration Manager.
2. In the pane, select Protocols for RTCINST and TCP/IP. (See Figure 1.)
Figure 1: SQL Server Configuration Manager Main dialog
3. Right-Click TCP/IP Properties and select Tab "IP Addresses".
4. To disable dynamic ports, make sure the field "TCP Dynamic Ports" is blank for all available IP addresses. (See Figure 2.)
Figure 2: TCP/IP Properties TCP Dynamic Ports settings
5. To configure the TCP listening port globally for all configured IP Addresses, scroll to the bottom of the dialog. Enter the desired port 1414. (See Figure 3.)
Figure 3: TCP/IP Properties setting the TCP listening port
Note. Depending on your configuration, you may want to scope the access to a specific IP addresses.
6. To close the dialog box, click OK. A pop-up box will remind you that the SQL instance must be restarted for the changes to take effect.
7. Restart the SQL instance using SQL Server Management Studio or Service manager.
To validate the settings use the following check.
netstat -ano | findstr 1414
taskslist /SVC | findstr <process ID>
Figure 4. Validating that SQL Instance RTCINST port change took effect.
To enable Lync Server 2010 to connect to a SQL Server back-end running on a SQL Server without SQL Browser service, create a SQL Client alias as described below. To create a SQL Client alias, the SQL instance must be listening on a static port. Support of dynamic ports requires the SQL Browser service.
To get the connection string by running Topology Builder, see the example below:
Figure 5. Topology Builder SQL Connection string
It is necessary to set up a client alias on each Lync Server system that requires access to this SQL back-end and any Lync remote admin stations running the Core Lync PowerShell provider. For the scenarios and tasks see Table 1.
Run "cliconfg.exe" to start the SQL Server Client Network Utility. The SQL Server Client is installed on all Lync Server systems, as well as Lync admin stations.
Figure 6. SQL Server Client Network Utility main dialog
Figure 7. SQL Server Client Network Utility Server alias
Manageability concerns of setting a SQL Server Alias individually
The obvious downside of creating an alias on each server is that the alias has to be applied to many servers, and the alias can get out of date. As a solution, it is possible to configure SQL Client aliases through GPO.
For details see: "How to deploy SQL Server Client Aliases using Active Directory GPO/ADM".
This article discusses options to run Lync Server 2010 in a SQL Server deployment with custom requirements or constraints.
Keep in mind when setting up custom configuration to understand first which server or admin workstation has to have access possibly multiple SQL Server back-ends. Consider special cases:
Setting up a Help Desk remote admin station with a limited user role to reset User PINs.
Keywords: Lync Server 2010 SQL; custom SQL Port; SQL Browser; no SQL Browser, SQL Client; locked down SQL; SQL Firewall settings