Provisioning Polycom SIP Phones

May 15, 2013 by Jeff Schertz · 4310Leave a CommentProvisioning+Polycom+SIP+Phones2013-05-15+15%3A13%3A19Jeff+Schertz

The process documented in this article can be used in any Lync 2010 or 2013 environment to setup a centralized provisioning server for managing Polycom SIP phones running Polycom Unified Communications Software (UCS).

This article is not intended to replace or accompany any official Polycom documentation. Instead this process alone can be used to deploy a basic provisioning server in a lab or testing environment when evaluating Polycom SIP phones, and much of the guidance contained reflects a non-production scenario. Also note that some of this guidance differs from instructions found in the official Polycom provisioning guides, most importantly the guidance to use a large number of parameters which no longer need to be defined for Lync interoperability as of the introduction of the Lync Base Profile.

Background

Traditionally Lync Optimized devices (e.g. CX600) receive all of their provisioning information and software update packages directly from a Lync server. Although Qualified devices (e.g. VVX400) do also receive a lot of information in-band from the Lync Server, UCS devices contain a variety of configurable parameters available outside of what the Lync Server can provide itself. When looking to provision any of these out-of-band features, like Paging, or when dealing with device firmware updates then it is required to deploy a centralized server to provide this today.

The provisioning server is not a specific product or solution, it is basically just a centrally-accessible file store which contains certain files that the devices are programmed to look for. The phones will look for specific firmware files to perform an upgrade/downgrade and will download and upload configuration data in XML files.

Polycom UCS devices can utilize a variety of different file server platforms to store and manage both firmware packages and configuration files, no additional third-party software is required. In this article a basic FTP server will be used but the phones also support the TFTP, HTTP, and HTTPS protocols.

When a factory-reset device is first powered on it will check for specific DHCP Options that may be defined on the network which would provide a path to the provisioning server. If this information is found then it will connect to that file service, authenticate with a pre-configured username and password, and then look for one of two specific filenames stored in the root directory. First the device will look for a configuration filename matching its MAC address (e.g. 0004f28062d6.cfg) but if that does not exist then it will revert to loading the default master configuration file provided in the UCS distributable package (e.g. 000000000000.cfg). Regardless of which file is downloaded it will contain a defined parameter which tells the device where to locate firmware packages and what (if any) additional configuration files to look for. By default the firmware packages are stored at the root of the directory and each individual phone model is programmed to look for a specific filename unique to each model (e.g. 3111-46157-001.sip.ld). Additionally the device can also upload files to the directory to store device-side settings (e.g. ringtone) as well as diagnostic and call logs.

Configure Provisioning Server

Specifically Microsoft FTP services in Internet Information Server are used in this example, running on Windows Server 2012 on a dedicated host. Any standard FTP service (e.g. FileZilla, WarFTP) can be used. It is not recommended to use an existing Lync Server also as the FTP server, thus the guidance that a separate Windows host be utilized.

Authentication

Before setting up the file server it is important to understand that the UCS firmware is pre-programmed with a default username and password which is used during authentication to the provisioning server. The default credentials use the same string for both the username and password and are stored in as case-sensitive so if the FTP server uses case-sensitive username and/or password make sure the uppercase and lowercase characters are used correctly. (Traditionally username are not case-sensitive while passwords are, but this may depend on the actual file server product used.)

Username PlcmSpIp

Password PlcmSpIp

It can be difficult to discern if some of these characters are an i, L, or a 1. The leading ‘p’ is uppercase, followed by a lowercase ‘L’ ‘c’ ‘m’, then an uppercase ‘s’, lowercase ‘p’, uppercase ‘i’, lowercase ‘p’. The name comes from the string ‘Polycom Soundpoint Ip’.

If using a custom set of user credentials is desired then they can be changed manually on each phone prior to provisioning by accessing the Settings > Advanced > Administration Settings > Network Configuration > Provisioning Server menu.

For this lab environment the Windows Active Directory password policy was customized to disable strong password complexity requirements as the default password does not meet the complexity of the default Windows AD password policy. In a production environment it would not be advisable to alter the password complexity policy simply for this reason, but a different file server platform which is not AD-integrated could be used which may not have this same limitation.

Create a new Active Directory user account (or a local user account in the event that the FTP Server is running on a standalone Windows server).

Name Resolution

To facilitate simple access to the FTP site select a dedicated hostname and configure it for name resolution.

Select a fully qualified domain name for the FTP server (e.g. ucs.schertz.name) and then create a new DNS Alias (CNAME) record in the proper zone pointing the physical server Host (A) record where the FTP service is installed and listening.

FTP Service

Using the directions provided in TechNet to Build an FTP Site on IIS add the FTP Server role, as well as any prerequisite IIS Web Service roles in the event that IIS is not currently installed on the desired server.
Launch Internet Information Services (IIS) Manager (inetmgr.exe) and expand the server object. Right-click Sites and select Add FTP Site.
Enter a name for the new FTP site (e.g. ucs) and then select or create a local path to place the root directory of the site (e.g. c:\inetpub\ucs).

On the Bindings and SSL Settings page disable secure sockets layer by selecting No SSL.
On the Authentication and Information page enable Basic authentication and then select Specified Users in the ‘Allow access to’ drop-down list. Enter the desired user name (e.g. PlcmSpIp) in the field below, and enable both Read and Write permissions.

Because the devices need to be able to upload configuration data as well as download it then both Read and Write permissions are required.

FTP Directory

Now that the FTP service has been prepared the root directory needs to be populated. This is a simple process given that every UCS package released by Polycom always includes the entire set of base files needed, so any version of UCS can be used to first populate the directory.

The desired software package can be downloaded from the Polycom Support site, either directly from the support page for a specific phone model, or from the Software Release Matrix page. Depending on the number of different device models which need to be supported multiple packages may be required, but the first package selected is sufficient to instantiate the directory.

As this article is using a Polycom VVX 400 for the examples then the current desired firmware version is 4.1.4.

From the Polycom support site download the Polycom UC Software 4.1.4 release sig split.zip package. (It is recommended to always download the ‘split’ package, the ‘combined’ packages can be ignored).
Expand the contents of the software package to the root of the defined FTP directory (e.g. c:\inetpub\ucs).

The package contains a number of directories and files but most of these can be ignored when dealing with Lync integration, including the directories which store sample configuration and localization files as well as the image and audio files. The important files are highlighted in the table below.

Name Description

0000000000.cfg Default Master SIP Configuration File

*.sip.ld Firmware files for each unique phone model

sip.ver Text file which stores the full version number for this package

To insure that the phones have the appropriate rights to the directory add the desired user account (e.g. PlcmSpIp) to the root folder’s Access Control List and grant it Modify permissions.

An additional recommendation is to create dedicated directories to store call and diagnostic logs for each phone. By default they would all be written to the root directory which in larger deployments can lead to a lot of files being stored there, making it more difficult to weed through and manage files configuration files.

Create new folders named calls and logs in the root directory.

Edit the master configuration file (0000000000.cfg) using Notepad or an XML Text Editor of choice and enter the names of the new directories for the LOG_FILE_DIRECTORY and CALL_LISTS_DIRECTORY parameters.

Notice that the APP_FILE_PATH parameter is set to sip.ld by default. This tells the device to look in the root directory for the firmware files. If desired the firmware files can also be moved into a new subdirectory (e.g. \firmware) and then the proper parameter value would be “firmware/sip.ld”. For the purposes of this article, and for most deployments, the firmware files can be left in the default location.

DHCP Configuration

For proper operation of the phones it is required to provide information about the location of critical network resources automatically to the phones via DHCP. In this example Microsoft DHCP Services are currently configured to hand out IP addresses to any network hosts. These options can be defined at either the server or scope level.

Provisioning Server Location

When receiving a dynamic IP address on the network the phone will by default look for the location of a provisioning server by first checking for the existence of DHCP Option 160. In the event that option 160 is not configured then it will fall back to looking for Option 66.

The preferred option 160 is specific to Polycom UCS devices while the secondary option 66 value is commonly shared with other SIP phones as well. Either option can be used with the UCS phones, thus the configuration of the existing network will typically drive the choice of which to utilize. In a lab or green-field environment where no other hosts are leveraging option 66 then this can be used and is commonly pre-defined as an available option on most DHCP servers. If some other devices are already leveraging option 66 then it may be best to utilize option 160 for these phones.

If planning to use option 160 with a DHCP server that does not already have it defined, like Microsoft Windows DHCP, then the option will first need to be created.

Using DHCP Manager highlight the network type object (e.g. IPv4) and then select the Set Predefined Options action.
Click Add to create a new option and then enter a descriptive name (e.g. UCS Boot Server Name). Change the Data Type to String and then enter 160 as the Code value. If desired add a Description and then save the new option.

Configure the Server Options under the same network scope and then select option 160 UCS Boot Server Name. For the data value use the format of <service type>://<fqdn> (e.g. ftp://ucs.schertz.name).

In the event that option 66 is to be used instead of option 160 then it can be defined in a Microsoft DHCP server by simply configuring the pre-defined option.

Using DHCP Manager configure the Server Options under an existing IPv4 scope and then enable option 066 Boot Server Host Name. For the data value use the format of <service type>://<fqdn> (e.g. ftp://ucs.schertz.name).

Time Server Location

Providing the location of a time server on the network is critical to operation of the phones, so if DHCP Option 42 is not already defined then it should be added to the same scope.

In the Server Options for the same scope enable 042 NTP Servers and then enter the IP address of at least one host which provides network time services (e.g. a Windows Active Directory Domain Controller).

Time Offset

Although the time server location will provide the accurate time required to perform authentication and registration processes the device will display the time in GMT by default. To show the correct local time on the phone’s display the standard time offset DHCP parameter can be used.

In the Server Options for the same scope enable 002 Time Offset and then enter the desired offset in seconds as a hexadecimal value (e.g. 0xffffaba0).

To calculate the correct hexadecimal value the Windows Calculator can be used in Programmer mode. The following example is used for the Central Time Zone which is GMT -6.

Enable Programmer Mode (Alt+3) and select Dec and Qword. Multiply the number of seconds in one hour (3600) by the desired offset value (make sure to include the negative sign if the time zone is earlier than GMT).

3600 x -6 = -21600

Select Hex to convert the value to hexadecimal.

FFFF FFFF FFFF ABA0

Select Dword to convert the string from 64 bits to 32 bits.

FFFF ABA0

Insert the 0x prefix and remove the space for the final value which should be used as the data in Microsoft DHCP.

0xFFFFABA0

Microsoft Vendor Class ID

For the purposes of this article it is assumed that the network is not pre-configured to support the Vendor Class DHCP Option 43 or Option 120 as documented in the article Configuring Lync Server for Phone Edition Devices. This option is leveraged by both UCS devices and Lync Phone Edition devices to download an internal, private certification authority (CA) certificate to establish TLS communications with the Lync Server as well as for supporting PIN Authentication. When option 43 is not defined on the network then the CA certificate must be provided by the provisioning server to support standard NTLM authentication with user credentials, but the Lync Server PIN Authentication feature would not be available.

At this point the example network configuration used for this article is simply using options 2, 42, and 160 as shown below.

Validate Configuration

Before moving on with additional customization make sure that the FTP server is discoverable, available and the desired user credentials are working correctly.

Using the Windows Command Prompt use the ftp command to connect to the site using the configured FQDN, username, and password.

The next step is to connect the phone to the network to make sure that the provisioning server is available before customizing any specific behavior on the phones. It is recommended to perform a full factory reset of the device first so that the process in this article can be followed without any problems created by any unknown settings. To reset the phone to factory defaults follow the Factory Reset process at the end of this article. If the phone’s current firmware does not match the version currently stored on the FTP server then the phone will automatically download and install that version after the first time it connects.

Connect the phone to the network and power it on. Once the startup process completes (and the firmware update process if triggered) and the main menu appears navigate to the Settings > Status > Platform > Configuration menu to check the provisioning server status.

If the configuration was successful then the phone should display the correct Boot Server and BootSrv Type options which were provided via DHCP. Because there are no custom settings yet defined then the Config value is blank. The three default configuration containers (SIP, Web, Local) should display zero parameters configured.

As previously mentioned the phones will not only attempt to pull down settings but also upload any local settings to the provisioning server directory. This allows the phones to backup any device-side settings to the central directory by creating two new files on the directory the first time they connect (if the files do not already exist).

