RSS Subscription 168 Posts and 2,769 Comments

Blog Archives

Manually enable Appear Offline in Lync 2013 Preview via Registry

Lync 2013, just as with previous releases, allows the ability to Appear Offline. And just as with previous releases, you can enable this functionality in the Lync Client Policies. For information on how Lync Client Policies work, see my post here.  To enable Appear Offline through Client Policie against the Global Policy, use the following command:

Get-CSClientPolicy | Set-CSClientPolicy -EnableAppearOffline $true

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.

Share

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

To Automate Lync Network Site and Subnet Creation with more than one Lync Network Region, please see my New-CSMultiRegionNetwork.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-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

Share

Lync Server 2013 Release Preview Persistent Chat with Enterprise Pool – Part 3

This article series is to guide you through the entire Lync Server 2013 Persistent Chat deployment process from scratch.  In Part 1, 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.

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:http://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.

Share

Lync Server 2013 Release Preview Persistent Chat with Enterprise Pool – Part 2

This article series is to guide you through the entire Lync Server 2013 Persistent Chat deployment process from scratch.  In Part 1, 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.

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.

Share

Lync Server 2013 Release Preview Persistent Chat with Enterprise Pool – Part 1

Now that Lync Server 2013 Release Preview is here, I thought it would be nice to create an article on how to deploy a Persistent Chat (formerly Group Chat) Server while connected to a SQL 2012 Backend Server.

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.

Share

Lync 2010 Central Site Resilience w/ Backup Registrars, Failovers, and Failbacks – Part 3

Introduction

Welcome to Part 3 of this article series. In Part 1, we started off by discussing the goal of this lab. That goal is to wrap all the information out there on how to utilize Central Site Resilience in regards to failovers, fallbacks, how redirects function, how SRV records fit in, etc… We first discussed what the lab setup is going to be using Hyper-V, and then proceeded to take a look at the base topology and configuration.  In Part 2 of this article series, I went through the sign-in process for each user.  Because the SRV record for sign-in was pointed to A-L14FE1.shudlab.net, the sign-in process was different for each user logging in.

In this Part, we’ll do a failover test and a failback test without a SRV record in place.  We’ll take a look at what happens to ClientUser1 using A-L14FE1 Pool and what happens to ClientUser2 using A-L14FE2 Pool when we take down one of the Pools.  We will then take a look at what happens when the Pool that came down comes back online. And finally, we will end our tests by seeing what happens when a second SRV record is in place.

Part 1

Part 2

Part 3

The Failover with only one SRV

As shown in Part 1, our SRV record is pointing to A-L14FE1.shudlab.net. If you recall from Part 2, when ClientUser1 signed in and connected to A-L14FE1.shudlab.net, he received no 301 Redirect and therefore was not informed of their Primary and Backup Registrar.  We also saw ClientUser2 connect to A-L14FE1.shudlab.get, and received a 301 redirect with his Primary and Backup Registrar and ClientUser2 then connected and registered to A-L14FE2.shudlab.net.

ClientUser1

Let’s start with disabling the NIC on A-L14FE1.  I wanted to see the behavior of ClientUser1.  Don’t forget, ClientUser1 initially connected to A-L14FE1.shudlab.net with no 301 redirection.  Because of this, it has no idea what its backup registrar is and there is no additional SRV records other than the one that has you connecting to A-L14FE1.

After approximately 30 seconds, ClientUser1 gets disconnected.

Remember in the Topology, we had a failover detection time of 30 seconds.  I let this sit here for about 5-8 minutes and it stayed disconnected.

ClientUser2

First thing I did is re-enable the NIC on A-L14FE1 and let ClientUser1 sign back in.  I want to be in a normal operational state.  Now let’s disable the NIC on A-L14FE2.shudlab.net and see what happens with ClientUser2.  What we should see happen is that it fails over to A-L14FE2.shudlab.net.  The reason being is that it signed in using the SRV record, received the 301 redirect, and was informed of both its Primary Registrar and its Backup Registrar.  While ClientUser2 should be able to fail over, don’t forget about the Endpointconfiguration.cache file.  It this client were to sign out and sign back in, it would not use the SRV record and connect directly to A-L14FE2.shudlab.net.  Because of that, it would no longer know about its Backup Registrar and would have no idea where to reconnect.

But let’s take a look at both scenarios.  Let’s first take a look at if it fails over properly since the last sign-in it completed it received a 301 redirect.

We’ll go ahead and disable the NIC on A-L14FE2.shudlab.net.

After around 30 or so seconds, ClientUser2 signs out.  What I would expect now is ClientUser2 connects to A-L14FE1.shudlab.net since again, when ClientUser2 initially signed in, it received a 301 redirect which informed ClientUser2 of both the Primary and Backup Registrar.

And just as I thought, ClientUser2 connects to A-L14FE1.shudlab.net

After re-enabling the NIC on A-LyncFE2.shudlab.net, within 40 seconds (which is the failback detection time), ClientUser2 reconnects.

The Failover with a second SRV pointing to the secondary pool

So we’ve seen ClientUser1 fail to connect when A-L14FE1.shudlab.net goes down because ClientUser1 never received a 301 redirect message and because there is no 2nd SRV record in the environment.  Let’s go ahead and add our second SRV record with a priority of 10.

And just to verify A-Client1 sees the change, let’s do a new nslookup.

Ok, now let’s run the same test we initially did.  I’m shutting down A-L14FE1.shudlab.net server’s NIC.  What we saw earlier on in our tests is that ClientUser1 would just sit signed out with nowhere to go.  What should happen now is the Lync client signs out, ends up finding the second SRV record, and now is able to connect to the second pool, A-L14FE2.shudlab.net.

After around 30 or so seconds, ClientUser1 signs out.  Let’s see if it picks up the 2nd SRV record and then signs into A-L14FE2.shudlab.net

After a little bit of waiting, sure enough, ClientUser1 can now successfully sign into A-L14FE2.shudlab.net

Now let’s take a look at a Netmon Trace and see what exactly ClientUser1 did for DNS lookups.

When the server is down, we see the client query for _sipinternaltls._tcp.shudlab.net.  We can see in the red highlights at the bottom, we have a-l14fe1.shudlab.net and l14fe2.shudlab.net returned.  Part of the data return is obviously the priority information.  What we end up seeing below is ClientUser1 ends up trying to connec tto a-l14fe2.shudlab.net because it knows it is having problems connecting to a-l14fe1.shudlab.net.  Because of that 2nd SRV being in place, ClientUser1 found it, is doing another query for a-l14fe2.shudlab.net to find its IP address, and now makes a connection to this server.  Voila, we now have a failed over client.

 

Reviewing some key points

  • If a client gets redirected to a server, it is a 301 redirect that informs the client of their Primary and Backup Registrar.  If the Primary happens to be down (for example, if you connected to a Director), the client will automatically be able to connect to their Backup Registrar.  If their Primary happens to be operational, the user connects, and their Primary Goes down, that user will failover to their Backup Registrar.
  • If a client has signed in at least once, their Primary Server has been cached into a file called Endpointconfiguration.cache.  That client will always connect directly to that server instead of potentially getting a 301 redirect.  It is because of this it is very important to have multiple SRV records in the environment to increase the chance that regardless if a server is cached in the Endpointconfiguration.cache file, that client will have another means to find another registrar in the environment.  If that registrar happens to be another pool that is not their primary, the user will get a 301 redirect to their Primary and Backup Registrar Pool.
  • A registrar does help as it will redirect clients to their correct pool and provides the clients with a 301 redirect thus letting the client know what their Primary and Backup Registrar is.  But as you have seen, do not completely rely on this due to the client caching server information in the Endpointconfiguration.cache. You absolutely should have at least 2 SRV records with two different priorities to ensure a client will failover to another registrar regardless if you have a Director in your environment or not.

 

Conclusion

Well folks, that is all for not just Part 3, but the entire article series. In this part, we performed a failover test and a failback test without a SRV record in place.  We then took a look at what happens to ClientUser1 using A-L14FE1 Pool and what happens to ClientUser2 using A-L14FE2 Pool when we take down one of the Pools.  We then took a look at what happens when the Pool that came down comes back online.  And we finally ended our tests in seeing what happens when a second SRV record is in place.

Hopefully these articles have helped you understand more on how the deployment of Lync 2010 Central Site Resilience works.  Feel free to ask questions in the comments below and I will do my best to answer questions.

 

Share

Lync 2010 Central Site Resilience w/ Backup Registrars, Failovers, and Failbacks – Part 2

Introduction

Welcome to Part 2 of this article series. In Part 1, we started off by discussing the goal of this lab. That goal is to wrap all the information out there on how to utilize Central Site Resilience in regards to failovers, fallbacks, how redirects function, how SRV records fit in, etc… We first discussed what the lab setup is going to be using Hyper-V, and then proceeded to take a look at the base topology and configuration.

In this Part, I will go through the sign-in process for each user.  Because the SRV record for sign-in is pointed to A-L14FE1.shudlab.net, the sign-in process will be different for each user logging in.

Part 1

Part 2

Part 3

The Sign-In Process

As shown in Part 1, our SRV record is pointing to A-L14FE1.shudlab.net.  This means when ClientUser1 connects, he will connect directly to his home server.  When ClientUser2 connects, he will connect to A-L14FE1.shudlab.net, will get authenticated, and will receive a 301 redirect to A-L14FE2.shudlab.net.

