To better understand DiffServ and its affect on the network, please check out the excellent blog article written by fellow Lync MVP Jeff Schertz at the following URL: http://blog.schertz.name/2011/08/lync-qos-behavior/

Part 1

Part 2

Server QOS

General Procedure for Server QoS

In Part 1, we talked about Windows Vista/7/8 vs Windows XP.  Windows Vista, Windows 7, and Windows 8 utilize Policy based QoS and Windows XP used QoS based on the Packet Scheduler.  For Lync 2013 Servers, you’ll always use Policy based QoS since Lync Server 2013 can only be installed on Windows 2008 R2 or Windows 2012 which both utilize Policy based QoS.  For Lync 2010 Servers, you’ll always use Policy based QoS since Lync Server 2010 can only be installed on Windows 2008 or Windows 2008 R2 which both utilize Policy based QoS.

For Server based QoS, we can configure Conferencing Servers, Application Servers, and Edge Servers (which will use QoS based on the destination port rather than the source port as everything else does).

Client to Server Port Configuration for Conferencing Servers and Application Servers

Client to Server Port ranges are out of the box different for all modalities except for Application Sharing. In Lync Server 2013, there are no more dedicated Audio/Video Conferencing Servers as the Audio/Video Conferencing Servers are always located directly on a Front End.  In Lync Server 2010, you still have the capability for deploying dedicated Audio/Video Conferencing Servers.  The same GPO for Lync Server 2010 and Lync Server 2013 can be deployed.  In Lync Server 2013, you will ensure that the GPO is deployed to the Lync Server 2013 Front End Servers whereas with Lync Server 2010, you will ensure the GPO is deployed to the Conferencing Servers whether that may be a Front End or a dedicated Audio/Video Conferencing Server.

The default ports for a Conferencing Server are as such:

• Audio: 49152 to 57500
• Video: 57501 to 65535
• Application Sharing: 49152 to 65535

At least 40 ports minimum are required for Application Sharing.  We will specify a 8,348 port range that is unique from other ports.  Ultimately, we will set Application Sharing to use the following ports:

• Application Sharing: 40803 to 49151

To set this, we will run the following command:

Configuring an Application Server is identical.  The only difference is that you use the Set-CSApplicationServer command instead of the Set-CSConferenceServer.  Make sure to include these ports in the QoS Policies for Edge Servers as you will learn later.

Client to Server Port Configuration for Dedicated Mediation Servers

A Mediation Server of course only handles Audio since it’s job is to transcode RTAudio to G.711.  The default ports for a Mediation Server are as such:

• Audio: 49152 to 57500

No Changes to this port range will be required.  If the Mediation Server is collocated on a Front End Server, no changes will need to be done as you can see the Audio Port Range for a dedicated Mediation Server is the same as the Audio Port Range for a Front End Conferencing Server.

Exchange Unified Messaging (UM)

I am not going to go into every step by step on how to enable Exchange UM for QoS as Lync MVP, Tom Pacyk, does that very well here.  What I will show, is how Exchange UM ties into DSCP marking from the Lync Edge Server based on the port ranges we have defined through this article series.

Edge Server Policy Configuration

An Edge Server doesn’t get configured per se.  But the policy that you create is based on a destination port (rather than source port like client peer to peer or client to server).  The destination port configuration in the QoS Policy is configured based on the client peer to peer ports you defined in Part 1 of this article series as well as the client to server ports you defined in this Part 2 of this article series.

So if we take a look at everything we’ve done so far, we have the following peer to peer configuration from Part 1 of this article series:

• Audio: 20000 to 20039 (TCP/UDP with UDP being preferred with TCP fallback)
• Video: 20040 to 20079 (TCP/UDP with UDP being preferred with TCP fallback)

We have the following client to server configuration from Part 2 of this article series:

• Audio: 49152 to 57500 (TCP/UDP with UDP being preferred with TCP fallback)
• Video: 57501 to 65535 (TCP/UDP with UDP being preferred with TCP fallback)
• Application Sharing: 40803 to 49151 (TCP)

Exchange UM will utilize the following port configuration:

• Audio: 1024-65535 (UDP)

The Edge QoS Policy will need to have several QoS Policies configured to handle each modality (Application Sharing not as critical as Audio/Video but can be enabled) for peer to peer (Audio/Video) and client to server (Audio/Video).  Additional QoS Policies may be needed depending on Application Servers in the environment and whether they have any different port ranges from your Peer to Peer or Client to Peer port configurations.

Configuring Policy Based QOS in Group Policy for Windows 2008 R2 and/or Windows 2012 for a Conferencing Server

As stated previously, Lync Server 2013 can only be installed on Windows 2008 R2 or Windows 2012.  Both Windows 2008 R2 and Windows 2012 utilize Policy Based QOS which allows a wider variety of options for configuring QoS.

In the below example, we will show how to create the Policy-based QoS for Audio.  Once finished, be sure to also create Policy-based QoS policies for Video.  The DSCP Value for Audio will be 46 and the DSCP Value for Video will be 34. Open up Group Policy (in my examples, I am using Local Computer Policy but in a real production environment you would be using Group Policy at some level in your Domain Hierarchy) and navigate to Computer Configuration > Windows Settings > Policy-based QoS.  Right-Click and choose Create new policy.

In the new Policy, give it a name and specify the DSCP Value.  DSCP Values for audio is typically 46.  Make sure the Outbound Throttle Rate check box is cleared.  Click Next.

Because there are multiple applications that will stamp DSCP Values, we will choose All Applications. Click Next.

On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.”  Click Next.

On  the following screen, choose TCP and UDP.  In our information above we stated the default audio port range is 49152 to 57500 and does not need to be changed.  Because of this, our source port range will 49152 to 575000 specified as 49152:57500.

Let’s go ahead and set the DSCP Value for Video with a DSCP value of 34. Right-Click Policy-based QoS and choose Create new policy. In the new Policy, give it a name and specify the DSCP Value.  DSCP Values for video is typically 34.  Make sure the Outbound Throttle Rate check box is cleared.  Click Next.

Because there are multiple applications that will stamp DSCP Values, we will choose All Applications. Click Next.

On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.”  Click Next.

On  the following screen, choose TCP and UDP.  In our information above we stated the default video port range is 57501 to 65535 and does not need to be changed.  Because of this, our source port range will 57501 to 65535 specified as 57501:65535.

If you would like Client to Server QoS for Application Sharing, feel free to also create a new QoS Policy that provides DSCP Values for the port ranges specified for Application Sharing.  The same can be done for SIP if you really want SIP to be marked. If you made this port range contiguous with Video, feel free to modify your Video QoS Policy to add the ports for Application Sharing if you are fine with also using a DSCP value of 34.

Now go ahead and restart your Lync Conferencing Servers so they pick up the changes. After Group Policy have applied the settings, you should see the following settings within the registry:

Configuring Policy Based QOS in Group Policy for Windows 2008 and/or Windows 2008 R2 for a Dedicated Mediation Server

As stated previously, Lync Server 2013 can only be installed on Windows 2008 R2 or Windows 2012.  Both Windows 2008 R2 and Windows 2012 utilize Policy Based QOS which allows a wider variety of options for configuring QoS. This same GPO Setting can also be applied to Lync 2010 Mediation Servers which utilize Windows 2008 or Windows 2008 R2 which both also utilize Policy Based QoS.

In the below example, we will show how to create the Policy-based QoS for Audio only.  The DSCP Value for Audio will be 46. Open up Group Policy (in my examples, I am using Local Computer Policy but in a real production environment you would be using Group Policy at some level in your Domain Hierarchy) and navigate to Computer Configuration > Windows Settings > Policy-based QoS.  Right-Click and choose Create new policy.

In the new Policy, give it a name and specify the DSCP Value.  DSCP Values for audio is typically 46.  Make sure the Outbound Throttle Rate check box is cleared.  Click Next.

Since this is Policy-based QoS, we will want to take advantage of only tagging traffic that the Mediation Server uses utilizing the executable MediationServerSvc.exe.  So make sure you choose the “Only applications with this executable name” and specify MediationServerSvc.exe. Click Next.

On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.”  Click Next.

On  the following screen, choose TCP and UDP.  In our information above we stated the default audio port range is 49152 to 57500 and does not need to be changed.  Because of this, our source port range will 49152 to 575000 specified as 49152:57500.

Now go ahead and restart your Lync Mediation Servers so they pick up the changes. After Group Policy have applied the settings, you should see the following settings within the registry:

Configuring Policy Based QOS in Group Policy for Windows 2008 R2 and/or Windows 2012 for an Edge Server

As stated previously, Lync Server 2013 can only be installed on Windows 2008 R2 or Windows 2012.  Both Windows 2008 R2 and Windows 2012 utilize Policy Based QOS which allows a wider variety of options for configuring QoS.  This same GPO Setting can also be applied to Lync 2010 Edge Servers which utilize Windows 2008 or Windows 2008 R2 which both also utilize Policy Based QoS.

In the below example, we will show how to create the Policy-based QoS for Audio from Clients which utilize ports 20000 to 20039.  Once finished, be sure to also create Policy-based QoS policies for Client Video as well as all the Audio/Video ranges for Conferencing Servers.  The DSCP Value for Audio will be 46 and the DSCP Value for Video will be 34. Open up Group Policy (in my examples, I am using Local Computer Policy but in a real production environment you would be using Group Policy at some level in your Domain Hierarchy) and navigate to Computer Configuration > Windows Settings > Policy-based QoS.  Right-Click and choose Create new policy.

In the new Policy, give it a name and specify the DSCP Value.  DSCP Values for audio is typically 46.  Make sure the Outbound Throttle Rate check box is cleared.  Click Next.

Since this is Policy-based QoS, we will typically want to specify the executable name to take advantage of only tagging traffic that the Edge Server uses utilizing the executable MediaRelaySvc.exe. Unfortunately, with the Edge Role, even in Lync 2013, no DSCP markings will happen when the executable name is specified.  So make sure you choose All applications. Click Next.

On the following screen, we will want to restrict this GPO from the Internal IP of our Edge to ensure that only DSCP markings happen when we talk to the Internal Network as QoS does not get applied on the Internet. Make sure you leave the default for ”Any destination IP Address.”  In the following screenshot, 10.10.10.20/32 would be the IP Address assigned to the Internal NIC on our Edge Server. Click Next.

On  the following screen, choose TCP and UDP.  In our information above we stated the default audio port range is 49152 to 57500 and does not need to be changed.  Because of this, our source port range will 49152 to 575000 specified as 49152:57500.

‘

I will not display the remainder of the QoS Policy configuration for the Edge as I’m sure by now, you are a master at configuring QoS Policies for Lync.  The remainder of the four QoS Policies will look as such:

Peer to Peer Video:

• Policy Name: Lync 2010/2013 Client Video
• DSCP Value: 34
• All Applications
• Specify Outbound Throttle Rate is Unchecked
• Source IP: Your Internal Edge IP (Our example is 10.10.10.20/32)
• Destination Port Range of 20040:20079 TCP/UDP

Conferencing Server Audio:

• Policy Name: Lync 2010/2013 Conferencing Audio
• DSCP Value: 46
• All Applications
• Specify Outbound Throttle Rate is Unchecked
• Source IP: Your Internal Edge IP (Our example is 10.10.10.20/32)
• Destination Port Range of 49152:57500 TCP/UDP

Conferencing Server Video:

• Policy Name: Lync 2010/2013 Conferencing Video
• DSCP Value: 34
• All Applications
• Specify Outbound Throttle Rate is Unchecked
• Source IP: Your Internal Edge IP (Our example is 10.10.10.20/32)
• Destination Port Range of 57501:65535 TCP/UDP

Exchange UM Audio :

• Policy Name: Lync Edge to Exchange UM01 Audio (assuming UM01 is the UM Server)
• DSCP Value: 34
• All Applications
• Specify Outbound Throttle Rate is Unchecked
• Source IP: Your Internal Edge IP (Our example is 10.10.10.20/32)
• Destination IP: Your Exchange UM IP (Our example, 10.10.10.30/32)
• Destination Port Range of 1024-65535 UDP

Note: For Exchange UM, because we are using the entire 1024-65535 range, I like to create targeted GPO Policy Entries that include a destination IP for the Exchange UM Server.  This way, it ensures this GPO that uses the entire upper port range does not interfere with other GPO QoS Policy Entries that have been defined as this QoS Policy Entry is more explicit in its Source/Target definitions.  This also means you will need to create a policy for each UM Server.

After all QoS Policies are created, reboot the Lync Edge Server.  You should see the following registry changes:

As always, log to ensure DSCP markings are being defined.  In order to understand how to log, please refer to Part 1 of this article series at the bottom to get an understanding of how to enable DSCP monitoring in WireShark.

The purpose of this multi-part article  is to lay everything out in a concise manner to help you, the reader, understand how to enable QoS for Lync Server 2013 and various supported clients such as Lync 2010, Lync 2013, and the Attendant Console .  Keep in mind that this article is only for the ability to enable QOS, it is not a comprehensive guide on all the various dynamic ports available in Lync to lock down your firewalls.  For that, you can check out my other article here. Second of all, the question may arise, why and when would you want to enable QoS?  Audio and Video are synchronize traffic that can be affected by jitter, delay, and packet loss on an IP Network.  Lync has been designed to work without QoS but Lync Administrators can choose to enable both Lync endpoints as well as servers to mark Differentiated Services Code Point (DSCP) values on audio and video packets.  This ensures that audio/video packets get prioritized on a network that is enabled for Differentiated Services (DiffServ).

