RSS Subscription 167 Posts and 2,643 Comments

Lync Non-E911 Local Trunk Dialing based on Location

Lync 2010 introduced Enhanced 911 dialing.  This has been vastly documented and therefore, I will not be blogging on how Enhanced 911 works.  For a great blog post on this, please see the following TechNet blog post from Jens Trier Rasmussen here.

One thing Jens does touch on is using Network Sites for using the Location Policies.  My intent of this blog post is show you how to configure this for Non-E911 Dialing so when a user travels from site to site, they will use a local trunk for Non-Enhanced 911 dialing.  This will be beneficial for organizations who will not be deploying Enhanced 911.

Configuration

The first thing we will want to do is get all of our Network Sites and Subnets defined. I have created two scripts for this that will help you automate this process.

  • New-CSMultiRegionNetwork.ps1
    • 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
  • New-CSSingleRegionNetwork.ps1
    • 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

After creating the network sites with subnets attached, we can see all that data has been imported into Lync.  The client subnet we will be testing on will be 192.168.1.0/24 which is assigned to the Chicago Site.

L15911Local01

What we now need to do is create a PSTN Usage which we will be assigning to the Chicago Voice Policy.  This PSTN Usage will be assigned to a 911 route.  That way, my test user will be in the Chicago Voice Policy which will have the 911 PSTN Usage which will allow them to utilize the 911 route.

Go into the Chicago Voice Policy that will be assigned to your test user account. Go ahead and click New under PSTN Usages.

L15911Local02

Go ahead and give the PSTN Usage a name.  Because this will be for local 911 routes, give it a prefix of Chicago.  In my example, I name it Chicago-911. Then click New for Associated Routes.

L15911Local03

Just like with our PSTN Usage, we’ll want to prefix the 911 route with the site name because the intent of this entire configuration is so users route out a local trunk.  It’s site-based routing.   Our 911 numbers will route out as +911.  I will show you why later.  In our example, the 192.168.1.99 trunk would route our +911 number over to this gateway which is a gateway located in Chicago.

L15911Local04

We can now see our Voice Policy for Chicago contains the Chicago-911 PSTN usage.  And the Chicago-911 PSTN usage is assigned to the Chicago-911 voice route.  This is what allows Chicago Voice Policy users to be able to hit the Chicago-911 Route.

L15911Local05

Now it’s time to create the Location Policy. You will need to create a user policy.  Site policies will not work for this type of automation.  This Location Policy will be assigned to our Chicago Network site which is what allows the automation to happen.

In our Location Policy, the below configuration is sufficient since we’re not using Enhanced 911.  We’re just leveraging Location Policies that will be assigned to Network Sites so when you hop from one site to another, you’ll get a new Location Policy.  This means you will have one Location Policy for every site.  And the Location Policies for each site will have their local PSTN Usage to ensure when a person goes from one site to another, they’ll get a new Location Policy so if they dial 911, it will use a different PSTN Usage which will route out the local trunk for that site.

The E9-1-1 dial number will automatically have a + added to it when it gets sent to the route.  This is the reason why our route pattern was +911.  The E9-1-1 dial masks, when entered, are automatically normalized to the E9-1-1 dial number.  So for example, if I enter 9911 or 4411, it will automatically normalize to +911.  And if you need multiple dial masks, you can use a semicolon.

L15911Local06

Go back to the Site, and specify Location Policy as Chicago-911.  Now, anytime someone who is in this site (192.168.1.0 or 192.168.2.0), will automatically get this Location Policy.

L15911Local07

Make sure your user has the Chicago Voice Policy assigned.

L15911Local08

Now before logging out, lets take a look at what happens if I try dialing 911.

L15911Local09

We see that no normalization has occurred.  But after signing out and back in, we can see that it will now display +911.  That means that the location policy has correctly been applied to the account.  We can also see that the 9911 and 4411 is also working.

L15911Local10

That’s all there is to it.  However, what happens to users who happen to fall onto a subnet that happens to not be assigned to a site?  Thankfully, there is a fallback.  In the user properties, assign the user to a Location Policy that is in their home site.  What happens is, if the Network Site they are on has a Location Policy, that Location Policy is handed back to the user.  If they happen to not be assigned to a Network Site due to the subnet they are on not being assigned to a Network Site, they will utilize the Location Policy assigned to their user account. You can see Jens Trier Rasmussen explaining this in this TechNet Post here.  Specifically, Jens calls this out in the “Configuring Location Policy” section.  Jens states the following:

  • If the subnet (defined by the cmdlet New-CsNetworkSubnet) is associated with a network site (defined by the cmdlet New-CsNetworkSite) and that network site is associated with a LocationPolicy, this location policy is returned to the client.
  • If the subnet is unknown or if the network site isn’t associated with a LocationPolicy, the location policy associated with the user is returned.
  • If the user is not associated with a location policy, the global location policy is returned.

