Elan Shudnow's Blog

Welcome to Part 2 on how to Enable QoS for Lync Server 2010. The purpose of this multi-part article (first part for QoS on Lync Client and second part for QoS on Lync Server) 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 vs Windows XP.  Windows 7 and Windows Vista utilize Policy based QoS and Windows XP used QoS based on the Packet Scheduler.  For Lync 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. The default ports for a Conferencing Server are as such:

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

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

• Application Sharing: 40803 to 49151

To set this, we will run the following command:

Configuring an Application Server is identical.  The only difference is that you use the Set-CSApplicationServer command instead of the Set-CSConferencingServer.  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.

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
• Video: 20040 to 20079

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

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

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 and/or Windows 2008 R2 for a Conferencing Server

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

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

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

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

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

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

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

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

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

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

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

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

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

As stated previously, Lync Server 2010 can only be installed on Windows 2008 or Windows 2008 R2.  Both Windows 2008 and Windows 2008 R2 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 only.  The DSCP Value for Audio will be 46. Open up Group Policy (in my examples, I am using Local Computer Policy but in a real production environment you would be using Group Policy at some level in your Domain Hierarchy) and navigate to Computer Configuration > Windows Settings > Policy-based QoS.  Right-Click and choose Create new policy.

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

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

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

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

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

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

As stated previously, Lync Server 2010 can only be installed on Windows 2008 or Windows 2008 R2.  Both Windows 2008 and Windows 2008 R2 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.

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

On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.”  Alternatively, you can change the Source IP Address to the internal IP of your Edge.  Click Next.

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

‘

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

Peer to Peer Video:

• Policy Name: Lync Edge Peer to Peer Video
• DSCP Value: 34
• Only applications with the following executable name: MediaRelaySvc.exe
• Specify Outbound Throttle Rate is Unchecked
• Source IP: Your Internal Edge IP (Our example is 10.10.10.50/32)
• Destination Port Range of 20040:20079

Client to Server Audio:

• Policy Name: Lync Edge Conferencing Audio
• DSCP Value: 46
• Only applications with the following executable name: MediaRelaySvc.exe
• Specify Outbound Throttle Rate is Unchecked
• Source IP: Your Internal Edge IP (Our example is 10.10.10.50/32)
• Destination Port Range of 49152:57500

Client to Server Video:

• Policy Name: Lync Edge Conferencing Video
• DSCP Value: 34
• Only applications with the following executable name: MediaRelaySvc.exe
• Specify Outbound Throttle Rate is Unchecked
• Source IP: Your Internal Edge IP (Our example is 10.10.10.50/32)
• Destination Port Range of 57501:65535

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

Elan Shudnow :: Nov.28.2011 :: Lync 2010 :: 24245 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F11%2F28%2Fenabling-qos-for-lync-server-2010-part-2%2FEnabling+QoS+for+Lync+Server+2010+-+Part+22011-11-29+01%3A26%3A06Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2424

There’s a doc available by Microsoft on how to enable Quality of Services (QoS) in Lync which you can find here.  The purpose of this multi-part article (first part for QoS on Lync Client and second part for QoS on Lync Server) 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/

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

Part 1

Part 2

Client QOS

Windows 7 versus Windows XP

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

Peer to Peer Port Configuration

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

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

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

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

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

Note: -ClientMediaPortRange is used for Office Communicator 2007 R2 Clients. The reason why this uses 40 is because this setting includes all modalities as Office Communicator 2007 R2 did not split apart each modality into their own separate switches.  Being able to break up each modality is a feature of Lync.

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

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

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

As stated previously, Windows Vista and Windows 7 clients utilize Policy Based QOS which allows a wider variety of options for configuring QoS.  For example, you can specify that only communicator.exe should tag x ports.

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

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

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

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

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

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

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

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

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

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

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

Configuring QOS Policies in Group Policy for Windows XP clients

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

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

Make sure to choose Service.  Click Add.

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

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

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

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

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

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

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

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

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

Configuring QOS for Lync Phone Edition

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

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

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

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

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

Conclusion

In this Part 1 on how to enable QOS for Lync Server 2010, we took a look at how to enable QOS for Lync clients.  In Part 2, we will take a look at how to enable QoS for for Lync 2010 servers.