To better understand DiffServ and its affect on the network, please check out the excellent blog article written by fellow Lync MVP Jeff Schertz at the following URL: http://blog.schertz.name/2011/08/lync-qos-behavior/

So, let’s dive into my version of how to enable QoS.  Shall we?

Part 1

Part 2

Comprehensive Table of QoS Configurations

In order to successfully deploy QoS, it helps if you have a table with all the various information needed.

Lync 2013 allows legacy Lync 2010 clients to connect to Lync 2013.  The legacy Lync 2010 client’s executable name is Communicator.exe whereas Lync 2013 now uses the executable name of Lync.exe. For Attendant clients, Lync 2010 Attendant is the current solution and the executable name is AttendantConsole.exe.  So we need to create policies for all three client executables as well as all the executables the server uses.  To help map out what we need to configure, inputting information into the following table will help set the stage for assigning QoS values for audio and video.

Communicator 2007 r2 does have some interoperability support with Lync 2013 but only for IM/Presence.  Therefore, the same legacy QoS support for the R2 client is no longer required in Lync 2013.  You can see Lync Server 2013 client inoperability support here.

This table will focus on Audio/Video.  In Part 2, we’ll add File Transfers, Application Sharing, and SIP to this list just in case you want to provide a more robust QoS configuration to your environment that extends to more than just Audio/Video.

Client QOS

Windows Vista/7/8 versus Windows XP

Windows Vista, Windows 7, and Windows 8 utilize Policy based QOS. Policy based QOS has the benefit that you can restrict the QoS application at the application level.  For Lync 2010, this would be communicator.exe. For Lync 2013, this would be lync.exe.  For the Lync Attendant Console, this would be attendantconsole.exe. Windows XP uses separate QOS Group Policy Options that do not allow you to restrict the DSCP values at the application level.  This means that all applications that utilize the Audio/Video ports we configure for Audio/Video will get DSCP markings stamped.

Peer to Peer Port Configuration

All client port ranges need to be changed as they are all overlapping by default.  Client Media traffic by default utilizing ports 1024 to 65535 when doing Peer to Peer. To specify the client media port ranges, Set-CSConferencingConfiguration must be used. The port ranges for each modality must not conflict with another modality. Also, it is highly recommended to ensure that when each modality is locked down to its own port range that all ports are contiguous as this will make configuring Group Policy later on a bit easier as you will see later on in the article.

The command used to enable the ability to lock down peer to peer client ports is Set-CsConferencingConfiguration with the ClientMediaPortRangeEnabled set to 1.  When enabled, clients will use the specified port range for media traffic. When disabled (the default value) any available port (from port 1024 through port 65535) will be used to accommodate media traffic.  Because we want to lock down the peer to peer ports, we must run the following command:

Once this command is run, we can go ahead and start locking down our ports.  Now keep in mind, all these commands are provided to the clients via in-band provisioning.  This means that once our client signs in, they will start using these locked down port ranges and it does not require any Group Policy Object to be created (at least not for locking down ports) and pushed down to your clients.

The following commands are where we finally choose the amount of ports and at what port each modality starts.  The commands are:

• Application Sharing:
  Set-CSConferencingConfiguration -ClientAppSharingPort <beginning of port range (5350 by default)> -ClientAppSharingPortRange <extent of port range, at least 4 (40 by default)>
• Audio:
  Set-CSConferencingConfiguration -ClientAudioPort<beginning of port range> -ClientAudioPortRange <extent of port range, at least 20 (40 by default)>
• Video:
  Set-CSConferencingConfiguration -ClientVideoPort <beginning of port range> -ClientVideoPortRange <extent of port range, at least 20 (40 by default)>
• File Transfer:
  Set-CSConferencingConfiguration -ClientFileTransferPort <beginning of port range> -ClientFileTransferPortRange <extent of port range, at least 20 (40 by default)>
• Communicator 2007 R2:
  Set-CSConferencingConfiguration -ClientMediaPort <beginning of port range> -ClientMediaPortRange <extent of port range, at least 40>

Note: -ClientMediaPortRange is used for Office Communicator 2007 R2 Clients. The reason why this uses 40 is because this setting includes all modalities as Office Communicator 2007 R2 did not split apart each modality into their own separate switches.  Being able to break up each modality is a feature of Lync. Because Lync Server 2013 only supports IM/Presence from Office Communicator R2 clients, if you are in a Lync Server 2013 environment with no Lync 2010 Servers, ClientMediaPortRange is unnecessary to configure.  However, you may be in an environment with both Lync Server 2010 and Lync Server 2013 and you may want to configure ClientMediaPortRange as this configuration in Lync Server 2013 still applies to Lync Server 2010 which may still be supporting Office Communicator 2007 R2 clients.  Therefore, we will still configure ClientMediaPortRange.

An example of a properly defined command with the minimum port requirement in one big switch is as follows:

An example of a properly defined command with the default port range is as follows (this is the example we will use going forward when configuring Group Policy):

Configuring Policy Based QOS in Group Policy for Windows Vista, Windows 7, and/or Windows 8 clients

As stated previously, Windows Vista, Windows 7, and Windows 8 clients utilize Policy Based QOS which allows a wider variety of options for configuring QoS.  For example, you can specify that only communicator.exe, lync.exe, or attendantconsole.exe should tag x ports. One thing to note however, is the Lync 2013 client is unsupported on Windows Vista and is only supported in Windows 7 and Windows 8.

In the below example, we will show how to create the Policy-based QoS for Audio.  Once finished, be sure to also create Policy-based QoS policies for Video.  The DSCP Value for Audio will be 46 and the DSCP Value for Video will be 34. Open up Group Policy (in my examples, I am using Local Computer Policy but in a real production environment you would be using Group Policy at some level in your Domain Hierarchy) and navigate to Computer Configuration > Windows Settings > Policy-based QoS.  Right-Click and choose Create new policy.

In the new Policy, give it a name and specify the DSCP Value.  DSCP Values for audio is typically 46.  Make sure the Outbound Throttle Rate check box is cleared.  Click Next.

Since this is Policy-based QoS, we will want to take advantage of only tagging traffic that communicator.exe uses.  So make sure you choose the “Only applications with this executable name” and specify lync.exe. Click Next.

On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.”  Click Next.

On  the following screen, choose TCP and UDP.  In our example above we used the Set-CSConferencingConfiguration command with the ClientAudioPort 20000 -ClientAudioPortRange 40 switches.  Because of this, our source port range will 20000 to 20039 specified as 20000:20039 since our ClientAudioPortRange was 40.

Let’s go ahead and set the DSCP Value for Video with a DSCP value of 34. Right-Click Policy-based QoS and choose Create new policy. In the new Policy, give it a name and specify the DSCP Value.  DSCP Values for video is typically 34.  Make sure the Outbound Throttle Rate check box is cleared.  Click Next.