ClientUser1

This is a completely fresh client.  No Lync 2010 client has signed in and therefore, there is no cached folder with any endpointconfiguration.cache file with a cached server.  The Lync 2010 client will sign in for its first time and do the SRV lookup.

Let’s enable logging on A-Lync14FE1 since that is the server that will be authenticating all Lync 2010 logins.  Essentially, if we had a Director, it would be doing the exact same thing in this situation.  We’ll start logging by going to: Start > All Programs > Microsoft Lync Server 2010 > Lync Server Logging Tool.  Enable the SIPStack option, choose Information, and then choose All Flags.  Then Click Start.

Now that we’re logging, we’ll hop back onto A-Client1, and sign into the Lync 2010 client using the ClientUser1 user account.  We can see that the Lync 2010 Client on A-Client1 signed in successfully and we can see in the Configuration Information (Control + Right-Click on Lync Icon in Notification Area) that we’re connected to A-L14FE1.

Heading back over to- AL14FE1.shudlab.net, let’s take a look at the Lync Logs.  We click Stop and then Analyze to view the logs in Snooper.  Make sure the Lync 2010 Resource Kit tools are installed otherwise Snooper will not launch.  Taking a look at the log, we can see a bunch of incoming Subscribes and a bunch of incoming Service messages.  This Pool has authenticated this user and is now servicing this user.  We see no SIP Redirects and therefore, this ClientUser1 has no idea what its backup registrar is.

Taking a look at the endpointconfiguration.cache file, we can see that this client now has A-L14FE1.shudlab.net cached.  It will no longer try to do an SRV lookup unless it cannot connect to the server specified in this endpointconfiguration.cache file.

ClientUser2

Just like ClientUser1, this is a completely fresh client.  No Lync 2010 client has signed in and therefore, there is no cached folder with any endpointconfiguration.cache file with a cached server.  The Lync 2010 client will sign in for its first time and do the SRV lookup.

Let’s go ahead and start logging again on A-L14FE1.  Refer to the ClientUser1 section on  how to log.  We’re logging on A-L14FE1 instead of A-L14FE2 to see the difference in how A-L14FE1 responds when a user is logging in from a different pool.

Now that we’re logging, we’ll hop back onto A-Client2, and sign into the Lync 2010 client using the ClientUser2 user account.  We can see that the Lync 2010 Client on A-Client2 signed in successfully and we can see in the Configuration Information (Control + Right-Click on Lync Icon in Notification Area) that we’re connected to A-L14FE2.

Heading back over to A-L14FE1.shudlab.net, let’s take a look at the Lync Logs.  We click Stop and then Analyze to view the logs in Snooper.  Make sure the Lync 2010 Resource Kit tools are installed otherwise Snooper will not launch.  Taking a look at the log, we see a ton less data than we did when ClientUser1 logged in.  Again, this is because ClientUser1 was homed on A-L14FE1 whereas ClientUser2 is not homed on A-L14FE1 but is rather homed on A-L14FE2.

Because ClientUser2 is homed on A-L14FE2, when ClientUser2 was initially connecting to A-L14FE2, we can see the authentication occurring, and then A-L14FE2 issues a 301 redirect to ClientUser2.  In the data on the right of the log, we see that in this 301 redirect message, the user is notified what their Primary Registrar is (A-L14FE2.shudlab.net:5061) and their Backup Registrar (A-L14FE1.shudlab.net:5061).  This is why Doug, in his blog article, talked about the benefits of Directors.  A Director will issue 301 redirect for all authenticating users.  This way, clients will know about Primary and Backup Registrar.

But Chris’ article talks about the endpointconfiguration.cache file.  When this ClientUser2 successfully connected, he put ONLY his Primary Registrar into this file.  Because of this, on subsequent attempts, ClientUser2 will connect directly to A-L14FE2.shudlab.net instead of doing an SRV lookup, connecting to A-L14FE1.shudlab.net, and then getting a 301 redirect.  It’s because of this Chris’ article mentions that you should still have multiple SRV records.  They are needed to handle this situation.

Taking a look at the endpointconfiguration.cache file on ClientUser2, we can see that the Backup Registrar is not cached.

Conclusion

Thanks for reading Part 2.  In this Part, I went through the sign-in process for each user.  Because the SRV record for sign-in was pointed to A-L14FE1.shudlab.net, the sign-in process was different for each user logging in.

In Part 3, we’ll then do a failover test and a failback test without a SRV record in place.  We’ll take a look at what happens to ClientUser1 using A-L14FE1 Pool and what happens to ClientUser2 using A-L14FE2 Pool when we take down one of the Pools.  Finally, we’ll take a look at what happens when the Pool that came down comes back online.

To read Part 3 of this article series, click here.

 

Share

« Prev - Next »