Elan Shudnow :: Nov.04.2011 :: Lync 2010 :: 23183 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F11%2F04%2Fenabling-qos-for-lync-server-2010-part-1%2FEnabling+QoS+for+Lync+Server+2010+-+Part+12011-11-05+02%3A51%3A47Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2318

In Lync Server 2010 we can utilize Dial-In Conferencing Phone Numbers so both users utilizing the Lync Client End-Points can join these meetings using an IP Network and Telephony Users can join the same meeting via a Telephone utilizing the Public Switched Telephony Network (PSTN).

As you can see, we can define multiple Dial-In Conferencing Phone Numbers in the Lync Control Panel within the Conferencing Section.

Now before we understand how to reorder Dial-In Conferencing Numbers, we must first understand how different users can have different numbers get displayed when they create a Lync Online Meeting.  When we create a Dial-In Conferencing Number, one of the requirements is to set a Region.

Now in order to be able to add a Region, the Region must be created ahead of time.  And that is done through your Enterprise Voice Dial-Plans.  You need to do this even if you have not deployed Enterprise Voice.  By default, there is only one Dial Plan called Global.  So all users in the organization by default would fall under the Global Dial Plan.

If we go into this Global Dial Plan, we can set the name of our Dial-In Conferencing Region.   Now when we create a Dial-In Conferencing Number, “Chicago, Illinois USA” will be an option.

If you use only the Global Dial Plan, all users when creating an Online Meeting will see all Dial-In Conferencing Numbers that are associated with this Region.  In an environment where you have multiple Dial Plans (example would be USA, Germany, China), you can set the USA Dial Plan’s Dial-In Conferencing Region to USA, the Germany Dial-In Conferencing Region to Germany, and the China Dial-In Conferencing Region to China.  Users that are in the USA would then be assigned to the USA Dial Plan, users that are in the Germany Dial Plan would be assigned to the Germany Dial Plan, and users in China would be assigned to the China Region.

Now keep in mind, all three of our numbers have the “Chicago, Illinois USA” Region associated with them which is associated with the Global Dial Plan.  This means that when any user in the organization goes to create an Online Meeting, they will see the following in the Online Meeting template.

Now going back to our previous USA/Germany/China example, if a user was in the Germany Dial Plan which had a Region of Germany, you would assign the Germany Dial-In Conferencing Numbers to the Germany Dial Plan.  When they create an Online Meeting, only the Germany Dial-In Conferencing Numbers would be displayed.   However, if this user happens to travel to the USA and wants to invite USA people to a Lync Online Meeting button, that user has an option in Outlook called Meeting Options.

If they click Meeting Options, you can see that this Germany user would be able to choose the location that most users will dial in from.  The German User would be able to select a USA based Region and then all phone numbers in the Meeting Template would have all Dial-In Conferencing Numbers that are associated with that USA based Region.

But let’s say you don’t like the order in which the numbers are being displayed in the Meeting Template. You can easily change a specific Dial-In Conferencing Numbers Priority by utilizing the following command (Priority 0 would be this Dial-In Conferencing Number on Top of the Online Meeting Template in Outlook):

You can easily see what the SIP Addresses are of your existing Dial-In Conferencing Numbers by utilizing the following command:

Once you change the Priority Orders in which the numbers are displayed, keep in mind that the Dial-In Conferencing Number that has a Priority of 0 will also be displayed in the “Join Information and Meeting Options” link when joined into a meeting with the Lync 2010 client.  The Dial-in number displayed is always the Dial-In Conferencing Number that has the priority of 0.

Elan Shudnow :: Sep.28.2011 :: Lync 2010 :: 23784 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F09%2F28%2Freordering-lync-2010-dial-in-conferencing-numbers%2FReordering+Lync+2010+Dial-In+Conferencing+Numbers2011-09-29+02%3A59%3A17Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2378

