harbar.net component based software & platform hygiene

SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Print | posted on Friday, December 26, 2008 7:31 PM

I keep getting sandbagged by folks on the topic of the SharePoint Central Administration (SPCA) application, and there is still considerable confusion about how SPCA should be best deployed within a farm topology, how to make it “Highly Available” and “Secure”. Most of the queries are around what I do in my deployments and what recommendations I have for SPCA. Therefore this article covers these topics along with some additional discussion and general recommendations.

Most of this information is available elsewhere but alas in a disparate and confusing manner. The idea of this article is to consolidate these SPCA related tips into one reference guide and offer some additional explanation which you may find useful (and that I can point people to when being cornered!).

I assume you are all familiar with SPCA and therefore I won’t spend time babble speaking about what it is for and so on. I will point out though that SPCA is pretty important (!!) in the grand scheme of things SharePoint, so it deserves plenty of consideration in your farm topology planning. I will use the classic ‘Medium Server Farm’ topology in the examples below, however the concepts are valid for larger environments as well (those being the context for most of the questions I’ve received).

 

This short update is to clarify the situation following discussions with Microsoft Premier Field Engineers on the matter.

Running Central Administration on more than one server in the farm is 100% supported, and indeed a recommended best practice.

Load Balancing Central Administration is 100% supported. And even if it wasn’t it wouldn’t matter as you can simply take load balancing out of the equation and hit one of the machines directly.

Implementing Kerberos Authentication for load balanced Central Administration is 100% supported.

Implementing Central Administration on Port 80 or 443 is 100% supported.

If you are told by someone that the above approaches are unsupported, they are incorrect. Please contact me via this blog and I will follow up with you.

[UPDATE 13/09/2010] Whilst this article is about SharePoint 2007, it is also entirely valid for SharePoint 2010.


Running Central Administration on more than one server in the farm.

One of the most common issues I see when performing health checks is that SPCA is only installed on one server in the farm, most commonly the ‘Index’ or ‘Application’ server. This is not unreasonable as it is the approach promoted by Microsoft for the classic ‘Medium Server Farm’, consisting of one ‘Application’ server, and two ‘Web Front End’ servers. This model has been around forever (Solution Accelerator for Intranets) and is tried, tested and proven.

A key design driver for this model with respect to the hosting of SPCA on the Application server is that access to SPCA will be “round the back”, on the inter-server LAN only from a small number of authorized administrators.

However deploying this model causes a couple of problems and/or risks:

  1. When crawls are taking place, SPCA response times and usability can tank.
  2. If the Application server goes offline or otherwise dies you have no SPCA.

Of course in event of a disaster with the Application server a different server can be provisioned with SPCA by SPCA itself if you could get to it (Operations… Services on Server), running the Configuration Wizard or STSADM, but this is far from ideal as you will likely need quick access to SPCA to help fix the problem at hand!

The solution to these problems is to deploy SPCA to more than one server in your farm. This is possible despite a bunch of erroneous information out there, including a MCS Consultant’s blog “explaining” topologies, stating that SPCA only runs on one machine, which is simply the default configuration.

[UPDATE, 18/05/2009] The blog post mentioned above has now been corrected.

This is what the Advanced button is all about in the SharePoint Configuration Wizard (SPCW). When we join a server to the farm we can use this screen to also provision SPCA onto that server.

SPCW1 SPCW2

If we go back to our ‘Medium Server Farm’ topology, the sensible place therefore to install SPCA is onto both of the ‘Web Front Ends’. Once we have done this each machine hosts SPCA, as detailed in the diagrams below.

 MediumFarm Topology 

At this point we have a couple machines running SPCA. Because of the frankly bizarre way SharePoint deals with addressing for SPCA each server is listening on the specified port, but only the primary server (the first machine we installed SPCA on) will be used. If we attempt to access the second server directly, it will redirect us to the first one! This is not the configuration we require.

[UPDATE, 27/12/2008] The redirect only takes place is we request the “top level” URL, e.g. http://mossweb2:8080/. If we request http://mossweb2:8080/default.aspx the redirect will not occur.

 

 