Therefore, it is recommended that if my Client User 1 is primarily based in Chicago, assign that user the Chicago Location Policy.  When they travel and they’re  not on a network site, their 911 will still route, even if it’s not a trunk that is local to their current location.  But at least they’ll hit the 911 PSAP who can then ask for the user’s address and route accordingly.  This is where Enhanced 911 would be better.  But if Enhanced 911 is not used, it is very important to make sure all the appropriate subnets are added to the Network Sites so you don’t have to revert to the fallback mechanism and potentially have a user route out of a trunk that is not local.

To assign the Location Policy to the user as part of this fallback mechanism, go into the Users section, open up that users settings, and choose that user’s Location Policy.

L15911Local11

Share

Updating SQL 2012 Express to SP1 on Lync 2013 Servers

General Information

When installing Lync 2013 Servers, as a part of the install, SQL Express 2012 RTM is installed.  In fact, there are several instances on Lync 2013 Front End Servers that get installed. The following lists what SQL Express instances get installed on what servers:

Standard Edition Front End Server

  • RTCLocal
  • LyncLocal
  • RTC

Enterprise Edition Front End Server

  • RTCLocal
  • LyncLocal

Now let’s say your Front End Servers are not installed yet.  There’s a great way to pre-install your SQL 2012 Express instances with SP1 instead of letting the Lync 2013 Deployment Wizard install SQL.  If you pre-install these SQL 2012 Express SP1 instances, Lync 2013 deployment wizard will see that the prerequisite of needing SQL 2012 is met, and will forgo the need for installing any SQL 2012 Express instances and will utilize the pre-installed SQL 2012 Express SP1 instances.  For more information on this, please see this TechNet blog post here.

Lync MVP, Pat Richard, has created an excellent script for all sorts of automated tool downloads/installs as well as prerequisite installs.  His script will take care of the SQL 2012 Express SP1 instances for you as well.  His script is here.

Let’s say you didn’t know about Pat’s script or that you could preinstall SQL 2012 Express SP1 and you have already installed Lync 2013 Front End Servers using the SQL 2012 Express RTM code.  I will show you how to upgrade your SQL 2012 Express RTM instances to SQL 2012 Express SP1.

Installation of SQL 2012 Express SP1 x64

First, you will need to download the SQL 2012 Express SP1 x64 bits from here.

Once these bits are downloaded, open a Command Prompt and navigate to where these bits are downloaded.

On an Enterprise Edition Server, you will want to run the following two commands:

SQLEXPR_x64_ENU.exe /ACTION=Patch /INSTANCENAME=RTCLOCAL /QS /HIDECONSOLE /IAcceptSQLServerLicenseTerms
SQLEXPR_x64_ENU.exe /ACTION=Patch /INSTANCENAME=LYNCLOCAL /QS /HIDECONSOLE /IAcceptSQLServerLicenseTerms

On a Standard Edition Server, you will want to run the following three commands:

SQLEXPR_x64_ENU.exe /ACTION=Patch /INSTANCENAME=RTCLOCAL /QS /HIDECONSOLE /IAcceptSQLServerLicenseTerms
SQLEXPR_x64_ENU.exe /ACTION=Patch /INSTANCENAME=LYNCLOCAL /QS /HIDECONSOLE /IAcceptSQLServerLicenseTerms
SQLEXPR_x64_ENU.exe /ACTION=Patch /INSTANCENAME=RTC /QS /HIDECONSOLE /IAcceptSQLServerLicenseTerms

In my environment, I have initiated the update for the RTCLocal instance.  Below are a few screenshots of the update process in action.

L15SQLUpdate01

L15SQLUpdate02

L15SQLUpdate03

L15SQLUpdate04

Validating SP1 Installation

Once the install is complete, I’m sure you’ll want to validate the instance has been updated to SP1.  Fortunately, an excellent script for this is provided here.  Once downloaded onto your server, you will have to run the following command to allow this unsigned script to be run:

Set-ExecutionPolicy Unrestricted

Go ahead and execute the getInfo-SqlServer.ps1 script.

