RSS Subscription 168 Posts and 2,769 Comments

Archive for September, 2010

Lync 2010 Media Bypass with and without Voice Resilience

General Overview

Media Bypass is an excellent new feature in Lync 2010, the successor to Office Communications Server (OCS) 2007 R2.  Currently, when an OCS Endpoint such as Communicator or Tanjay utilize Enterprise Voice, they must utilize RTAudio which an OCS Mediation Server must then transcode to G.711 which is the codec utilized on the Public Switched Telephone Network (PSTN).  This obviously adds an extra hop in your call increasing the chance for added latency and needless transcoding which can cause reduced call quality. It can even help reduce WAN traffic as a remote branch user can interact with their telephony equipment directly without having to traverse their WAN to communicate with the Mediation Server.
The big thing to keep in mind here, is that there are several things required to support Media Bypass.  These include:

  • Supported Telephony Equipment (Voice Gateway, IP-PBX, Session Border Gateway at the Internet Telephony Service Provider (ITSP) for SIP Trunking
  • Mediation Server Peer must be able to handle communication directly from clients.  Many ITSP’s support communication with its direct peer only (Mediaion Server).  Contact ITSP for more information.
  • Clients must be able to route to the Telephony equipment it will be doing G.711 with.

Many of you will ask, “Well, if all my telephony equipment supports Media Bypass, can I just get rid of all my Mediation Servers?”  The answer to this, is… NO!  In OCS 2007 R1 and OCS 2007 R2, both the signaling and media flow went through a Mediation Server.  Now, the signaling still goes through the Mediation Server but the media will not when using Media Relay in the given location that has Media Relay enabled. So again, the signaling will still appear from the Mediation Server.

OCS 2007 R2 Topology

So in this case, let’s say you have one branch office and one main datacenter.  Both the main datacenter and the branch office have users in them. Let’s take a look at what a possible architecture would look like in OCS 2007 R2.

In OCS 2007 R2, let’s say we had HA requirements.  We’ve deployed the following:

  • 2 Front End Servers
  • 2 Mediation Servers (cannot put them on the Front End Servers)
  • 2 Voice Gateways since Mediation Servers and Voice Gateways have a 1:1 relationship

Now in the above architecture, we see the users have to contact the mediation server(s) directly.  As stated earlier, this is because both Media and Signaling must flow through Mediation Servers.  Clients will communicate using Secure Real Time Protocol (SRTP) utilizing the RTAudio codec to the Mediation Server.  The Mediation Server will then transcode that to G.711 and then send G.711 to the Voice Gateways. For the client in the branch site, they must traverse the WAN to utilize the Mediation Servers in the Primary Site.  This is a big CON as you’re traversing the WAN making you prone to latency issues, quality issues, and network issues.

Lync Topology Improvements

Now let’s take the same topology and redo it with Lync topology improvements. Let’s take a look at both a voice non-resilient architecture and voice resilient architecture both utilizing Media Bypass.

Non-Resilient Voice Architecture using Media Bypass

The non-resilient voice architecture by itself looks much simpler.  The following are benefits of this architecture:

  • Mediation Servers co-located on Front End Servers meaning less software/hardware procurement costs.  Keep in mind, having the Mediation Servers on the Front End is optional and in some cases, you may want dedicated Mediation Servers.  More on this in a future article for which I will provide a link here.
  • Primary Site clients talking to voice gateways using G.711 meaning less voice latency and enhanced call quality due to the lack of need for transcoding from RTAudio to G.711
  • Branch Site clients talking to a local voice gateway using G.711 meaning less voice latency, enhanced call quality, no need to traverse WAN, less chance for network failures in the WAN, and enhanced call quality due to the lack of need for transcoding from RTAudio to G.711.  Again, don’t forget, signaling still occurs through the Mediation Server in the Primary Site.  There is no Voice Resilience in this architecture and if the WAN link goes offline, the signaling is dropped and the call is disconnected.

This is most definitely a much better architecture than anything OCS 2007 R2 provides.

Voice Resilient Architecture using Media Bypass

As Lync is becoming a full fledged PBX (subjective statement, I know), Microsoft most definitely needed to provide Voice Resiliency.  Lync does indeed provide Voice Resiliency using any of the following:

  • Survivable Branch Appliance (SBA) – Host between 25 and 1000 users at your branch site, and if the return on investment does not support a full deployment or where local administrative support is unavailable
  • Survivable Branch Server (SBS) – Host between 1000 and 5000 users at your branch site, lack a resilient WAN connection, and have trained Lync Server admins available
  • Full Fledged Deployment – If you have more than 5,000 users.

In the following Visio, we will be using an SBA.

We get the same benefits as the non-resilient voice architecture.  But in addition to that, we now have registrar pools for each location.  For a user located in the Primary Site, their Primary Registrar Pool will be the Registrar Pool belonging to the Primary Site. This user will not have a backup registrar configured as an SBA/SBS cannot act as a Backup Registrar (known as Branch Site Resilience) whereas a Front End Standard Edition Server or Enterprise Edition Pool can act as a Backup Registrar (known as Central Site Resilience which I talk more about here).  For a Branch Site User, their Primary Registrar Pool will located in the Branch Site and their Secondary Registar Pool will be located in the Primary Site.  Keep in mind, these Registrar Pools are voice only.  A Branch Site user will still utilize the Lync Architecture (Front Ends, Directors, Etc.) located in the Primary Site for things like Instant Messaging, Web/Video Conferencing, presence, call forwarding settings, etc.

This SBA appliance contains a Mediation Server, a Registar, and a Voice Gateway.  This will allow you to do your signaling, media, and PSTN connectivity all from the Branch Site. Should this SBA fail or something happen to internet connectivity, the client can begin using the Registrar Pool on the Primary Site.  The user knows about this site through information provided in in-band provisioning from their SIP connection to their Front End Servers.

The capabilities you do or don’t have will depend on the equipment you are using.  For example, this resilient voice architecture will allow for outbound call connectivity.  But it will be up to the carriers to support inbound call failover.  Another example, is unless you have a full scale deployment in the Branch Site, other features will be unavailable such as:

  • IM, Web and A/V conferencing
  • Presence and DND-based routing
  • Updating call forwarding settings
  • Response Group Service and Call Park
  • Provisioning new phones and clients
Share

Exchange 2010 Site Resilience, Multiple DAG IPs, and Cluster Resources

Exchange 2010 allows us to have Database Availability Group (DAG) members in several AD Sites.  For every subnet a DAG member’s MAPI NIC is in, we must obtain a DAG IP.  This DAG IP is a separate IP than is located on the MAPI NICs themselves. We take this DAG IP to the DAG using the Set-DatabaseAvailabilityGroup command.

Multiple DAG IPs

Let’s take a look at an example of how the architecture may look.

Taking a look at the above Visio diagram, we have two sites, Primary Site and DR Site, with one node in each.  The MAPI NIC in the Primary Site has an IP Address of 172.17.24.200.  That means that we’ll need to have a DAG IP that lives in this same subnet.  We choose a DAG IP of 172.17.24.120.  The MAPI NIC in the DR Site has an IP Address of 172.16.24.200. That means that we’ll need to have a DAG IP that lives in this same subnet.  We choose a DAG  IP of 172.16.24.120.

In order to add these MAPI IP Addresses, we’ll need to run the following the command.

Note: IPs on Replication NIC’s subnet do not get added to the Database AvailabilityGroupIPAddresses. Only MAPI NIC Subnets get added.

Keep in mind, when adding additional IPs in the future, it is important that you include all existing DAG IPs.  The Set-DatabaseAvailabilityGroup -DatabaseAvailabilityGroupIPAddresses property is not additive.

To verify the DAG IPs were added successfully, let’s check out our DAG Properties.

In Exchange 2010 SP1, we have the ability to add our DAG IPs via the GUI. If we go to the DAG Properties, we now see we can manage our Witness Server and Alternate Witness Server.

This allows us to do our IP Address configuration right from the GUI instead of needing to use Set-DatabaseAvailabilityGroup  with the DatabaseAvailabilityGroupIPAddresses property and needing to worry about all previous IP Addresses being included since the property isn’t additive.

Cluster Resources

So, let’s take a look at what really happens to the cluster resources and what determines which DAG IP is active.  Let’s open the Failover Cluster Manager.  Start > Administrative Tools > Failover Cluster Manager.

After selecting our DAG, let’s take a look at the cluster resources.  We can see from here that we have two Network IP Resources.

But let’s take even a deeper look.

Select the DAG from within the Cluster Core Resources > Right-Click > Choose Properties.

Now let’s take a look at the Dependencies Tab.

As we can see, the two DAG IPs are set up with an OR dependency which means that the cluster can activate either DAG IP at any given time.  As we saw earlier, the 172.16.24.120 IP is the existing DAG IP that is online which means the DRSiteNode’s DAG IP is currently the online Network IP resource.

Let’s run a cluster command so we can failover the default “Cluster Group” from one cluster node to another.

We now see the PrimarySiteNode is the node that has the “Cluster Group.”  Let’s go ahead and take a look at the Cluster Resources again and see which Network IP Resource is online.

Looks like the PrimarySiteNode’s DAG IP is now Online instead of the DRSiteNode’s DAG IP.  This means that the Network IP Resource that is online depends on which DAG Node has the “Cluster Group.”  If you recall from my previous articles, the DAG Node that has the “Cluster Group” is the DAG Node that acts as the Primary Active Manager.  The Primary Active Manager is the DAG Node responsible for choosing what databases get activated in a failover.  For more information on Active Manager, click here.

Share

Exchange 2007/2010 Connection Filtering and Transport Configuration

Connection Filtering Basics (Blocking Connection to the Server)

Many of you know what Connection Filtering is in Exchange. It allows you to control what IPs are allowed and what IPs are blocked.   Taking a look at the following image, we can see exactly what parts of Anti-Spam utilize the connection filtering agent.

In the following image, we can see in what order the anti-spam agents run.

If you utilize the IP Block List, if something is blocked, the connection dies there.  Let’s take a look at the IP Block in action and how the connecting server’s connection is terminated.  For starts, let’s take a look at the connecting machine’s IP.

Let’s make a telnet to the server on port 25.

We see the connection works just fine.  Now, let’s go add the client IP to the IP Block List. To do this, Select IP BlockListRight-Click > Select Properties > Click Add > Enter Client IP Address.

Now let’s try Telneting to the Server over port 25 again.

As we can see, we cannot communicate via port 25 to the SMTP Server anymore due to the connecting IP being on the IP Block List.

Connection Filtering and Non-Exchange SMTP Filtering Appliances/Servers

One of the big things here, is that Connection Filtering happens based on the last untrusted IP Address.  One of the biggest things that are overlooked when using the Exchange or Forefront Connection Filtering Agent is that it is very important for you to enter the trusted SMTP IP Addresses in your organization.

This will need to be done via your Hub Transport Server.  To modify the trusted SMTP IP Addresses in your organization, go to Organization Configuration > Hub Transport > Global Settings > Message Delivery.

It is very important when using Connection Filtering to enter ALL trusted IP Addresses that handle SMTP in the organization.  This includes any type of SMTP Appliance/Server that is sending traffic to Exchange.  This includes Ironport, Sendmail, Barracuda, etc…  The reason why is, the way Connection Filtering works, is that it looks at the sending server’s IP Address and does the lookup on that.  But, let’s say it’s the Edge Transport Server and it’s receiving mail from an Ironport.

Do you really want the Connection Filtering lookup to lookup the Ironport IP?  Of course not, Ironport is an internal server.  Connection filtering ignores any IPs listed in the above Message Delivery list.  This means, if an Exchange Edge server receives mail from an Ironport, if the Ironport IP is on that list, the Exchange Edge will then do a Connection Filteirng lookup on the last untrusted IP which would be the server that sent the mail to the Ironport (that is if the server that sent mail to Ironport is not also another internal device that is on the above list.

So, make sure you add all trusted IPs (Exchange and non-Exchange that are handling SMTP) internal to your organization to make sure Connection Filtering is working as it should be.

Share