Welcome to Part 3 of Exchange 2010 Site Resilient DAGs and Majority Node Set Clustering.  In Part 1, I discussed what Majority Node Set Clustering is and how it works with Exchange Site Resilience when you have one DAG member in a Primary Site and one DAG member in a Failover Site.  In Part 2, I discussed how Majority Node Set Clustering works with Exchange Site Resileince when you have two DAG members in a Primary Site and one DAG member in a Failover Site. In this Part, I will show an example of how Majority Node Set Clustering works with Exchange Site Resilience when you have two DAG members in a Primary Site and two DAG members in a Failover Site.

Part 1

Part 2

Part 3

Real World Examples

Each of these examples will show DAG Models with a Primary Site and a Failover Site.

4 Node DAG  (Two in Primary and Two in Failover)

In the following screenshot, we have 4 Servers.  Four are Exchange 2010 Multi-Role Servers; two in the Primary Site and two in the Failover Site.  The Cluster Service is running only on the four Exchange Multi-Role Servers.  More specifically, it would run on the Exchange 2010 Servers that have the Mailbox Server Role. When Exchange 2010 utilizes an even number of Nodes, it utilizes Node Majority with File Share Witness.  If you have dedicated HUB and/or HUB/CAS Servers, you can place the File Share Witness on those Servers.  However, the File Share Witness cannot be placed on the Mailbox Server Role.

So now we have our five Servers; four of them being Exchange.  This means we have five voters.  Four of the Mailbox Servers that are running the cluster service are voters and the File Share Witness is a voter as well.  So the question is, how many voters/servers can I lose?  Well if you read the section on Majority Node Set (which you have to understand), you know the formula is (number of nodes /2) + 1.  This means we have (4 Exchange Servers / 2) = 2 + 1 = 3.  This means that 3 voters must always be online for your Exchange Cluster to remain operational.

But now let’s say one or two of your Exchange Servers go offline.  Well, you still have at least three voters online.  This means your cluster will be still be operational.  If all users/services were utilizing the Primary Site, then everything continues to remain completely operational.  If you were sending SMTP to the one of the servers in the Failover Site or users were for some reason connecting to the Failover Site, they will need to be pointed to another Exchange Server that is operational in the Primary Site or the Failover Site. This of course depends on whether the user databases are being replicated from a mailbox database failover standpoint.

But what happens if you lose a third node in which all DAG members in the Failover Site go offline including the FSW? Well, based on the formula above we need to ensure we have 3 voters operational at all times.  At this time, the entire cluster goes offline.  You need to go through steps provided in the site switchover process but in this case, you would be activating the Primary Site and specify a new Alternative File Share Witness Server that exists in the Primary Site so you can active the Exchange 2010 Server in the Primary Site.  The DAG will actively use the File Share Witness since there will be 2 Exchange DAG Members remaining which is an even number of nodes.  And again, when you have an even number of nodes, you will use a File Share Witness.

But what happens if you lose two nodes in the Primary Site as well as the FSW due to something such as Power Failure or a Natural Disaster? Well, based on the formula above we need to ensure we have 3 voters operational at all times.  At this time, the entire cluster goes offline.  You need to go through steps provided in the site switchover process but in this case, you would be activating the Failover Site and specify a new Alternative File Share Witness Server that exists (or will exist) in the Failover Site so you can activate the Exchange 2010 Servers in the Failover Site.   The DAG will actively use the Alternate File Share Witness since there will be 2 Exchange DAG Members remaining which is an even number of nodes.  And again, when you have an even number of nodes, you will use a File Share Witness.

Once the Datacenter Switchover has occurred, you will be in a state that looks as such.  An Alternate File Share Witness is not for redundancy for your 2010 FSW that was in your Primary Site.  It’s used only during a Datacenter Switchover which is a manual process.

Once your Primary Site becomes operational, you will re-add the two Primary DAG Servers to the existing DAG which will still be using the 2010 Alternate FSW Server in the Failover Site and you will now be switched into a Node Majority with File Share Witness Cluster instead of just Node Majority.  Remember I said with an odd number of DAG Servers, you will be in Majority Node Witness and with an even number, the Cluster will automatically switch itself to Node Majority with File Share Witness?  You will now be in a state that looks as such.

Part of the Failback Process would be to switch back to the old FSW Server in the Primary Site.  Once done, you will be back into your original operational state.