To illustrate this process navigate to the Settings > Basic > Ring Type menu and select a different ring (e.g. #10 Beeble). Within a few seconds the device should save this change up to the provisioning server. Viewing the FTP service logs should show the device connect to the FTP site and upload a single file.

2013-05-10 16:12:16 192.168.1.100 SCHERTZ\PlcmSpIp 192.168.1.30 21 STOR 0004f28062d6-phone.cfg 226 0 0 c87c3435-b5d5-45ed-9d16-b1b291df24fc /0004f28062d6-phone.cfg

2013-05-10 16:12:46 192.168.1.100 SCHERTZ\PlcmSpIp 192.168.1.30 21 QUIT – 221 0 0 c87c3435-b5d5-45ed-9d16-b1b291df24fc –

Open the FTP root directory on the server and look for the newly created phone configuration file starting with the MAC address of the device and the suffix -phone. (e.g. 0004f28062d6-phone.cfg).

Open the file in an XML or Text viewer to view the newly defined configuration parameter in the OVERRIDES section.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!– Application SIP PrairieDog 4.1.4.0296 29-Nov-12 02:40 –>
<!– Created 10-05-2013 11:12 –>
<PHONE_CONFIG>
<OVERRIDES np.normal.ringing.calls.tonePattern="ringer10"/>
</PHONE_CONFIG>

During the initial connection to the FTP server the phone should have also uploaded separate application and boot log files into the defined log directory. (Or at the root of the FTP directory in the event that the CALL_LISTS_DIRECTORY parameter was left undefined). These logs can be used to troubleshoot registration problems or other issues if needed. Be aware that if a separate log directory is defined the phone may initially create these two logs files in the root directory during the first connection, but after pulling down the custom setting will then create new log files in the specified directory. It is safe to delete any orphaned log files in the root directories in this case.

Configuring Global Settings

At this point a basic provisioning server has been established, but nothing has yet been done to facilitate Lync interoperability with the SIP phones. As covered in a previous article the UCS 4.1 software versions provide a Base Profile configuration which can be used to put the device into Lync mode. While this can be set manually on each phone, it is also possible to set this centrally.

The example configuration in this article will show how to centrally provision two phones so that once each is powered on from a factory-reset state they will automatically enable Lync mode, and populate some or all of the user credentials. The Polycom UC Administrator’s Guide covers many of the configurable parameters and can be used as a detailed reference for additional customization.

The general approach is to use a combination of files to provide various settings to the phones in an efficient manner. Any parameters which would be configured on all devices should be defined in a single, shared configuration file (separately from the master configuration file) while device-specific settings would be included in a separate file for each phone. This article will start with using just a single global configuration file and then move on to adding a per-device file to illustrate how either one or both scenarios can be leveraged.

For editing the configuration files it is recommended to use an XML editor as it is easy to make simple formatting mistakes when using a basic text editor which in turn could prevent the phones from importing the data correctly. XML Notepad 2007 from Microsoft is used throughout the examples in this article. (If installing XML Notepad 2007 on Windows Server 2012 make sure to install the .NET Framework 3.5 feature first which includes the prerequisite 2.0 components.)

Master Configuration File

Actual device settings are not defined in the master configuration file, instead this file can be configured to point the phone to additional configuration files which will store the desired settings. The names of these files need to be manually defined in the CONFIG_FILES parameter which supports one or more entries in a comma-separated list.

In the FTP root directory edit the Master Configuration File (000000000000.cfg) and add the device-specific file mask entry following value to the CONFIG_FILE parameter and save the file.

CONFIG_FILES="shared.cfg”

Shared Configuration File

Now that a shared configuration file has been defined (shared.cfg) the file needs to be created and populated with the desired parameters. Basically any parameter where every phone in the environment needs to receive the same value is a candidate for including in this file. In this example file three things will be addressed that will impact every Polycom UCS phone that is placed on the network.

Most importantly the Base Profile will be set to Lync mode using the following set of parameters. Some of the official Polycom provisioning guides do not cover this base profile approach and instead recommend to include a group of about 30 different parameters for Lync interoperability. All of those settings are pre-programmed into the Lync Base Profile which was introduced in the 4.1.0 release, so there is no longer any need to define all those other settings.

device.set="1"

device.baseProfile.set="1"

device.baseProfile="Lync"

Secondly the root CA certificate is provided to the phone so that it will trust the certificate issued to the Lync Server to allow for secure TLS communications. In the event that the DHCP server is already configured correctly with DHCP Options 43 and 120 then this parameter can be omitted from the configuration file. There is no need to pass a private CA certificate in this manner as UCS will utilize DHCP 43 to locate the Lync Certificate Provisioning service and automatically download the certificate.

sec.TLS.customCaCert.1="—–BEGIN CERTIFICATE—– MIIDazCCAlOgAwIBAgIQUuNtVsIFbI5GvIJV0CDH3TANBgkqhkiG9w0BAQsFADBI MRQwEgYKC2d5H6ghLGQBGRYEbmFtZTEXMBUGCgmSJomT8ixkARkWB3NjaGVydHox
<<<snipped>>>
w6/GfOTi9Ce/qI7u20OpLZpPmp8HPiZhDPe5WkAe+BdhvmYTrOq6mfq24mfgSysS DPH/HAGcv81DVkOwsNMQrO+lggZAfl7t0BuobPdhvA4ELfF+XIejjoJ2XHueGxIR dfgh8erdcgh28or83/2Bv —–END CERTIFICATE—– "

And finally when DHCP Options 43 and 120 are not defined on the network then PIN Authentication is not available. By default the phone displays the PIN Authentication sign-in screen after the Lync base profile is selected, thus it would be ideal to disable the feature on the phone when not available to prevent a poor user experience. So if DCHP Options 43 and 120 are configured then this setting can also be omitted to utilize PIN Authentication. (Currently only the VVX 300 through 600 models support PIN Auth; any of the SoundPoint or SoundStation devices will ignore this parameter.)

reg.1.auth.usePinCredentials="0"

To create the customized shared file simply copy the text in the following box and then paste into a new text file.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<!–Sample Polycom Shared configuration file for UCS–>

<LYNC>

<device device.set="1" device.baseProfile.set="1" device.baseProfile="Lync"/>

<registration reg.1.auth.usePinCredentials="0" sec.TLS.customCaCert.1="—PASTE CERTIFICATE HERE—"/>

</LYNC>

Save the text file into the root of the FTP directory (e.g. "c:\inetpub\ucs\shared.cfg")

To locate the certificate trusted by the environment’s Lync Server follow the directions in the first section entitled Retrieving the CA Certificate Hash in this previous article. Disregard the remainder of that article as it is outdated and applies to older UCS firmware versions (4.0) which pre-date the Lync Base Profile.

Open the certificate file which was exported and saved in the other article and copy the entire contents of the file to the clipboard, including the BEGIN and END strings.

Then open the shared.cfg file in XML Notepad and then paste the contents of the clipboard directly into the sec.TLS.customCert.1 parameter and save the changes to the file.

The completed configuration file should look similar to the following example.

Note that the names used in the XML tags (e.g. LYNC, device, registration) have no special meaning and are only provided as a way to organize groups of parameters for easy reading. Any name could be used, or if desired all parameters could be defined under the primary Lync tag as the file hierarchy is also not important. The phone will simply read in all defined parameters in the file as long as at least one tag is defined. The device configuration file example in the next section will use this approach to illustrate that either format is acceptable.

Test Registration

At this point the phones have enough information to register to Lync Server and it would be possible to simply enter the SIP address and user credentials for a Lync User directly on the phone itself. Now is a good time to validate that this is functional in the environment before moving on to provisioning any additional account registration information.

Reboot the phone by either disconnecting the power temporarily or by selecting the Settings > Advanced > Reboot Phone menu option.

After the device completes rebooting it should have picked up the new configuration options in the shared file which will trigger Lync mode then default to the displaying the Sign In menu.

Using the phone’s keypad or on-screen keyboard enter the SIP Address, Active Directory Domain name, User name, and Password for the desired account. The Domain field can be populated with either the NetBIOS Domain Name (e.g. SCHERTZ) or the DNS Domain Name (e.g. schertz.name). In the User field if the user account’s sAMAccountName and Username are not identical in AD then make sure to use the value that matches the domain name format selected. (For additional details it is suggested to read through the Understanding Active Directory Naming Formats article.)

Once the credentials are entered select the More button and then select the Sign In button. After a few seconds the phone should report a successful registration to Lync Server.

Depending on the configuration of the Lync user’s Line URI field the Line 1 button will either show the extension, full telephone number, or Display Name of the user account.

To review the current configuration status on the phone navigate to the Settings > Status > Platform > Configuration menu to check the provisioning server status.

The Config value should show the name of the shared configuration file as well as the number of parameters imported from each source. The 5 parameters configured in the shared.cfg file are reflected in this screenshot.

Configuring Per-Device Settings

Moving on with the automatic provisioning process for the phones there are two options available for providing credentials to the phone instead of having to enter them manually into the device itself. One approach can be used to send the full set of credentials to the device, including the password, for a zero-touch administration scenario by defining per-line registration parameters. In this scenario the credentials cannot be viewed or managed directly on the device so this is typically intended for devices used in common areas or meetings rooms where the associated AD account can be configured with either no password expiry or the central configuration files can be updated with new password by an administrator.

The alternative approach is to pre-populate all but the password field in the phone’s actual Login Credential store. It is not possible to send the password using this approach but the rest of the credentials can be pre-configured. This would provide a near-complete provisioning process in which the end-user is responsible for entering only their password into the phone to complete the registration process, saving them from having to enter the rest of the information on the phone themselves.

In this section two unique device configuration files will be created for two separate phones. The VVX400 that has been used throughout this article will be configured using the scenario where the Login Credentials are pre-populated, except for the password. This would best match an information worker scenario where a user is assigned their own phone. Additionally a SoundPoint IP 331 will be used to illustrate a completely automated registration process which better suits shared or common area scenarios where the user credentials are centrally managed.

Master Configuration File

Just as before the new device files will need to be defined in the master configuration file so that the phone knows to download it. The CONFIG_FILES parameter supports multiple entries in a comma-separated list and special masks are understood by the software so that devices can locate files only intended that that specific device without having to specify the actual device file name for every phone which would simply not scale well beyond a handful of devices.

In the FTP root directory edit the Master Configuration File (000000000000.cfg) and add the device-specific file mask entry of [MACADDRESS]-lync.cfg value to the existing CONFIG_FILE parameter by using a comma separator.

CONFIG_FILES="shared.cfg,[MACADDRESS]-lync.cfg”

The string [MACADDRESS] is used in the master configuration file to tell a device to look for a file matching the defined pattern with its MAC address in the name. For example the entry ‘[MACADDRESS]-foo.cfg’ would tell a device with the MAC address of 01-02-03-aa-bb-cc to look specifically for a file named ‘010203aabbcc-foo.cfg’. Although most any name can be chosen the suffixes of -phone and -web are reserved for special files that the phone manages itself. The examples throughout this article will utilize -lync as the suffix for device-specific configuration files.

A suffix is required as the file cannot simply be named with only the MAC address (e.g. 010203aabbcc.cfg) as that filename is reserved for a device-specific master configuration file. That file would need to basically be a duplicate of the generic 000000000000.cfg file but with unique master configuration data specific to a device.

Device Configuration Scenario 1

The following set of parameters will be used for the VVX400 device file and will prep-populate the user’s SIP Address, user name, and domain name. Notice that although the SIP address is stored in a line registration parameter (reg.1.*) the remaining parameters will pre-populate the device’s Login Credentials store (device.logincred.*).

reg.1.address="vvx400@mslync.net"

device.logincred.domain.set="1"

device.logincred.domain="SCHERTZ"

device.logincred.user.set="1"

device.logincred.user="vvx400"

To create the device file simply copy the text in the following box and then paste into a new text file.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<!–UCS Device Configuration file for Lync–>

<LYNC reg.1.address="vvx400@mslync.net" device.logincred.domain.set="1" device.logincred.domain="SCHERTZ" device.logincred.user.set="1" device.logincred.user="vvx400"/>

Save the text file into the root of the FTP directory utilizing the desired device’s MAC address in the name (e.g. "c:\inetpub\ucs\0004f28062d6-lync.cfg")

Open the new file in XML Notepad and then replace the example SIP address and credentials with valid information for the desired Lync user account.

If using the same phone which was manually registered in the previous step then reset the phone to factory defaults again by following the Factory Reset process at the end of this article. This will remove the current user and configuration and then automatically reapply all the settings defined on the FTP server.

Test Registration Scenario 1

After resetting the phone view the current configuration status on the phone by navigating to the Settings > Status > Platform > Configuration menu.

The Config value will now show the names of both the shared configuration file and the device configuration file for this phone. The number of parameters imported from each file is reported as well.

Return to the Home Screen on the phone and select More then Sign In.

The resulting Sign In menu should show the pre-populated user information. Manually enter the password and then select More > Sign In. A successful registration should be reported just as seen in the earlier attempt.

The obvious benefit of this scenario is that the end-user was only required to enter their password which greatly reduces the time and complexity involved in entering a full set of credentials as well as having to understand exactly what to enter in terms of domain names. In the event that the password changes on the AD user account the phone will remain connected to Lync and still be able to register even after rebooting the phone. This is because after the initial registration with user credentials the phone will be issued a client certificate by the Lync Server and then use TLS-DSK for all subsequent authentication attempts. This works even in the absence of DHCP 43/120 options which is only required for PIN Authentication to be used as the initial registration process.

Device Configuration Scenario 2

The following set of parameters will be used for the SoundPoint IP 331 device file to fully provision the entire set of user credentials to a phone and trigger an automatic registration. Using this approach requires that the previously used Login Credential feature of the phone is disabled and the user credentials are stored in the registration parameters for a specific phone line (reg.1.*).

reg.1.auth.useLoginCredentials="0"

reg.1.address="spip331@mslync.net"

reg.1.auth.domain="SCHERTZ"

reg.1.auth.userId="spip331"

reg.1.auth.password="Pass123"

To create the first device file simply copy the text in the following box and then paste into a new text file.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<!–UCS Device Configuration file for Lync–>

<LYNC reg.1.auth.useLoginCredentials="0" reg.1.address="spip331@mslync.net" reg.1.auth.domain="SCHERTZ" reg.1.auth.userId="spip331" reg.1.auth.password="Pass123" />

Save the text file into the root of the FTP directory utilizing the desired device’s MAC address in the name (e.g. "c:\inetpub\ucs\0004f2a6af1b-lync.cfg")

Open the new file in XML Notepad and then replace the example SIP address and credentials with valid information for the desired Lync user account.

If using the same phone which was manually registered in the previous step then reset the phone to factory defaults again by following the Factory Reset process at the end of this article. This will again remove any existing configuration and then automatically reapply all the settings defined on the FTP server.

Test Registration Scenario 2

Because the full set of credentials have been supplied in the line registration parameters then the phone should have automatically registered successfully after resetting.

The main screen should show the Lync user’s phone number indicating that the registration is active. To validate this navigate to the Status > Lines > Line Information menu.

The latest configuration status on the phone can be confirmed by navigating to the Settings > Status > Platform > Configuration menu to verify the provisioning server status.

The SoundPoint IP models do not currently support PIN Authentication so the parameter to disable that feature will not be recognized, resulting in 1 error reported in the shared configuration file.

Managing Firmware Updates

When new firmware versions are published for different Polycom SIP phones the associated package can be downloaded and easily added to the provisioning server’s root directory. Make sure never to simply copy over all the files though as this might overwrite a customized master configuration file and break the integration; only use the firmware files provided in the package.

Open the software release package and extract only the .sip.ld files copying them into the FTP root directory (or wherever the firmware files are stored on the provisioning server if a custom directory was configured).

As long as the firmware file stored on the server is a different version, newer or older, than what the device currently has installed then it will download and update the firmware automatically at the next reboot.

The following table can be used as a reference for the latest recommended versions of each model phone for Lync interoperability. The uncompressed file size of each firmware image is also provided as a way to help identify which release package an individual file might be from.

Device Firmware File 4.1.0i 4.1.2b 4.1.4

SoundPoint IP 321 2345-12360-001.sip.ld 3,793 KB

SoundPoint IP 331 2345-12365-001.sip.ld 3,793 KB

SoundPoint IP 335 2345-12375-001.sip.ld 3,793 KB

SoundPoint IP 450 2345-12450-001.sip.ld 4,452 KB

SoundPoint IP 550 2345-12500-001.sip.ld 3,851 KB

SoundPoint IP 560 2345-12560-001.sip.ld 3,851 KB

SoundPoint IP 650 2345-12600-001.sip.ld 3,851 KB

SoundStation IP 5000 3111-30900-001.sip.ld 4,087 KB

SoundStation Duo 3111-19000-001.sip.ld 4,846 KB

VVX 300 3111-46135-002.sip.ld 50,159 KB

VVX 310 3111-46161-001.sip.ld 50,159 KB

VVX 400 3111-46157-002.sip.ld 50,159 KB

VVX 410 3111-46162-001.sip.ld 50,159 KB

VVX 500 3111-44500-001.sip.ld 58,517 KB

VVX 600 3111-44600-001.sip.ld 58,517 KB

All of the devices listed above are currently qualified for both Lync 2010 and 2013 environments when running on at least the firmware versions indicated.

Filed under Lync, Voice · Tagged with Polycom, UCS

April 2013 Lync Users Group Meeting

April 7, 2013 by Jeff Schertz · 4202Leave a CommentApril+2013+Lync+Users+Group+Meeting2013-04-07+15%3A35%3A06Jeff+Schertz

The second round of quarterly Lync Users Group meetings for 2013 have been scheduled and announced for this month.

Presentations will be provided on two topics: Lync 2013 Mobility and Lync 2013 Video & Interoperability.

A local UC expert will be on hand to present on Mobility while a Polycom Solutions Architect will be providing the Video & Interoperability session.

Polycom is a special sponsor of this event providing food and beverage, as well as a Lync Qualified VVX 500 IP Phone as a giveaway for one lucky attendee, so please be sure to visit an event near you.

The list of scheduled events is provided below with a link to each regional group’s Meetup page. To sign-up for any event simply create a Meetup account if you do not already have one and then confirm your attendance on the event page.

Date	Location	Address
April 16th 6:00 PM	Cincinnati UC User Group	Microsoft Office 4605 Duke Drive, Suite 800 Mason, OH 45040
April 16th 6:00 PM	Detroit UC Users Group	Microsoft Technology Center 1000 Town Center Drive, 19th Floor Southfield, MI 48075
April 17th 4:00 PM	Columbus UC Users Group	Microsoft Office 8800 Lyra Drive, 4th Floor Columbus, OH
April 17th 1:00 PM	New York UC Users Group	Microsoft Technology Center 1290 Avenue of the Americas, 5th Floor New York, NY, 10104
April 23rd 6:00 PM	Atlanta UC Users Group	Microsoft Technology Center 1125 Sanctuary Parkway, Suite 300 Alpharetta, GA 30009
April 25th 6:00 PM	Chicago UC Users Group	Microsoft Technology Center 200 East Randolph Drive, Suite 200 Chicago, IL 60601
April 30th 6:00 PM	Nashville UC Users Group	Microsoft Office 2555 Meridian Blvd, Suite 300 Franklin, TN 37067
May 1st 11:00 AM	Wisconsin UC Users Group	Microsoft Office N19 W24133 Riverwood Dr, Suite 150 Waukesha, WI 53188

Additionally there are plans to begin recording some meeting sessions to provide for offline viewing of presentation for member who are unable to attend in person.

As usual I will be hosting the Chicago area event, but I will be presenting the Video sessions on-site at both of the Chicago and Detroit meetings. Hope to see you there.

Filed under Lync · Tagged with Events

Lync Server 2013 Deployment – Part 2

March 22, 2013 by Jeff Schertz · 410938 CommentsLync+Server+2013+Deployment+-+Part+22013-03-22+13%3A22%3A28Jeff+Schertz

Continuing from Part 1 of the series this article covers the installation and configuration of the Lync Server components on a Standard Edition Front End server. As with the previous article any mandatory steps are identified by bulleted paragraphs while additional steps for validation and knowledge transfer are optional.

Install Lync Server System

The next step is to install a second SQL Express named instance called RTCLOCAL on the local server which will contain a replica of the existing RTC named instance.

Only the first Standard Edition server in the organization would contain the authoritative RTC instance installed in the previous article, while all other Lync Front End Servers (and even Edge Servers) would contain their own RTCLOCAL instance to replicate the Central Management Store data. This approach also allows for redundancy and availability features which were lacking in previous versions of OCS. This RTCLOCAL instance can only ever be stored in an automatically installed SQL Express instance, it is not supported to locate this data in a full SQL Server instance on a Standard Edition server installation.

As the Administrative Tools have already been installed on the server then the Lync Server 2013 Deployment Wizard can be found in the Start Menu on the local server. The Lync Server installation media is no longer required as the installation files have been copied to the server in the following default directory.

%ProgramFiles%\Microsoft Lync Server 2013\Deployment

On the Windows Start Menu search for ‘Deploy’ to locate and launch the Lync Server 2013 Deployment Wizard. From the main menu select Install or Update Lync Server System.
On Step 1: Install Local Configuration Store select Run and leave the default setting of Retrieve the configuration data directly from the Central Management Store and complete the wizard.

Reviewing the results in the execution window should confirm that the second SQL Express instance of RtcLocal was installed as well as the core Lync Server components.

Checking prerequisite PowerShell…prerequisite satisfied.
Checking prerequisite WindowsIdentityFoundation…prerequisite satisfied.
Checking prerequisite SqlInstanceRtcLocal…installing…success
Checking prerequisite VCredist…prerequisite satisfied.
Checking prerequisite SqlNativeClient…prerequisite satisfied.
Checking prerequisite SqlClrTypes…prerequisite satisfied.
Checking prerequisite SqlSharedManagementObjects…prerequisite satisfied.
Checking prerequisite UcmaRedist…prerequisite satisfied.
Installing OcsCore.msi(Feature_LocalMgmtStore)…success

Secondly the Local CMS replica was instantiated by importing the configuration from the existing CMS database an then replicating the database data itself.

Import-CsConfiguration -FileName "C:\Users\ADMINI~1.SCH\AppData\Local\Temp\2\CSConfigData-2013_03_16-08_10_01.zip" -Verbose -LocalStore

> Enable local replica service

Enable-CSReplica -Verbose -Confirm:$false -Report "C:\Users\administrator.SCHERTZ\AppData\Local\Temp\2\Enable-CSReplica-[2013_03_16][08_08_59].html"

An additional step is performed here which is new to Lync 2013: the automatic replication of certificates to the CMS. Although no certificates have been installed yet for this deployment had there been one then this action would have replicated any existing OAuth certificates required for server to server MTLS communications in Lync Server 2013.

> Replicate-CsCmsCertificates

Logging status to: C:\Users\administrator.SCHERTZ\AppData\Local\Temp\2\ReplicateCMSCertificates-[2013_03_16][08_08_59].html

To confirm the installation location of the RTCLOCAL database files on the server check the default SQL Server installation directory for the existence of the xds files.

%ProgramFiles%\Microsoft SQL Server\MSSQL11.RTCLOCAL\MSSQL\DATA

On the Lync Server 2013 Deployment Wizard advance to Step 2: Setup or Remove Lync Server Components and click Run to start the Set Up Lync server Components wizard.

Once again the Bootstrapper application will execute and perform a prerequisite check before installing additional components. These include a third SQL instance called LyncLocal and additional Windows Speech components and foreign language packs.

Checking prerequisite SqlSharedManagementObjects…prerequisite satisfied.
Checking prerequisite UcmaRedist…prerequisite satisfied.
Checking prerequisite WinFab…installing…success
Checking prerequisite MicrosoftIdentityExtensions…installing…success
Checking prerequisite SqlInstanceLyncLocal…installing…success
Checking prerequisite SqlInstanceRtc…prerequisite satisfied.
Checking prerequisite RewriteModule…installing…success
Checking prerequisite SpeechPlatformRuntime…installing…success
Checking prerequisite MSSpeech_TTS_ca-ES_Herena…installing…success
Checking prerequisite MSSpeech_TTS_da-DK_Helle…installing…success

Immediately following will be the installation of the Lync server components which make up the different services and roles on the Front End server (e.g. AVMCU, Mediation Server).

Installing OcsMcu.msi(OcsMCUCommon, ASMCU, AVMCU, IMMCU)…success
Installing AppServer.msi(Feature_AppServer)…success
Installing Ats.msi(Feature_Ats)…success
Installing CPS.msi(Feature_CPS)…success
Installing DataMcu.msi(Feature_DataMCU)…success

During the WebComponents installation a number of features will be installed which are the different virtual web directories and application pools in IIS.

Installing WebComponents.msi(Feature_Web_Common, Feature_Web_External, Feature_Web_GroupExpansion_Ext, Feature_Web_HybridConfig_Ext, Feature_Web_Internal, Feature_Web_JoinLauncher_Ext, Feature_Web_JoinLauncher_Int, Feature_Web_LocationInfo_Int, Feature_Web_Lwa_Ext, Feature_Web_Lwa_Int, Feature_Web_Mcx_Ext, Feature_Web_Mcx_Int,

To confirm the installation and configuration of the various web services launch Internet Information Services Manager (inetmgr.exe) and browse to the Sites folder to see the status of the two new web sites.

Then select the Application Pools object to view the various Lync web services which were installed for both the internal and external web sites.

Also check the installed services by running the Services control panel applet (services.msc). They will not yet be running as server certificates must be imported first, which is the next step in the deployment.

To review exactly what SQL instances were installed and their roles the Microsoft SQL Server Management Studio (if installed as covered in the previous article) can be used to view each instance and database.

Instance Database Description

RTC lis Location Information Services data

RTC xds Central Management Store data

RTCLOCAL rtc Standard Edition Pool data

RTCLOCAL rtcdyn Standard Edition transient user data

RTCLOCAL xds Local replica of Central Management Store data

LYNCLOCAL lyss Lync Storage Service data

Returning to the server deployment process the next step is to request and assign server certificates so that the Lync services can be started.

Run Step 3: Request, Install or Assign Certificates and then expand the Default Certificate entry to verify that all roles are checked. Click Request to start the Certificate Request wizard and enter the information listed in the following tables.

Delayed or Immediate Requests

Send the request immediately to an online certificate authority

Choose a certificate Authority

Select from a list detected in your environment
(DC.schertz.name\schertz-RootCA)

Certificate Authority Account

Skipped as the current Administrator account has sufficient permissions to perform this action.

Specify Alternate Certificate Template

Skipped as the Windows CA certificate template of ‘Web Server’ will be used by default.

Name and Security Settings

Friendly Name Lync Front End Cert

Bit Length 2048

”Mark the certificate’s private key as exportable”

Organization Information

Organization Schertz Lab

Organizational Unit Home

Geographical Information

Country/Region United States

State/Province Illinois

City/Locality Chicago

Subject Name / Subject Alternate Names

The following names will be automatically populated for the subject name and subject alternative name.

Subject Name lync.schertz.name

Subject Alternative Name lync.schertz.name
dialin.mslync.net
meet.mslync.net
admin.mslync.net
Lyncdiscoverinternal.mslync.net
Lyncdiscover.mslync.net

SIP Domain setting on Subject Alternate Names (SANs)

Configured SIP Domains mslync.net

Configure Additional Subject Alternate Names

Skipped as no additional SIP domains are configured in the topology so there are none to add to the certificate request.

Completing the process will execute the Request-CsCertificate cmdlet with the provided configuration information, performing an online certificate request against the CA and then automatically importing the issued certificate into the Local Computer store. (The following results were snipped down to just the important items.)

> Request Certificate

Request-CSCertificate -New -Type Default,WebServicesInternal,WebServicesExternal -CA "DC.schertz.name\schertz-RootCA" -Country US -State "Illinois" -City "Chicago" -FriendlyName "Lync Front End Cert" -KeySize 2048 -PrivateKeyExportable $True -Organization "Schertz Lab" -OU "Home" -DomainName "sip.mslync.net" -AllSipDomain -Verbose -Report

Create a certificate request based on Lync Server configuration for this computer.
Issued thumbprint "C6D87D6224A91E103734C582034E7FBE22F46A4A" for use "Default,WebServicesInternal,WebServicesExternal" by "DC.schertz.name\schertz-RootCA".
No changes were made to the Central Management Store.

"Request-CSCertificate" processing has completed successfully.

In the next window verify that Assign this certificate to Lync Server certificate usages is selected and then click Finish to launch the Certificate Assignment wizard next.
Complete the wizard which automatically runs the Set-CsCertificate cmdlet to assign the desired certificate to the three server usages.

> Assign Certificate

Set-CSCertificate -Type Default,WebServicesInternal,WebServicesExternal -Thumbprint C6D87D6224A91E103734C582034E7FBE22F46A4A -Confirm:$false -Report

The following certificate was assigned for the type "Default":
Default: C6D87D6224A91E103734C582034E7FBE22F46A4A lync.schertz.name 03/16/2015 CN=schertz-RootCA, DC=schertz, DC=name 5A0000000313D2DB08C6C90DCE000000000003

The following certificate was assigned for the type "WebServicesInternal":
WebServicesInternal: C6D87D6224A91E103734C582034E7FBE22F46A4A lync.schertz.name 03/16/2015 CN=schertz-RootCA, DC=schertz, DC=name 5A0000000313D2DB08C6C90DCE000000000003

The following certificate was assigned for the type "WebServicesExternal":
WebServicesExternal: C6D87D6224A91E103734C582034E7FBE22F46A4A lync.schertz.name 03/16/2015 CN=schertz-RootCA, DC=schertz, DC=name 5A0000000313D2DB08C6C90DCE000000000003

At this point the main Certificate Wizard window should reflect the new status by adding a green check mark to the Default certificate and its usages.

Since this is the first Lync 2013 server in the topology then an additional shared certificate needs to be created for use with a new open authentication standard called OAuth. This certificate will be used for server-to-server communications between Lync 2013 servers in addition to other 2013 products which support OAuth like Exchange Server and Office Web Apps Server.

On the main Certificate Wizard window expand and highlight the OAuthTokenIssuer entry and click Request to start the Certificate Request wizard and enter the information listed in the following tables.

Delayed or Immediate Requests

Send the request immediately to an online certificate authority

Choose a certificate Authority

Select from a list detected in your environment
(DC.schertz.name\schertz-RootCA)

Certificate Authority Account

Skipped as the current Administrator account has sufficient permissions to perform this action.

Specify Alternate Certificate Template

Skipped as the Windows CA certificate template of ‘Web Server’ will be used by default.

Name and Security Settings

Friendly Name Lync OAuth Cert

Bit Length 2048

Organization Information

Organization Schertz Lab

Organizational Unit Home

Geographical Information

Country/Region United States

State/Province Illinois

City/Locality Chicago

Subject Name / Subject Alternate Names

The following names will be automatically populated for the subject name and subject alternative name.

Subject Name lync.schertz.name

Subject Alternative Name <blank>

Configure Additional Subject Alternate Names

Skipped as no additional SIP domains are configured in the topology so there are none to add to the certificate request.

> Request Certificate

Request-CSCertificate -New -Type OAuthTokenIssuer -CA "DC.schertz.name\schertz-RootCA" -Country US -State "Illinois" -City "Chicago" -FriendlyName "Lync OAuth Cert" -KeySize 2048 -PrivateKeyExportable $True -Organization "Schertz Lab" -OU "Home" -AllSipDomain -Verbose -Report

Create a certificate request based on Lync Server configuration for this computer.
Issued thumbprint "2A55DA39DD43DAEB2AC2510AFB61EE21103ADCDB" for use "OAuthTokenIssuer" by "DC.schertz.name\schertz-RootCA".
No changes were made to the Central Management Store.

"Request-CSCertificate" processing has completed successfully.

In the next window verify that Assign this certificate to Lync Server certificate usages is selected and then click Finish to launch the Certificate Assignment wizard.
Complete the wizard which automatically runs the Set-CsCertificate cmdlet to assign the desired certificate to the OAuth usage.

> Assign Certificate

Set-CSCertificate -Identity Global -Type OAuthTokenIssuer -Thumbprint 2A55DA39DD43DAEB2AC2510AFB61EE21AA6ADCDB -Confirm:$false -Report

The following certificate was assigned for the type "OAuthTokenIssuer":
OAuthTokenIssuer: 2A55DA39DD43DAEB2AC2510AFB61EE21AA6ADCDB mslync.net 03/16/2015 CN=schertz-RootCA, DC=schertz, DC=name 5A00000004B92C660018992201000000000004

> Export Global Configuration Store

Export-CSConfiguration -FileName "C:\Users\ADMINI~1.SCH\AppData\Local\Temp\2\CSConfigData-2013_03_16-13_27_15.zip"

> Import Local Configuration Store

Import-CSConfiguration -LocalStore -FileName "C:\Users\ADMINI~1.SCH\AppData\Local\Temp\2\CSConfigData-2013_03_16-13_27_15.zip"

> Replicate-CsCmsCertificates

The main difference between the two certificate requests is that the creation of the OAuth certificate also triggers a database replication task as this certificate is automatically replicated to all Lync Servers in the topology.

To review the new certificates on the server use either the Certificates snap-in available in the Microsoft Management Console (mmc.exe) or IIS Manager (inetmgr.exe). In IIS Manager for example highlight the server object in the Connections window and then open Server Certificates in the IIS section to view the two Lync server certificates.

View each certificate file to see the configured parameters and compare the Subject Name and SAN fields (the OAuth certificate will not include any SAN entries).

Returning to the Lync Server 2013 Deployment Wizard move on to Step 4: Start Services and click Run to trigger an automatic start of all Lync services. This process may take a few minutes as due to some service dependencies they are started in a specific order and not all simultaneously.

> Start Services

Start-CSWindowsService -NoWait -Verbose -Report

Start services for the Lync Server computer "lync.schertz.name".

"Start-CSWindowsService" processing has completed successfully.

To verify that all services have started successfully click Run on the Service Status (Optional) step to launch the Services control panel applet. Depending on how soon after the previous step this is performed one or more of the services may still be in a stopped or starting state. (Note that the Lync Server Audio Test Service will typically not be running as this service will routinely start and stop itself.)

If the Lync Server Front-End service (or any other prerequisite service) is still reported as starting then check the server CPU in Task Manager as it may still be fully tasked with all of the first-time processes performed after a fresh server installation.

DNS Configuration

Since this deployment is using a Standard Edition server then the required server host record (e.g. lync.schertz.name) already exists in the form of the Dynamic DNS record created by the server when it was previously joined to the domain. But a number of additional DNS records need to be manually created to match the various Autodiscover and Simple URLs which were defined in the topology in the previous article.

Review the Subject Alternative Name field on the Default certificate which was just assigned to the Front End server as it will contain all of the FQDNs which need to be represented in the appropriate internal DNS forward lookup zones.

DNS Name=sip.mslync.net
DNS Name=lync.schertz.name
DNS Name=dialin.mslync.net
DNS Name=meet.mslync.net
DNS Name=admin.mslync.net
DNS Name=LyncdiscoverInternal.mslync.net
DNS Name=Lyncdiscover.mslync.net

As mentioned the server FQDN is already automatically defined in the proper DNS zone so that entry can be ignored (e.g. lync.schertz.name). The Simple URLs (dialin, meet, admin) were manually created in the previous article after publishing the topology so all that remains to be created are the Automatic Client Sign-In and Autodiscover records.

It is important to understand the different between the legacy Automatic Client Sign-In process and the newer Lync Autodiscover approach as these are two completely different solutions.

In the legacy scenario OCS 2007 and Lync 2010 clients locate their SIP registrar directly by looking for one or more predefined hostnames (e.g. sip.<sipdomain>). Yet in the newer Autodiscover scenario Lync 2013 clients are programmed to first look for a different set of predefined hostnames (e.g. lyncdiscover.<sipdomain>). But these names will instead direct the client to a web service which will in turn respond back to the client with the appropriate SIP registrar URL. So in the first case the clients are attempting to locate a SIP registrar directly, where as in the second and more flexible solution they are attempting to locate a service which will tell them where to find their SIP registrar. This advancement in Lync provides for additional flexibility not previously made available, most notably the ability to support distributed Access Edge registrations in enterprise networks with multiple Edge pools.

Legacy Automatic Client Sign-In

This section is only required if any legacy clients will be used with the environment (e.g. Lync 2010). All Lync 2013 clients will leverage the newer Autodiscover process, although some 2013 clients still support this legacy mode as a fall-back.

Using DNS Manager create a new Host (A) record in the DNS zone which matches the SIP domain namespace (e.g. sip.mslync.net) using the same IP address as the Lync Front End server.

Create a new Service Location (SRV) record in the same zone (e.g. _sipinternaltls._tcp.mslync.net) and define the Port number as 5061 and the Host offering this service as the previously created host record (e.g. sip.mslync.net)

To verify the new DNS record configuration run the following command from the Windows Command Prompt.

C:\>nslookup -q=srv _sipinternaltls._tcp.mslync.net

_sipinternaltls._tcp.mslync.net SRV service location:
          priority       = 0
          weight         = 0
          port           = 5061
          svr hostname   = sip.mslync.net
sip.mslync.net internet address = 192.168.1.33

Lync Autodiscover

Either a Host (A) or an Alias (CNAME) record can be used for the Autodiscover records. But some Lync clients (primarily the mobility clients) do not support a CNAME record which points to a Host record in a different domain namespace, so in the topology used in this series of articles it would be poor practice to create an alias in the SIP domain namespace (e.g. lyncdiscoverinternal.mslync.net) which then pointed to the server’s FQDN (e.g. lync.schertz.name) in another namespace.

Thus two configuration possibilities are available: either use a Host record with the server’s IP address, or create an Alias record pointing to a Host record in the same namespace (e.g. sip.mslync.net). In an Enterprise Edition deployment this Lyncdiscoverinternal record would typically be an alias pointing to the Internal Web Service FQDN (e.g. lyncweb.<sipdomain>) but as this is a Standard Edition server then in the internal web service FQDN is the same as the server’s FQDN (e.g. lync.schertz.name) so the simplest configuration would be to just create a host record here.

Only the Lyncdiscoverinternal entry should be created on internal DNS zones as Lyncdiscover is used by external clients and thus should be reserved for external DNS zones which will be addressed in a later article.

Create a new Host (A) record in the DNS zone which matches the SIP domain namespace (e.g. lyncdiscoverinternal.mslync.net) using the same IP address as the Lync Front End server.

Summary

If all has gone according to plan then the environment now includes a functional Lync Front End server which is ready for additional configuration and client testing which will be covered in Part 3 of the series.

Filed under Lync · Tagged with 2013

Lync Server 2013 Deployment – Part 1

March 16, 2013 by Jeff Schertz · 403523 CommentsLync+Server+2013+Deployment+-+Part+12013-03-16+16%3A32%3A16Jeff+Schertz

As provided in the past this series of basic deployment articles will be used to capture a specific environment used as the foundation for many other Lync Server 2013 specific deployment articles. Starting with a single Standard Edition Lync Server in a fresh Active Directory forest future articles will build on this deployment with additional component installation like Group Chat, Edge Services, Exchange Server integration, etc.

Throughout this series of articles the same basic instructional flow is used as in other articles. Although it may not have been obvious, the usage of bulleted items is intentionally specific. Steps starting with a bullet are typically mandatory to reach the same level of installation completion as the article intends to provide at the end. Yet normal paragraphs without bullets may include optional steps intended to provide a deeper understanding of a previous action or cover the installation of optional tools or components used to aid in knowledge transfer of the topic at hand. This format aids in skimming through the article for repeated installations.

Environment

For these articles specific to Lync Server 2013 a new lab environment has been created which is nearly identical to the one used in previous Lync Server 2010 articles. One important change worth noting is that the internal Active Directory namespace is now configured as schertz.name as opposed to the previously used schertz.local domain name. This was done to match newer best practices of moving away from using invalid Top Level Domain (TLD) names which would prevent the ability to issue public certificates for those internal services, as described in this previous article. The primary SIP domain namespace will continue to be mslync.net throughout all articles.

Physical Host: Windows Server 2008 R2 Hyper-V running on a Core2 Duo desktop-class system with 8GB RAM.
Domain Controller: A single Windows Server 2012 x64 Standard Edition guest promoted to a domain controller for the new Active Directory forest root domain of schertz.name.
Lync Server: A second virtual guest running Windows Server 2012 x64 Standard Edition and joined to the schertz.name domain.
The default domain administrator account used to perform all steps is a member of the Domain Admins, Enterprise Admins, and Schema Admins domain security groups.
The Forest and Domain functional levels were set to Windows Server 2012.
A Windows Enterprise Certificate Authority was deployed on the domain controller to provide SSL certificates for internal services. The CA configuration was updated to provide access to the Certificate Revocation List via HTTP, as explained in this article.

Server and Forest Preparation

Before installation any of the Lync Server components it is best to install any prerequisite components on the targeted server so that steps like Active Directory preparation are easily dealt with.

Mount the Windows Server 2012 installation media on the server to an available drive letter as some of the components to be installed will need to be read from the installation media as provided by the Source parameter in the following cmdlet (e.g. D:\sources\sxs).
Launch Windows PowerShell by selecting ‘Run As Administrator’ and enter the following cmdlet to quickly install the .NET Framework package, the Remote Server Administrative Tools, and all additional prerequisites followed immediately by a required server reboot. (The Telnet Client is not a requirement but is helpful to have installed when troubleshooting any connectivity issues.)

Install-WindowsFeature RSAT-ADDS, Web-Server, Web-Static-Content, Web-Default-Doc, Web-Http-Errors, Web-Asp-Net, Web-Net-Ext, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Http-Logging, Web-Log-Libraries, Web-Request-Monitor, Web-Http-Tracing, Web-Basic-Auth, Web-Windows-Auth, Web-Client-Auth, Web-Filtering, Web-Stat-Compression, Web-Dyn-Compression, NET-WCF-HTTP-Activation45, Web-Asp-Net45, Web-Mgmt-Tools, Web-Scripting-Tools, Web-Mgmt-Compat, Windows-Identity-Foundation, Desktop-Experience, Telnet-Client, BITS -Source D:\sources\sxs -Restart

After the server finishes rebooting disconnect the Windows Server media and mount the Lync Server 2013 installation media.
Launch the Lync Server 2013 Deployment Wizard from the following path and then select Yes if prompted to install the Microsoft Visual C++ Runtime package.

D:\Setup\amd64\setup.exe

Confirm the default Installation Location or change the path to a different directory if desired.

C:\Program Files\Microsoft Lync Server 2013

At the main menu of the deployment wizard select Prepare Active Directory and then click Run on Step 1: Prepare Schema.

If deploying in an environment with a single domain controller there is no need to run the optional verification processes.

Select Run on Step 3: Prepare Current Forest and select the Local Domain as the Universal Group Location if desired. If Lync is being installed into a multiple domain forest and the universal groups need to be stored in a domain other than the domain that the current server is a member of then enter the desired domain FQDN.
Advance to Step 5: Prepare Current Domain to complete the Active Directory preparation steps.

To confirm some of the changes which were applied in these steps a few items can be spot checked.

Run adsiedit.msc and connect to the Schema container to view the properties for the following object. Confirm that the UpperRange attribute value is set to 1150 (which was incremented up from 1100 in Lync Server 2010).

CN=ms-RTC-SIP-SchemaVersion,CN=Schema,CN=Configuration,DC=schertz,DC=name

Run dsa.msc to open Active Directory Users and Computers and then browse to the default Users container. Look for a number of groups starting with ‘CS’ and ‘RTC’ in their names. These groups were created during the Forest preparation step in the chosen domain.

Run adsiedit.msc and connect to the Configuration container and browse to the following path. Notice that a number of empty containers have been created where some of the Topology configuration will be stored when later published.

CN=RTC Service,CN=Services,CN=Configuration,DC=schertz,DC=name

Lync Server Preparation

This process will install the SQL Native Client and SQL Server Express components, as well as configure Windows Firewall exceptions for remote SQL connectivity. Mostly importantly it also deploys a SQL Express named instance, simply called RTC. This instance will be the default location for the Central Management Store which is where Lync will store the majority of the global (forest-wide) configuration data. The RTC Service container shown above in the AD Configuration partition is still used to store some data, but mainly for coexistence with previous versions of OCS.

Return to the main menu of the deployment wizard and select Prepare First Standard Edition server. It is normal for the installation to take a few minutes to complete during this step.

A quick glance at the Programs and Features control panel shows all of the components which were installed on the server once this process is completed.

The SQL Server Configuration Manager can be used to verify that the local SQL services are properly installed and running.

The newly installed SQL Server Express instance default database files can be found in the following location.

%ProgramFiles%\Microsoft SQL Server\MSSQL11.RTC\MSSQL

Before moving further the domain Administrator account used throughout this process should be added as a member to the domain security groups CsAdministrator and RTCUniversalServerAdmins.

This user account should then logoff and back on to the Windows Server where Lync is being installed to update the associated security token. Once logged back on use the following whoami commands in the Windows Command Prompt to verify the new group membership.

whoami /groups /fo list | findstr /i CsAdmin
whoami /groups /fo list | findstr /i RTC

The final preparation step is to manually create a file share on the server which will later be referenced during the Lync Server topology configuration.

Create a new folder on the server (e.g. lyncshare) anywhere on the server. The following path was used in this lab deployment.

C:\LyncShare

Verify that the local Administrators group is already granted Full Control at the file permission level and then enable sharing for this folder. Provide a name for the new share (e.g. lyncshare) and then assign Full Control share permissions to the administrator account currently being used to perform the installation. These permissions will be more granularly defined when the Topology is published in a later step.

Deployment and Administration Tools Installation

Now that the first Lync server in the environment has been fully prepared the next step is install and run the Topology Builder tool.

Return to the main menu of the Lync Server 2013 Deployment Wizard and select the Install Administrative Tools option. An installation window will briefly appear followed by a green check box next to the component name in the wizard, indicating the installation was complete.

To verify the installation is is complete simply search the Windows Start Menu for “lync” to see the administrative tools.

Outside of the installation media Microsoft also provides a handful of great administrative and troubleshooting tools for Lync Server 2013. It is recommended to download and install each of these packages on the server as they include some important tools used in other blog articles like OCSLogger, Snooper, or DBAnalyze.

If all of the above packages are installed into the default directory then the tools can be found and launched from their respective installation directories.

%ProgramFiles%\Microsoft Lync Server 2013

Additionally it can be helpful to have access to the SQL Express database management tools on the local server. Normally this is not needed but can be used for following some of the validation steps throughout these articles. (Download and install only the SQLManagementStudio_x64_ENU.exe package from the following Microsoft Download page.)

Microsoft SQL Server 2012 Express – Management Studio

Topology Definition

This section covers creating a new Lync Topology in a new Active Directory forest and domain.

Launch the Lync Server 2013 Topology Builder application and select New Topology from the initial prompt.
Save a new .tbxml file with any desired name (e.g. lynctopo.tbxml).
For the Primary SIP domain enter the desired domain namespace (e.g. mslync.net).

Add any additional desired SIP domains at this point , but a single SIP domain is sufficient for most deployments as well as this series of articles.

Select a Name for the first site to be created in the topology (e.g. Chicago) and enter a Description if desired.
Specify the locality information associated with the first Lync site and then complete the wizard.

At this point the Define New Front End Pool wizard should be automatically launched.

On the Define Front End Pool FQDN page enter the Fully Qualified Domain Name (FQDN) of the Windows domain member server where the Lync Front End services will be hosted. This would be the same server that all of the prerequisite components have been installed on. Make sure that the server’s FQDN is correctly configured so that it matches exactly what is entered into the topology as this is how the later installation process identifies which components to install on the server.

Select Standard Edition Server and advance to the next page.

On the Select Features page choose the desired options for this installation. To start only Conferencing and Enterprise Voice features will be selected, with additional components to be addressed in later articles.

Retain the default enabled setting of Collocate Mediation Server on the Select Collocated Server Roles page.
On the Associate Server Roles with this Front End Pool page leave the option blank as an Edge Server does not yet exist. This setting will be addressed when an Edge Server is deployed in a later article.
As this is a Standard Edition server then there will be no configurable options available on the Define the SQL Store page. Take note of the automatically defined SQL Server store which is comprised of the server’s FQDN (lync.schertz.name) followed by the previously installed SQL Express instance name (RTC).

On the Define a File Store page enter the name of the Windows file share created in the previous section (e.g. lyncshare).

On the Specify the Web Services URL page the External Base URL will automatically be set to the same FQDN as the internal Front End server (e.g. lync.schertz.name). For the purposes of this article the default setting will be retained and in the future when external services are published this will be updated to reflect the external namespace.
The next page Select an Office Web Apps Server is new to Lync Server 2013 and is used to either define a new OWAS pool FQDN or associate this server with an existing OWAS pool. As a later article will cover deploying OWAS simply uncheck this option and then click Finish to complete the wizard. (Note that until this server is deployed that PowerPoint content sharing will be unavailable in Lync conferences as this is no longer performed by the Front End server.)

Upon completion the Topology Builder window should refresh and the defined settings will be populated as shown.

Back at the main Topology Builder window select Edit Properties on the Lync Server root-level object. Highlight the Simple URLs section and enter the desired Administrative Access URL (e.g. https://admin.mslync.net). Technically his is an optional step as the administrative access URL is not required, but is a recommended way to access the Lync Server Control Panel via a web browser internally.
Move down to the Central Management Server section and select the new Front End server (e.g. lync.schertz.name) as the location to install the CMS component on.

The final process is to publish the changes made to the topology into the Central Management Server database which also updates information in the RTC services container in Active Directory and sets up the folder structure and permissions on the file share.

From the Action menu select Publish Topology. The local server FQDN for the Central Management Store location should already be populated in the drop-down menu due to the previous step. If all configuration steps were performed correctly then the wizard should complete without any errors or warnings.

As indicated by the To-Do List shown under Next Steps a couple of DNS records will need to be manually created to match the FQDN set in the Lync Server topology.

Create new DNS Host (A) records for the Simple URLs on the internal DNS server’s forward lookup zone which match the SIP domain used. Each record should point to the static IP address used by the server where the Standard Edition roles will be deployed, thus the same IP address as the lync.schertz.name server is used for all records.

meet.mslync.net
dialin.mslync.net
admin.mslync.net

To validate and understand the changes the Topology Builder has applied to Active Directory there are a number of places to look throughout the various results logs, within Active Directory, and the SQL databases themselves.

Use adsiedit.msc to connect to the Configuration context and browse to the path shown below and notice that the previously empty containers are now populated with child objects and attributes.

CN=RTC Service,CN=Services,CN=Configuration,DC=schertz,DC=name

The SQL Server Management Studio tool (if installed) can be used to connect to the RTC instance on the Lync Server to view the databases new xds and lis databases.

The raw database files can be found on the Lync Server in the default installation directory shown below.

Additionally the defined file share is now populated with the new folder structure and the required share permissions.

Summary

At this point all organization preparation steps have been completed and the next article in the series will focus on installation of the actual Lync Server components to the Standard Edition Front End server.

Filed under Lync · Tagged with 2013

Breaking Down the Lync File Share

March 1, 2013 by Jeff Schertz · 39188 CommentsBreaking+Down+the+Lync+File+Share2013-03-01+14%3A42%3A39Jeff+Schertz

This article outlines the default folder structure and permissions created on the File Share when deploying a Lync 2013 Server Front End server or pool. Optional Lync services (like Persistent Chat) can trigger the creation of additional folders in the directory but for the purposes of this article only the default folders for a Standard Edition server are covered.

The general guidance is to manually create a new file share on the desired server and then set the share permissions to grant Full Control to the Administrators group. This will insure that the administrator account performing the Lync Server deployment will have sufficient rights to the file share and NTFS Access Control Lists (ACL) so that when publishing the Lync Topology the proper configuration is applied.

For the examples used in this article a single Standard Edition Lync 2013 Front End Server was deployed and the changes were captured to identify the default configuration for Lync. Although Lync 2010 uses nearly the same configuration there are a few changes to the folder structure among the various Web Services subfolders.

Root Directory

Prior to publishing the initial configuration of the Lync Topology the pool or server file share in this example was created at the root of the C: drive on the desired server. The Lync Front End server itself was used in this environment which is allowed only for Standard Edition servers, Enterprise Edition pool servers can not be collocated with the file share data as it must be hosed on a separate server or servers.

After every successful instance of publishing the topology (regardless of what has changed) Lync will refresh the correct permissions (if needed) on the directory structure throughout the file share. Thus if any undesired changes are made to any of the file structure permissions simply re-publish the topology in Lync to repair the configuration.

The following Access Control Entries (ACE) are assigned to the root directory of the Lync file share, in addition to any rights which might already assigned to that specific folder or any inherited from a parent folder.

Principal Access

NETWORK SERVICE Change

RTCHSUniversalServices Change

RTCComponentUniversalServices Change

RTCUniversalServerAdmins Change

RTCUniversalConfigReplicator Change

RTC Local Administrators Change

RTC Local Config Replicator Change

RTC Server Local Group Change

RTC Component Local Group Change

The root of the file share contains three primary folder used to store shared Server Application data, Central Management configuration data, and data used by the various Web Services in Lync.

These folder names are encapsulated in digits which denote the Site and Pool instance that each folder belongs to. The folder naming convention is <Site ID>-<Service ID>-<Pool ID>. In the above example the minimum folder configuration would reflect a single Site (ID 1) and Pool instance. If a Director server was later added to the existing site then a new folder would be automatically created as “1-WebServices-2” and if a second pool was deployed then that would be called “1-WebServices-3” and so on. In the event that a second site was defined and any pools are deployed in that site then new folders starting with “2-“ would be instantiated as well.

Application Server

The “1-ApplicationServer-1” folder contains data utilized by Lync applications like Call Park, Response Groups, and Call Admission Control. Within the child “AppServerFiles” folder the following three subfolders will exist be default.

The CPS folder is used by the Call Park Service.
The PDP folder name stands for Policy Decision Point and is used by Call Admission Control (CAC) to distribute policies defining some of the CAC rules.
The Rgs folder is used by the Response Group Service to store common data like Music On Hold audio files (.wav) configured on a Hunt Group. The “Rgs\Instances” and “Rgs\Queues” folders should contain a subfolder for each response group that is defined in the topology, but with nonsensical names reflecting a GUID associated to each one. There may also exist an “Rgs\Temp” folder which seems to store the originally uploaded music file.

The AppServerFiles directory is configured when publishing the topology with the following file permissions.

C:\LyncShare\1-ApplicationServer-1\AppServerFiles

Principal Access Applies To

NETWORK SERVICE Modify This folder, subfolders, and files

RTCComponentUniversalServices Modify This folder, subfolders, and files

RTCUniversalServerAdmins Modify This folder, subfolders, and files

RTC Server Local Group Modify This folder, subfolders, and files

RTC Component Local Group Modify This folder, subfolders, and files

Central Management

The “1-CentralMgmt-1” folder is used by the Central Management Server to temporarily store replication data sent to and from other active replication partners defined in the topology in the form of data.zip files containing XML data.

Under various subfolder (e.g. replicas, working\fta, etc) will be a list of all the Computer objects defined in the Topology which are enabled for replication. The following screenshots demonstrate how only the 4 objects enabled for replication will have an associated folder.

The CMSFileStore directory is configured when publishing the topology with the following file permissions.

C:\LyncShare\1-CentralMgmt-1\CMSFileStore

Principal Access Applies To

NETWORK SERVICE Modify This folder, subfolders, and files

RTCUniversalConfigReplicator Modify This folder, subfolders, and files

RTC Local Config Replicator Modify This folder, subfolders, and files

Web Services

From the introduction of web service applications in LCS to the latest release of Lync the amount of new features and functionality provided by IIS has grown steadily. In Lync Server 2013 the following subfolders will appear by default under the “1-WebServices-1” folder.

The ABFiles folder is probably the most familiar of all the web services as this folder stores the Lync Address Book files for distribution to many different Lync client types (e.g. Windows, Lync Phone Edition). At minimum a singe subfolder will exist using the default msRTCSIP-TenantID of all zeros (00000000-0000-0000-0000-000000000000). In a multi-tenant environment each unique tenant ID will have an associated folder of its own. The next level down will include another folder name with a string of zeros for the msRTCSIP-GroupingID which is used to create different address book file groups within the same tenant ID. Finally this folder will store the various *.lsabs and *.dabs files which are downloaded directly by Lync clients. Additionally the Invalid_AD_Phone_Numbers.txt file can be found in this directory.

The CollabContent, CollabJournal, and CollabMetadata folders are all used to store data associated with Lync multi-party conferences. Any attachments or PowerPoint files which are uploaded by Lync or Lync Web App attendees are stored by the server in the CollabContent directory underneath a subdirectory associated with the specific conference’s Focus ID.

The DataConf folder is new in Lync 2013 and stores conferencing data like whiteboarding information.

The DeviceUpdateLogs folder contains various types of logs files for Lync Phone Edition devices. The Client subfolder contains Windows CE (.clg1) and Dr.Watson (.log & .kdmp) files which are uploaded from Lync Phone Edition devices. These files are primarily meant to be used by Microsoft PSS as they require special tools (e.g. readlog.exe) to open and read. The Server subfolder contains daily log files created by the RequestHandler web application which report whenever a device queries the server for any new potential firmware update files.

The DeviceUpdateStore folder is where Lync saves any device update files which are published using the Import-CsDeviceUpdate cmdlet. There are two potential subfolders names depending on if any updates have been imported for any Lync phones. For all Lync Phone Edition devices the subfolder UCPhone is used to store each update package for every individual manufacturer, model, hardware revision, locale, and firmware version. For Lync Qualified devices a subfolder called 3PIP will be automatically created when importing any updates for these devices. (3PIP is shorthand for Third Party Interoperability Program).

The LMStaticData folder is another folder which can be used to store web conferencing related data.
The StorageService folder is new in Lync 2013 and is used by the Lync Storage Service (LSS) to store data that it uses with Exchange Server 2013 for a back-end data store.
The WebAuthStore folder stores copies of previously issued server certificates.

The following directories are configured when publishing the topology with the following file permissions.

C:\LyncShare\1-WebServices-1\ABFiles

Principal Access Applies To

NETWORK SERVICE Modify This folder, subfolders, and files

RTCHSUniversalServices Modify This folder, subfolders, and files

RTCComponentUniversalServices Read & Execute This folder, subfolders, and files

RTC Server Local Group Modify This folder, subfolders, and files

RTC Component Local Group Read & Execute This folder, subfolders, and files

C:\LyncShare\1-WebServices-1\DeviceUpdateLogs

Principal Access Applies To

NETWORK SERVICE Modify This folder, subfolders, and files

RTCComponentUniversalServices Modify This folder, subfolders, and files

RTCUniversalServerAdmins Modify This folder, subfolders, and files

RTC Server Local Group Modify This folder, subfolders, and files

RTC Component Local Group Modify This folder, subfolders, and files

C:\LyncShare\1-WebServices-1\DeviceUpdateStore

Principal Access Applies To

NETWORK SERVICE Read & Execute This folder, subfolders, and files

RTCComponentUniversalServices Read & Execute This folder, subfolders, and files

RTCUniversalServerAdmins Modify This folder, subfolders, and files

RTC Server Local Group Modify This folder, subfolders, and files

RTC Component Local Group Read & Execute This folder, subfolders, and files

C:\LyncShare\1-WebServices-1\CollabContent
C:\LyncShare\1-WebServices-1\CollabJournal
C:\LyncShare\1-WebServices-1\CollabMetaData
C:\LyncShare\1-WebServices-1\DataConf
C:\LyncShare\1-WebServices-1\LMStaticData
C:\LyncShare\1-WebServices-1\StorageService
C:\LyncShare\1-WebServices-1\WebAuthStore

Principal Access Applies To

NETWORK SERVICE Modify This folder, subfolders, and files

RTCComponentUniversalServices Modify This folder, subfolders, and files

RTC Component Local Group Modify This folder, subfolders, and files

Filed under Lync · Tagged with 2013

Certificate Revocation in Lync 2013

February 28, 2013 by Jeff Schertz · 39936 CommentsCertificate+Revocation+in+Lync+20132013-02-28+15%3A26%3A29Jeff+Schertz

With the introduction of new clients and services throughout Office 365, Lync Server 2013, and Office Web App Server there is now an even higher level of security enforced in relation to using SSL certificates. In the past Office Communicator and Lync clients would not require availability of revocation status for a certificate that was presented during authentication or TLS connections with any servers. But this has changed for some scenarios in Lync 2013 and it would be good guess that more clients will start enforcing this practice in future versions.

Currently the Windows Store App (aka RT or MX client) for Lync 2013 requires the ability to locate and access the Certificate Revocation List (CRL) for the Certificate Authority (CA) which issued the server certificate to the Lync server that it attempts to sign-in to. If the client is unable to validate that the certificate issued to the authenticating server has not been revoked then the RT client will display a generic error that it is unable to contact the server. Additionally if the standard Windows Lync 2013 client is installed on a workstation which is not a member of the same Windows domain as the Office Web App server then it will be unable to participate in PowerPoint sharing sessions.

This behavior was first reported by colleague Adam Jacobs in his article entitled Lync Online ADFS Sign-in Issues (server is unavailable) for non-domain joined client PCs and a Windows CA when initially testing connectivity leveraging Active Directory Federation Services utilized by Office 365. Another article on TechNet discusses how to resolve the same issue related to Office Web App server connectivity.

Background

Before going into further details about the root cause and resolutions it is important to understand what a Certificate Revocation List is and what purpose it serves.

The CRL is not a new concept, but it may be new to many Lync administrators as with anything else in the product from a security standpoint, if it was not enforced or required before then no one really needed to learn about it. But just as understanding the basic concept of SSL certificates became a necessity when Office Communications Server started using TLS for nearly all communications, security enhancements in Lync 2013 are doing this again for additional certificate capabilities.

Basically the CRL is exactly what is sounds like, a list of revoked certificates. Note that this is different than certificate expiration which is self-enforced. Since the beginning OCS and Lync has adhered to the expiration of a server certificate and when that date and time is reached services can stop running and clients will stop allowing connections to servers presenting an expired certificate. But in the event that the certificate issued to the server was previously revoked by the CA that may have not prevented anything from working normally as that data was not leveraged.

In practice most administrators probably do not take the time to actually go back to a CA and revoke certificates, but it would be a good practice to start now. For example in a deployment it might take two or three attempts at get a certificate formatted with all the names needed for an environment as it is not uncommon to spend some time running through different certificate requests until the proper one is found. All of the previous certificates issued to that server are still valid even if they are not being used, so it would be recommended to go to the Certificate Authority and revoke the unused certificates.

This concept has a bigger impact on internal communications for reasons which will be explained later on, as public certificates issued by trusted third-party CAs all provide access to their CRLs by default.

Configuration

An SSL certificate includes a standard extension entitled CRL Distribution Points (CDP) that includes paths which clients can use to locate the CRL. By default a Windows CA only provides an LDP URL to access this data, as shown in the following screenshot.

Another important parameter is the Authority Information Access (AIA) field which indicates how to access information like policy data or validation services related to the issuing CA. The location of CRLs is specifically provided by the CDP mentioned above, but it is important that access to both services be made available.

Now an internal, domain-connected Windows workstation would be able to access these locations via LDAP, but what about non-domain connected workstations or external clients? If those clients do not need to access CRL information, as was true in the past, then there is no problem. But clearly now that some clients do need to locate the CRL then this is a problem.

The first issue is that LDAP access is not sufficient for provide connectivity for these other client scenarios, so a better form of access is needed.

This article on NextHop by Rick Kingslan shows to modify the configuration on a Windows CA to add HTTP URLs to these parameters to start providing accessible paths to clients which are passed certificates issued by that CA.

But simply making these changes to the CA configuration is not enough, as that will only impact new certificate requests. The CA cannot automatically update the configuration of any previously issued certificates, so the next step is to reissue new certificates for all the internal servers and replace the old certificates.

After applying the configuration changes in Adam’s article to a Windows CA any newly issued certificates would now include an additional HTTP path to locate the CRL, as shown below.

To view the CRL itself simply connect to the published URL using a web browser and then download the CRL file when prompted.

Open the downloaded file in Windows and then navigate to the Revocation List tab to see any certificates which have been revoked by the CA.

To view the same information provided by a public CA simply locate the published CDP in any certificate issued by that CA and access the HTTP URL in a browser to download the associated CRL file.

For example here is the published HTTP CDP for a GoDaddy certificate.

The Revocation List on this CRL contains much more data than the earlier Windows CA example, literally thousands of entries identifiable only by their unique serial number.

Behavior in Lync 2013

This information above is exactly what the Lync 2013 RT client needs access to before it can successfully sign-in to a Lync Server.

The problem stems from the common use of a Windows Enterprise CA for issuing SSL certificates to all internal servers (e.g. Lync, Exchange, Office Web App). As seen here the Windows CA does not include the necessary HTTP path by default and thus should be added manually prior to issuing SSL certificates to the Lync server components. Additionally this also reduces the effectiveness of using a private internal certificate on an Edge server for testing as has been done in the past. It is not enough to simply import the root CA certificate (and issuing CA certificate is applicable) into the client workstation to test Edge connectivity with the RT app as now the CRL would also need to be made available. But if an internal certificate leverages internal namespaces then it may not technically be possible to publish the advertised HTTP URL anyways.

Thus when dealing with public certificates on Internet facing services like Edge and Reverse Proxy solutions there should be no problems getting these clients to connect, so these behavioral changes will really only impact internal connectivity.

So in summary it should now be considered a best practice to perform this additional CA configuration prior to deploying Lync Server to insure that clients can access CRL information from any location in which they may attempt signing in from. In general it would have always been a recommended practice to provide access to certificate revocation information, but it was not a necessity in OCS or Lync. In order to support the Windows RT client at minimum this configuration is no longer optional.

Filed under Lync · Tagged with 2013, Certificates

Lync Server ‘Certificate Cliff’

January 29, 2013 by Jeff Schertz · 396813 CommentsLync+Server+%27Certificate+Cliff%272013-01-29+14%3A19%3A51Jeff+Schertz

The average human interpretation of the Mayan calendar may have proven grossly inaccurate regarding the significance of the date of December 21, 2012 but there is now a new date to be genuinely concerned about which will actually have a real impact on at least some of our lives: November 1, 2015.

As pointed out on a few other blogs, like this article from fellow Lync MVP Curtis Johnstone, there will be some changes to how public certificates will be issued by most public certificate authorities. Be aware that although that date is still a few years away any public certificates requested today may already incorporate these modifications.

Background

Before getting into what the changes are and how they will affect Lync Server deployments (and Active Directory design in general) it would be prudent to understand where they coming from and who will be enforcing them.

Basically there exists a voluntary organization called the Certificate Authority Browser Forum (or CA/Browser Forum for short) which is comprised of many leading public certificate authorities (e.g. Comodo, Digicert, Symantec) and Internet browser vendors (e.g. Apple, Google, Microsoft). Representatives from these companies work together to publish an agreed upon set of standards that each member adheres to in the spirit of providing secure communications throughout the Internet.

The latest agreed upon set of standards was recently published and adopted by these members as the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificate, v1.0. Within this document are two very important changes to how certificate requests will be handled which can or will impact Lync Server deployments for some organizations based on their current Active Directory namespace configuration. The first change limits the scope of accepted namespaces in the subject fields and the second change actually inverts the importance of the Subject Name (SN) and Subject Alternative Name (SAN) fields.

Subject Name Fields

The change which will have a lessor impact is that certificates issued which are compliant to this specification must always contain a Subject Alternative Name field, while the Subject Name field becomes optional. This is a complete reversal from previous practices where the certificate’s Common Name (CN) (e.g. server.domain.com) was included as part of the Distinguished Name (DN) defined in the Subject Name field, yet the SAN field was optional, and often for an additional cost. (Note that although CN and SN are often used interchangeably the CN is actually part of the SN.)

Looking at the CA/B Forums’ requirements document the following statements are highlighted in sections 9.2.1 and 9.2.2 which outline this shift in subject name usage.

9.2.1 Subject Alternative Name Extension
Certificate Field: extensions:subjectAltName
Required/Optional: Required

9.2.2 Subject Common Name Field
Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Deprecated (Discouraged, but not prohibited)

Note that the SAN field is now listed as a requirement and the Subject Name field is defined as optional. Although the SN field is deprecated it is still being included in certificate requests today from the participating CAs. By definition of the word this indicates that sometime in the future the SN field will become obsolete and be dropped entirely, but probably only after all software vendors have been able to update their products to work with that type of certificate configuration.

So this in itself should not pose any risk to past or future Lync Server deployments as all clients and servers already support both field types and for the foreseeable future both fields will still be included in public certificates. Microsoft will need to do some testing to find out if any services or communications will break in the event that the certificate contains only a SAN field and no SN field though, and adjust their product accordingly. But there is no known defined timeline on when the Common Names will be dropped from public certificates across the board.

Namespace Support

The second and more important change is also defined in the SAN field definition but it requires a little closer reading to understand and fully appreciate the gravity of the statements.

9.2.1 Subject Alternative Name Extension
Certificate Field: extensions:subjectAltName
Required/Optional:Required

Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an IP Address containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IPaddress or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate.

Wildcard FQDNs are permitted.

As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name. 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.

There is a lot going on in this section, so it is easier to understand by breaking down each highlighted portion.

The CA must validate any and all domain names included in the certificate request. Some public CAs have already been doing this for some time, but others have not. Starting from the adoption date reflected in the requirements document (July 2012) participating public CAs will no longer issue a certificate to a requestor if any of the domain names defined in the certificate request cannot be validated. This validation process typically involves the CA performing a WHOIS lookup on the domain name to leverage the contact information for a validation email or phone call.
The CA shall notify the current owners of any valid certificates which do not meet these new requirements will no longer be allowed after October 2016. Basically this means that CAs need to inform their customers that practices are changing and they will need to update their usage and design to be compatible with future certificate requests.
The CA shall not issue a certificate which does not meet these requirements which would expire after November 1, 2015. In short this means that if a certificate is requested today for one or two years then the previous configurations may still be allowed by that CA. But if a 3 year certificate was to be purchased today, placing the expiration date after November 1st 2015 then the CA will not allow the use of any domain names which cannot be validated.

So what does this all mean? On the surface it all looks like a good idea, providing for additional security and preventing the use of domain names which cannot be proven to be owned or managed by the requestor.

The key concept to understand is though the impact this has on organizations still using internal namespaces which cannot be validated. There are still many Active Directory forests in operation which utilize invalid DNS Top-Level Domains (TLD) like .local, .domain, .corp and so on. These namespaces cannot be registered with a Domain Name Registrar and thus certificate authorities have no method to prove the validity of these internal-only namespaces.

For some time now it has been a general Active Directory best practice in the field to no longer use these pseudo TLDs in internal deployments and instead use one of a couple different solutions. Even the examples used through this blog site do not reflect these newer best practices (e.g. schertz.local and mslync.net) but all internal server certificates have always been issued by a Windows Enterprise CA which clearly does not need to conform to the changes that public CAs are adopting.

One option is to still go with a disparate namespace configuration retaining the public name as external only (e.g. contoso.com) but to select a valid internal domain name (e.g. contoso.net) and then register that name with a public registrar. The domain name does not need to be used externally and may contains no actual DNS records (expect maybe a www redirection to the real public namespace if desired) but it does exist and includes a valid contact in the registrar records so a public CA can validate the ownership of that domain name.

Another option is to utilize a Split-Brain DNS approach where the same namespace (e.g. contoso.com) is used as both the internal AD domain namespace and the public namespace. This approach is becoming more common although there is some additional overhead in managing separate DNS zone database for internal and external records.

The benefits or drawbacks to either approach go far beyond the scope of this article and it is a topic which can be highly debated among IT professionals. In reality one solution may be ideal over the other for a given organization so there is not always a simple answer as to which is better. Future articles on this blog will reflect new example namespaces as a new AD forest and Lync Server 2013 deployment will bring the opportunity to select a new approach. For the sake of simplicity it would be ideal to just use mslync.net for both internal and external namespaces, but this often obfuscates the domain name and does not make it immediately apparent to the reader which namespaces (internal or external) is being referred to without specifically calling it out.

Impact to Lync Server

Everything discussed up until now covers design theory in detail, which is great for planning new deployments or environments, but what about existing environments which cannot be modified? Performing a complete Active Directory migration (or worse yet the dreaded domain rename) for the sole purposes of ditching an internal-only namespace is typically not feasible.

As covered in this previous blog article Lync Server 2010 and 2013 introduced new client architectures for Mobility and 2013 clients which adds some complexity when dealing with the balancing act of namespaces, certificate trusts, and device management. If locked into internal namespaces then using public certificates on an internal Lync server will no longer be possible, meaning that all devices will need to trust the internal certificate authority. This is easy for domain-joined workstations but not as simple when dealing with the wave of impending bring-your-own-device workforces. If public namespaces are used internally then the internal servers can utilize public certificates on all roles, allowing pretty much any device the ability to trust the registrar and web services roles on any internal Lync server.

But most importantly any environments out there still running internal-only namespaces which do not have their own internal certificate authority are going to find themselves left out in the cold very soon. As Microsoft works through defining new best practices with the product group, field engineers, partners, and customers one might expect to see some form of official documentation in the future outlining new recommendations along this topic.

Filed under Lync · Tagged with 2013, Autodiscover, Certificates, Mobility

Chicago Lync Users Group Meeting

January 21, 2013 by Jeff Schertz · 39782 CommentsChicago+Lync+Users+Group+Meeting2013-01-21+15%3A31%3A07Jeff+Schertz

The Chicago UC Users Group will be conducting their next meeting January 24th, 2013. Lync Server 2013 introduces new high availability (HA) and disaster recovery (DR) procedures. Understanding how to identify business requirements for HA and DR, and then executing a proper design to meet those requirements is critical. This topic will be presented by Keenan Crockett, a Senior Solution Architect with Perficient who will cover the new HA and DR features in Lync Server 2013, and provide details on key design decisions and procedures for HA and DR.

Additionally, I will present an overview of the Persistent Chat (formally Group Chat) capabilities that have been introduced in Lync Server 2013 and the Lync 2013 client.

Industry Experts will be on site to deliver this presentation and help answer any questions related to Lync Server.

Attend any Lync Users Group Event across the nation in January, and you will be automatically entered to win a Microsoft Surface RT! Must attend in person, and must complete your survey for entry. Random winner will be drawn February 1 2013.

Thursday, January 24th, 2012

5:30 PM – Arrival & Networking
6:00 PM – Event Kickoff

Microsoft Downtown Chicago Office
Microsoft Technology Center – Aon Building – 2nd Floor

200 East Randolph Drive, Suite 200, Chicago, IL (Map)

To sign-up for the event simply create a Meetup account if you do not already have one and then confirm your attendance on this event page: http://chicago.lyncusersgroup.com/events/97877672

Filed under Lync · Tagged with Events

How HTTP is Utilized in Lync Server

December 30, 2012 by Jeff Schertz · 30224 CommentsHow+HTTP+is+Utilized+in+Lync+Server2012-12-30+15%3A30%3A00Jeff+Schertz

Nearly all communications between Lync clients and the Lync Server web services are maintained over port 443, yet there are a few instances when HTTP traffic over Port 80 is utilized. Thus depending on the scenario if any traffic over this port is not allowed to or from the server then some functionality may be limited.

Internal Servers

The Ports and Protocols for Internal Servers documentation lists Port 80 as a requirement in two places: Front End Servers and Directors, with a description including when HTTPS is not used. OK, but when is HTTPS not used? And why?

Lync Phone Edition Certificate Download

Traditionally all internal Lync servers would be issued an SSL certificate from a Windows Enterprise Certificate Authority which automatically embedded the root and any issuing subordinate CA certificates into Active Directory. Thus all domain connected Windows workstations would transitively trust the private certificate authority, and the Lync client running on those computers would be able to connect to the Lync servers over TLS without issue. In the event that a trusted third party public certificate was issued to the internal Lync servers then the Windows client would typically trust those by default assuming that the CA is one of the pre-installed trusts in the Windows operating system certificate store.

But what about Lync Phone Edition devices? These are not domain-joined and although they do support a host of pre-installed public certificates which would allow them to connect to Edge or internal servers utilizing public certificates, how do they function in an internal scenario with private certificates?

Since the introduction of the Phone Edition client with the original Tanjay device the client has been able to automatically download the complete root certificate chain directly from a Front-End or Director Server (OCS or Lync). This download is actually facilitated over HTTP (port 80 by default) as until the root certificate is downloaded the client cannot establish a secure connection over HTTPS (port 443 by default) with the server.

Also be aware that this behavior is not limited to Lync Phone Edition devices are other Lync Qualified devices (e.g. Polycom VVX Phones) can use this same solution to automatically download the CA certificates.

The following network trace shows a Lync Phone Edition device (192.168.1.117) connecting to the Certificate Provisioning service on the Lync Server (192.168.1.23) over port 80 and receiving a response from the server (HTTP/1.1 200 OK) which includes the root certificate data.

If a device which supports PIN Authentication in Lync is unable to connect to the Lync Web Services initially over HTTP to download the certificate then it will not be able to successfully complete the authentication process as TLS communications over HTTPS is unavailable without the certificate trust in place.

In the event that port 80 is not reachable on the internal Lync Server the Test-CsPhoneBootstrap cmdlet will return the following error message:

TargetUri : https://lync.schertz.local:443/CertProv/CertProvisioningService.svc
TargetFqdn : lync.schertz.local
Result     : Failure
Latency    : 00:00:01.0291919
Error      : No response received for GetRootCertChains().
Diagnosis :

Earlier in the cmdlet output the failure to connect to initially connect to the web services over HTTP is clearly reported.

Connecting to web service : http://lync.schertz.local/CertProv/CertProvisioningService.svc
        Using anonymous authentication
        Successfully created connection proxy and website bindings
        Attempting to download certificate root chain
        request created
        ERROR communicating with GetRootCertChains() service System.ServiceModel.EndpointNotFoundException: Could not connect to http://lync.schertz.local/CertProv/CertProvisioningService.svc/anon. TCP error code 10061: No connection could be made because the target machine actively refused it 192.168.1.23:80. —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 192.168.1.23:80

This situation is more common with internal firewalls or hardware load balanced scenarios as the Lync Server will allow connections to both ports 80 and 443 by default. But if any traffic-filtering devices or routing misconfiguration prevent requests over TCP 80 to the server, yet still allow TCP 443, then Windows Lync clients will continue to work fine but Lync Phone Edition devices may not be able to connect, USB tethered or not.

Thus make sure that both port 80 and 443 are reachable on all internal Front end and Director servers from any subnet where Lync clients may reside internally, and also do not forgot to configure any hardware load balancers to handle HTTP requests as well as HTTPS.

Autodiscover

The Lync autodiscover web service first introduced in a cumulative update for Lync 2010, which is now embedded in Lync 2013, can also utilize HTTP. Previous articles Deploying the Lync 2010 Mobility Service and Lync 2013 Client Autodiscover already discuss this topic in detail, but the key point is that clients which support this service will simultaneously attempt connections to both HTTP/80 and HTTPS/443 to the server name resolved by either lyncdiscoverinternal.<sipdomain> or lyncdiscover.<sipdomain>. Whichever response is received first is what the client will utilize, but in the event of most internal communications the clients should typically have access to both ports. Since both ports are assigned to the same web services then if a client does receive answers from both port connection attempt the reply will still contain the same results. Only the initial Autodiscover request can be handled over HTTP, all other communications afterward are secured over 443.

External Servers

As depicted in the Port Summary documentation for the single Edge and Reverse Proxy server reference architecture Port 80 can be used for two different types of requests, one for outbound traffic from an Edge Server to the Internet and another for inbound requests from clients on the Internet to the Reverse Proxy server.

Edge Server Certificate Revocation Check

The Edge Server’s Access Edge Service will utilize port 80 for outbound requests so that the Edge Server can perform basic certificate revocation checks. This is more of a Windows Server related behavior than the Lync Access Edge service itself, but is important to support TLS communications with other federated partners. By default the Edge server will periodically query a CA’s Certificate Revocation List (CRL) for certificates presented during Edge to Edge federated communications and will need to make outbound connections over port 80 to download the CRL via HTTP.

Often this is not a port which requires manual configuration on firewalls as it is common practice to allow outbound connections over any port or protocol from a more trusted network (e.g. a Perimeter or DMZ network) to a less trusted network (e.g. the Internet). In the event that all outbound requests through an external firewall from the Edge Server need to be specifically defined in a policy then Port 80 must be allowed. Alternatively (although not recommended) this behavior can be disabled on the Edge Server by defining the KeepCrlsUpToDateForPeers parameter with the Set-CsAccessEdgeConfiguration cmdlet.

Reverse Proxy Redirection

This is a completely optional usage of Port 80 designed to allow inbound client requests over HTTP (TCP80), which are then automatically redirected to HTTPS (TCP443) by a Reverse Proxy rule.

Prior to the addition of the Autodiscover service this rule was almost never deployed, but there is one scenario where it can be advantageous.

The client autodiscover behavior is the same regardless of where the client is located, but external autodiscover is typically configured differently. Where most often internal clients can connect to the autodiscover web service over either 80 or 443 when dealing with externally published web services it is more common (and reflected as best practices in the production documentation) to only allow connections from the Internet over HTTPS/443.

In normal scenarios clients would only receive a response from connections to 443 while connections to 80 would be refused at the reverse proxy. But by adding this rule and allowing HTTP/80 requests to reach the internal web services then the reverse proxy listener does not need to include the lyncdiscover.<sipdomain> FQDN. This feature has more importance back when the services was newly added to Lync Server 2010 and provided for simpler (and sometimes even cheaper) deployments of the Mobility service in existing Lync environments. But for Lync Server 2013 deployments it is recommended to include the lyncdiscover FQDNs (or a Simple URL wildcard entry) in the certificate SAN fields.

Filed under Lync · Tagged with Certificates, Edge, Lync Phone Edition, Reverse Proxy

Lync 2013 Web Conferencing Upload Limit

December 20, 2012 by Jeff Schertz · 38864 CommentsLync+2013+Web+Conferencing+Upload+Limit2012-12-20+18%3A58%3A12Jeff+Schertz

This article shows how to customize the file size limit for items uploaded to Lync 2013 web conferences by attendees connected using either a Windows Lync client or Lync Web App.

Lync Client

Any Lync clients which connect to a multi-party conference hosted on a Lync 2013 Front End server will only be allowed to upload files which do not exceed a default limit of of 500MB.

When attempting to upload a file of roughly 750 MB in size from the Lync 2013 Windows client to the conference the following error is presented.

The message will appear after a few seconds as the file properties are checked against the defined policy. Lync does not require the entire file to be uploaded before deciding whether or not it falls within the defined limits.

Lync Web App

The Lync 2013 Web App client also supports the ability to upload content, but are limited to a much smaller file size of roughly 30MB.

Attempts to upload the a sample file of 48 MB will also present the Lync Web App attendee with the following error message.

b

Verifying the Limits

Fortunately these values are not hard-coded in Lync Server 2013 and thus can be customized by an administrator. But before making any changes it would be prudent to first see how and where these limitations are configured to understand the potential impact of any changes.

Using the Lync Server Management Shell execute the following Get-CsConferencingConfiguration cmdlet to identify the limits applied to standard Lync clients.

Get-CsConferencingConfiguration | Select-Object MaxUp* | fl

MaxUploadFileSizeMb : 500

Due to the way that cmdlets and parameters in PowerShell have the first letter of each word capitalized this name actually appears to indicate the value is stored in megabits (Mb) versus megabytes (MB). But that would be an incorrect assumption as these values are in fact megabytes (MB). Thus the default value of 500 MB is reflected above.

To check the limits configured for Lync Web App connections locate the web.config files located in either the Int and Ext Web Components directories on the Lync Front End servers.

%ProgramFiles%\Microsoft Lync Server 2013\Web Components\DataCollabWeb\Int\Handler

%ProgramFiles%\Microsoft Lync Server 2013\Web Components\DataCollabWeb\Ext\Handler

Open the web.config file and locate the following two lines defined under separate tags. The maxRequestLength value is used by ASP.NET requests while the maxAllowedContentLength value is applied to IIS requests.

<httpRuntime maxRequestLength="30000" executionTimeout="600" />

<requestLimits maxAllowedContentLength="30000000" />

Note that the Deployment Checklist for Web Conferencing page in the TechNet documentation states that the “file size upload limit for Lync Web App is set to approximately 30MB”. That approximation comes from the fact that the maximum allowed values are rounded off as 30,000,000 bytes is actually only 28.6 MB. Yet the conferencing configuration above was defined as 500 MB which actually comes out to 524,288,000 bytes. What is also apparent is that the maxRequestLength value used by ASP.NET is defined as kilobytes but 30000 KB are equal to 30,720,000 B. So even the two limits in this file are not exactly equal to each other.

These differences in values may seem minor but if the goal is to provide settings that are uniform between Lync clients and Lync Web App attendees then the math should be carefully checked so there are no discrepancies. Otherwise a file which does not exceed the limit for one client type may actually be blocked by another.

Customizing the Limits

Most likely after reading this article some administrators may want to actually reduce the limit as allowing conference attendees to store half-gigabyte files on the Lync server may be a quick way to consume disk space on the server. Realistically documents only slightly larger than what one would be able to send via email these days are all which might need to be supported, so decreasing the limits to something like 50MB may be much more realistic. And in doing so slightly increasing the Lync Web App limits to match that setting would provide a more uniform experience.

Incidentally this article was also just posted by fellow Lync MVP John Weber which includes some additional sizing guidance with a real-world example of its usage.

Using the Lync Server Management Shell execute the following Set-CsConferencingConfiguration cmdlet to define a new value of 50 MB for the MaxUploadFileSize parameter.

Set-CsConferencingConfiguration -Identity Global -MaxUploadFileSizeMb 50

There should be no need to restart any services as this parameter change should update in a few minutes and then be applied to any new conferences.

For the Lync Web App configuration update both the files in the Int and Ext paths if the same limit is desired for both types of attendee locations. In practice their may be reasons that one source should have a different limit than the other, but the example in this article uses the same value throughout for continuity.

Launch Notepad as an administrator and edit the web.config files located in both of the following Int and Ext Web Components directories on any and all Lync Front End servers in the environment.

%ProgramFiles%\Microsoft Lync Server 2013\Web Components\DataCollabWeb\Int\Handler\

%ProgramFiles%\Microsoft Lync Server 2013\Web Components\DataCollabWeb\Ext\Handler\

In each file change the maxRequestLength value to 51200 (51,200 KB = 50 MB).

<httpRuntime maxRequestLength="51200" executionTimeout="600" />

The executionTimeout value can be left at the default value of 600 seconds, but it may be advisable to increase it in parallel to the file size limit. Basically if the file transfer takes longer than the timeout value of 10 minutes then the upload can fail. So to provide flexibility for attendees which may have limited upload bandwidth available to them increasing this timeout can help. Updating the timeout value from 600 to 1024 would retain the same estimated ratio of 50 KB/s currently assigned by default.

Then locate the maxAllowedContentLength parameter and delete the comment tags immediately before and after to enable this additional parameter.

Update the maxAllowedContentLength value to 52428800 (52,428,800 B = 51,200 KB = 50 MB) and save the file.

<requestLimits maxAllowedContentLength="52428800" />

Execute an iisreset to update the changes immediately by recycling the IIS Application Pools.

The resulting configuration will provide a single file size limit of 50 MB for any attendee. Now attempts to upload the 48MB test file will complete successfully when using Lync Web App.

Filed under Lync · Tagged with 2013

Search for:
Tweets
Twitter Authentication data is incomplete
Recent Posts
Statistics
- Total Stats
  - 150 Posts
  - 2,168 Comments
Archives
- [—]2013 (8)
  - [—]May (1)
    Provisioning Polycom SIP Phones
  - [+]April (1)
  - [+]March (3)
  - [+]February (1)
  - [+]January (2)
- [+]2012 (29)
  - [+]December (4)
  - [+]November (1)
  - [+]October (4)
  - [+]September (2)
  - [+]August (3)
  - [+]July (4)
  - [+]June (1)
  - [+]May (3)
  - [+]April (2)
  - [+]March (2)
  - [+]February (1)
  - [+]January (2)
- [+]2011 (25)
  - [+]December (2)
  - [+]November (1)
  - [+]October (3)
  - [+]September (1)
  - [+]August (3)
  - [+]June (2)
  - [+]May (3)
  - [+]April (2)
  - [+]March (2)
  - [+]February (3)
  - [+]January (3)
- [+]2010 (40)
  - [+]December (2)
  - [+]November (9)
  - [+]October (4)
  - [+]September (7)
  - [+]June (9)
  - [+]May (1)
  - [+]March (2)
  - [+]February (1)
  - [+]January (5)
- [+]2009 (27)
  - [+]November (1)
  - [+]September (3)
  - [+]August (6)
  - [+]July (1)
  - [+]June (4)
  - [+]May (1)
  - [+]April (4)
  - [+]March (3)
  - [+]February (2)
  - [+]January (2)
- [+]2008 (15)
  - [+]December (1)
  - [+]October (2)
  - [+]August (4)
  - [+]July (1)
  - [+]June (1)
  - [+]May (2)
  - [+]April (2)
  - [+]March (2)
- [+]2007 (6)
  - [+]December (1)
  - [+]November (3)
  - [+]October (2)
Articles
Blogroll
Flickr Photostream

Name	Description
0000000000.cfg	Default Master SIP Configuration File
*.sip.ld	Firmware files for each unique phone model
sip.ver	Text file which stores the full version number for this package

Device	Firmware File	4.1.0i	4.1.2b	4.1.4
SoundPoint IP 321	2345-12360-001.sip.ld	3,793 KB
SoundPoint IP 331	2345-12365-001.sip.ld	3,793 KB
SoundPoint IP 335	2345-12375-001.sip.ld	3,793 KB
SoundPoint IP 450	2345-12450-001.sip.ld	4,452 KB
SoundPoint IP 550	2345-12500-001.sip.ld	3,851 KB
SoundPoint IP 560	2345-12560-001.sip.ld	3,851 KB
SoundPoint IP 650	2345-12600-001.sip.ld	3,851 KB
SoundStation IP 5000	3111-30900-001.sip.ld	4,087 KB
SoundStation Duo	3111-19000-001.sip.ld	4,846 KB
VVX 300	3111-46135-002.sip.ld			50,159 KB
VVX 310	3111-46161-001.sip.ld			50,159 KB
VVX 400	3111-46157-002.sip.ld			50,159 KB
VVX 410	3111-46162-001.sip.ld			50,159 KB
VVX 500	3111-44500-001.sip.ld		58,517 KB
VVX 600	3111-44600-001.sip.ld		58,517 KB

Instance	Database	Description
RTC	lis	Location Information Services data
RTC	xds	Central Management Store data
RTCLOCAL	rtc	Standard Edition Pool data
RTCLOCAL	rtcdyn	Standard Edition transient user data
RTCLOCAL	xds	Local replica of Central Management Store data
LYNCLOCAL	lyss	Lync Storage Service data

Country/Region	United States
State/Province	Illinois
City/Locality	Chicago

Subject Name	lync.schertz.name
Subject Alternative Name	lync.schertz.name dialin.mslync.net meet.mslync.net admin.mslync.net Lyncdiscoverinternal.mslync.net Lyncdiscover.mslync.net

Principal	Access
NETWORK SERVICE	Change
RTCHSUniversalServices	Change
RTCComponentUniversalServices	Change
RTCUniversalServerAdmins	Change
RTCUniversalConfigReplicator	Change
RTC Local Administrators	Change
RTC Local Config Replicator	Change
RTC Server Local Group	Change
RTC Component Local Group	Change

Principal	Access	Applies To
NETWORK SERVICE	Modify	This folder, subfolders, and files
RTCComponentUniversalServices	Modify	This folder, subfolders, and files
RTCUniversalServerAdmins	Modify	This folder, subfolders, and files
RTC Server Local Group	Modify	This folder, subfolders, and files
RTC Component Local Group	Modify	This folder, subfolders, and files

Background

Configure Provisioning Server

Authentication

Name Resolution

FTP Service

FTP Directory

DHCP Configuration

Provisioning Server Location

Time Server Location

Time Offset

Microsoft Vendor Class ID

Validate Configuration

Configuring Global Settings

Master Configuration File

Shared Configuration File

Test Registration

Configuring Per-Device Settings

Master Configuration File

Device Configuration Scenario 1

Test Registration Scenario 1

Device Configuration Scenario 2

Test Registration Scenario 2

Managing Firmware Updates

Install Lync Server System

DNS Configuration

Legacy Automatic Client Sign-In

Lync Autodiscover

Summary

Environment

Server and Forest Preparation

Lync Server Preparation

Deployment and Administration Tools Installation

Topology Definition

Summary

Root Directory

Application Server

Central Management

Web Services

Background

Configuration

Behavior in Lync 2013

Background

Subject Name Fields

Namespace Support

Impact to Lync Server

Internal Servers

Lync Phone Edition Certificate Download

Autodiscover

External Servers

Edge Server Certificate Revocation Check

Reverse Proxy Redirection

Lync Client

Lync Web App

Verifying the Limits

Customizing the Limits

Tweets

Recent Posts

Statistics

Archives

Articles

Blogroll

Flickr Photostream