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:

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.

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.

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.

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.

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.

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.

There’s two ways to migrate to Exchange 2010 UM:

• Full Upgrade
• Partial Upgrade

In a Full Upgrade scenario, you are doing a big bang migration for your Exchange 2007 UM users and moving them all to Exchange 2010 UM at the same time.  At the same time, you are replacing your Exchange 2007 UM Servers within your UM Dial Plan with Exchange 2010 UM Servers.

In a Partial Upgrade, you are going to  have Exchange 2007 UM Servers and Exchange 2010 UM Servers coexist within the same Dial Plan.

It is important to note how the call flows work in a Partial Upgrade Path.  You can see this documented very well here. In order for the Partial Upgrade process to work, the documentation clearly states, “When you install the first Exchange 2010 UM server and add it to an existing Exchange 2007 organization, you must add the Exchange 2010 UM server to an existing UM dial plan that contains Exchange 2007 UM servers. Then you must configure each IP gateway or IP PBX to send all incoming calls to the Exchange 2010 UM servers within the same UM dial plan.”

The key part to note is that you must configure each IP Gateway object that is in the Dial Plan to now send ONLY to Exchange 2010.  The problem with the article, is that it does state this clearly and does show example of call flows, but what isn’t really explained is what exactly is happening on the Back-End.  And that, is what I am here to explain.

The basic jist of it, is that Exchange 2010 will redirect the IP Gateway to Exchange 2007 where necessary.  But let’s say you have a PBX connected to a gateway which is connected to UM.  Exchange 2010 UM will always redirect the gateway for an Exchange 2007 user and the gateway will connect directly to Exchange 2007 UM.  The gateway never has to relay any information back to the PBX in this case so there are no considerations you have to make for the PBX here.  The only consideration you should make is to make sure that the gateway has been certified against Exchange 2010 UM before you decide to do your partial upgrade.  The certified gateway/IP-PBX for Exchange 2007 is here and the certified list for Exchange 2010 is located here.

With that said, the redirects from Exchange 2010 to Exchange 2007 work a couple different ways depending on the circumstances.  Thanks to Chun from Microsoft for providing me with these details that were documented in great detail.

There are two broad categories on how the redirection happens:

• Before UM 2010 accepts the invite, it knows the call is for an UM 2007 user (e.g., diversion exists and UM can tell that the call is for a 2007 user). In this case, we simply use 302 redirect.
• UM 2010 needs to accept the invite before it knows the call is for an UM 2007 user. E.g., someone calls into the subscriber access from a phone that we cannot resolve to a user. UM needs to answer the call first, and wait for the user to punch in the mailbox extension. In this case, UM will send a REFER to the gateway to cause the gateway to send a new INVITE to the same UM 2010 server. But in the REFER header, we stick in a couple of information which shows up in the new INVITE. The UM 2010 server sees this information, realizes it is for a 2007 user, and redirects the call to UM 2007.

Example

Now let’s take a look at a real life migration example from a procedural standpoint.  Let’s start off with not having Exchange 2010 yet.  We have our IP-PBX which is sending data to an IP Gateway which is then sending data to Exchange 2007.

We then build our Exchange 2010 Server, install Exchange 2010 UM Role on it, and we then add it to our Dial Plan which will then consist of both Exchange 2007 and Exchange 2010 UM.  Keep in mind, when using OCS as the IP-PBX, you must be on at least OCS 2007 R2 CU5 and Exchange 2010 SP1 to be able to allow Exchange 2010 UM SP1 and Exchange 2007 to be in the same Dial Plan.  The reason for this is Exchange 2010 SP1 introduces capabilities that allow OCS 2007 R2 CU5+ and/or Lync to be able to do a user lookup, determine if they’re on Exchange 2010 or Exchange 2007 and route to the appropriate Exchange Version (2007 or 2010) regardless if they’re in the same Dial Plan.

