Tuesday, February 1, 2011

Lync DNS Load Balancing and Server Draining

Recently I was onsite with a customer and was asked about DNS Load Balancing. How does it work? Why the change from OCS 2007 R2?

DNS Load Balancing

Microsoft Office Communications Server 2007 requires a Hardware Load Balancer (HLB) to provide resilience for the Enterprise pool. This configuration is both expensive and difficult to configure for SIP load balancing. Lync 2010 introduces DNS load balancing as an alternative to hardware load balancing.

How it Works

The front-end servers register their fully qualified domain name (FQDN) as A records in DNS. When the Enterprise pool is created, the pool FQDN is registered to return from DNS the list of IP addresses of all the front-end servers. The client attempts to connect to one of the IP addresses that were returned. If this connection fails, the client attempts to connect to the next IP address in the list until the connection succeeds.

Server Failure and Recovery

When a server fails, the physical registrar sequence is updated to show the server as unavailable and shared amongst all surviving servers by using a server-server heartbeat. Users are redirected to the next server in their logical registrar sequence and are then connected in backup mode. The server will be recovered returning the physical registrar sequence back to its original state.

Server Commission and Decommission

When topology changes occur, the logical registrar sequence is recalculated for all users. Some users are re-homed to a different front-end server in the same pool. When the server is fully operational, the heartbeat process updates the physical registrar sequence. This results in the batched re-registration process. Decommission is very similar to server failure, with the exception of the re-home to a new primary registrar being part of the decommission process. The topology change results in the recalculation of the logical registrar sequence. This step doesn't happen in a server failure.

You can use DNS load balancing for the SIP traffic on Front End pools and Director pools. With DNS load balancing deployed, you still need to also use hardware load balancers for these pools, but only for HTTP and Distributed Component Object Model (DCOM) traffic. The hardware load balancer is used for HTTP traffic from clients over ports 443 and 80, and for DCOM traffic over port 135 from administrators performing user moves.

Although you still need hardware load balancers for these pools, their setup and administration will be primarily for HTTP traffic, which the administrators of hardware load balancers are accustomed to.

DNS Load Balancing Decision Guidelines

Situation

DNS load balancing supported?

DNS load balancing recommended?

Hardware load balancer (only) recommended?

All or most users homed in the pool run Lync Server 2010 clients.

Yes

Yes

 

Many users homed in the pool still running older clients.

Yes

 

Yes

Interoperates only with other Lync Server 2010 servers.

Yes

Yes

 

Interoperates with many servers running earlier versions of Office Communications Server.

Yes

 

Yes

Running Exchange UM with Exchange 2010 SP1 (or not running Exchange UM)

Yes

Yes

 

Running Exchange UM with earlier versions of Exchange

Yes

 

Yes

Before you can use DNS load balancing, you must:

  1. Override the internal web services pool FQDN.
  2. Create DNS A host records to resolve the pool FQDN to the IP addresses of all the servers in the pool.
To override internal web services FQDN

1. From the Lync Server 2010 program group, open Topology Builder.

2. From the console tree, expand the Enterprise Edition Front End pools node.

3. Right-click the pool, click Edit Properties, and then click Web Services.

4. Below Internal web services, select the Override FQDN check box.

5. Type the pool FQDN that resolves to the physical IP addresses of the servers in the pool.

6. Below External web services, type the external pool FQDN that resolves to the virtual IP addresses of the pool, and then click OK.

7. From the console tree, select Lync Server 2010 , and then in the Actions pane, click Publish Topology.

To create DNS A Host Records for all internal pool servers

1. For each Front End Server in your pool, create a DNS A Host record that maps the pool FQDN to the IP address of that Front End Server.

For example, if you had a pool named pool1.contoso.edu  and three front-end servers, you would create the following DNS entries:

FQDN

Type

Data

Pool1.contoso.edu

Host A

192.168.1.10

Pool1.contoso.edu

Host A

192.168.1.20

Pool1.contoso.edu

Host A

192.168.1.30

     

 

Server Draining

A new feature called server draining enables you to take a server offline without any loss of service to users. When a server is drained it stops taking new connections and calls. These new connections and calls are routed through other servers in the pool. A server being drained allows its sessions on existing connections to continue until they naturally end. When all existing sessions have ended, the server is ready to be taken offline