Correcting the Central Administration AAM Collection

The cause of the redirect is by default, the Public URL for every Internal URL is that of the first server, as shown below.

AAMsBefore

We can fix this easily by editing the Public URLs so that instead of having two entries within the AAM Collection in the Default Zone (which logically is incorrect) we have two separate Zones, which can then have different URLs.

This is done by clicking the Edit Public URLs button within the Central Administration AAM Collection page, and then adding the second server’s URL into one of the Zones (Intranet recommended):

PublicZoneURLs

Once we hit Save our AAMs are as we wish:

AAMsAfter

Now if we access http://mossweb2:8080 from a web browser we won’t be redirected. We have two “independent” SPCA instances and we can choose which one to use simply by changing the URL in browser’s address bar.

[Documented previously on the From the Field blog]

[UPDATE, 27/12/2008] Making such modifications will break the second (and third, forth etc) instance when using Kerberos Authentication. SharePoint can only configure Authentication on a URL in the Default Zone. Therefore if we wish to use Kerberos, we should *NOT* make these changes, and workaround the issue by using the full address (e.g. http://mossweb2:8080/default.aspx) when requesting SPCA. More details in the Kerberos section below.

 

 


Modifying the CentralAdministrationURL Registry key.

Having our AAMs in order doesn’t help if we use the SharePoint v3 Central Administration shortcut on our servers. This shortcut is not simply a URL but rather runs PSConfigUI.exe to determine the URL of SPCA and then open a browser window with that URL. This is a good thing in most scenarios as our SPCA may have been moved. PSConfigUI determines the URL by checking a registry key.

The problem here is that this is only designed to support a standard configuration, with only one SPCA URL. On every server, the URL will be the URL of the first server on which SPCA was installed. In our scenario, if we are logged on to MOSSWEB2 and click the shortcut it doesn’t make sense to hop across to MOSSWEB1.

We can fix this easily by editing the CentralAdministrationURL string value at HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS on each machine hosting SPCA, to be the local SPCA instance.

Registry

Now for both of the Web Front End servers we will go to the local SPCA. Our ‘Application’ server of course can only have one value.

[Documented previously on William Baer’s blog]

 

 


Providing “Highly Available” SPCA using Network Load Balancing

At this point we now have resilience for our SPCA as it’s deployed on more than one server and we can easily switch the instance we wish to use. However an extremely common request is for “High Availability”. I personally don’t like that term as there’s way more to it than meets the eye. What people generally mean is they want to load balance SPCA.

Despite what you might read elsewhere, it is possible to load balance SPCA and it’s really easy. There’s nothing clever going on with SPCA and in fact it’s generally simpler than other Web Applications as the SPCA IIS Web Site doesn’t include any Host Headers in it’s bindings.

The first thing we need is a DNS A Record (not an Alias), e.g. spca.sharepoint.com for the URL we wish to use to access SPCA and a Virtual IP Address (VIP) for that to listen on.

Don’t ask me why Microsoft calls VIPs “Cluster IP Addresses”, I have no clue!

Assuming our Network Load Balancing cluster is already setup and includes our VIP, we then go ahead and set up a NLB Port Rule for the port we are running SPCA on (e.g. 8080). We should use Single Affinity for performance reasons (there is no benefit to "true” load balancing in this scenario).

PortRule

The next step is to add an additional Public URL within the Central Administration AAM Collection for our new URL (this will prevent Render Failed errors in Web Parts and other mishaps whilst using this URL).

AAMsNLB

We can now browse to http://spca.sharepoint.com:8080/ to use SPCA and if one machine goes down, the application will still be available without us needing to change anything. You can use another load balancer product if you wish, but remember the Public URL is required.

We could now update the registry key to point to this new URL and regardless of which SharePoint machine we are on we will access SPCA through NLB.

 [UPDATE, 27/12/2008] Making such modifications will break the load balanced URL when using Kerberos Authentication. SharePoint can only configure Authentication on a URL in the Default Zone. Therefore if we wish to use Kerberos, we should *NOT* make these changes, and workaround the issue by adding the Load Balanced URL in the default zone. More details in the Kerberos section below.

 


Running Central Administration on the standard Port

A lot of folk are annoyed that the SPCW doesn't allow port 80 to be used for SPCA. There are a couple of reasons for this. Firstly the bogus security by obscurity recommendation (running on a high port), is still persuasive even if it’s only actual security benefit is defence in depth.

Secondly, the IIS Default Web Site uses port 80 and you can’t have multiple sites on the same port unless Fixed IPs or Host Headers are used. If not, only one site at a time on a given port can be started. This second reason is much more important, as if port 80 was enabled in the SPCW, there’d be a ton of broken deployments right out of the gate, by default.

However if we have intelligent security architects at our company and wanted to use the standard port we can.

The first thing we need to do is to stop the Default Web Site using the IIS Manager on each machine running SPCA.

Then we use STSADM to set the port used by SPCA:

stsadm –o setadminport –port 80

 

Doing this will change the bindings in IIS and modify the AAMs, we also need to repeat the steps in Correcting the Central Administration AAM Collection section to correct the Public URLs as shown below.

AAMsPort80

If we are doing load balancing, we would also of course need to modify our NLB port rule so that it is load balancing traffic on port 80 and add our additional Public URL (http://spca.sharepoint.com).

AAMsPort80NLB

Don’t forget to also modify the Registry key which will be reset by the setadmin port operation.

 


Running Central Administration over SSL.

So far all of our access to SPCA has been over HTTP, which means plain text over the network. In lots of places SPCA asks us for service account credentials which are then passed back to the server when we hit OK or Save. These credentials also go over the wire in plain text. These credentials could therefore potentially be disclosed, to prevent this we need to implement Transport Layer Security.

There are two ways to do this – and remember we hopefully trust our network, it’s ours after all in most cases :). Firstly and the best option by far in terms of performance and security is to use IP Sec which is built into Windows. This is vastly preferable, but unfortunately not many people seem to have this together with the requisite infrastructure configured. The second more common option is to use HTTP (SSL).

This requires us to request a SSL certificate for each name our SPCA application is running under (e.g. MOSSWEB1 & MOSSWEB2). We would then add the cert for our server (one per server) to the Machine Certificate Store. IIS7 makes this process much less error prone as we can do all of this from the IIS Manager and don’t have to open the Certificates MMC Snap in. This is all done from the Server Certificates item within the Server Home section.

SSL1

We then need to add an IIS binding for HTTPS and select an SSL Certificate. We do this by selecting the SPCA Site within the Connections pane and clicking Bindings in the Actions pane. On the Site Bindings dialog, click Add…

SSL2

Our next step is to require SSL which we configure from the SSL Settings item within the SPCA Site Home.

SSL3

Once our certificates are installed and SSL is configured, we use STSADM to set the port used by SPCA and enable SSL:

stsadm –o setadminport –ssl –port 443

This step tells SharePoint to use SSL and will also remove the HTTP binding from IIS.

Again, we would need to repeat the steps in Correcting the Central Administration AAM Collection section to correct the Public URLs.

AAMsSSL1

Don’t forget to also modify the Registry key which will be reset by the setadmin port operation.

If we are doing load balancing, we need a single certificate for the load balanced URL (e.g. http://spca.sharepoint.com), which is applied to both servers.

With SSL we can’t do both direct server access and load balancing unless we use a wildcard certificate and fully qualified names for direct server access.

Once our certificates are installed, we use STSADM to set the port used by SPCA and enable SSL:

stsadm –o setadminport –ssl –port 443

We would also need to add an NLB Port Rule to load balance our SSL port

Again, we would need to repeat the steps in Correcting the Central Administration AAM Collection section to correct the Public URLs.

AAMsSSL2

Don’t forget to also modify the Registry key which will be reset by the setadmin port operation.

We don’t need to use 443 for SSL but it would be silly to use a non standard port! However bear in mind that multiple SSL sites using Host Headers (yes, it is possible) requires use of a wildcard SSL Certificate. If we are planning to host other SSL Web Applications we should consider using an alternate port for SPCA.

Either way, using individual server names or a load balanced URL, once SSL is configured we will no longer see the security warning on pages where credentials are submitted.

SSLmain

 

 


Isn’t coming in over the Public LAN a risk?

At this point we’re coming in over the front end, Public LAN and many people see this as a risk. It isn’t really, assuming we have configured the membership of the Farm Administrators group correctly and optionally configured Transport Layer Security. Another concern is that this traffic is also going to degrade the end user Web Application performance, this again is a bit of a myth as SPCA shouldn’t be used heavily by large numbers of users.

Consider the counterpoint that allowing access “in the back” is more secure. This of course is security by obscurity again and is this case is completely moot.

If we are really paranoid we can use IIS to further restrict access to SPCA to a defined list of client IP Addresses using the IP Address Restrictions feature.

Note that in IIS7 this feature (IpRestrictionModule) is neither installed by default, or by the MOSS SP1 installer and must be added using Add Role Services within Server Manager.

 

 


Right, so what about Kerberos?

Configuring SPCA to use Kerberos is very straightforward and the same as for any other Web Application. I have separate resources on Kerberos available here.

One of my key recommendations here is to configure using NTLM first. In other words, don’t select Kerberos in the SPCW. It’s not about how great your build scripts are, its about having a working deployment with the least amount of hassle. By configuring as NTLM first, you can be sure that SPCA is working and then setup Kerberos. This way you’re not in a situation where it is difficult to diagnose what is at fault, SPCA or Kerberos.

In a nutshell the process is:

  1. Setup SPN(s). Don’t forget to include the port in the SPN if you are using non standard ports. Note you *do not* need to configure delegation on any computer or user accounts for SPCA. SPCA does not include any functionality which requires Kerberos Delegation.
  2. Configure Kerberos in SPCA or using STSADM
  3. Optionally set Negotiate “only” using ADSUTIL.VBS.
  4. Configure Kernel Mode Authentication (if using IIS7).

 

 [UPDATE, 27/12/2008]

If you wish to use Kerberos with multiple SPCA instances (and optionally Load Balancing) you *MUST NOT* make the modifications to the AAM Collection as described in the earlier section.

Making such modifications will break the second (and third, forth etc) instance when using Kerberos Authentication. SharePoint can only configure Authentication on a URL in the Default Zone.

Take the examples below, our first server (which is the URL in the Default Zone) displayed the RSS Feed from a remote site (which requires Kerberos). The second server cannot display the Web Part and it displays the usual “doesn’t support authenticated feeds” error.

CAKerb1 CAKerb2

If we attempt to configure the second instance to use Negotiate in SPCA or STSADM the command will fail. We can’t work around it by attempting the configuration locally on each machine either. It simply doesn’t work!

KerbError

Therefore if we wish to use Kerberos, we should *NOT* make the AAM changes and stick with the default AAM configuration:

KerbAAMs

If we want to also use Load Balancing with Kerberos, we need to enter an additional Internal URL for our load balanced URL:

KerbAAMsNLB

Now we can configure each URL to use Kerberos, which we must do with STSADM as SPCA is mightily confused with our configuration and can only set the authentication for a single URL!

stsadm -o authentication -url http://mossweb1:8080 -type Windows –usewindowsintegrated
 

stsadm -o authentication -url http://mossweb2:8080 -type Windows –usewindowsintegrated
 
stsadm -o authentication -url http://spca.sharepoint.com:8080 -type Windows
                                                                 -usewindowsintegrated

 

Now we have SPCA using Kerberos correctly on both instances (and optionally Load Balancing).

CAKerb3 CAKerb4

However our redirect is still a problem. The way to work around this issue is to update the Registry key to use the full address, with the default.aspx bit (e.g. http://mossweb2:8080/default.aspx).

This is the best you can get. Watch out however thou, if you click the Central Administration link in the very top left hand corner, this is a link to ‘/’ so you will redirected to the Public URL (mossweb1). The Home tab link doesn’t do this.

 


Other Recommendations

  1. Don’t let the SPCW pick a random high port
    If you wish to keep a high port for SPCA, stick with something sensible like 8080. I like 8080 as it’s contiguous with other default ports in the product (Document Conversions uses 8081 and 8082 by default) and it’s also a semi-standard from back in the day when admin ports like 88 and 8080 were common.
  2. Don't use DNS CNames (Aliases)
    You should only use Aliases when you need one. In addition they cause problems with certain clients (IE6) and Kerberos. Oh and did I mention you shouldn’t use an alias when it’s not an alias you’re after? :)
  3. Windows Firewall on Windows 2008 
    Remember this guy will get in the way of your inter-server communications, including requests to SPCA on high ports. You will need to allow your SPCA ports through. Another in depth post on how to configure the Windows Firewall for a SharePoint Farm is coming soon.
  4. Internet Explorer Trusted Zone
    Ignore the crazy install guides – don’t use them. Don’t be adding SPCA URLs into the Trusted Zone! It’s a totally bogus, single server recommendation. Use the Intranet Zone instead which will send credentials automatically and means you don’t need to turn off Internet Explorer Enhanced Security Configuration.
  5. AAMs are not backed up
    The only way to back up your AAM configuration is to document it. The only way to restore your AAM configuration is to re-implement it based upon that documentation. This is not specific to SPCA but a general problem (one of many!) with AAMs.
  6. Save hassle by running the SPCW first on a machine you want to host SPCA.
    Tidying up later is always a hassle as the SPCW will not change this. If you install SPCA on the Application server and later “move” it, the registry key will always be the application server URL.
  7. Use SETADMINPORT and AAMs with caution!
    In addition changing the admin port or AAM Internal URL, will modify the registry key:
    1. Running STSADM –o SETADMINPORT will reset the key back to the original server with the port specified, on all servers in the farm. It will also reset the AAM URLs back to the original ‘redirect’ configuration.
    2. Modifying the first AAM Internal URL will set the key to that value, on all servers in the farm

 


Summary

So there you have it. A bunch of stuff about Central Administration. Hopefully some of it will be useful, I am sure there are things I have overlooked and/or the odd mistake, and if so I will update in the future.

I managed to get all the way to the end before saying “Best Practice” – this area is a classic example of where there are no across the board best practices, only design compromises. For example using load balancing for SPCA is only a best practice if certain business requirements demand it. Like most other things in SharePoint you need to take a pragmatic, holistic view based upon the entire solution space and then choose what is best for your deployment.

Feedback

Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Hey Spence.
I got a bit more enlightened by your awesome article.

1/6/2009 2:25 PM | [MVP] Tobias Zimmergren
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

The one area that I don't see covered is high availability for content deployments. It seems only one CA server can be configured to accept content deployment jobs, and it's a manual process to change the server that accepts these jobs. Is there another way around this issue I may have missed?

Chris

1/6/2009 7:04 PM | Chris M
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Great article Spence, very informational.

tk

1/7/2009 3:02 PM | Todd Klindt
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Chris M:

The accept/reject incoming deployment jobs is a Farm wide setting and therefore applies to every machine running SPCA. You can in fact configure different Content Deployment Paths to use a different URL for the destination CA server.

If you were to use a load balanced URL in this option, then the Load Balancer would determine which server to connect to. This works....

However, you are limited to a single export server and a single import server. This is the nub of the problem and at present there is no way around this baked in limitation. The best approach here is to provision SPCA onto your import and export servers, and use that URL when configuring Paths.

This of course doesn't give you automatic high availability and should there be problems with the import/export servers the CD configuration would require updating to use other machines. This could be semi-automated using the CD APIs.

1/7/2009 6:07 PM | harbars
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Hi Spence,

If you add the second CA using "psconfig -cmd adminvs ..." the registry entry will be updated on all servers in the farm.

Regards,

Brad

1/22/2009 11:36 PM | Brad Smith
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

awesome! Thanks :)

1/29/2009 8:54 AM | Frobnitzz
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

really a great article man, wonderfull.

1/30/2009 6:24 AM | sunilprabha
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Its always amazing we do what Microsoft tell us, until someone else proves that it can work another way and is in fact perfectly happy to do that, its just Microsoft weren't that sure whether it was a good idea or not.

Excellent Article! My gratitude to you for taking so much time over this kind of endeavour.

4/8/2009 1:13 PM | VitalHostage
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Spence, is running SPCA is this manner supported? I have been told (by MCS in UK) it isn't...

4/22/2009 8:15 PM | Matt Groves
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Matt:

Yes, this is 100% supported. Any of the configurations above are.

MCS UK are flat out wrong. If you want a correct supportability statement you should contact a PFE.

If you wouldn't mind, please follow up with me on email - I would like to address this misinformation.

4/22/2009 8:22 PM | harbars
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Hi Spense, Very informative article, a good handy for people like me wandering on this info. CHEERS :)

5/5/2009 11:22 AM | Ram
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Spence,
Great stuff. Glad you pointed it out in your comment on Joel Oleson's blog. I hadn't found this before and there is not enough published on Central Admin.
-Tom

5/5/2009 4:32 PM | Thomas Resing
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Spence,

You rock. Thanks for the info and your efforts!

5/7/2009 4:04 PM | Josh
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Hi Spence,
In this case how will solution deployment work. Do we have to run addsolution on each of the CA server or we can just run it on one and will be replicated to other?

Thanks,
Amish

5/10/2009 5:23 AM | Amish
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

What's the registry key you need to change?

5/11/2009 2:30 AM | Zach
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Amish,

Solution Deployment will take care of it. You only need to run addsolution once and it will be added to the "store".

Cheers
Spence

5/11/2009 4:45 PM | harbars
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Zach:

the registry key is detailed in the article. Please see the section titled:

Modifying the CentralAdministrationURL Registry key.

Cheers
Spence

5/11/2009 4:46 PM | harbars
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Fantastic! Thanks!

5/19/2009 1:33 AM | Mike
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Hi,

I have login issue with SPCA on one of PROD server, I am getting prompted 3 times login window, Even i am entering right credentials i could n't able to login,

Getting 401.1 errors due to invalid credentials.

we enabled IIS http Compression recently made on IIS, after having restart on the server we have this issue later we disabled that..
Any help would be highly appreciated!!!

Thanks,
Raju...

5/28/2009 4:25 AM | Raju....
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Hey Everyone! I am struggling with my first installation of WSS 3.0 and I seem to get confused with all this server farm information. I am just running a standalone install of this package; do I really need to use Central Admin to manage my site, or can I just utilize the site utilities. We are a non-profit and only have 50 employees so we will never need the full capabilities that all of you seem to use.

Again, is Central Administration really important to me in my situation. I appreciate any assistance you can offer. Thanks.

7/27/2009 5:04 PM | Deb
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Thanks very much for this exemplary article not only clearing up the vexed support question but also many of the technical details for actually getting the recommended configurations to work. This is extremely useful information.

8/11/2009 8:41 PM | Todd I. Stark
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

let assume that we have two load balancer one for front end servers and other for applications server. in this senario do we make the spca point to the application server nlb or front end server nlb?

help is highly appreciated.

8/19/2009 5:22 AM | giva
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Giva: It all depends where your central admin is hosted. If it's hosted on the WFEs as described in my articles you would use the Front End Server NLB. There are very few cases with MOSS where an application server load balancer is required.

8/19/2009 10:44 AM | harbars
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Thank you sir for your prompt reply. In our case we have deployed the spca in application server "a". so i assume we may need to use the application server nlb for our scenario. also could you kindly point me to a site or an article that discuss about cases where an application level load balancer will enhance availability and what are the changes in the configuration (is ssp needed to point to application nlb etc) when compared to a 5 server farm installation.

8/19/2009 5:06 PM | giva
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Hi Giva,

It is very unusual to load balance anything other than the "Web Front Ends" within a SharePoint farm.

No application service within MOSS (Search, Excel Calc, Document Conversions, etc) require a network load balancer, as they determine their "balancing" through software. It is therefore not necessary to deploy a load balancer for the application servers. You gain zero benefit from deploying one, and indeed deploying one increases the complexity and therefore operational service cost of your farm.

If you have two application servers and you have deployed central admin onto both of those, then yes you would use the application server NLB for central admin. But there is very little point - why have a separate load balancer, when you can use the one for the WFEs? Unless you have strict requirements for "security zones" there is no reason to do this.

Shared Services are installed on every machine in the farm and they require zero load balancing as they are for intra-farm communications between the servers only. The SSP Admin Web Site is deployed to the WFEs (and this cannot be changed). Therefore load balancing of the SSP Web Site is handled by the same load balancer that handles all other web applications on the WFEs.

A second load balancer doesn't offer any compelling benefit whatsoever in a 5 server farm.

Hope this helps, I talk about some of these topics within my Mythbusters presentation that you can find on my speaking page. I would also recommend the Planning & Deployment Guides on TechNet which offer fantastic coverage of farm topology design considerations.

Feel free to follow up, if you have more questions, or if I have mis-read your scenario.

Cheers
Spence

8/22/2009 10:34 PM | harbars
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Spence,

Excellent article - you are always amazing me with the SharePoint boundaries you are breaking through! And I have 2 requests: Has your team done any load testing to see what the increase in farm performance is for multiple SPCA's? Second, I see articles all over the web for NLB but practically none for appliance LB devices such as F5 Big-IP utilizing kerberos. I am building a large farm now and plan on implementing multiple SPCA's with F5's/kerberos. I am going to load test with single and multiple. Do you have any articles on this or can anyone point me in the right direction?

Thanks!

9/24/2009 1:29 PM | Julian Stevens
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Your last point 7.1 mentions that you can "reset" the admin port by issuing STSADM -O SETADMINPORT, but without parameters this command doesn't work. I assume that you meant to include the -PORT <port> parameter/argument as well? I have a situation where I scripted the installation and configuration of SharePoint (application server), the first server creates the farm and hosts central admin, the second server joins the farm and should also have central admin on it but I want all central admin interaction to go to the first server. However when I use psconfig -cmd adminvs -provision... it means that all central admin requests are redirected to the second server. What I'd like to do is somehow get requests for central admin going back to the first server and I'd like to acheive this through scripted psconfig or stsadm commands. I've tried deletealternatedomain, but it doesn't seem to work for me. Any suggestions?
Cheers, Des F

10/8/2009 4:31 PM | Des Finkenzeller
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Thanks
how can i implement sharepoint in 3 server using load balancing but with ntlm security if u have steps


Regards

10/8/2009 4:46 PM | ahmad
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

You have some fantastic information here, especially for someone like me who is brand new to managing SharePoint. I'm curious if the SPCW will reconfigure anything other than installing the SPCA should I decide to follow this idea. I apologize if this seems like an obvious question.

11/9/2009 8:42 PM | Jimmie Jines
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Great job! Although this is a little more advanced than what I am currently working on, your clear writing style has given me confidence to tackle the more advanced topics. It is well written and easy to follow. Thanks

1/18/2010 3:17 PM | Dan
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

I am seeing an issue with certain features in central admin now that it's load balanced (granted, I'm using F5 hardware load balancing and not NLB software based load balancing). One example is if you select the "Update Farm Administrators" link from Operations, then click the "New" button from the menu in order to add user(s). The link fails because for some reason instead of my same base URN, SharePoint has built that link using a port tacked on (the high port I'm running CA on). So you end up with (e.g.) http://example.ca.com:8080/blahblahblah instead of what you should have there which would be https://example.ca.com/blahblahblah. I'm still investigating this behavior, but am curious as to your take on it, Spence. Is this F5 behavior, or perhaps SharePoint trying to "help" and not succeeding?

2/12/2010 3:42 PM | Jeff
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Jeff: sounds like AAMs are causing this one. It won't be anything specific to the Load Balancer implementation.

2/13/2010 10:35 PM | harbars
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Thanks - I ended up needing to enter an AAM for the load balanced URL with the high port appended (even though that doesn't work) and that caused the behavior to stop. The strange request of example.ca.com:8080/blahblahblah now gets "translated" to example.ca.com/blahblahblah thanks to the AAM entry.

Hopefully that will help any others that see a similar issue!

2/24/2010 4:03 PM | Jeff
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Hi Harbar,
This is really very good article. it helps me much.

Thanks very much..

Ram....

3/5/2010 4:16 PM | Ram
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Spence,
Thank you so much for this well thought out, well documented article. I have been researching various ways to load balance my Central Admin server (it was installed onto the Index server) and nothing out there was as clear cut as your work. I followed your instructions and had everything straightened out in 30 minutes. Awesome!

3/11/2010 2:05 AM | Marc
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Spence, thanks a lot i was able to config the WFE 1 and 2 in NLB and i can now access CA either one of them is down. However, my problem now is that when i created web application and site collection this site in no accessable instead "page can not be displayed". Tell me what i missed here.

3/17/2010 9:48 PM | JunM
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

It's really a nice article.

9/27/2010 7:30 AM | Praveen
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Amazing information. Would be awesome if you could put up a 2010 specific version of this post.

thanks

10/6/2010 12:40 AM | John
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

this has really helped me and a few of my collegues, thank you very much

3/8/2011 1:55 PM | Ant Bradshaw
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

i agree with John, would be great if you could put a 2010 specific verison up :)

3/10/2011 10:28 AM | Ant Bradshaw
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Awesome article, Spence! Thanks for busting myths and bringing much needed clarity to this!

4/14/2011 11:59 PM | Deron Dilger
Gravatar

# Running Central Administration over SSL.

Hello;

Very informative article thank you!

In regardsto running CA over SSL.

When creating the certificate for ssl, is there any reason you cannot use self-signed certificate for the purpose of abstracting the plain text that gets sent?

Kind Regards
James

7/20/2011 8:45 PM | James
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

James: Yes you can use a self signed cert, but be aware that this will result in certificate warnings in Internet Explorer.

7/20/2011 11:55 PM | harbars
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Great! it worked like magic with Application server load balancing, with SharePoint Server 2010.
I didn't use the default port cuz of security issues with the network team at the company.

Thank you Spence.

7/27/2011 10:26 AM | Saed Shaar
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Hi,

I am almost surprised to see this. This is one of the fantastic articles i came across with SharePoint Central Adminstation configuration.

Thanks you much for the great post.

Cheers,
Paramesh.

12/1/2011 12:05 PM | Paramesh
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

If you (okay, "I") already have a SP 2010 farm with SPCA only on one server, how do you get SPCA installed on the others without? If fired up the config wizard but since the server is already joined to a farm, the config wizard don't do much.

12/13/2011 11:46 PM | amccollough
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

This is one of the best articles so far I have read online. No crap, just useful information. Very well presented. Thanks for sharing with us. I have found another wonderful post related to this over the internet which explained very well about the tools provided by the sharepoint central administration. For more details of that post check out this link...
mindstick.com/.../

Thanks

12/19/2011 2:24 PM | Somesh Batra
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

This post is a couple of years old but still very relevant, great article and very well written and presented.

1/5/2012 12:19 PM | Roger Moore
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

A technical article which enyoyable, full of sarcasm but contains indeniable truth, right-to-the point, from REAL master...hats-off to you! you had save me from this kerberos scrutiny.

Thank you very much for this post,

Regards,

SharePoint Greenhorn

2/25/2012 3:22 PM | Syahri Ramadhan
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

thanks for sharing knowledge. helpful for sharepoint 2010 administrators.

2/26/2012 9:58 AM | Syed Shujaat Ali
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Hey Spence,
Although this article is quite old but yet it's one of the best ones i've read so far. Brilliantly written !

6/16/2012 7:50 AM | Talib Ali Khan
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Thanks, I'll give it a try!

10/8/2012 2:34 PM | A.Miller
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Great Article, Thanks

1/30/2013 11:57 AM | sathish
Gravatar

# re: SharePoint Central Administration: High Availability, Load Balancing, Security & General Recommendations

Very helpful, much appreciated Spence.

11/23/2013 6:47 PM | Troy Brittain

Post Comment

Title  
Name  
Email
Url
Comment   
Please add 4 and 8 and type the answer here: