Exchange and Related Technologies
TwitterFacebookGoogle

ExchangeBytes

TwitterFacebookGoogle

Tag Archives: Kemp Technologies

Exchange 2010 SSL Offload

Posted on by Posted in Exchange Leave a comment

The use of Network Load balancers (NLB) for Exchange has increased significantly over the last few years. NLB devices do a fantastic job of balancing load and providing additional failover capabilities for you Exchange Client Access Severs. Another less published benefit of a NLB device is to further increase performance on Exchange by offloading SSL traffic at the NLB device. In large environments this offers a significant performance benefit by allowing the exchange servers to handle only http-based traffic and removing all of the SSL handling.

With Exchange 2010 SP1, Microsoft has simplified the configuration task required to allow Exchange to run straight HTTP for service such as OWA and Outlook Anywhere. The following command below will properly configure Exchange 2010 SP1. Configuring your NLB device to perform SSL offload requires unique configuration per manufacture. I use Kemp Technologies frequently and have included the link the their documentation.

** Exchange Management Shell must be run as an administrator

Set-OutlookAnywhere –Identity "$($env:COMPUTERNAME)\RPC (Default Web Site)" -SSLOffloading $true
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\MSExchange OWA' -Name SSLOffloaded -Value 1 -PropertyType DWORD
Import-Module webadministration
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/OWA"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/ECP"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/OAB"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/EWS"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/Microsoft-Server-ActiveSync"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/Autodiscover"
iisreset

** RTM Version ONLY configuration Changes
If you are running the RTM version of Exchange 2010 in addition to the changes above you will also need to modify a few files. This will have a negative outcome if the following files are modified on a SP1 version of Exchange. Verify version before continuing

Open the web.config file located in the Installation directory of Exchange under ClientAccess\Exchweb\ews with your favorite text editor.
Replace all instances of httpsTransport with httpTransport
repeat the process for the web.config file located in ClientAccess\Autodiscover directory

Exchange 2010 Load Balancing Sizing Tool

Posted on by Posted in Exchange, Technology Leave a comment

When doing a design for Exchange 2010 it is takes a lot of effort to look at all aspects of a system before choosing a product. Choosing the right size load balancer for exchange entails looking at the systems as a whole and how it will be used. A few of the things I look at before making a decision are
1. Client Count
2. Protocols used
3. Client connection speeds
4. Encryption Used
5. Device type
6. Message size
These numbers will tell a person a lot about Exchange and how it is being used so that one can make an educated decision about the size and capabilities of a load balancer. Unfortunately time constraints or a number of other factors do not always allow one the time to analyze and Exchange environment. In other cases a general idea is need for general discussion or budgetary estimates are needed prior to a deep analysis is done. Luckily Kemp Technologies has come up with a handy tool that can be used to get a broad look at what products they offer and a general idea of how to size them, given certain parameters. Take a look at the tool and give it a whirl.
http://www.kemptechnologies.com/fileadmin/templates/sizingDoc/lme_calc_2k/lme_calc_2k.htm

Exchange 2010 Hardware Load Balancing Client Access Services (True High Availability)

Posted on by Posted in Exchange Leave a comment

d Balancing Exchange 2010 Client Access Roles has never been easier with today technologies. When you load balance Exchange by creating 1 big rule for all ports or even a rule for each port sometimes it is not always the best course of action. With a few simple changes and a lot of IP address an Exchange administrator can build a greater degree of availability into ones environment.

Most all Exchange admins know that more and more Exchange services are moving to web driven services. Services like Outlook Web Access, Exchange Web Services, and ActiveSync all are just a few examples. Like most web services these application rely on either port 443 or port 80. Most load balancers will tell you when a port is up or down and if it is down will remove it from the pool so that users do not get random failures for port 80. Again the scope of you reporting on these protocols is that they are up or down and not which one of the services using the protocol is up or down. Having a single rule for each of these protocols limits the ability of an administrator to know what each services is doing and if it is responding properly. Take the following example.

Environment:
You have 5 servers in a load balanced cluster. You have a hardware load balancer handling all traffic for port 443 and port 80. A rule has been created for each protocol and each of the servers has been configured as the “Real Server” for the above rule. You create an A record in DNS and point it to your load balanced IP address for your CAS Servers. You then configure each of your exchange services to use the A record for web service using the name webmail.domain.com.

Problem: ActiveSync is not functioning for some Users
Users in your environment are reporting that they are randomly unable to receive email on their mobile device. There appears to be no reason why the device works one minute and not the next. In trouble shooting you find that the ActiveSync Service on server 2 is not responding properly to request. Since you have created one rule for port 443 you were never made aware of the situation because port 443 was responding but the service was not.

Solution: Check Port/Check URL
The ability of Load balancers to use both a check port and check parameter on that port will allow you to not only create a rule that checks to ensure that the port is alive but that the requested url is also function properly. To achieve this configuration 1 must create a unique IP address and port combination for each protocol selected. For example, an administrator would create a Virtual IP address (VIP) for each Exchange related web service and assign each web service a rule in the load balancer with port 443 and the proper check url parameter for each web service. Each respective VIP would then have an associated DNS A record for the required service IE (owa.domain.com, oab.domain.com, ActiveSync.domain.com, and EWS.domain.com). Now when a particular services is experiencing a problem it is remove from the pool of available servers automatically for non-response to the check url and users don’t receive random failures

