Unable to create system performance counter with error code PDH_CSTATUS_NO_MACHINE

One of our case we faced with annoying ULS log errors about performace counters. Multiple errors like below filling ULS logs and keep inflated rapidly.

Unable to create system performance counter ComputerName\Memory\Available Mbytes\. The following exception was thrown: System.ComponentModel.Win32Exception: Unknown error (0x800007d0) at Microsoft.SharePoint.Win32.SPPdh.CheckReturnValue(PDH_STATUS status, Boolean throwOnError) at Microsoft.SharePoint.Utilities.SPPerformanceCounter.Initialize() at Microsoft.SharePoint.Utilities.SPPerformanceCounter.NextValue(Int32 retry, Int32 retryInterval) at Microsoft.SharePoint.Utilities.SPPerformanceCounterMonitorInternal.UpdateValue() at Microsoft.SharePoint.Utilities.SPPerformanceCounterMonitorInternal.Create(String computer, String category, String counter, String instance)
Performance Counter OS (pdh) call failed with error code PDH_CSTATUS_NO_MACHINE.

Cause:
Microsoft Sharepoint Timer Service’s account does not have the necessary permissions to access the performance counters on the server.

Resolution:
Find Microsoft Sharepoint Timer Service account and set the account as local admin on all machines in farm.

Backup Error on Moss2007: Object Shared Search Index failed in event OnPrepareBackup, The current operation timed-out after 3600 seconds

If you getting error in spbackup.log file when getting backup like:
Error: Object Shared Search Index failed in event OnPrepareBackup. For more information, see the error log located in the backup directory.
WebException: The current operation timed-out after 3600 seconds
Debug: at Microsoft.Office.Server.Search.Administration.SearchSharedApplication.Microsoft.SharePoint.Administration.Backup.IBackupRestore.OnPrepareBackup(Object sender, SPBackupInformation args) at Microsoft.SharePoint.Administration.Backup.SPBackup.RunPrepareBackup(SPBackupRestoreObject node)

Cause:
When performing a backup of a search application, sometimes the operation for pausing the search application fails. In this case, the backup of the search index cannot continue. In that case, the SSP backup is virtually useless. Pre-SP2, the process of backing up the search database will continue. Post-SP2, the failure to pause the search application during a backup process will also result in failure of backing up the search databases, and the search databases will be marked with the same error as the search index component.
For More info:
http://download.microsoft.com/download/4/1/F/41F3A698-55E8-40B4-A306-AD6CF1F95394/2007%20Office%20Servers%20Service%20Pack%202%20Changes.xlsx

Resolution:
Upgrade to Moss 2007 SP2

Multiple file upload and Drag and Drop file feature on Sharepoint 2010

When using multiple file upload if you are facing problem of  Some of client computers shows Drag and Drop feature and some of are not ,you like this article. First of all Multiple File upload is not a sharepoint feature.It is a Microsoft Office feature and working with just only IE8(+) and Office installed machines.This feature is not supported by other browsers like firefox and chrome. Sharepoint provide an ActiveX control named “STSupld.UploadCtl” via interacting with Microsoft Office’s dll of STSUPLD.DLL at background. And the version of this dll is define that you have Drag and Drop option or not. we e.g see that ActiveX control and there isnt any Silverlight in this issue.

 

More clearly if your client computer have installed Office 2010 than you have drag drop  option if only have office 2007/2003 installed than you see  old version of dialog with CheckBoxes. There isn’t any way to use this option on office 2007 installed computers except installing or upgrading office 2010 according to Microsoft Licence agreements .

Sometimes we are getting problem with this feature even if we are using that Office 2010. The possible problem is here the old version of dll still remain in background. You can able to check the activeX control dll from your IE -> Tools -> “Manage Add ons”

 

The versions below show us which office is in use.
11.0.xxxx   Office 2003 
12.0.xxxx   Office 2007
14.0.xxxx   Office 2010 

Also you can find the assemblies defined folders

C:\Program Files (x86)\Microsoft Office\Office14\STSUPLD.DLL
C:\Program Files (x86)\Microsoft Office\Office12\STSUPLD.DLL
C:\Program Files (x86)\Microsoft Office\Office11\STSUPLD.DLL

If you somehow remove or currupt this dll you could not be use Multiple File Upload feature anymore.

 