Adding Custom Presence to Lync

Office Communicator has supported the customization of up to 4 additional presence states for some times, and there are many articles all over the Internet on this topic.  But I have not yet seen one specifically for Lync, so here is a brief overview. 

Basically the same configuration steps are used as what Office Communicator 2007 R2 required, since a change to the default security behavior was added after the 2007 (R1) client which prevented the use of non HTTPS connections to the configuration file.

  1. Create a new XML file on the local workstation and customize the presence states and descriptions.
  2. Disable SIP High Security Mode within Lync.
  3. Enable Custom Presence States within Lync.

So if you already know how to do this in the OCS R2 client, then follow the same steps.  For those of you new to the Communications Server products then here is a step-by-step walkthrough specifically for Lync.

Configuration File

The custom configuration information is stored in an XML file that must be manually created first.  Unique entries can be created with a few limitations: a maximum of 4 states and a limit of 64 characters in the description text.  This file can be accessed by the Lync client using either direct access to the file (via local disk or shared directory on a remote server) or as a web client using HTTP or HTTPS.

The aforementioned change between OC 2007 and 2007 R2 is the default behavior is now to force a secure connection to the XML file, limiting the option to only accessing the file via HTTPS.  This is fine when you want the same custom states to be available for multiple users across all workstations, but for simply adding the additional states to a single primary workstation for yourself using a local file is the best approach.