As you can see with how this works, the question that may arise is where to put your FSW?  Well, it should be in the Primary Site with the most users or the site that has the most important users.  With that in mind, I bet another question arises?  Well, why with the most users or the most important users?  Because some environments may want to use the above with an Active/Active Model instead of an Active/Passive.  Some databases may be activated in both sites.  But, with that, if the WAN link goes down, the Exchange 2010 Server in the Failover Site loses quorum since it can’t contact at least 2 other voters.  Again, you must have three voters online.  This also means that each voter must be able to see two other voters.  Because of that, the Exchange 2010 Server will go completely offline.

To survive this, you really must use 2 different DAGs.  One DAG where the FSW is in the First Site and a second DAG where its FSW is in the Second Site.  In my example, users that live in the First Active Site would primarily be using the Exchange 2010 DAG Members in the First Active Site which would be on DAG 2.  Users that live in the Second Active Site would primarily be using the Exchange 2010 DAG Members in the Second Active Site which would be on DAG 1. This way, if anything happens with the WAN link, users in the First Active Site would still be operational as the FSW for their DAG is in the First Active Site and DAG 2 would maintain Quorum.  Users in the Second Active Site would still be operational as the FSW for their DAG is in the Second Active Site and DAG 1 would maintain Quorum.

Note: This would require twice the amount of servers since a DAG Member cannot be a part of more than one DAG.  As shown below, each visual representation below of a 2010 HUB/CAS/MBX is a separate server.

The Multi-DAG Model would look like this.

Elan Shudnow :: Sep.07.2011 :: Exchange, Exchange 2010 :: 234310 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F09%2F07%2Fexchange-2010-site-resilient-dags-and-majority-node-set-clustering-%25e2%2580%2593-part-3%2FExchange+2010+Site+Resilient+DAGs+and+Majority+Node+Set+Clustering+%E2%80%93+Part+32011-09-07+13%3A26%3A29Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2343

Welcome to Part 2 of Exchange 2010 Site Resilient DAGs and Majority Node Set Clustering.  In Part 1, I discussed what Majority Node Set Clustering is and how it works with Exchange Site Resilience when you have one DAG member in a Primary Site and one DAG member in a Failover Site.  In this Part, I will show an example of how Majority Node Set Clustering works with Exchange Site Resilience when you have two DAG members in a Primary Site and one DAG member in a Failover Site.

Part 1

Part 2

Part 3

Real World Examples

In Part 1, I showed a Real World example when you have one Exchange DAG member in the Primary Site and one Exchange DAG member in the Failover Site.  In this Part, I am showing a Real World example when you have two Exchange DAG members in the Primary Site and one Exchange DAG member in the Failover Site.

3 Node DAG  (Two in Primary and One in Failover)

In the following screenshot, we have 3 Servers.  Two are Exchange 2010 Multi-Role Servers; one in the Primary Site and one on the Failover Site.  The Cluster Service is running on all three Exchange Multi-Role Servers.  More specifically, it would run on the Exchange 2010 Servers that have the Mailbox Server Role. When Exchange 2010 utilizes an even number of Nodes, it utilizes Node Majority with File Share Witness.  Because we have an odd number of Nodes, we are utilizing Node Majority and will not utilize a File Share Witness.

So now we have our three Servers; all three of them being Exchange.  This means we have three voters which would be the same if we were using an even number of nodes with a File Share Witness since a File Share Witness is also a voter.  So the question is, how many voters/servers can I lose?  Well if you read the section on Majority Node Set (which you have to understand), you know the formula is (number of nodes /2) + 1.  This means we have (3 Exchange Servers / 2) rounded down = 1 + 1 = 2.  This means that 2 voters must always be online for your Exchange Cluster to remain operational just like if we were utilizing 2 DAG members with a File Share Witness.

But now let’s say one of your Exchange Servers go offline.  Well, you still have at least two voters online.  This means your cluster will be still be operational.  If all users/services were utilizing the Primary Site, then everything continues to remain completely operational.  If you were sending SMTP to the Failover Site or users were for some reason connecting to the Failover Site, they will need to be pointed to the Exchange Server in the Primary Site.