Good Tools for Fixing Missing Features on Sharepoint

Some scenarios removing a feature unproperly or after migration your sharepoint to upper version  or in a development envoriment adding removing solutions with multiple times cause  getting several kind of feature errors like “Failed to find the XML file at location ’12\Template\Features\{feature name}\feature.xml’

Here is a very good article about this problem and solution.
http://blogs.msdn.com/b/tehnoonr/archive/2009/02/15/resolving-the-error-failed-to-find-the-xml-file-at-location-12-template-features-feature-name-feature-xml.aspx

 You may need belowed tools for fixing that problem. (Some tools are using  just stsadm at background but giving you a visual form experience.)

Wss Remove Feature From Tool
http://archive.msdn.microsoft.com/WssRemoveFeatureFrom
In some situation the STSADM command STSADM.EXE -o deactivatefeature is not able to deactivate a feature either on site collection or on site level.
This can (e.g.) happen if the feature definition for the feature that has to be removed is not installed in the farm.
This tool allows to remove the feature from the site or site collection completly.
Usage:
WssRemoveFeatureFromSite -scope (site|sitecollection) -url <url-to-site> -featureid <featureid> -force

Wss Analyze Features  Tool
http://archive.msdn.microsoft.com/WssAnalyzeFeatures
This tool allows to verify if the feature definition files for all installed features are present on the file system. Also allows to verify if the features used in site collections an sites are installed on the server.
In addition it can create a checklist file which can be used to verify if a server has all features installed required to act as destination for a content deployment job of an existing sitecollection.
Usage:
WssAnalyzeFeatures -url http://server:port
This command will verify all features on the server and in the site collection.
It will create two files:
– ProblemFeatures.txt outlining all identified problems.
– ContentDeploymentFeatures.txt this is the created checklistfile. It will contain all features that have to exist on the target to be able to act as target for a content deployment of the site collection.
WssAnalyzeFeatuers -verify ContentDeploymentFeatures.txt
this command will verify the features installed on the server against the features listed in the ContentDeploymentFeatures.txt checklistfile which was created on the source server.

SharePoint Feature Administration and Clean Up Tool
http://featureadmin.codeplex.com
Find faulty FeatureDefinitions and cleanly uninstall them.
Find Feature remainders in Sites, SiteCollections, WebApps and in the Farm, from e.g. forcefully uninstalled Features from farm without deactivating them before, causing errors.
Also, de-/activate Features Farm wide.

Faulty Feature Tool v2
http://www.moss2007.be/blogs/vandest/Documents/FaultyFeatureTool_EXE.zip

 .

How to fix 64bit ACL limit exceeded problem on Sharepoint.

In many cases getting “The Parameter is incorrect” error when searching crawl logs for defining why my search is not working or one site is not to be crawled.This is one specific error that addres us to  64 kb size limit of an Access Control List (ACL). Microsoft says : “This behavior occurs if the size of the access control list (ACL) is larger than 64 kilobytes (KB). The maximum buffer size of the InitializeAcl function is 64 KB. Therefore, the maximum size of an ACL in Windows, including the access control entries (ACEs) that are contained in the ACL, is 64 KB.” http://support.microsoft.com/kb/885482

Sharepoint uses ACL on background for securty issues. And this limitation is not actually a sharepoint limit .It is an operating system limit. If the limit is exceeded , calculation of security principals is not working and causes anomalies. One of them is unable to crawl and getting “The Parameter is incorrect” error on crawl logs.

What is the boundries and Limits

For Moss 2007 Security Principal Limit is Approximately 2,000 per ACL (Access Control List) on any securable object (scope)
The total size of the ACL on scopes can be no larger than 64kb. Because each security principal is approximately 32 bytes in size, there can be no more than approximately 2,000 security principals or less for each scope.  If this limit is reached, indexing of items in that scope, and all items below that scope, to fail.
Also, because SharePoint Groups are expanded during the indexing process, having more than 2,000 users or Directory Groups in a SharePoint group and using that group for securing scopes may cause indexing of items secured with these groups, and all items below them, to fail.
This limit only occurs when Windows Integrated Authentication is utilized.”
http://technet.microsoft.com/en-us/library/cc262787(office.12).aspx

For Sharepoint 2010 you should consider belowed two limit definition.  