Since this is Policy-based QoS, we will want to take advantage of only tagging traffic that communicator.exe uses.  So make sure you choose the “Only applications with this executable name” and specify lync.exe. Click Next.

On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.”  Click Next.

On  the following screen, choose TCP and UDP.  In our example above we used the Set-CSConferencingConfiguration command with the ClientVideoPort 20040 -ClientAudioPortRange 40 switches.  Because of this, our source port range will 20040 to 20079 specified as 20040:20079 since our ClientVideoPortRange was 40.

Now go ahead and repeat the above policies for the Lync 2010 Client and the Attendant Client.  The only things you will have to change are the Policy Name and the Application Name.  The AttendantConsole.exe would only have an Audio policy. After finished, you will have 5 client GPO policies and will look like the following:

Now go ahead and restart your Lync clients so they pick up the changes. After Group Policy have applied the settings, you should see the following settings within the registry:

Also, if you are in Workgroup Mode and notice that DSCP Values are not being applied, you may have to apply the following registry key:

Configuring QOS Policies in Group Policy for Windows XP clients

As stated previously, Windows XP Clients (it’s the same for Windows Server 2003) cannot use policy-based QoS.  Instead, it uses QoS Policies based on the QoS Packet Scheduler.  To install the QoS Packet Scheduler on Windows XP or Windows Server 2003, please proceed with the following steps:

Go to Control Panel > Network Connections > Right-Click Network Interface > Choose Properties. Then Choose Install.

Make sure to choose Service.  Click Add.

Choose QoS Packet Scheduler as the Network Service.  Click OK.

Now it is time to go into Group Policy. The DSCP Value for Audio will be 46 and the DSCP Value for Video will be 34. Open up Group Policy (in my examples, I am using Local Computer Policy but in a real production environment you would be using Group Policy at some level in your Domain Hierarchy) and navigate to Computer Configuration > Administrative Templates  > Network > QoS Packet Scheduler.

The section we will be working with is, “DSCP value of conforming packets.”  You do not need to modify “DSCP value of non-conforming packets.” And the two options within “DSCP value of conforming packets” we will be working with is:

• Controlled load service type (For Video with a DSCP Value of 34)
• Guaranteed service type (For Audio with a DSCP Value of 46)

Let’s go ahead and set the DSCP Value for Video (Controlled load service type).  Go ahead and open “Controlled load service type.”  Choose Enabled and set the DSCP to 34. Then click OK.

Let’s go ahead and set the DSCP Value for Audio (Guaranteed service type).  Go ahead and open “Guaranteed service type.”  Choose Enabled and set the DSCP to 46. Then click OK.

After Group Policy have applied the settings, you should see the following two settings set within the registry:

Now hop on your Lync Server and open the Lync Management Shell and type the following command:

This command should set your Windows XP and/or Windows Server 2003 machine with the following registry key:

Configuring QOS for Lync Phone Edition

Configuring Lync Phone Edition QoS is really simple and there’s really only one step.  By default, the DSCP Value is set to 40 which is not typical for voice DSCP. We can see the default value by running the following:

To set this value to 46, run the following command (leaving -Identity blank will modify the global settings):

Surprisingly, that’s all there is to it for enabling QoS to Lync Phone Edition.  That is of course other than rebooting your Lync Phone which is required.

As an alternative to DSCP value, you can utilize 802.1p for Lync Phone edition.  This setting is effective only for networks in which switches and bridges are 802.1p-capable.  The minimum value for this property is 0 and the maximum is 7.  The default value is 0.

To enable 8021.p you can run the following command (leaving -Identity blank will modify the global settings):

Validating QoS using WireShark

What better way to test out your QoS policies than to ensure that using WireShark to see and verify the ports are correctly being restricted to the range of ports we have defined and verify a DSCP value is being added.  Keep in mind, our audio packets will show as UDP as Lync prefers UDP over TCP and only falls back to TCP if UDP does not work.

When opening WireShark, go ahead and start capturing your interface.  Right-click one of the columns and choose Column Preferences.  Add IP DSCP as a column.

Start logging and look for UDP packets and you should see audio packets in the 20000:200039 range we specified and they should be marked as 46.

And voila, there we go. Working as intended!

Conclusion

In this Part 1 on how to enable QOS for Lync Server 2013, we took a look at how to enable QOS for Lync 2010 clients, Lync 2013 clients, and the Attendant Console.  In Part 2, we will take a look at how to enable QoS for for Lync 2013 servers which include QoS for the Lync 2013 Edge Server in addition to Exchange UM.

When first installing the Lync RT app from the Microsoft Store, logging will be turned off.  However, the directory that will house the log files will be created similar to the full Lync 2010 and Lync 2013 client.

For the remainder of the article, I will use the following terminology:

• Lync MX (instead of Lync RT, Lync Metro, Lync Store App, etc…)
• Lync Desktop Client (instead of Lync 2010 or Lync 2013)
• Lync Mobile Client (used when referring to the IOS, WP7, or Android client)

So far, it seems like Lync MX is structured more like the full Lync desktop client.

From below, we can see the location of the tracing log files would be: C:\Users\Username\AppData\Local\Packages\Microsoft.LyncMX_8wekyb3d8bbwe\LocalState\Tracing.  That Microsoft.LyncMX_8wekyb3d8bbwe directory may seem like a dynamic name, but it is not.  It’s static and will be the same path no matter what installation you are looking at.

So far, we have no UCCAPI Logs which are the tracing logs we would use in Snooper to see what the client is doing.  We also see no ETL logs which are the log files that provide more information that you would care to see (in 99.9% of cases).  After logging into Lync MX, I still have no UCAAPI log files.  What I realize is, that for the Lync MX Client, the log file we are looking for no longer does not end in the extension of UCCAPI as we’re used to with the Lync Desktop Client.  The log file we’re looking for is actually Lynclog and does open in Snooper.  But even though this log file exists, no data will be written to it just yet.  We still need to configure a setting first.

Once in Options, scroll to the very bottom and turn on Diagnostic Logs.

Once this is On, I’ll log off and log back on to the Lync MX client.  After doing so, I see some new ETL data and a WPPMedia folder.  But, still no UCAPPI Log that we would use in Snooper to view client-side traces.  What I realized is, with Diagnostic Logging turned on, I now also see some data in the Lynclog file.

So I tried opening the Lynclog file in Snooper and low and behold, it appears that LyncLog is the replacement for UCCAPI… at least for the Lync MX client.

If you have experience with the mobile client, you will know that once you turn on Diagnostic Logging, there is some action you must perform to save the log files.  For example, in the WP7 client, you choose to save the log file and it creates a JPG that you can attach to an e-mail, rename to log on a PC, and view the log information.

So going back into the Lync MX Settings (Windows + I), go to About, scroll to the bottom and choose Save logs.

From digging around, it appears that the Save logs option doesn’t actually do anything.  I’ll keep looking around to see if it actually does anything.  If you discover it does anything, be sure to let me know and I’ll update the article accordingly.

Lync Server 2010 – DBIMPEXP.EXE

Note: I am documenting the commands below for Enterprise Edition of Lync.  For Standard Edition, simply remove /sqlserver.

Backing up and restoring all user data

From the official, “Backing Up Core Data and Settings” Technet article, Microsoft provides the following DBIMPEXP.exe commands to back up user data:

An example would be:

To import data from your backed up .xml file, the following command would import user data:

An example would be:

 Backing up and restoring specific user’s data

There is more control over the usage of Dbimpexp.exe.  With the above commands, you are essentially backing up and restoring the entire rtc database for all user contact and conference information.  If we wanted to backup a specific  user’s contact/conference information, we can run the following command:

To import that specific user’s data from their backed up .xml file, the following command would import that user’s data.

Backing up specific data resource types

With the aforementioned commands, all have a /restype set to all.  This means both contact list and conference directory information is exported.  There is a way to backup either the user or conference data without exporting both.  To export only the user contact list data, the following restype would be specified:

To export only the conference data, the following restype would be specified

When using /restype:confdir, you can also specific a specific conference directory by using the /dirid switch as follows:

 Lync Server 2013 Preview – *-CSUserData

Lync Server 2013 Preview has deprecated the use of DBIMPEXP.exe.  There are now native Lync Mangement Server cmdlets to provide the equivalent.  These three commands are:

• Export-CSUserData – Exports User Data to a ZIP File
• Import-CSUserData – Imports User Data from a ZIP File.  This does require a restart of the Front End Service (RTCSRV) to allow the data from the SQL blob store to the RTC Database.  This is a fast process to import data and is geared more towards bulk import operations.
• Update-CSUserData – Updates User data from a ZIP File  This does NOT require a reboot of the Front End Service (RTCSRV)  but is an expensive and slow process and therefore, should only be run in one-off user scenarios rather than bulk import operations.
• Convert-CSUserData – Converts between a 2010 XML file provided from DBIMPEXP.exe and a ZIP file provided from Export-CSUserData

Note: For this article, I will be showing the new Export-CSUserData and Import-CSUserData commands.  In a future article for Lync Server 2013 RTM, I will provide more information on the remaining commands.

Export-CSUserData

This is the direct replacement for dbimpexp.exe /export.

The command I will be running against my test Lync Server 2013 Preview Pool is as follows:

After exporting the data, we see that we now have a ZIP file.

And within that ZIP, we get a couple XMLfiles.  The meat of the data is stored in DocItemSet.xml.

Just as with DBIMPEXP.exe, we can filter on specific users and conference directories for export.

To filter for a specific user, we would run the following command:

To filter for a specific Conference Directory, we would run the following command:

Import-CSUserData

This is the direct replacement for dbimpexp.exe /import.  It imports data from the ZIP file previously exported from Export-CSUserData.  Then the user data will be replicated with Active Directory automatically at regular time via Lync user replicator service

I will be importing the data I ran previously from Export-CSUserData. The command I will be running against my test Lync Server 2013 Preview Pool is as follows:

After importing the data, we see need to restart the Front End Service, RTCSRV, on all Front End Servers in the pool so that the restored data will propagate from the SQL blob store.

This can easily be achieved by running the following commands:

After all Lync Server 2013 Preview services have been stopped, the following command will start all the Lync Server 2013 Preview services.

Just as with DBIMPEXP.exe, we can filter on specific users and conference directories to import.

To filter for a specific user, we would run the following command:

To filter for a specific Conference Directory, we would run the following command:

With Lync Server 2010 and 2013, there are Lync Regions, Lync Sites, and Lync Subnets.  There are three functions in which these can be utilized:

• Call Admission Control
• Controlling Media Bypass Behavior
• Ability to assign a Location Policy to Network Sites so users 911 will route to a given gateway based on the Network Site they are currently located on
• Provide Site to Site Media Quality behavior in the Monitoring Server Location Reports

Active Directory (AD) is a good starting point to gather all the information on your Sites as well as your Subnets.

Script Functionality

To help automate this process, I wrote the New-CSMultiRegionNetwork.ps1 script.  The purpose of this script is to:

• Make a connection to AD and record every AD subnet that exists and its corresponding AD Site
• Export Data to CSV
• Allows you to specify Lync Network Regions and their corresponding Lync Central Sites
• Allows you to assign Location Policies to Sites (Note: The Location Policies need to be created beforehand as the script will not create Location Policies)
• Allows you to assign Bandwidth Policies to Sites (Note: The Bandwidth Policies need to be created beforehand as the script will not create Bandwidth Policies)
• Will create the Lync Network Regions and assign them to the corresponding Lync Central Site as defined in the CSV
• Will create the AD Site in Lync Network Sites
  • Something to note is that AD Sites support non-alphanumeric characters such as a hyphen while Lync Network Sites do not support non-alphanumeric characters.  Because of this, this script will create the Lync Network Site without any non-alphanumeric characters.  It is safe to re-run the script more than once as the script will always take notice that an AD Site with non-alphanumeric characters will match a Lync Network Site with non-alphanumeric characters.  Important: Be sure that you don’t have an AD Site that would match another AD Site if non-alphanumeric characters were to be removed.  An example if you had two AD Sites: One called Site01 and another called Site-01.  When the process to remove non-alphanumeric characters occur, they will both conflict.
  • If any Lync Network Sites are created, the script will pause for 15 seconds to allow the Lync Network Sites to instantiate.  If no Lync Network Sites exist, it will move immediately on to subnets.
  • It will create the Lync Network Subnets and assign them to their corresponding Lync Network Site
  • It will assign the Lync Bandwidth Policies and/or Lync Location Policies as defined in the CSV

Miscellaneous Notes

Something to note is that the script will function with one or more Lync Network Regions.  If you have only one Lync Network Region, please run my New-CSSingleRegionNetwork.ps1 script which will automate the entire AD Site and Subnet creation without any CSV file tweaking needed. Please go here for this script.

Video Demonstration

Download

v1.0 – New-CSMultiRegionNetwork.zip

Changelog

v1.0 – Script Creation

This will require a Lync 2013 client restart.

As an Administrator, you may not want to make this change to a Client Policy as the goal of Lync is to promote collaboration, not inhibit it by having users Appear Offline and hide from other users.  At the same time, you may want to enable it for a user or two at request and won’t want to have to bother providing this small group of users their own Client Policy.  Lync 2010 provided the ability to do that via registry key.  Mike Pfeiffer provides a great article on Lync 2010 for setting the Lync 2010 registry key to manually enable Appear Offline in Lync 2010.  You can see his article here.