But what happens if you lose a second node? Well, based on the formula above we need to ensure we have 2 voters operational at all times.  At this time, the entire cluster goes offline.  You need to go through steps provided in the site switchover process but in this case, you would be activating the Primary Site and specify a new Alternative File Share Witness Server that exists in the Primary Site so you can active the Exchange 2010 Server in the Primary Site.  The DAG won’t actively use the File Share Witness but you should specify it anyways because part of the Failback process is re-adding the Primary Site Servers back to the DAG once they become operational. And once you re-add the second DAG node, you now have two DAG members in the DAG which will want to switch the DAG Cluster into a Node Majority with File Share Witness which is why you need to still specify a File Share Witness.

But what happens if you lose two nodes in the Primary Site? Well, based on the formula above we need to ensure we have 2 voters operational at all times.  At this time, the entire cluster goes offline.  You need to go through steps provided in the site switchover process but in this case, you would be activating the Failover Site and specify a new Alternative File Share Witness Server that exists (or will exist) in the Failover Site so you can activate the Exchange 2010 Server in the Primary Site.   The DAG won’t actively use the File Share Witness but you should specify it anyways because part of the Failback process is re-adding the Primary Site Servers back to the DAG once they become operational.

Once the Datacenter Switchover has occurred, you will be in a state that looks as such.  An Alternate File Share Witness is not for redundancy for your 2010 FSW that was in your Primary Site.  It’s used only during a Datacenter Switchover which is a manual process.

Once your Primary Site becomes operational, you will re-add the Primary DAG Server to the existing DAG which will still be using the 2010 Alternate FSW Server in the Failover Site and you will now be switched into a Node Majority with File Share Witness Cluster instead of just Node Majority.  Remember I said with an odd number of DAG Servers, you will be in Majority Node Witness and with an even number, the Cluster will automatically switch itself to Node Majority with File Share Witness?  You will now be in a state that looks as such.

Part of the Failback Process would be to switch to a FSW Server in the Primary Site.  Once done, you will be back into your original operational state.

Now the final step of the Failback Process would be to re-add your final remaining DAG Member in the Primary Site.  Once done, your cluster will switch back into a Node Majority Cluster and will no longer be utilizing the FSW.

As you can see with how this works, the question that may arise is where to put your the majority of your Exchange DAG Members?  Well, it should be in the Primary Site with the most users or the site that has the most important users.  With that in mind, I bet another question arises?  Well, why with the most users or the most important users?  Because some environments may want to use the above with an Active/Active Model instead of an Active/Passive.  Some databases may be activated in both sites.  But, with that, if the WAN link goes down, the Exchange 2010 Server in the Failover Site loses quorum since it can’t contact at least 1 other voter.  Again, you must have two voters online.  This also means that each voter must be able to see one other voter.  Because of that, the Exchange 2010 Server will go completely offline.

To survive this, you really must use 2 different DAGs.  One DAG where the majority of your Exchange 2010 DAG Members is in the First Site and a second DAG where the majority of the Exchange 2010 DAG Members is in the Second Site.  Users that live in the First Active Site would primarily be using the Exchange 2010 DAG Members in the First Active Site.  Users that live in the Second Active Site would primarily be using the Exchange 2010 DAG Members in the Second Active Site. This way, if anything happens with the WAN link, users in the First Active Site would still be operational as the majority of its Exchange 2010 DAG Members for their DAG is in the First Active Site and DAG 1 would maintain Qourum.  Users in the Second Active Site would still be operational as the majority of its Exchange 2010 DAG Members for their DAG is in the Second Active Site and DAG 2 would maintain Quorum.

Note: This would require twice the amount of servers since a DAG Member cannot be a part of more than one DAG.  As shown below, each visual representation below of a 2010 HUB/CAS/MBX is a separate server.

The Multi-DAG Model would look like this.

Elan Shudnow :: Aug.12.2011 :: Exchange, Exchange 2010 :: 232811 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F08%2F12%2Fexchange-2010-site-resilient-dags-and-majority-node-set-clustering-part-2%2FExchange+2010+Site+Resilient+DAGs+and+Majority+Node+Set+Clustering+-+Part+22011-08-12+15%3A13%3A59Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2328