As expected, we see the RTCLOCAL instance has successfully been updated to SP1.

L15SQLUpdate05

Share

Enabling QoS for Lync Server 2013 and Various Clients – Part 2

Welcome to Part 2 on how to Enabe QoS for Lync Server 2013 and Various Clients. 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.  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/

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:

Set-CsConferenceServer -Identity <ConferencingServer:FQDN of Lync Pool or Lync2010AV Server/Pool FQDN> -AppSharingPortStart 40803 -AppSharingPortCount 8348

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.

Lync15QoS20

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

Lync15QoS21

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

Lync15QoS22

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.

Lync15QoS23

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.

Lync15QoS24

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

Lync15QoS25

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

Lync15QoS26

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.

Lync15QoS27

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:

Lync15QoS28

Lync15QoS29

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.

Lync15QoS30

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.

Lync15QoS31

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

Lync15QoS32

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.

Lync15QoS33

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:

Lync15QoS34

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 Local Group Policy since this is an Edge Server 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.

Lync15QoS35

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.

Lync15QoS36

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.

Lync15QoS37

 

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.

Lync15QoS38

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:

Lync15QoS39

Lync15QoS40

Lync15QoS41

Lync15QoS42

Lync15QoS43

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.

Share

Enabling QoS for Lync Server 2013 and Various Clients – Part 1

There’s documentation available by Microsoft on how to enable Quality of Services (QoS) in Lync which you can find here.  I have a previous article series on enabling QoS for Lync 2010 here.  This article series will be more comprehensive than my previous article series and can be used instead of my Lync 2010 article series as this article series will provide all the necessary QoS configuration for both Lync Server 2010 and Lync Server 2013 and all the various clients while also supporting QoS for the Communicator 2007 R2 Client during a co-existence period when Communicator 2007 R2 is run against a Lync 2010 Pool.

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.

Component Communication type Executable name DSCP value TCP/UDP Source IP Destination IP Source Ports Destination Ports
A/V Conferencing service Audio AVMCUSvc.exe 46 Both Any Any 49152-57500
Video AVMCUSvc.exe 34 Both Any Any 57501-65535
A/V Edge service Audio MediaRelaySvc.exe 46 Both Edge Internal IP Any 49152 – 57500 from Lync Edge to Servers20000 – 20039 from Lync Edge to Internal Clients
Video MediaRelaySvc.exe 34 Both Edge Internal IP Any 57501 – 65535 from Lync Edge to Servers20040 – 20079 from Lync Edge to Internal Clients
A/V Edge service to Exchange UM   Servers Audio MediaRelaySvc.exe 46 UDP Edge Internal IP Exchange UM Servers 1024-65535
Mediation Server Audio MediationServerSvc.exe 46 Both Any Any 49152-57500
Response Group application Audio OcsAppServerHost.exe 46 Both Any Any 49152-57500
Conference Announcement service Audio OcsAppServerHost.exe 46 Both Any Any 49152-57500
UCMA applications Audio OcsAppServerHost.exe 46 Both Any Any 49152-57500
Lync 2010 Audio Communicator.exe 46 Both Any Any 20000 – 20039
Video Communicator.exe 34 Both Any Any 20040 – 20079
Lync 2013 Audio lync.exe 46 Both Any Any 20000 – 20039
Video lync.exe 34 Both Any Any 20040 – 20079
Lync 2010 Attendant Audio AttendantConsole.exe 46 Both Any Any 20000 – 20039
Lync 2010 Phone Edition Audio n/a 46 Both Any Any 20000 – 20039

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:

Set-CsConferencingConfiguration -ClientMediaPortRangeEnabled 1

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:

Set-CsConferencingConfiguration -ClientAudioPort 20000 -ClientAudioPortRange 20 -ClientVideoPort 20020 -ClientVideoPortRange 20 -ClientAppSharingPort 20040 -ClientAppSharingPortRange 4 -ClientFileTransferPort 20044 -ClientFileTransferPortRange 4 -ClientMediaPort 20048 -ClientMediaPortRange 40

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):

Set-CsConferencingConfiguration -ClientAudioPort 20000 -ClientAudioPortRange 40 -ClientVideoPort 20040 -ClientVideoPortRange 40 -ClientAppSharingPort 20080 -ClientAppSharingPortRange 40 -ClientFileTransferPort 20120 -ClientFileTransferPortRange 40 -ClientMediaPort 20160 -ClientMediaPortRange 40

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.

Lync15QoS1

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.

Lync15QoS2

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

