Tag Archives: MSCryptic

SharePoint 2010 – Application pools recycle when memory limits are exceeded (PART 2)

Recently I started seeing this error show up in the Health Analyzer after consolidating some of my SharePoint application pools so as to conserve some server resources.  On this particular farm we had set up a main collaboration site running under it’s own application pool, and then about a dozen web applications that contained custom coding that we ended un consolidating under another application pool.

Now there are actually several reasons for this error to occur.  If you’ve set up a large farm and broken out your app server from your WFE servers, then this error is pretty standard as Microsoft has this rule set up as an all or nothing type rule as documented here.

However, another reason for this error message coming up is if you’ve consolidated your application pools and reassigned your web applications to use one generic pool, while you can safely delete these application pools, SharePoint is still looking for them in order to verify their existence and proper settings.  When it can’t find them, that is when it gives you the MSCryptic and quite wrong error message that there is a problem with the application pool recycle settings.

In order to “fix” the alert, first you need to check and see what application pools the SharePoint farm is still expecting on the servers, to get this list you can open a PowerShell console and enter the following:

$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$contentService.ApplicationPools | fl Name, ID

In my case, there were several application pool entries that existed in the ApplicationPools collection whose Web Application had already been reassigned to my GenericPool application pool, and in some case I had already deleted from the servers or showed as having 0 applications connected to them.  These ApplicationPools entries were literally just hanging around with nothing to do other than set off my HA alerts.

The solution is to go through and remove the entries from the ApplicationPools collection so SharePoint HA does not try to iterate through them and check their health settings:

$contentService.ApplicationPools.Remove("<insert application pool ID>")

And now, go into SharePoint Central Admin->Monitoring->Review Problems and Solutions and recheck the "Title Application pools recycle when memory limits are exceeded. " warning, it should go away in a minute or two.

SharePoint 2010 – Application pools recycle when memory limits are exceeded.

Title Application pools recycle when memory limits are exceeded.
Severity 0 – Rule Execution Failure
Category Performance
Explanation Access is denied.
Remedy In the Internet Information Services Manager, uncheck any memory-based maximums set for the application pools named above. For more information about this rule, see "http://go.microsoft.com/fwlink/?LinkID=142692".
Failing Services SPWebService (WSS_Administration)

Another fun MSCryptic message from our good friend the SharePoint Health Analyzer.  In this case, Microsoft has yet to allow us to separate out the HA rules to individual servers Unfortunately these rules tend to be an all or nothing approach, and in the case of this rule’s scope we get two choices:


So, what this means is that if we’re running a medium or large farm and we’ve gone and separated out our various application pools so that the Central Admin (CA) and the Web Front End (WFE) are on different services and are in fact isolated, then even though everything is properly set up, because it does not see certain app pools on a server that it thinks should be there it flags the SPHA rule.

Hopefully MS will someday allow us to configure the rules to run on a per-server level instead of just farm level.  In the meantime, three possible solutions:

  1. Easiest way to make this rule go away is disable it
  2. second easist is to install the app pools/services it is expecting on every server in the farm. The health rule checks each application pool in the SPWebService ContentService ApplicationPools collection. If it can’t find the Application Pool on the member server is it checking, it will fail and cause this Health Analyzer (HA) item (notice the application pool name(s) are blank in the message).  You can determine the potentially missing Application Pool(s) with the following PowerShell:
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$contentService.ApplicationPools | fl Name

3. Complete Hack, but you can create dummy application pools so the SPHA can find them but they don’t do anything, thus preserving your service isolation on the farm and at the same time keeping the rule intact.

EDIT: So, turns out if you reassign the web application to a generic application pool and delete the old application pools from the server, SharePoint is still expecting to see them and will throw a Health Analyzer alert if you delete them from the server since it is trying to check for them. In order to remove unused application pools from the SharePoint configuration, please review: SharePoint 2010 – Application pools recycle when memory limits are exceeded (PART 2) where I show how to remove unused application pools from the ApplicationPools collection.

SharePoint 2010 has SQL error connecting to local database

Log entry for EventID 5586: Unknown SQL Exception 297 occurred.

Additional error information from SQL Server is included below.  

The user does not have permission to perform this action.

This is occurring because your SQL Server has not been configured to use named pipes

Fix: Open the SQL Server Configuration Manager and browse down to SQL Server Network Configuration – Protocols and Right-click “Named Pipes” in the right pane and choose Enable.

You may need to restart the server for changes to take effect.

SharePoint 2010 – 503 Error, Service Unavailable After Successful Installation and System Reboot

Nothing is more frustrating than doing everything right and when the moment of payoff appears, getting some MSCryptic error message with no hint as to what the real issue may be.  During a recent setup of SharePoint 2010 I followed my usual script of installing the system and configuring everything using Central Admin.  It went without a hitch until the reboot of the WFE when IIS 7.5 returned a nice 503 error instead of what we were expecting.

The Event Logs and SharePoint logs were useless… Until I saw the Windows Process Activation Service (WAS) error.

Long story short, in some locked down domains where the admins go a little GPO crazy a domain group policy may override some of the permissions of the application pool accounts, specifically the “Log on as batch job” permissions.  The applicaion pool account needs to be allowed the log on as batch job policy, and the farm admin account and all other service accounts need to be allowed the “Log on as service” permissions.  So while the setup and initial running of SharePoint was great and everything appeared to be working, it was the server reboot that was the culprit as the first time after a reboot the policies are overwritten with the more restrictive domain policies.

The solution is to add the app pool accounts to the “Log on as batch job” and all the service accounts to the “Log on as service” domain policies and run a “gpupdate /force” to upgrade the policy on the WFE.  Just for good measure do another reboot and you should see SharePoint in all it’s glory humming along and ready for content.