The goal of this article is to show how to do the same in Lync 2013.  Because Lync 2013 is now a part of Office 2013, Lync 2013 registry items are now under the Office 2013 registry section (Office 15.0).  There are two ways to set this registry:

1. Cmd.exe
2. Regedit.exe

Using Cmd.exe

The type the following command:

Reg Add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Office\15.0\Lync" /V "EnableAppearOffline" /D 1 /T REG_DWORD /F

Using Regedit.exe

1. Start regedit.exe
2. In Registry Editor, expand HKEY_LOCAL_MACHINE, expand Software, expand Policies, expand Microsoft, expand Office, expand 15.0, expand Lync
3. Right-click the Lync registry key, point to New, and then click DWORD (32-bit) Value
4. After the new value is created, type EnableAppearOffline to rename the value.
5. Double-click the new EnableAppearOffline registry value.
6. After the new value is created, type EnableAppearOffline to rename the value.
7. Double-click the new EnableAppearOffline registry value.
8. In the Edit DWORD (32-bit) Value dialog box, type 1 in the Value data box, and then click OK.

Bug in Lync 2013 Preview

At the current time of this writing, the latest version of Lync 2013 is Lync 2013 Preview.  In the current Lync 2013 Preview, there is currently a bug that prevents the Appear Offline option from being displayed in the Presence drop down selection.

The workaround until this issue is fixed is that you can set Appear Offline in the taskbar by hovering over the Lync 2013 Preview icon and choosing the Appear Offline option there.

With Lync Server 2010 and 2013, there are Lync Regions, Lync Sites, and Lync Subnets.  There are three functions in which these can be utilized:

• Call Admission Control
• Controlling Media Bypass Behavior
• Ability to assign a Location Policy to Network Sites so users 911 will route to a given gateway based on the Network Site they are currently located on
• Provide Site to Site Media Quality behavior in the Monitoring Server Location Reports

Active Directory (AD) is a good starting point to gather all the information on your Sites as well as your Subnets.

Script Functionality

To help automate this process, I wrote the New-CSSingleRegionNetwork.ps1 script.  The purpose of this script is to:

• Make a connection to AD and record every AD subnet that exists and its corresponding AD Site
• Will create the AD Site in Lync Network Sites
  • Something to note is that AD Sites support non-alphanumeric characters such as a hyphen while Lync Network Sites do not support non-alphanumeric characters.  Because of this, this script will create the Lync Network Site without any non-alphanumeric characters.  It is safe to re-run the script more than once as the script will always take notice that an AD Site with non-alphanumeric characters will match a Lync Network Site with non-alphanumeric characters.  Important: Be sure that you don’t have an AD Site that would match another AD Site if non-alphanumeric characters were to be removed.  An example if you had two AD Sites: One called Site01 and another called Site-01.  When the process to remove non-alphanumeric characters occur, they will both conflict.
    
  • If any Lync Network Sites are created, the script will pause for 15 seconds to allow the Lync Network Sites to instantiate.  If no Lync Network Sites exist, it will move immediately on to subnets.
  • It will create the Lync Network Subnets and assign them to their corresponding Lync Network Site

Miscellaneous Notes

Something to note is that the script will only function with one Lync Network Region.  There are several reasons why:

• I wanted this script to be completely automated.  If you have one Region, run the script and the script will automatically create all Lync Network Sites, Lync Network Subnets, and associate everything accordingly without any administrative intervention whatsoever.
• I thought about checking if multiple Regions exist and if they do, prompt what Network Region needs to be assigned to a Network Site every time a Network Site were to be created.  If you had a ton of Network Sites, this would be incredibly annoying.  Because of this, I will be making another script sometime soon that will run in an Import and Export Mode.  The Export Mode would dump all the AD Sites and AD Subnets to CSV where you can then create a Region Field.  You would then be able to run the script in Import Mode which would then create the Network Sites, Network Subnets, and associate everything accordingly to what is in the CSV.

Video Demonstration

Download

v1.0 – New-CSSingleRegionNetwork.zip

Changelog

v1.0 – Script Creation

Part 1

Part 2

Part 3

Persistent Chat Configuration

At this point, we have Persistent Chat installed but no configuration has been done.  Therefore, our client will show no Persistent Chat capabilities.  The first icon highlighted is to display the contact list and the second icon is to display your conversation history.

By going into the Lync Server 2013 Control Panel, we can see that there’s a new section for configuring Persistent Chat.  We’ll start by configuring a Persistent Chat Policy.  We’ll modify the Global Policy.  Available options are to configure Persistent Chat Policies on a Global level (which is provided by default and not able to be deleted), Site Level, Pool Level, or User Level.  Because we’ll be using the Global Level, go ahead and choose the Global option and choose to edit it.

We can see that the only real option is to enable or disable Persistent Chat.  I chose the option to enable Persistent Chat.  Because this is a Global Policy, it will enable Persistent Chat for the entire organization.

After you commit, you will now see a new icon be displayed in your Lync 2013 client after you wait about 30 seconds or so and then sign out and then sign back in.

Let’s have a look at the Persistent Chat Configuration.  Unlike the Persistent Chat Policy which we can modify at the Global, Site, and User level, Persistent Chat Configuration can only be modified at the Global, Site, and Pool Level.  There’s no User Level.

In the configuration, we have the following options:https://www.shudnow.net/wp-admin/post-new.php

• Default chat history – define the number of chat messages that will be processed for each room upon first request. By default, the number is 30. This is the global default, and administrators can disable chat history per category
• Maximum file size – select the maximum file size of each chat history. By default, the number is 20 MB (20,000 KB).  This setting is enforced on the server because custom applications or legacy Group Chat clients using Office Communications Server 2007 R2 Group Chat Server or Lync Server 2010, Group Chat can post files to a room. The Lync 2013 Preview client does not have file upload/download capability, so if you have a pure Lync 2013 Preview deployment or Lync 2013 Preview client, it is not possible to post files in a Persistent Chat Server chat room.
• Participant Update Limit – select the limit for participant updates. By default, the number is 75. This limit indicates the maximum number of participants in a given room beyond which Persistent Chat Server stops sending roster updates to connected clients about who is present in the room.
• Room Management URL – select the room management URL. This is the URL for a web-based custom room management.
  If you want to customize your room creation experience and include your specific business workflow, you build a custom room management solution, host it somewhere and put the URL here. This URL is sent down to the client so that when a user tries to view/create a room, he is directed to your custom room management solution.

For this article series, we’ll leave the defaults selected.

We’ll now have a look at chat room categories. A chat room category is a logical structure for organizing chat rooms. A category defines a default set of access control lists (ACLs) for controlling the users and user groups who may create or join the chat rooms. You can also use categories in multiple Persistent Chat Server pool deployments and to enforce ethical walls between different subdivisions within their organizations