Lync15QoS3

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.

Lync15QoS4

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.

Lync15QoS5

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.

Lync15QoS6

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

Lync15QoS7

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.

Lync15QoS8

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:

Lync15QoS9

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:

Lync15QoS10

Lync15QoS11

Lync15QoS12

Lync15QoS13

Lync15QoS14

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:

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\QoS]“Do not use NLA”=”1″

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:

Set-CsMediaConfiguration -EnableQoS $true

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:

Get-CsUCPhoneConfiguration

Identity             : Global CalendarPollInterval : 00:03:00 EnforcePhoneLock     : True PhoneLockTimeout     : 00:10:00 MinPhonePinLength    : 6 SIPSecurityMode      : High VoiceDiffServTag     : 40 Voice8021p           : 0 LoggingLevel         : Off

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

Set-CsUCPhoneConfiguration -VoiceDiffServTag 46

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):

Set-CsUCPhoneConfiguration -Voice8021p <value>

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.

Lync15QoS15

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.

Lync15QoS16

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.

Share

Lync MX Client – Viewing Logs

The Lync MX Client is a new client that was released in late October 2012.  Maybe people will refer to this client as the Lync MX client.  In fact, when viewing log files, you will see the log files refer to MX.  The interesting part about this client is it appears to be a hybrid between a full Lync client and the Lync client you will find on your other mobile devices such as IOS (both Iphone and IPad), Android, and Windows Phone 7.  The biggest difference with the Lync RT client, is that it supports voice and video which allows you to use this client as a full blown client.  It also allows my to expand Exchange Distribution Lists I have on my contact list, visual voicemail, conversation history, etc..  It is a richer client.  That is for sure.

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.

Share

DBIMPEXP.exe functionality integrated into Lync 2013 Preview Management Shell

Prior to Lync Server 2013, there was a tool.  And this tool was called DBIMPEXP.exe.  It stands for Database Import Export.  This tool was part of the OCS and Lync 2010 Resource Kits, but will now be deprecated to make way for built-in Lync Management Shell PowerShell commands.  But before we talk about its replacement in detail, let’s talk a little bit about DBIMPEXE.exe’s capabilities. DBIMPEXP.exe was used to back up users contact and conference data.  In fact, part of the official backup instructions were to use the DBIMPEXP.exe to backup user data.

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:

Dbimpexp.exe /hrxmlfile:<path and backup file name> /sqlserver:<SQL Server FQDN>\<instance name>

An example would be:

Dbimpexp.exe /hrxmlfile:D:\BackupUser.xml /sqlserver:sql.contoso.com\rtc

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

Dbimpexp.exe /hrxmlfile:<path and file name of backed up Rtc database> /sqlserver:<SQL Server FQDN>\<instance name> /import /restype:all

An example would be:

Dbimpexp.exe /hrxmlfile:D\BackupUsers.xml /sqlserver:sql.contoso.com\rtc /import /restype:all

 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:

dbimpexp.exe /hrxmlfile:contacts.xml /user:<sip URL> /sqlserver:sqlservername

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

dbimpexp.exe /import /hrxmlfile:contacts.xml /user:<sip URL> /sqlserver:SQL_SERVER

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:

/restype:user

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

/restype:confdir

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

/dirid:1001

 

 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:

Export-CsUserData -PoolFQDN “lync15pool.15lab.net” -FileName “C:\Logs\ExportedUserData.zip”

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:

Export-CsUserData -PoolFQDN “Pool FQDN” -UserFilter “user@domain.com” -FileName “<path and backup file name>”

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

Export-CsUserData -PoolFQDN “Pool FQDN” -ConfDirectoryFilter 13 -FileName “<path and backup file name>”

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:

Import-CsUserData -PoolFQDN “lync15pool.15lab.net” -FileName “C:\Logs\ExportedUserData.zip”

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:

Stop-CSWindowsService -Name RTCSRV

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

Start-CSWindowsService

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:

Import-CsUserData -PoolFQDN “Pool FQDN” -UserFilter “user@domain.com” -FileName “<path and backup file name>”

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

Import-CsUserData -PoolFQDN “Pool FQDN” -ConfDirectoryFilter 13 -FileName “<path and backup file name>”
Share

New-CSMultiRegionNetwork.ps1 – Automate Lync Network Site and Subnet Creation

To Automate Lync Network Site and Subnet Creation with only one Lync Network Region, please see my New-CSSingleRegionNetwork.ps1 script here.

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

Share

Next »