Exchange 2010 & Load Balancers

Posted on by Posted in Exchange Leave a comment

 

Now that Microsoft has moved the client Endpoint from the mailbox server to
the Client Access Server (CAS) role the importance of having a highly available
CAS is even more important. Nothing is more frustrating that having an online
database that nobody can access due to a down CAS. In recent post by Microsoft
at TechEd Europe Microsoft is now recommending Hardware
Network Load Balancers (NLB) or Virtual NLB type devices for some very good
reasons. A primary reason for me and my customer for using Hardware based
load balancers is the ability to run multi role boxes providing Database
availability services and function as a member of a Client Access Array. With
the Microsoft Free NLB product it is not possible to have both the Network Load
Balancing services and required cluster components installed on the same server.
This leaves you with two options (1) split the roles in install more servers (2)
install and configure a hardware load balancer. Having used both the Microsoft
and Appliance based load balancers, I can say without a doubt the Appliance
based NLB devices are far superior in the form of performance and granularity of
control. Even the cost of the devices can be justified over building additional
servers. Personally, I have come to love Kemp Technologies VLM  This product is fantastic!
It is simple easy to setup and performs extremely well. The Kemp Team has an
excellent support staff and provide you with great documentation to get you going right
away.

 

Load Balancers are great devices and provide a high level redundancy into
your Exchange Environment. However, Load Balancers do provide a level of
complexity that must be taken into consideration when working with
3rd party applications. For Example, Exchange Backups programs
usually have a client install piece that talks with some sort of media/master
backup server. These agents are usually network based and have a higher order
TCP port association 1024 and above. When installing network load balancer to
work with Exchange you configure a Virtual IP (VIP) and associate TCP ports to
this VIP along with the real servers that services them. One should note in
order to get these types of client network based 3rd party
applications working with a network load balancer the applications ports must be
identified and added to the load balancer. It should also be noted that these
applications may have multiple ports that need to be configured as a single
entity with a longer affinity defined. You would not want network communications
in the middle of a backup to switch halfway through. Even with these required
extra steps, NLB devices are worth every penny.

 

if you missed the links in the article here they are again

 

http://www.msteched.com/2010/Europe/UNC311

 

http://www.kemptechnologies.com/us/

 

http://www.kemptechnologies.com/fileadmin/content/downloads/documentation/5.1/KEMP_MS__Exchange_2010_Deployment_Guide_5_1_0924.pdf

Achieving High Availability with SMTP Smart Hosts and

Posted on by Posted in Exchange Leave a comment

Exchange 2010 has built in features that allow for the timely delivery of
email even in the event of an Exchange server failure.  However, Exchange does
not reroute messages automatically when a network connectivity issue is
preventing communication with an SMTP smart host.

 

Problem:

 

When an Exchange client sends a message to external recipient the exchange
server determines the best route for the messages and sends the message on its.
This message will find its way to a send connector that is setup for either
smart host or DNS based delivery. If a smart host is configured exchange routes
the message to a queue waiting for smart host connectivity.  If the smart host
is available, the message is delivered, and the smart host sends the message to
the next hop.  The problem becomes if the smart host is unavailable the message
will sit in queue until the max retries are hit.  If the message is not
delivered during this period it will NDR the message back to the original
sender.

 

Solution:

 

Use a Hardware or Virtual Load Balancer to route SMTP traffic based on
availability.  Load Balancers are becoming a very popular item with Exchange
2010 especially in large environments where High Availability (HA) is a must.
Here is a sample configuration to illustrate this HA solution.

 

So given the above solution we are dealing with 2 sites, both with inbound
and outbound direct SMTP.  In our case we would create 4 Virtual IPs (VIP) 2 in
New York and 2 in Detroit.  In New York we would create a VIP that would allow
the edge DMZ smart hosts to talk to talk to the exchange servers via a load
balanced IP.  Because Load balancers have the capability of checking service
availability, if one of our exchange servers goes down in New York the down
server is removed from the pool and all SMTP traffic is directed to the
surviving exchange servers.  Now because we only have a single Edge SMTP device
in New York, we will create another VIP and have one member of pool be in New
York and the other member be in Detroit.  With this configuration we have HA for
our SMTP edge devices.  To control traffic so that we are not sending external
email from New York to Detroit needlessly, we can associate a cost on the pool
members.  For Example, the SMTP device in New York we will have a cost of 1 and
the device in Detroit will have a cost of 100.  The Load Balancer will then only
use the lower cost device unless it becomes unavailable at which point it will
direct all outbound traffic to Detroit.  Now when we can create our SMTP send
connectors in Exchange and specify the VIP we created for outbound SMTP as the
smart host destination.  Finally, we would duplicate this configuration in
Detroit changing the cost of the devices to ensure the local devices always have
a lower cost.  Exchange will now route all messages to the VIP providing us a
higher degree of redundancy without manual intervention.