I’ve talked about this topic in some of my other articles but wanted to create an article that talks specifically about this model and show several different examples in a Database Availability Group (DAG)’s tolerance for node and File Share Witness (FSW) failure.  Many people don’t properly understand how the Majority Node Set Clustering Model works.  In my article here, I talk about Database Activation Coordination Mode and have a section on Majority Node Set.  In this article, I want to visibly show show some real world examples on how the Majority Node Set Clustering Model works.  This will be a multi-part article and each Part will have its own example.

Part 1

Part 2

Part 3

Majority Node Set

Majority Node Set is a Windows Clustering Model such as the Shared Quorum Model, but different.  Both Exchange 2007 and Exchange 2010 Clusters use Majority Node Set Clustering (MNS).  This means that 50% of your votes (server votes and/or 1 file share witness) need to be up and running.  The proper formula for this is (n / 2) + 1 where n is the number of DAG nodes within the DAG. With DAGs, if you have an odd number of DAG nodes in the same DAG (Cluster), you have an odd number of votes so you don’t have a witness.  If you have an even number of DAGs nodes, you will have a file share witness in case half of your nodes go down, you have a witness who will act as that extra +1 number.

So let’s go through an example.  Let’s say we have 3 servers. This means that we need (number of nodes which is 3 / 2) + 1  which equals 2 as you round down since you can’t have half a server/witness.  This means that at any given time, we need 2 of our nodes to be online which means we can sustain only 1 (either a server or a file share witness) failure in our DAG.  Now let’s say we have 4 servers.  This means that we need (number of nodes which is 4 / 2) + 1 which equals 3.  This means at any given time, we need 3 of our servers/witness to be online which means we can sustain 2 server failures or 1 server failure and 1 witness failure.

Real World Examples

Each of these examples will show DAG Models with a Primary Site and a Failover Site.

2 Node DAG  (One in Primary and One in Failover)

In the following screenshot, we have 3 Servers.  Two are Exchange 2010 Multi-Role Servers; one in the Primary Site and one on the Failover Site.  The Cluster Service is running only on the two Exchange Multi-Role Servers.  More specifically, it would run on the Exchange 2010 Servers that have the Mailbox Server Role. When Exchange 2010 utilizes an even number of Nodes, it utilizes Node Majority with File Share Witness.  If you have dedicated HUB and/or HUB/CAS Servers, you can place the File Share Witness on those Servers.  However, the File Share Witness cannot be placed on the Mailbox Server Role.

So now we have our three Servers; two of them being Exchange.  This means we have three voters.  Two of the Mailbox Servers that are running the cluster service are voters and the File Share Witness is a voter as well.  So the question is, how many voters/servers can I lose?  Well if you read the section on Majority Node Set (which you have to understand), you know the formula is (number of nodes /2) + 1.  This means we have (2 Exchange Servers / 2) = 1 + 1 = 2.  This means that 2 voters must always be online for your Exchange Cluster to remain operational.

But now let’s say one of your Exchange Servers go offline.  Well, you still have at least two voters online.  This means your cluster will be still be operational.  If all users/services were utilizing the Primary Site, then everything continues to remain completely operational.  If you were sending SMTP to the Failover Site or users were for some reason connecting to the Failover Site, they will need to be pointed to the Exchange Server in the Primary Site.

But what happens if you lose a second node? Well, based on the formula above we need to ensure we have 2 voters operational at all times.  At this time, the entire cluster goes offline.  You need to go through steps provided in the site switchover process but in this case, you would be activating the Primary Site and specify a new Alternative File Share Witness Server that exists in the Primary Site so you can active the Exchange 2010 Server in the Primary Site.  The DAG won’t actively use the File Share Witness but you should specify it anyways because part of the Failback process is re-adding the Primary Site Servers back to the DAG once they become operational.

But what happens if you lose two nodes in the Primary Site? Well, based on the formula above we need to ensure we have 2 voters operational at all times.  At this time, the entire cluster goes offline.  You need to go through steps provided in the site switchover process but in this case, you would be activating the Failover Site and specify a new Alternative File Share Witness Server that exists (or will exist) in the Failover Site so you can activate the Exchange 2010 Server in the Primary Site.   The DAG won’t actively use the File Share Witness but you should specify it anyways because part of the Failback process is re-adding the Primary Site Servers back to the DAG once they become operational.

