Tags » ‘Client Access Server’
September 12th, 2011 by Scott
I wouldn’t be surprised if I saw this topic covered at TechEd next year. I have many clients ask me the following question a lot, “do I need a CAS Array in my organization?” I imagine that there are many people out there wondering the exact same thing. So, do you need a CAS Array for your Exchange 2010 organization?
Well, let’s start out by looking at how Exchange 2010 will work without a CAS array. In the event where you do not have a CAS Array when you create a Database the database will configure the “RpcClientAccessServer” (the RPC Endpoint for Outlook Client Connectivity) based on one of the following:
- If you have both the Client Access server role and the Mailbox server role on the same physical server, the value of RPCClientAccessServer property for a particular Mailbox server will be the same as the Mailbox server.
- If you have the Client Access server role on a separate maching the RPCClientAccessServer property for a particular Mailbox server will be set to a random Client Access server within the Active Directory site.
What this means is that the Mailbox Database that you created will either assign the RPCClientAccessServer property based on one of the two options above. Which brings me to Scenario one.
Scenario one:
Let’s say you have two Exchange Servers deployed within your organization EXCH1 and EXCH2. Each server is running the Mailbox, Hub Transport, and Client Access role in the same Active Directory Site. Now say you deploy one databases on each server Database1 on EXCH1 and Database2 on EXCH2. Each Database will be assigned the RPCClientAccessServer property with the server name the database resides on. i.e. Database1 will have a RPCClientAccessServer set to EXCH1 and Database2 will have a RPCClientAccessServer set to EXCH2.
Next we deploy a DAG within our two nodes and replicate the two databases between the servers. Even with a DAG deployed in the event that EXCH2 goes off line all users in Database2 will lose their connection! This is because their RPCClientAccessServer points to EXCH2 even thought their database is mounted on EXCH1. The RPCClientAccessServer property does not get updated automatically.
End Scenario one
Now let’s take a look at how Exchange 2010 behaves if the CAS Array is already created. When you create a Database the database will configure the “RpcClientAccessServer” (the RPC Endpoint for Outlook Client Connectivity) based on one of the following:
- In the event that you have first created a CAS Array and then second created a mailbox database Exchange will assign the RPCClientAccessServer property with the name of the CAS Array for that Active Directory site.
Which brings me to Scenario two!
Scenario two:
Let’s say you have two Exchange Servers deployed within your organization EXCH1 and EXCH2. Each server is running the Mailbox, Hub Transport, and Client Access role in the same Active Directory Site. There is no hardware load balancer in your organization but you decided that before creating any databases in your organization you would create a CAS Array. (for info on creating a CAS Array see my article: Exchange 2010 Client Access Server Array (CAS Array)
Once the CASArray has been created you go out and create a DNS entry, in this case cas.scottfeltmann.com. For an IP address for this DNS entry you type in the IP Address of EXCH1 and set the time to live to 5 minutes or less (you could do DNS round robin but in the event of an outage 50% of the users will be off line).
Now that we have our CAS Array created we can move forward and create our two new databases, Database1 and Database2. Each Database will reside on their respective servers EXCH1 and EXCH2. Since we have created our CAS Array the RPCClientAccessServer property will be set with the CAS Array name, in this case “cas.scottfeltmann.com”.
As a final step a DAG has been deployed to replicate the mailbox databases between the two servers within our organization. Since our CAS Array is currently pointing to cas.scottfeltmann.com which points to EXCH1 in the event that we lose the server EXCH1 our users will lose their connection. Once this occurs a manual process needs to take place to update the DNS entry cas.scottfeltmann.com to point to EXCH2. Once DNS updates, all users will be back on line and working again! Much better than the scenario one if you ask me.
End Scenario 2.
Honestly to simply the failover process I always suggest a Hardware Load Balancer like Kemp Technologies (http://www.kemptechnologies.com/us/) which will automatically re-establish the connection.
Also keep in mind that if you created a Mailbox database before the creation of a Client Access array or the installed a Client Access server within the Active Directory site, you’ll need to reconfigure the value of the RPCClientAccessServer property. If no Client Access server exists in the Active Directory site when the Mailbox database is created, the value of the RPCClientAccessServer property will be set to the FQDN of the Mailbox server. To configure the value of the RPCClientAccessServer property, use the following command: Set-MailboxDatabase DBName -RPCClientAccessServer cas.scottfeltmann.com (or whatever your CAS Array name is). In some rare instances you may run into a bug where you created the CAS Array after the databases were deployed, and updated the RPCClientAccessServer property on the Database. For more information on that bug see my article Outlook Profile not updating after creating CAS Array.
So, to answer the question, “Do I need a CAS Array?” The answer is Yes! Most certainly! Absolutely!
Edit — I should point out, even if you have a single Exchange 2010 Server in your entire Organization you should use a CAS Array!
Questions? Comments? Please Share!
April 5th, 2011 by Scott
As many of you know I have been working with a lot of Exchange 2010 deployments and leveraging the CASArray feature in Exchange 2010. As a result I have been using the KEMP load balancers for my small to medium size business clients.
Having said that you will recall a few months ago I posted an article about the KEMP Technologies being certified for Exchange 2010 CASArray. I just received a press release stating that KEMP has introduced a server load balancing appliance designed specifically for Exchange 2010.
Here is the press release:
—————————————————————————————————————
KEMP’s LoadMaster Exchange comes pre-configured and ready to deploy for instant redundancy and high availability of critical Exchange 2010 services
Yaphank, N.Y. – April 5, 2011 – KEMP Technologies today announced the availability of its new LoadMaster Exchange (LM-Exchange) server load balancing and application delivery appliance. The newest member of its family of affordable load balancers, the KEMP LoadMaster Exchange is designed to address high-availability and scalability demands of Microsoft Exchange 2010 deployments for businesses up to 250 users.
While all of KEMP’s server load balancing and application delivery controller (ADCs) products currently support and are approved by Microsoft’s Exchange Server 2010 qualification program for hardware and software load balancers, the LM-Exchange is the first product of its kind that was specifically designed and purpose-built for Microsoft’s Exchange 2010. “For the smaller business that may not be familiar with load balancing technology, ease-of-use and speed of deployment was our top priority in the design and development of this product,” said Peter Melerud, vice president of product management at KEMP. “For the vast majority of smaller enterprises, which will consolidate the primary Exchange 2010 server roles onto a pair of servers, the LM-Exchange can be deployed in less than five minutes, providing instant redundancy and high-availability for client access server (CAS) and other critical Exchange 2010 services.”
The LM-Exchange supports up to 13 virtual services and six real (physical) servers. To simplify installation, the LM-Exchange is pre-configured and optimized for the most commonly deployed Exchange 2010 server roles. Moreover, the appliance is designed out-of-the-box to support Outlook Web Access, Outlook Anywhere and ActiveSync. The LM-Exchange will include all the key functionality that the typical Exchange 2010 deployment will require, including distribution of Exchange 2010 traffic load across and up to six servers, CAS server affinity (persistence), SSL offload and application service and server hardware health checking with automatic failover upon detection of outages. The LM-Exchange scales to support up to 250 Exchange 2010 users, with performance capacity of 920Mbps of layer-seven (L7) throughput, SSL offload of up to 200TPS and can support up to 25,000 L7 connections per second.
The LM-Exchange is currently available for shipping and has an MSRP of $1,590 including first-year hardware maintenance and support.
About KEMP Technologies
KEMP Technologies is a leader in affordable server load balancer appliances and application delivery controllers tailored to meet the needs of businesses that rely on the Internet for e-commerce and business-critical applications. KEMP helps companies rapidly grow their business with 24/7 high-availability, better web infrastructure performance, scalability and secure operations – while streamlining IT costs.
Thousands of KEMP LoadMaster products are in use today to improve customer satisfaction by accelerating user access to business-critical web applications. Service providers also rely upon KEMP products to enable fast time-to-market and cost-effective operations for new and existing managed services.
KEMP’s highly affordable LoadMaster products include Layers 4-7 load balancing, content switching, server persistence, SSL offload/acceleration, and application front-end capabilities (caching, compression, intrusion prevention system), plus one full year of product support – delivering industry leading price/performance value.
The company is headquartered in Yaphank, New York. For more information, visit www.KEMPtechnologies.com, or call at +1 631-345-5292.
——————————————————————————————————–
If you don’t have a NLB for Exchange 2010 I would suggest looking into the Kemp Technologies solution. They are affordable and work well. I have a few clients that have purchased them and so far so good!
Questions, comments? Please share!
October 27th, 2010 by Scott
One of the questions I frequently get from my clients is how to remove a Client Access Server from my CASArray. Well, I thought I would write it up since it seems to come up more and more.
If you recall I wrote an article a few months back called Exchange 2010 Client Access Server Array (CAS Array). This article basically explained the process for creating a CASArray in an Active Directory Site for the Exchange Users in that Site. The basic idea is to create a “new-clientaccessarray” and then “set-mailboxdatabase” –RPCClientAccessServer CASARRAY.FQDN.COM.
If you recall in order to get the CASArray to work properly you needed to create a new DNS entry with whatever name you like pointing to a Virtual IP (VIP) address. The Virtual name (DNS Entry) and VIP were then assigned to a Network Load Balancer (NLB). The NLB was then configured by you or an Admin to point to the Client Access Servers you have in the Active Directory Site. So for example, if you have three Client Access Servers in your Site, CAS1, CAS2, and CAS3, each server would belong to the CASArray via the NLB that you or the Admin configured. The NLB would include the actual IP address of the Client Access Server where traffic would be directed based on the configuration of the NLB.
Now, say for example you have three Client Access Servers as I mentioned above, CAS1, CAS2, and CAS3. Each one of these servers would be part of the CASArray due to the configuration of the NLB device from above. If you desire to remove a Client Access Server from the CASArray you will simply just remove the server from the NLB route. So, for example, if I wanted to remove CAS3 from the CASArray I would simply remove it from the NLB configuration, may it be a physical device or Windows Network Load Balancer configuration.
That’s it, nothing special about it! There is no need to uninstall the CAS role from the server, you simply take it out of the NLB rotation.
I believe where a lot of confusion is occurring is that when an Administrator uses the command “Get-ClientAccessArray” they end up seeing something like this:
Name Site Fqdn Members
——– —— ——- ————–
Casarray Sitename Casarray.scottfeltmann.com {CAS1, CAS2, CAS3}
Really, the Members are NOT actually members of the CASArray but rather the Client Access Servers that happen to be in the Active Directory Site where the CASArray is configured. The NLB configuration is what really controls the membership of a CASArray! So, again, to remove a Client Access Server from a CASArray you simply remove it from the NLB configuration!
Hope this helps!
Questions, Comments? Please Share!
June 28th, 2010 by Scott
I came across an interesting situation this morning where I created a CAS Array in Exchange 2010, updated the RPCClientAccessServer property on the existing database, and re-launched outlook. As it turns out there is a Bug in Outlook 2007 (and apparently 2010) where the users profile will not update to the new CAS Array. Instead the profile will remain until the profile is updated or the target is taken off line. To resolve the issue I had to update the users Outlook Profile. Thankfully I only have six users testing Exchange 2010 at this point.
I can’t stress from what was learned this morning the importance of configuring your CASArray prior to migrating to Exchange 2010. Even if you do not plan on using a CASArray I would suggest you create one and point it to the single CAS in your environment. This will this give you the ability to add a NLB CAS Array in the future AND save you a ton of work of having to repair all the existing profiles connected to Exchange 2010 at a later date.
For more info on a CASArray see my previous post Exchange 2010 Client Access Server Array (CAS Array).
I should point out that after some research I did manage to find a blog article pertaining to the issue on Elan Shudnow Blog. Thanks Elan for sharing!
June 14th, 2010 by Scott
During TechEd 2010 in New Orleans I was able to attend a session dealing with the CAS workload Sizing. Microsoft put together a new chart to help with the different workloads that hit a CAS. The chart is based on the amount of workload that a typical CAS will see and the CPU Cost and Network Cost. I have attached a copy of the Chart that MS will be publishing to help with CAS sizing in the future. The chart is based on a 100 messages sent/received per day.
The Chart:
The chart gives a potential impact of using all Outlook using in the form of Outlook Anywhere, Outlook Web Application, Outlook, and ActiveSync. You can see that the chart includes IMAP and POP3 but those protocols are used for reading and not submitting mail.
If you take a look at the chart you will notice that Outlook Anywhere and Outlook Web App are basically the same thus simplifying the sizing used for those roles. ActiveSync is actually an additional cost to Outlook. The logic here is that users will both be using Outlook and ActiveSync at the same time. Rarely do you see a user just using ActiveSync and not use Outlook at any given time during the day. (Actually I’m using Outlook right now and ActiveSync since my phone is automatically syncing)
Another key take away from this session is the use of Windows 2008 R2. It was mentioned that the improvements to Windows 2008 R2’s rpcproxy service allows for the expansion of 15,000 Outlook Anywhere users on an 8-core CAS i.e. 2 sockets with 4 cores each (Recall my previous post?)
Anyway, I felt this chart was very useful and since it hasn’t been published on TechNet yet I thought I would share.
Enjoy!
June 10th, 2010 by Scott
I am currently down in New Orleans attending TechEd 2010 and was able to attend a session by Ross Smith IV. During the presentation Ross brought to our attention a new feature in Exchange 2010 SP1 regarding Outlook behavior is a cross-site (two datacenters) database failover.
As it stands now in the event that a failover would occur in a DAG the outlook client will connect directly to its preferred CAS server which is set at the RPCClientAccessServer property. So for example, say you have two AD sites. Each site contains a CAS Array, CAS1 in Datacenter 1 and CAS2 in Datacenter 2. The preferred CAS Array in this scenario is CAS1 (RPCClientAccessServer). So, what this means is that the outlook client is going to default to CAS1 and then to its local database in Datacenter 1. Now, in the event of a Database failure and the Database fails over to a mailbox server in Datacenter 2 the outlook client will have a direct connect to CAS1 and CAS1 will have a direct connect to the mailbox server in Datacenter 2. In RTM you can only get a redirect to CAS2 by changing the RPCClientAccessServer property on the database.
In Exchange 2010 SP1 you can choose to enable or disable cross-site direct connect. You can also define an activation preference for a database which determines whether to perform a direct connect or a redirect.
What this means is that if you consider our scenario above where we have two datacenters and two CAS Array’s CAS1 and CAS2 we can control the cross-site failover event. In the event where Cross Site Connections are allowed the RPCClientAccessServer remains CAS1 and CAS1 will connect the user to their mailbox server in Datacenter 2. However, say we wish to disable Cross Site Connections, in the event of a failover Autodiscover detects the profile change and updates the client to point to CAS2 (requires restart). CAS2 then will provide the mailbox access to the mailbox server in Datacenter 2! This behavior in SP1 is based on three properties.
1. Home server property in Outlook
2. Preferred database site (RPCClientAccessServer)
3. Active database site
Now, keep in mind that since the Autodiscover service is being used this feature will not work well with Outlook 2003. Actually during one of the session it was strongly encouraged that if you are still using Outlook 2003 you should move off of it prior to moving to Exchange 2010. In the event that you have disabled Cross Site Connections and have outlook 2003 when outlook attempts to connect to CAS1 it will detect the failover via ecWrongServer and redirect to CAS2. However, in the event that CAS1 goes down, Outlook 2003 can’t update if the source CAS goes down.
Don’t ask me how to configure, that part wasn’t convered and I haven’t had a chance to play with SP1 in a lab yet.
Hope you enjoyed this article, I will continue to work on getting more for everyone! Have a great night!
February 9th, 2010 by Scott
One of the new features in Exchange 2010 that many people are not familiar with is the CAS Array. The CAS array is a really neat feature for clients looking for High Availability in their Exchange organization and wants to remove the chance for a single point of failure.
In the old versions of Exchange clients would connect directly to the mailbox server but that is no longer the case in Exchange 2010 (http://www.scottfeltmann.com/index.php/2009/10/26/sizing-exchange-2010-client-access-servers). This leads us to the reason why CAS arrays are so important in the Exchange 2010 environment. In Exchange 2010 clients now connect directly to the CAS. The CAS then will proxy the client to the mailbox server. This means that all outlook client connectivity is now routing through the CAS. When not using the CAS array the outlook client will connect directly to the CAS and remain connected to that CAS. In the event of an outage the Outlook client will lose connectivity to the Exchange Mailbox Server and will not be able to fail over to another CAS in the Active Directory Site since it has already established a connection to a CAS which is now down. How does the Outlook client find the CAS? When a CAS is deployed in Active Directory it will create a service connection point (SCP). This SCP then tells clients the clients via autodiscover how to find a CAS. If an organization has multiple CAS then there are multiple SCP created in AD. This process holds true in both Exchange 2007 and Exchange 2010. The difference is Exchange 2010 has the ability to create Client Access Array’s.
So, you’re asking yourself, ok, what is a Client Access Array? Well, I’m glad you asked! In Exchange 2010 Microsoft introduced a new concept for High Availability for the Client Access Servers called a CAS Array. What organizations are now capable of doing is configuring a set of Client Access Servers to act as one by using Network Load Balancing (NLB), either Windows or a Hardware Load Balancer will do. When using NLB admins create a DNS record that points to a Virtual IP address (VIP). Behind this VIP will be the Client Access Servers. You may have one or twenty. Keep in mind though, if using one, when that server goes down, users lose connectivity. (I’m assuming that you know how to NLB the Client Access Servers, unfortunately I don’t have anything written on setting up NLB but there are some good articles out there.) So, if you have three CAS in your environment you are capable of creating a new array which will include all three of these servers. The array will point to the NLB hostname which will then route the traffic to one of the CAS behind the NLB URL. In the event that a CAS should go offline, and since the client is connecting directly to the NLB URL and IP the client will be redirected to a functioning CAS and be able to maintain their connection!
Now that we have an idea of what a Client Access Array is the next logical step is creating the array! In order to create a new Client Access Array we will use the new command of “New-ClientAccessArray”. This command will create an object that represents a load balanced array of CAS within a single Active Directory Site. Keep in mind, that each array is specific to the AD site. This means if you have multiple sites with Client Access Servers you can create arrays specific to that site.
The following example is the command for creating a new array, this command will create a server array named cas.scottfeltmann.com:
New-ClientAccessArray –FQDN cas.scottfeltmann.com –Name “cas.scottfeltmann.com” –Site “HQ”
The Fqdn parameter specifies the fully qualified domain name (FQDN) of the Client Access server array. (Required)
The Name parameter specifies the name of the Client Access server array.
The Site parameter specifies the Active Directory site to which the Client Access server array belongs. (Required)
In the event that exchange databases already existed prior to the creation of the CAS array you will need to configure the databases to point to the new array. To do this you can use the following command:
Set-MailboxDatabase Databasename –RpcClientAccessServer “cas.scottfeltmann.com”
Otherwise, when a new database is created it will automagically detect the Client Access array and point users to the load balanced URL.
In close if you’re looking for some HA you will want to use the Client Access Array to provide the highest level of redundancy for your Outlook client connection. Keep in mind you will still need another form of HA for OWA and ActiveSync. ISA 2006 presents a group solution for this process as well since ISA can direct traffic to multiple Exchange Client Access Servers. For more information on NLB Exchange 2010 CAS see my link here: (http://www.scottfeltmann.com/index.php/2009/10/21/network-load-balancing-recommended-for-exchange-2010-cas-public-facing-internet-facing-and-internal/)
Edit:
I would also like to point out that if you would like to remove a CAS from a CAS Array you will need to remove that Client Access Server from the NLB array. This can be done either through WNLB if that is what you are using or via your NLB appliance. Simply remove the desired server from the NLB and that server will no longer be included in the CAS Array.
November 16th, 2009 by Scott
As I mentioned earlier last week I had the privilege of going to a MS Exchange 2010 Partner Ignite training course. I found the course to be quite interesting give the audience was mostly Exchange architects from around the country. With this type of Audience there were a number of interesting conversations that occurred during the session and the following was one that was quite interesting.
During the class we were talking about the Client Access Server and how Outlook clients will now connect to a CAS rather than the mailbox server. The question came up, “What happens if a user who normally resides in the New York office is visiting the Los Angeles office?”
This really sparked a great conversation because we were not sure. We determined first the Outlook client machine will log on to a DC in LA (assuming the domain topology is simple) due to the configuration of Active Directory Sites and Services. That domain controller will then inform the computer what site the computer is in. Once the computer is alerted of its site the computer will then connect to a CAS server in that AD site.
Now, the question is, what’s next? The conversation went about a few ways. Will the user remain off line? Will the user connect to their CAS server back in NY rather than the LA CAS server? Why won’t outlook connect directly to the mailbox server?
After doing some digging I believe I found the answer to this question and great conversation back in class. When a user connects to a CAS in a different Site the CAS will perform an AD lookup. This AD lookup will inform the CAS where the users mailbox resides. If the users mailbox resides in the same site as the CAS then do nothing, the connection is established. However, if the mailbox resides in another mailbox server in a different site the CAS will then “redirect” (yes, redirect) the user to the proper CAS server which will then connect the user to their mailbox.
So, what this means is that when the user visiting LA launches outlook, outlook will do a query and locate the CAS in the LA office. That CAS will look up the user in AD and redirect that users request to a CAS in NY.
Here is how MS explains it:
If the user’s mailbox is in the same Active Directory site as the Client Access server, the user is connected directly to their mailbox. If the user’s mailbox is in a different Active Directory site than the Client Access server that received the initial connection, the connection is redirected to a Client Access server in the remote Active Directory site.
I pulled that from this link:
http://technet.microsoft.com/en-us/library/aa998561(EXCHG.140).aspx
October 27th, 2009 by Scott
I was in the process of installing Exchange 2010 today on a W2K8 box when I came across the error:
The start mode for the Net. TCP Port Sharing service must be set to Automatic before Setup can continue
As it turns out the Net. TCP Port Sharing Service is set to a manual start up
The best way to resolve this is to set the Startup type as Automatic. You can do this in two ways, one by opening the properties of the service and selecting Automatic or by opening up PowerShell (Which you should have installed prior to deploying Exchange) and typing the command Set-Service NetTcpPortSharing –StartupType Automatic. Walla! The service is now configured correctly and you may continue with the Exchange 2010 install.
*Note: This was deploying Exchange 2010 RC1, this may change with the RTM release.
October 26th, 2009 by Scott
I was reading through technet today to review some of the new features of Exchange 2010 and came across an interesting little note about Sizing for Client Access Servers. In Exchange 2007 it was recommended to size a server of 1GB per core on the Client Access Server. Well, reading here I noticed that it states for a large organization that you should consider doing 2GB per core with a Max of 8GBs. A typical installation is recommended to have 4GB of RAM. However, based on your deployment you may need to add additional servers to your environment depending on just how large. MS is also recommending 1:4 Core ratio for CAS to Mailbox. That is for every four cores on a MB server you should have 1 core for your CAS. For example, if you deploy eight Mailbox servers in an Active Directory site, and each Mailbox server contains four processor cores (for a total of 32 Mailbox server processor cores), you should deploy at least eight Client Access server processor cores. These could be deployed as two Client Access servers with four processor cores each, or four Client Access servers, with two processor cores each.
Another interesting aspect is that Clients will now connect to the Client Access Servers for all access, this includes Outlook 2007/2010 as well as Outlook Web App. This works rather slick when using DAGs and moving a users mailbox. Since the user is connected to the CAS they will not see an outage, but rather the CAS will point them to the new mailbox server on the backend. Having considered that all clients will connect to the CAS it may be recommended for additional memory on the server itself, if you’ have a large environment or perhaps you happen to have a CAS and HUB installed on one box.
Time will tell as Exchange 2010 gets out in the world. Much of the information is based on RC1 and Beta so who knows, it will probably change. I do recall reading an article some time ago that a CAS should have no less then 16GBs or RAM.
MS does have a good table for helping on sizing an Exchange 2010 Client Access Server. To be honest given the fact that Exchange 2010 is supported for virtualization how hard will it be to adjust settings?
Check out Recommended Performance Counters, it’s at the bottom of the page.
|
|