1)”Security Scope: The maximum number of unique security scopes set for a list should not exceed 1,000.
A scope is the security boundary for a securable object and any of its children that do not have a separate security boundary defined. A scope contains an Access Control List (ACL), but unlike NTFS ACLs, a scope can include security principals that are specific to SharePoint Server. The members of an ACL for a scope can include Windows users, user accounts other than Windows users (such as forms-based accounts), Active Directory groups, or SharePoint groups.”  http://technet.microsoft.com/en-us/library/cc262787.aspx.

It is a little confusing.For both version of sharepoint the rule is same don’t exceed 64 Kb limit. For Sharepoint 2010 “exceed 1000 ACE” is just a threshold. Depending of ACE’s size there isnt any strict count limit . It should be between 1820 – 2000 ACEs.

“Except for the 64 KB limit on the ACL, there is no hard-coded limit for the number of users and groups to whom you can grant access to the portal site. You can add as many users and groups to a portal site as you want until the 64 KB limit of the ACL is reached. Because the sizes of individual ACEs vary, the total number of ACEs that can be put in an ACL also varies. Therefore, the exact number of groups and users who you can add to the portal site cannot be determined from the 64 KB limit of the ACL. To avoid this issue, we recommend that you do not add more than 1,000 users and groups to your portal site. ”
http://support.microsoft.com/kb/885482

Ok . I assume that you understand the ACL and limits . now we return our main issue how to fix that problem. 
Where do we start : Determining which scopes can cause the problem.

Important !  Do not change sharepoint database ! Application of any schema change to the SharePoint database, except as part of a Microsoft-supplied service pack or hot fix, will make the SharePoint environment unsupportable. This type of change should never be applied.

Using this query you can identify the amount of security principals (ACEs) per scope (ACL):

select COUNT(ra.PrincipalId) as [Count],p.ScopeUrl
from RoleAssignment ra with(nolock)
join Perms p with(nolock) on p.SiteId = ra.SiteId and p.ScopeId = ra.ScopeId
group by p.ScopeUrl
order by [Count] desc

As you see in the results that the scope of “planing” contains 370 principals. This can be groups  or directly added users to that scope.
We could not say here if this is exceeding the 64kb ACL Windows Limit.
Look at these scenarios:

               (1) If there are 369 directly added users and one SharePoint group which contains 5.000 users than you would definitely exceed the total limit of that scope! (total principal count would be 5.369!)

               (2) If there are 369 directly added users and one SharePoint group containing an AD group with 400.000 users than you don’t exceed the total limit of that scope! (total principal count would be only 370!)

In general: For each site, or list, or list-item for which you break the permission inheritance from the parent site you will get a new scope and It will use its own ACL.

Using the following query you can identify how many users are in your available SharePoint groups:

select COUNT(m.MemberId) as [Count], g.Title as [Group-Title]
from GroupMembership m with(nolock)
join Groups g with(nolock) on m.GroupId = g.ID and m.SiteId = g.SiteId
group by g.Title
order by [Count] desc

there are two sharepoint group that are in our interest.
1289 Performace Management System.
1050 Quality Team Members .

Using one of these group on any of his sites (= ScopeUrl) can cause the crawl error “The parameter is incorrect” which the customer reported for the site.

Lets consider that we add one of these big groups  (Performance Management System) to an scope for example Operations (280) .The group counts as one principal so there are still 279 principals left or direct.
this mean 279 + 1289 = 1568 principals . it is so close the 1820-2000 limit. Think about a worst scenario to add another group to one of left 279 slot. you will exceed the limit with a big possibility.

So for workaround:
1) Define your big sharepoint groups.
2) Create a AD security group for each one
3) Move users sharepoint group to AD group.
4) Add this ad group to your Sharepoint Group instead of adding user one by one.
Resources:
http://support.microsoft.com/kb/885482
http://technet.microsoft.com/en-us/library/cc781716(WS.10).aspx
http://blogs.msdn.com/b/mattlind/archive/2007/11/02/sharepoint-indexing-limited-by-64-kb-acl-limit.aspx
http://blogs.msdn.com/b/arvind7in/archive/2010/05/26/what-is-64k-acl-limit.aspx

And Special thanks to Holger Lutz for these valuable informations .

See you in next articles.