Because Lync follows the same default behavior of forcing HTTPS then in order to use a local XML file this behavior will need to be disabled, which will be addressed in the next section.  For now the following steps should be performed to create the configuration file and store it on the local workstation.

  • Copy the following text and save into a new text file named presence.xml saved somewhere on the local workstation. (e.g. c:\Windows\presence.xml).  (This file can be saved anywhere as long as file security settings allow read access to it.  Commonly it can be stored in either the client installation directory or user's documents folder.  I simply prefer to drop stuff in the system directory and the path is simple and does not include spaces which often require encapsulating paths within quotes.)

<customStates>
  <customState ID="1" availability="Busy">
    <activity LCID="1033">Urgent Interruptions Only</activity>
  </customState>
  <customState ID="2" availability="Busy">
    <activity LCID="1033">Customer Demo</activity>
  </customState>
  <customState ID="3" availability="Busy">
    <activity LCID="1033">In a Video Call</activity>
  </customState>
  <customState ID="4" availability="Busy">
    <activity LCID="1033">In Training Session</activity>
  </customState>
</customStates>

  • Within the presence.xml file edit the availability values and description text to customize each of the 4 custom states to the desired information.  The availability values are limited to the following strings: Online, Busy, and Do-Not-Disturb.  The activity string text is limited to a maximum of 64 characters.

Registry Settings

To trigger the Lync client to import and use the custom state information two settings will need to be set within the local  workstation's registry.  The first is to allow a local file to be read and removed the HTTPS requirement while the second settings tell Lync where to find the presence configuration file.

  • Create a new REG_DWORD value named EnableSIPHighSecurityMode in the Communicator Software Policies key shown below.  Enter the value of '0' to disable this security mode.

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Communicator
Name: EnableSIPHighSecurityMode
Value: 0

  • Create a new REG_SZ value named CustomStateURL in the same key as shown below.  Enter the absolute path to the presence.xml file using the file:/// URL format.

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Communicator
Name: CustomStateURL
Value: file:///C:/Windows/presence.xml

image

Restart Lync

  • Exit and restart the Lync client to pick up the configuration changes and then pull down the status menu to locate the new choices.

image

Lync 2010 Client Policies

Rejoice Lync Administrators!  Gone are the days of out-of-band provisioning (Group Policy) and utilizing in-band-provisioning (connecting to the server and getting custom settings).  This is great news as many companies have machines that are either domain-joined and/or are outside of the network.  Deploying Group Policies are not viable for non-domain joined machines and are possible to mobile workers if you are using Direct Access.  But, with Lync 2010, you won't have to worry about either.  Because Group Policies for Lync 2010 Client Settings have now been moved to in-band provisioning.  Lync 2010 uses the Lync Management Shell (LMS) to manage these in-band settings utilizing commands with the following noun: CSClientPolicy*.  Commands with this noun include:

  • New-CSClientPolicy
  • Get-CSClientPolicy
  • Set-CSClientPolicy
  • Grant-CSClientPolicy
  • Remove-CSClientPolicy
  • New-CSClientPolicyEntry

The main commands will will look at are the first four commands.

The biggest thing to note about Client Policies, is that they can be configured at three different levels.  These levels include:

  • User Level
  • Site Level
  • Global Level

By default, user policies are set at the Global Level.  Unfortunately, the Get-CSClientPolicy -Identity User, does not show anything other than the user set policies. So let's say I want to see what I am assigned.  I can run the following command:

Get-CSUser "Shudnow, Elan"

VoicePolicy                       : ChicagoVoicePolicy
ConferencingPolicy                :
PresencePolicy                    :
DialPlan                          :
LocationPolicy                    :
ClientPolicy                      : ChicagoClientPolicy
ClientVersionPolicy               :
ArchivingPolicy                   :
PinPolicy                         : ChicagoPinPolicy
ExternalAccessPolicy              :
HostedVoiceMail                   :
HostedVoicemailPolicy             :

If one of the variables above is $null, that doesn't mean you are not abiding by some policy.  The above will only display User Level Policies.  Site Level and Global Policies are not displayed.  This is because User Level Policies are readily available in Active Directory whereas the Site Level Policies and Global Policies.  More information on this as well as a script that can provide more verbose information showing what policies including Site Level Policies or Global Level Policies are included here.

But by default, we can see that no policies exist other than the Global Policy by running the following command:

Get-CsClientPolicy | FL Identity

There are some fundamental things you should know about when managing policies on users:

  • When we want to create policies, we use the New-CSClientPolicy command.
  • When we want to modify policies, we use the Set-CSClientPolicy command.
  • When using the Set-CSClientPolicy with no -Identity (as -Identity is actually Optional), the Global Policy is modified.
  • When using the Set-CSClientPolicy with the -Identity specified, if we want to modify or create a Site Policy, we prefice the Identity with site:.  For Example: Set-CSClientPolicy -Identity site:Chicago.
  • When using the Set-CSClientPolicy with the -Identity specified, if we want to modify or create a User Policy, we do not prefice the Identity. For Example: Set-CSClientPolicy -Idenitty ChicagoClientPolicy.
  • When setting a client policy on a user, we use the Grant-CSClientPolicy.  For Example: Grant-CsClientPolicy -Identity "Elan Shudnow" -PolicyName SalesPolicy

Example

Let's take a look at an example.  Let's remove the ability for my account to be able to display photos.  As you can see in the following screenshot, I currently have the ability to display photos:

We need to first create the ChicagoClientPolicy.  We do this by running the following command:

New-CSClientPolicy -Identity ChicagoClientPolicy

Now let's re-run the command we saw in the first screenshot in this article to verify we see both a Global Policy as well as our new ChicagoClientPolicy.

Get-CsClientPolicy | FL Identity

I will run the following two commands command to remove the ability to Display Photos for our new ChicagoClientPolicy and then verify the DisplayPhoto parameter is set to NoPhoto:

Set-CSClientPolicy -Identity ChicagoClientPolicy -DisplayPhoto NoPhoto
Get-CSClientPolicy -Identity ChicagoClientPolicy | Format-List DisplayPhoto

Now we'll have to assign the ChicagoClientPolicy to my user account and then verify it was assigned.  We do this by running the following commands:

Grant-CSClientPolicy -Identity "Shudnow, Elan" -PolicyName ChicagoClientPolicy
Get-CSUser -Identity "Shudnow, Elan" | FL ClientPolicy

After signing out and signing back in, voila, pictures are no longer there.  Success!

But, let's say we wanted to reverse this.  You may think to yourself, can I just set the setting to Null/Remove Policy or do I have to set the property to the opposite value to reset the registry setting?  Well, let's have a look.  I'm going to try to just remove the policy from my account and verify that and then see if that takes care of it.  I'll do this by running the following command:

Grant-CSClientPolicy -Identity "Shudnow, Elan" -PolicyName $Null
Get-CSUser -Identity "Shudnow, Elan" | FL ClientPolicy

After signing out and signing back in, voila, pictures are back.  Success again!