Chat room categories may contain chat rooms but not other categories. Each category describes its contents with metadata such as Name and Description. In addition, the category has properties which can be set to control the behavior of the chat rooms belonging to it, such as if the chat rooms allow Invitations, or File Uploads or contain Chat History.

After choosing new, we’re asked to choose a specific Persistent Chat Pool.  If you had chosen to deploy a Persistent Chat Server instead of a Pool, you would choose the server. Or if we had multiple Persistent Chat Servers/Pools, we would choose the specific Persistent Chat Server or Pool.

Let’s go ahead and configure our category.  By default, the highlighted options “Enable invitations” and “Enable file upload” were disabled.  I chose to enable these options.  The options below do the following:

• Enable invitations – if selected, the category supports rooms that may have invitations on or off; if cleared, the rooms of this category are not allowed to have invitations.
• Enable file upload – if selected, the rooms of this category can enable or disable file uploads; if cleared, the rooms of this category are not allowed to have file uploads.  This setting is enforced on the server because custom applications or legacy Group Chat clients using Office Communications Server 2007 R2 Group Chat Server or Lync Server 2010, Group Chat can post files to a room. The Lync 2013 Preview client does not have file upload/download capability, so if you have a pure Lync 2013 Preview deployment or Lync 2013 Preview client, it is not possible to post files in a Persistent Chat Server chat room.
• Enable chat history – if selected, room chats become non-persistent. If compliance is enabled, room chats will be saved but users will not be able to access older messages.

I also chose to add the John Doe user to this category which I called Sales. If you scroll down, there are two additional sections where you can deny certain users and add creators. Creators are people who can create chat rooms and assign managers to specific chat rooms they create.

Now it’s time to configure our Chat Rooms. Configuring chat rooms is commonly handled by users or other central teams using Windows PowerShell command-line interface; an administrator typically does not manage chat rooms. However, if you have to create and manage rooms, you can use the Windows PowerShell command-line interface, or add yourself as a member to a room, and use the Lync 2013 Preview client.

The following are things to note about Chat Rooms:

• Administrators can delete older content (for example, content posted before a certain date) from any chat room to keep the size of the database from growing greatly. Or, they can remove or replace messages considered inappropriate for a given chat room. (or consider, unsuitable)
• End-users, including message authors, cannot delete content from any chat room.
• Chat room managers can disable rooms, but cannot delete rooms. Only administrators can delete a chat room after it’s created.

To see all the Lync Management Shell commands for managing Chat Rooms, please see here.

I decided to create a sales chat room called Sales Forecast within our sales category in which John Doe is assigned by running the following command:

Even though you added John Doe to the Category, that does not assign the users to chat rooms.  As stated previously, a category defines a default set of access control lists (ACLs) for controlling the users and user groups who may create or join the chat rooms. You can also use categories in multiple Persistent Chat Server pool deployments and to enforce ethical walls between different subdivisions within their organizations,

Let’s go ahead and add John Doe directly to the Sales Forecast Chat Room. To add John Doe to the Sales Forecast Chat Room, type the following:

Note: You can also add managers which can add members to a Chat Room right from the Lync 2013 client.  And if you recall in the Category for Sales, we could create creators.  Creators can create chat rooms and assign managers to chat rooms within categories they are assigned as a Creator.

Without needing to sign and sign back into the Lync 2013 Client, we see that the new Chat Room automatically shows up for John Doe.

Now if you double-click on Sales Forecast, we enter the chat room in which all data is persistent.

Oh and just to mention, all of this works without having to create a PGPool.15lab.net A record in DNS. The Lync Server 2013 Front Ends handles all the routing internally without any DNS queries.

If you go back to the Followed Section, you see an Ego Filter.  This allows you to be notified on key words.  If you right-click and edit your Ego filter, you will see it allows you to set up Topic Feed Options and Notification Options.  One thing I wanted to point out is that by default, it is configured to notify you if someone types your name in a Persistent Chat Room you are a member in.

Conclusion

In Part 1, we took a look at preparing the environment for the Persistent Chat Pool.  In Part 2, we took a look at the installation process in the Lync 2013 Persistent Chat Pool.  In the Part 3, we  finished up the article series by taking a look at the client capabilities utilizing the Persistent Chat features.

There’s a lot more to learn in Persistent Chat and I feel I showed a small glimpse into the feature set.  But I hope you enjoyed the glimpse into the new Persistent Chat configuration  and capabilities.  I definitely think it’s a huge improvement over Group Chat in previous versions.

Part 1

Part 2

Part 3

Persistent Chat Installation

In Part 1, we configured the Topology to support a Persistent Chat Pool.  We then finished up Part 1 by publishing the topology.  Now we’ll go ahead and install Persistent Chat on our Persistent Chat Server.

After running the Lync Server 2013 setup, just like with any previous release, we need to install the Visual C++ Tools.

Choose the location you want to install Lync Server 2013.

After we click install, read the licensing agreements and then Lync Server 2013 will install the Core Components.  We’ll then hit the Deployment Wizard where you’ll want to click “Install or Update Lync Server System.”

Choose Step 1 to install the Location Configuration Store.  This will install SQL Express on our Persistent Chat Server which will contain a copy of the Central Management Store which contains a copy of our Topology.

Because this is a domain joined machine, we’ll choose “Retrieve directly from the Central Management store.”  This will query Active Directory to find the location of the Pool which owns the Central Management Store database.

You’ll see the following after the Local Configuration Store has been installed which checks if all server prerequisites are installed and then installs the Local Configuration store (SQL Express) with a copy of the Central Management Store.

Go ahead and proceed with Step 2: “Setup or Remove Lync Server Components.”  This will install the Persistent Chat role.

As you can see, there’s only one thing below that gets installed which is the MGCServer.msi.

We’ll now go ahead and start on Step 3 to procure a certificate from our internal CA and the assign the certificate.

Click Request to begin the procurement process for our Persistent Chat Certificate.

I’m not going to go through the entire Persistent Chat certificate procurement process as it’s just like any other standard certificate procurement process (Organization Name, Friendly Name, etc…).  You will see though, since we configured our Persistent Chat environment in a Persistent Chat Pool configuration instead of a single server, the certificate will have a Common Name of PGPool.15lab.net.  We will not be adding any SAN names to the certificate which is an option provided on the screen after choosing a Subject Name.

After specifying all of our options, the Lync Setup process will contact our Online CA to procure the certificate.

We then have the option to assign the certificate for Persistent Chat.

After assigning it, we can verify that the certificate was successfully assigned.

Go ahead and run Step 4 to start the Persistent Chat services.

We can verify that the services started successfully.

But to be extra safe, let’s start services.msc and verify the Lync Server 2013 Persistent Chat service is running as well as any other Lync Server 2013 services.

Conclusion

