Client Access Server Role

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Hi

Just a quick one and im sure theres a very basic answer to this. I am currently watching CBT Nugget videos on Exchange 2010 (70-662) and in one of the very first videos the guy states that it is important to distribute a "client access server" to each one of your sites.

I was just wondering what the disadvantages of just having all your Exchange server roles hosted at your central site were rather than distributing a client access server role to each site.

The only reason i can think of is that for users at these sites accessing e-mail may be a little slower depending on the internet connection and also maybe its better to set things up as he said as this then distributes the load off the one central server maybe?

Thanks

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

It's pretty much a 'recommendation', and if you want to run a non-recommended installation of Exchange 2010, you'll fall into the trap of having issues the day you want Premier to help you.

It may work, but the general recommendation from MCS is to build multi-role servers. By doing this, you'll escape many of the issues you may find otherwise. It's the recommendation I give all my customers as per the recommendations told us consultants by the product group.

In other words, do it at your own peril.

PM me and I can clarify the situation if you're confused or want some more obscure things sorted out (up to a level of course, I'm not allowed to give you all the hints and tips out there, but I also don't want you to setup something that will hurt you or your customer).

 

All it was, was that I'm new to Enterprise environment IT and in my current role that I've been in just over 6 months now they have all exchange roles on one server apart from the Edge obviously. Its not a huge company, maybe about 50-100 in the central office then we have around 5 remote sites each with around 5 people there.

I was just wondering why my boss had chose to keep it all on the one central server rather than at least put a client access server at each site. Would these users at the remote sites be seeing a delay in receiving and sending email due to not even having a client access server local long and having to go completly out to the internet to get emails.

Or is it case that they probably don't see any delay but maybe if there was more users at the site it would be definetly worth having a client access server there and probably even there mailbox server.

Just really trying to get an understanding of what issues can be caused by the way this is currently setup as I'm currently studying the 70-662.

 

Shinigami, knows his Exchange 'onions' so I recommend listening to him.

We usually role with Client Access/Hub together and then separate Mailbox Server.

 

Same here, we role hub/cas on one server and MBX on another server... The exchange designs vary from infra to infra... Also not all recommendations apply to every infra...

 

This thread seems to be venturing off in a different direction to the answers i was looking for lol. Thanks for your input anyway but i know the reasons for obviously taking the load off a server hosting every single role at your main site. But my questions were related to pushing extra server roles out to remote sites and the reasons why this was so important, as said in my previous post.

"Would these users at the remote sites be seeing a delay in receiving and sending email due to not even having a client access server locally and having to go completely out to the internet to get emails.

Or is it case that they probably don't see any delay but maybe if there was more users at the site it would be definitely worth having a client access server there and probably even there mailbox server."

 

One of the main reasons to have CAS servers at remote sites is to counter act latency issues for MAPI clients.

If threshold increases to over 100ms then you can get pop up boxes for authentication as the kerberos packets don't perform the syn ack syn correctly.

Also you can send out directly from the CAS server and then only use the 'head office' server only for incoming mail, saving bandwidth etc.

 

btw, small clarification. When I stated that installing a CAS in each location is a recommendation, I was assuming that the site also has an MBX and HT server... CAS on its own can help in sites with very poor connectivity to the MBX as the CAS at least ensures a stable MAPI connection for the client, and in the background, the CAS does the work of contacting the MBX for the actual mail content.

But I very rarely see installations that contain MBX servers only at a 'main site' and then there's a bunch of CAS stringed out amongst all the various sites around the world. Don't get me wrong, all those Exchange and Windows Server licenses make our sales team very happy But I have just one customer where this type of activity became a clear recommendation, and even there, the site required a multi-role server because quite frankly, the countries in question (in Africa) have to resort to satellites for telephony and internet connectivity (resulting in high packet loss and long round-trip times).

In other words, an on-site CAS can only help so much, and eventually you need the rest of the roles also hosted locally or your users just end up with a highly frustrated experience...

But yeah, multi-role servers, typically with 4 node DAG's is a recommendation that works very well. I rarely go for the option of separating the CAS+HT from the MBX server these days. But as with everything, IT DEPENDS (so choose wisely).