Once the Datacenter Switchover has occurred, you will be in a state that looks as such.  An Alternate File Share Witness is not for redundancy for your 2010 FSW that was in your Primary Site.  It’s used only during a Datacenter Switchover which is a manual process.

Once your Primary Site becomes operational, you will re-add the Primary DAG Server to the existing DAG which will still be using the 2010 Alternate FSW Server in the Failover Site and you will now be switched into a Node Majority with File Share Witness Cluster instead of just Node Majority.  Remember I said with an odd number of DAG Servers, you will be in Majority Node Witness and with an even number, the Cluster will automatically switch itself to Node Majority with File Share Witness?  You will now be in a state that looks as such.

Part of the Failback Process would be to switch back to the old FSW Server in the Primary Site.  Once done, you will be back into your original operational state.

As you can see with how this works, the question that may arise is where to put your FSW?  Well, it should be in the Primary Site with the most users or the site that has the most important users.  With that in mind, I bet another question arises?  Well, why with the most users or the most important users?  Because some environments may want to use the above with an Active/Active Model instead of an Active/Passive.  Some databases may be activated in both sites.  But, with that, if the WAN link goes down, the Exchange 2010 Server in the Failover Site loses quorum since it can’t contact at least 1 other voter.  Again, you must have two voters online.  This also means that each voter must be able to see one other voter.  Because of that, the Exchange 2010 Server will go completely offline.

To survive this, you really must use 2 different DAGs.  One DAG where the FSW is in the First Site and a second DAG where its FSW is in the Second Site.  Users that live in the First Active Site would primarily be using the Exchange 2010 DAG Members in the First Active Site.  Users that live in the Second Active Site would primarily be using the Exchange 2010 DAG Members in the Second Active Site. This way, if anything happens with the WAN link, users in the First Active Site would still be operational as the FSW for their DAG is in the First Active Site and DAG 1 would maintain Qourum.  Users in the Second Active Site would still be operational as the FSW for their DAG is in the Second Active Site and DAG 2 would maintain Quorum.

Note: This would require twice the amount of servers since a DAG Member cannot be a part of more than one DAG.  As shown below, each visual representation below of a 2010 HUB/CAS/MBX is a separate server.

The Multi-DAG Model would look like this.

Elan Shudnow :: Aug.05.2011 :: Exchange, Exchange 2010 :: 227614 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F08%2F05%2Fexchange-2010-site-resilient-dags-and-majority-node-set-clustering-part-1%2FExchange+2010+Site+Resilient+DAGs+and+Majority+Node+Set+Clustering+-+Part+12011-08-05+16%3A47%3A09Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2276

General Information

When you’re first installing Lync Server 2010, there’s some confusion out there as to why you would or wouldn’t choose the option, “Deploy First Standard Edition Server” option.  Every Lync 2010 Server in your deployment will hold a copy of your Lync Server 2010′s topology configuration called the Central Management Store (CMS).  These copies are located in a SQL 2008 Express instance called rtclocal on each Lync Server 2010 Server.  A very good post on the CMS can be read here.  The purpose of this article is not to explain what the CMS is, but how you go about utilizing the setup process of Lync to deploy the CMS if your first pool is a Standard Edition Server or an Enterprise Pool.

To help understand the difference, I wanted to preface the remainder of my post with a couple images that were taken from Jen’s excellent CMS post which I linked to in the above paragraph.

This first image shows how the CMS database is placed in the first Enterprise Edition Pool.  With this setup, we can see we have two Front End Servers (FE1 and FE2) which are collocated within the same Enterprise Pool.  Each of these servers have SQL 2008 Express which contain the rtclocal instance that contains a copy of the Master CS on the BE SQL Server which would be a SQL Standard or SQL Enterprise. A key thing to note here, is that the SQL BE Server has only one instance called rtc.  From a CMS standpoint, this rtc instance contains the master xds database.  The xds database is the cms database.  This rtc instance also holds your other Lync databases: cpsdyn, lis, rgsconfig, rgsdyn, rtc, rtcdyn, rtcab, rtcab1, and rtcdyn.

al