In Part 1, we took a look at preparing the environment for the Persistent Chat Pool.  In Part 2, we took a look at the installation process in the Lync 2013 Persistent Chat Pool.  In the Part 3, we’ll finish up the article series by taking a look at the client capabilities utilizing the Persistent Chat features.

This article series is to guide you through the entire Lync Server 2013 Persistent Chat deployment process from scratch.  In Part 1, we’ll take a look at preparing the environment for the Persistent Chat Pool.  In Part 2, we’ll take a look at the installation process in the Lync 2013 Persistent Chat Pool.  We’ll then finish up the article series with Part 3 by taking a look at the client capabilities utilizing the Persistent Chat features.

Part 1

Part 2

Part 3

Lab Setup

Guest Virtual Machines

There will be four virtual machines being introduced into the lab; one Windows 2008 R2 Global Catalog with Certificate Services, one Front End Enterprise Edition Server, one SQL Server 2012 BackEnd, and one Windows 7 x64 Client.

Assumptions

• You have a domain that contains at least one Server 2003 SP2 Domain Controller (DC)
• You have configured the IP settings accordingly for all servers to be on the same subnet or be on subnets that are routable to eachother.
• You have at least SQL 2008 R2 server installed if doing an Enterprise Edition deployment. We will be using SQL 2012 installed on Server 2008 R2 SP1.
• You have a copy of Lync Server 2013 Client Release Preview.

Computer Names

Global Catalog Cserver – B-DC1

Lync Server 2013 Enterprise Edition Release Preview – B-L15FE1.15lab.net

Persistent Chat – B-L15PG1.15lab.net

SQL Server 2012 – B-S15BE1.15lab.net

Windows 7 Client – B-Client1.15lab.net

General Information on Topology Support

Persistent Chat installation is very different than OCS 2007 R1 or R2 installation.  You can see my guide on deploying Group Chat with OCS 2007 R2 here.  The first thing we will see is that there is now a Persistent Chat section in Lync 2013 Topology Builder. In Lync Server 2010, it was not supported to collocate Group Chat Databases on the same SQL Server (not just instance, but server) as other Lync 2010 databases.  This is now supported in Lync Server 2013.

If using Lync Server 2013 Standard Edition Front End, it is supported to collocate the Persistent Chat role on the Lync Server 2013 Standard Edition Front End and you can also deploy the Persistent Chat role on its own dedicated box.  The Persistent Chat Database (including Compliance Database) is supported for installation on the Lync 2013 SQL Express instance utilized by a Lync 2013 Standard Edition Front End Server.

If using Lync Server 2013 Enterprise Edition, it is not supported to collocate the Persistent Chat role on the Lync Server 2013 Enterprise Edition Front End.  The reason for this is the the way Lync 2010 Pools (which include CMS, Monitoring, and Archiving) DR work is different than the way Persistent Chat Pools work.  With Enterprise Edition Pools, DRs operate by pairing Enterprise Pools with another Enterprise Pool in a DR Site.  A service called the Backup Service is installed when you pair pools that replicate Enterprise Edition Pool databases (along with the CMS, Monitoring, and Archiving Databases) to the DR Enterprise Edition Pool.

With a Persistent Chat Pool, a single Persistent Chat Pool is stretched across two locations.  This Pool supports up to 8 Persistent Chat Pool Servers where four can be active at any given time. Persistent Chat Pools will use SQL Mirroring to replicate their databases from one Site to the other Site.  However, unlike the Pool Pairing which uses the Backup Service, Persistent Chat Servers use a file share (these file shared are not part of the Lync Server 2013 Topology and you can read more about how these file shares are configured here and here) to replicate SQL database data from the SQL Mirror Instance in the primary datacenter to the SQL Mirror Instance in the secondary/DR datacenter.

In the below example, if there is good connectivity between your sites (low latency and high bandwidth), you will have one Group Chat Pool with up to 4 Group Chat Servers active at any given time and either site can be hosting Active servers at the same time.

In the below example, if there is not good connectivity between your sites (high latency and low bandwidth), you will have one Group Chat Pool with up to 4 Group Chat Servers active at any given time and you will only want one site  hosting Active servers at any given time.

Hopefully that gives you some insight as to why collocation for Persistent Chat role is supported on Standard Edition Front End Servers and why it’s not when using Enterprise Edition Front End Servers.

Prerequisites

Because we need a dedicated Persistent Chat Server, we need to install prerequisites which depend on the operating system (Windows Server 2008 R2 does not have these prerequisites whereas Windows Server 2012 do).

• Software Installation
  • .Net Framework 4.5 RC (available here)
  • PowerShell 3.0 (available here)
  • Windows Identity Foundation (available here)

Installing Persistent Chat

When taking a look at the Lync Server 2013 Topology Builder, we can see there’s a new Persistent Chat Pool section.

Go ahead and right-click on Persistent Chat pools and create a new Persistent Chat Pool.

I decided to choose to create a Highly Available Persistent Chat Pool instead of a single server even though for now, I’m only going to deploy a single Persistent Chat Server.

Go ahead and add the server FQDN of your Persistent Chat Server.

Define the name of the Persistent Chat Pool.  We won’t be enabling compliance in this article but I will be writing a new article in the future when Lync Server 2013 RTMs that shows a Persistent Group Chat Pol with compliance and most likely with DR.  We only have one Central Site currently in my Lync Server 2013 Lab deployment called Chicago.

As you can see, we can utilize the same SQL Instance that our Enterprise Front End Pool uses.  In the previous screenshot, if we were doing Persistent Chat DR, we would have chosen the “Use backup SQL Server stores to enable disaster recovery” option.  If we chose that option, the next screen after “Define the SQL Store” would ask us to define the SQL Stores in the secondary/DR datacenter.  But, we’re not choosing that option at this time.

We now define our File Store.  This can be the same file store used by the Enterprise Front End Pool.

Choose the Front End Pool that Persistent Chat will utilize.  Previously, we chose to use the Central Site, Chicago.  We would now be able to select any pools that are deployed within the Chicago Site.

After finishing up the above, we can now go ahead and publish the Lync Topology.

One of the previous pains with deploying Group Chat in OCS and Lync Server 2010 is that there were manual steps to pre-create databases and manual permission assignment.  It felt a bit alien in comparison to how the rest of the OCS and Lync Server 2010 roles were deployed.  Now, in Lync Server 2013, Persistent Chat no longer requires this manual work and is now has a very familiar and native installation experience.

After publishing the topology, we can see everything went successfully and the databases were created.

Conclusion

Thanks for reading Part 1 where we took a look at preparing the environment for the Persistent Chat Pool.  In Part 2, we’ll take a look at the installation process in the Lync 2013 Persistent Chat Pool.  We’ll then finish up the article series with Part 3 by taking a look at the client capabilities utilizing the Persistent Chat features.