Log in


Tags » ‘Client Access Server’

Outlook Profile not updating after creating CAS Array

Categories: Exchange Server Microsoft Related
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!

Tags:
8 Comments »

Exchange 2010 Client Access Server Workload Sizing

Categories: Exchange Server Microsoft Related TechEd
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:
CAS Workload Sizing

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!

Tags:
No Comments »

New feature in Exchange 2010 Service Pack 1 regarding cross-site database failover

Categories: Exchange Server Microsoft Related
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!

Tags:
No Comments »

Exchange 2010 Client Access Server Array (CAS Array)

Categories: Microsoft Related
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. 

Tags:
14 Comments »

Client Access Server Outlook Redirection – Scenario

Categories: Exchange Server Microsoft Related
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

Tags:
No Comments »

Error installing Client Access Server role in Exchange 2010

Categories: Microsoft Related
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.

Tags:
1 Comment »

Sizing Exchange 2010 Client Access Servers

Categories: Microsoft Related
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.

Tags:
No Comments »

Autodiscover for ActiveSync!

Categories: Microsoft Related
October 25th, 2009 by Scott

Microsoft has introduced a new feature in Exchange 2010, autodiscover for mobile devices.  The idea here is that a user will enter their email address and their password.  The mobile will then query a DNS server looking for autodiscover.domain.com and grab an xml file from the web server.  The xml file will then configure the device for the user!  This communication is over SSL so it is secure.  Talk about making the deployment of mobiles even easier!  Of course the mobile device needs to be able to support audodiscover.

Tags:
No Comments »

Client Access Servers in the DMZ

Categories: Microsoft Related
October 21st, 2009 by Scott

I came across an interesting article over at the Exchange Team blog, http://msexchangeteam.com/archive/2009/10/21/452929.aspx.  Basically explaining why not to place a CAS in the DMZ. 

I have to agree, I have come across this request a number of times in the past while at client sites stating that they would like to place a CAS in the DMZ and I have always recommended (even when the subject doesn’t come up) to place an ISA server in the DMZ to act as a reverse proxy.  ISA 2006 really gives you added benefit protecting your servers from a number of different attacks.  By allowing users to authenticate at the ISA level in the DMZ your remove the opportunity for a malicious user to attack your servers.  There is also the aspect that you can use ISA to load balance and perform link translation, that’s where your internal link is different than your external link. 

The other added benefit?  You don’t have to open your internal firewall to all the required ports Exchange will use.  This would be termed swiss cheese. 

So, if you’re thinking about placing a Client Access Server in the DMZ think twice, you really shouldn’t.

Thanks to the MS Exchange team for posting a reminder out there!

Tags:
No Comments »

Exchange 2010 Client Access Server Proxying…

Categories: Microsoft Related
October 20th, 2009 by Scott

I came across an interesting note on the Exchange 2010 ActiveSync and Exchange 2003

Users who have mailboxes on an Exchange 2003 server who try to use Exchange ActiveSync through an Exchange 2010 Client Access server will receive an error and be unable to synchronize unless Integrated Windows authentication is enabled on the Microsoft-Server-ActiveSync virtual directory on the Exchange 2003 server. This enables the Exchange 2010 Client Access server and the Exchange 2003 back-end server to communicate using Kerberos authentication.

 Proxying isn’t supported between virtual directories that use Basic authentication. For client communications to be proxied between virtual directories on different servers, the virtual directories must use Integrated Windows authentication. 

 http://technet.microsoft.com/en-us/library/bb310763(EXCHG.140).aspx

Tags:
No Comments »