This second image shows how the CMS database is placed in the first Standard Edition Server.  The key difference here, is we can see that on this first Standard Edition Server, we see two instances; rtclocal and rtc.  We can see, that because we do not have a dedicated BE server as we would in an Enterprise Edition Server, we collocate that dedicated rtc instance on the SE Server which will hold the same databases that the rtc instance would on the first Enterprise Edition Pool; the master xds database, cpsdyn, lis, rgsconfig, rgsdyn, rtc, rtcdyn, rtcab, rtcab1, and rtcdyn.  But this SE Server will also have the same rtclocal instance that Enterprise Edition FE Servers would have that would contain a copy of the xds instance.  Because of this, from a CMS standpoint, the first SE Server would contain two instances; one with the master xds and one with the replica xds.  Any subsequent Standard Edition Front End Servers (and any other Lync Server 2010 Server in the environment) would only have the rtclocal database holding a copy of the master xds as there can only be one Pool (Standard Edition Pool or Enterprise Edition Pool) that can hold the master CMS role.

It is possible, however, to move the CMS Master role to a new pool after the fact in case you deployed a Standard Edition Front End first such as a Pilot and then later deploy Enterprise Edition Pools such as when determining the pilot is a success and going full production. A very good blog article that explains this process can be read here.

Let’s take a look at how we accomplish the setup if our first Front End will be a Standard Edition and how it differentiates with an Enterprise Edition Front End.

Standard Edition Setup

Now when running setup.exe for Lync Server 2010, one of the deployment options you can see is “Prepare first Standard Edition Server.”

You will only want to run this option when you are deployment the first Lync Server 2010 Standard Edition Server in your deployment and you don’t already have any Lync Server 2010 Enterprise Edition Front End Servers.

What the Prepare first Standard Edition server does is simple.  It creates the rtc instance if it does not exist already and it creates the xds master database within the rtc instance.  This creates a Service Connection Point (SCP) record in Active Directory that allows any future deployment options to know how to locate the CMS information.  Taken from Jen’s blog article, “The SCP is an object in Active Directory created under the path of the following Distinguish Name (DN), CN=Topology Settings, CN=RTC Service,DC=<domain>, of type msRTCSIP-GlobalTopologySetting. This object contains the msRTCSIP-BackEndServer attribute, which specifies the FQDN of the master and the instance name of the SQL Instance. All tools use the SCP to locate and connect to the CMS master.”

If you ever wondered how the Topology Builder automatically knows how to find and download Topology Information, the Topology Builder queries this SCP record, uses the msRTCSIP-BackEndServer attribute, contacts the FQDN of the master, and downloads the topology information.

Now because the rtc instance has been created with the xds database, when you go to run the actual install, you will see “Install Local Configuration Store” which will install the rtclocal instance which contain a copy of the master xds database.  The regular databases will still be installed in the rtc instance.

Enterprise Edition Setup (Read the Standard Edition section first to fully understand this section)

Now when deploying the first pool in your Lync Server 2010 deployment happens to be an Enterprise Edition Pool, you won’t bother with the “Prepare first Standard Edition server” option. When taking a look at the first Standard Edition Front End, you can see we needed to create the rtc instance first with the master xds.  The same thing happens with the Enterprise Edition but in a different fashion.  Because this is an Enterprise Edition Pool, you will be using a SQL Standard or SQL Enterprise.  During the Topology Builder process, you need to define your SQL Server unlike a Standard Edition Deployment.  When publishing your Enterprise Edition Pool, at that time your rtc instance is being created on your SQL Server as well as the xds database.  Just like with the Standard Edition deployment, the SCP record in AD is getting created.

Now when running the Setup below and choosing “Install Local Configuration Store,” the Setup Process is creating the rtclocal instance (SQL  2008 Express) local to that Enterprise Edition Front End Server and then goes out to the master xds database that is on the SQL Standard or SQL Enterprise Server, and then creates a copy of that xds database on the Enterprise Edition Front End Server.

Elan Shudnow :: Jun.16.2011 :: Lync 2010 :: 221129 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F06%2F16%2Flync-2010-deploy-first-standard-edition-server-option%2FLync+2010+-+Deploy+First+Standard+Edition+Server+Option%3F2011-06-16+14%3A08%3A33Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2211