As can be seen above, we now have Exchange 2010 and Exchange 2007 in the same Dial Plan.  We have also started routing all traffic to Exchange 2010.  If the call is for an Exchange 2007  User, Exchange 2010 will redirect the IP Gateway to start talking to Exchange 2007 to service those Exchange 2007 users.

The problem is, what if down the road, you decide that you now have a team that you want to be able to view these reports.  The OCS 2007 R2 Monitoring Reports had an option to grant users access to view the reports.  The Lync Server 2010 Monitoring Reports no longer has this option.  The provided  Lync documentation does not provide you guidance other than, “You can also configure the read-only group directly in SQL Server Reporting Services” which really isn’t much of a help.  Typically, your SQL guys can take care of this after the fact.  But, I was a bit curious (I’m not a SQL expert but I know my way around a bit) so I decided to figure this out on my own.

So let’s have a look, shall we?  Go ahead and open up Reporting Services Configuration Manager.

The part we are interested in is the Report Manager URL.  The Web Services URL will show you the URL you specify in the Lync Installation Wizard when deploying your Monitoring Server Reports.

When selecting Report Manager URL, you’ll see the URL on the right side of the screen.

Go a head and click on that URL you see in the Figure above.  You’ll now see the following screen.

Go ahead and click on LyncServerReports.  You’ll now see the following screen.

Go ahead and click on Properties you see in the above Figure.  Just make sure you’re in the context of LyncServerReports.  You’ll now see the following screen.

Click on Security which will provide you with the following screen.

Now, before I add anything here, let’s make sure that I am refused Access when I try to login to the Monitoring Server Reports with a specific account.

So now, let’s get back to SQL Reporting Services.  Go ahead and click on New Role Assignment.  Go ahead and Assign a Group Name and choose Browser. Keep in mind that this group will have be pre-created before SQL Reporting Services will accept the input.  Once done, choose Ok.

You’ll now see the group has successfully been added.

On my client that I previously tried to connect with but got Access Denied, I give it another shot and go to the following URL:

http://SQLServer/ReportServer_REPORTING?%2fLyncServerReports&rs:Command=ListChildren

I get right in!  Success!

I recently encountered the following issue when a remote user were to try to upload a PowerPoint Presentation while internal users had no problems.

Immediately, I thought that this was an issue with the reverse proxy.  For those that don’t know what the role of a reverse proxy server is in Lync Server 2010, the Reverse Proxy handles the following traffic for remote users:

• Enabling external users to download meeting content for your meetings.
• Enabling external users to expand distribution groups.
• Enabling remote users to download files from the Address Book service.
• Accessing the Microsoft Lync Web App client.
• Accessing the Dial-in Conferencing Settings webpage.
• Accessing the Location Information Service.
• Enabling external devices to connect to Device Update web service and obtain updates.

As we can see in red above, the Reverse Proxy is used for meeting content externally.  I did two things to troubleshoot whether it was the client hitting the reverse proxy and having it not function correctly.  The first thing was that I loaded up Network Monitor on my client.  What I saw is, when I would add a new distribution list to my contact list which is a function of the reverse proxy, I properly saw in the trace the client make a request out to the public IP of our Reverse Proxy Server.  Because of this, I knew the Reverse Proxy was functioning just fine, especially since I could also access our Simple URLs (dialin.domain.com and meet.domain.com from the outside).  But when I tried uploading a PowerPoint Presentation in an Online Meeting, I never saw a call go out to the Reverse Proxy.

So I went onto our Reverse Proxy Server which is Microsoft Forefront Threat Management Gateway (TMG).  I wanted to see anything that came into it with my Client IP Address.  I went to the Logs & Reports and modified the filter

Once at the bottom of the dialog, choose Filter By IP and set the Value to your Public IP Address.  You can easily obtain your Public IP on your client machine by going to www.whatismyip.com.  Once done, choose Update.  Your filter will now look as such:

Once ready to start logging, choose the Start Query Option.

When I started the Query, I saw absolutely no traffic for Web Conferencing PowerPoint Presentations at all. This verified the client was really not even getting to the point of trying to communicate with the Reverse Proxy, especially since the Network Monitor logs didn’t even see the request try to go out.

At this point, I was at a bit of a loss and went back to basic troubleshooting more and sometimes, we often overlook the basics. I tried the other Web Conferencing functionality on the client.  What I noticed is, I got the same exact errors even when trying to utilize polling or whiteboarding.  Bingo.  It’s a Web Conferencing Edge problem, not something with the client to the Reverse Proxy.

I looked at our Web Conferencing Edge and noticed two errors (neither of which you will find any information online about them… I guess I am the lucky one):

First Event Log Entry (more common)

Log Name:      Lync Server
Source:        LS Web Conferencing Edge Server
Date:          5/4/2011 5:42:28 PM
Event ID:      41990
Task Category: (1023)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      lyncedge.domain.com
Description:
Failed to verify client cookie

Over the past 44 minutes Lync Server has failed to validate cookie presented by the clients 5 time(s). The last such client which failed validation was “22.33.44.55:50307″.
Cause: This can occur if the Web Conferencing Server and Web Conferencing Edge Server machine time(s) are out of sync. This can also be the result of a client attempting to connect to Web Conferencing Server without having the appropriate permissions.
Resolution:
Check to make sure that the Web Conferencing Server and Web Conferencing Edge Server machines and verify that the connection came from a trustworthy client. This could indicate an attack being by a rogue client.
Event Xml:
<Event xmlns=”http://schemas.microsoft.com/win/2004/08/events/event”>
<System>
<Provider Name=”LS Web Conferencing Edge Server” />
<EventID Qualifiers=”50175″>41990</EventID>
<Level>2</Level>
<Task>1023</Task>
<Keywords>0×80000000000000</Keywords>
<TimeCreated SystemTime=”2011-05-04T22:42:28.000000000Z” />
<EventRecordID>20548</EventRecordID>
<Channel>Lync Server</Channel>
<Computer>lyncedge.domain.com</Computer>
<Security />
</System>
<EventData>
<Data>44</Data>
<Data>5</Data>
<Data>22.33.44.55:50307</Data>
</EventData>
</Event>

Second Event Log Entry

Log Name:      Lync Server
Source:        LS Web Conferencing Edge Server
Date:          5/4/2011 5:11:03 PM
Event ID:      41993
Task Category: (1023)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      lyncedge.domain.com
Description:
Failed to process data received from the client

Over the past 599 minutes Lync Server has disconnected clients 1 time(s) as a result of invalid data being received on client connections. The last such client which was disconnected is “22.33.44.55:46361″.
Cause: Failed to process data received from the client
Resolution:
Check and make sure that the connection came from a trustworthy client.
Event Xml:
<Event xmlns=”http://schemas.microsoft.com/win/2004/08/events/event”>
<System>
<Provider Name=”LS Web Conferencing Edge Server” />
<EventID Qualifiers=”50175″>41993</EventID>
<Level>2</Level>
<Task>1023</Task>
<Keywords>0×80000000000000</Keywords>
<TimeCreated SystemTime=”2011-05-04T22:11:03.000000000Z” />
<EventRecordID>20543</EventRecordID>
<Channel>Lync Server</Channel>
<Computer>lyncedge.domain.com</Computer>
<Security />
</System>
<EventData>
<Data>599</Data>
<Data>1</Data>
<Data>22.33.44.55:46361</Data>
</EventData>
</Event>

The Fix

Simple. I tried restarting the Web Conferencing Edge Service but had the same issue.  I then restarted the Web Conferencing Service on the Front End.  The issue was resolved.  It’s apparently an issue where the Web Conferencing Edge Service had problems talking to the Web Conferencing Service on the Front End for client persistence and the services just needed to be restarted.