Serious SharePoint

Issue: Your crawl component stops responding and the content source is is stuck on a crawling, starting, or stopping status.  You may try a multitude of solutions and eventually attempt to delete and recreate the service application.  Upon creation of the search service application and opening it you are greeted by this message.

Resolution:  This error is a fun one, and by fun I mean painful.  I researched a lot of various solutions but the most consistent answer was as follows.  Please note that this is not a guaranteed resolution, but a common one:

1. Delete your search applications
2. Run the Farm Configuration Wizard to create a search service application
3. Rec-create your search service applications as needed
1. Note: you may receive the same error when initially created.  Give it a few minutes.

It appears that if you are running 64 bit Microsoft Office then you are unable to use the 32 bit Active X controls that allow the File Upload functionality. Go into your control panel->uninstall programs, select Microsoft Office 2010 and click Change. Go to Office Tools and from the dropdown choose Run All From Hard Drive. Complete the change and after the elements are installed you will be able to upload properly.

Scenario: You are working in a site collection where the root site was instantiated from a web template.  You have then created subsites which you wish to save as a web template.  Upon doing so, you receive an error.

Issue:

Error exporting the list named “Announcements” at the URL: Lists/Announcements

If you rename the list and try to save as a template again it will just give the same error with a different list, in alphabetical order.  When you look at the correlation ID you see:

SPSolutionExporter: System.NullReferenceException: Object reference not set to

an instance of an object.

at Microsoft.SharePoint.SPContentType.Serialize...

This is the one of the first lines in the log for your correlation ID.  When you look at the content types for your subsite, you see some of your custom content types but none of the defaults.  When looking at the root web for the site collection you see the same.

Resolution:

Run the SharePoint 2010 Management Shell as Administrator.  Run the following command to disable the default content type feature:

Disable-SPFeature –Identity ctypes –url http://SiteCollection

Then enable the content type feature:

Enable-SPFeature –Identity ctypes –url http://SiteCollection

If you look at your content types, they should now all be there.  Try saving the subsite as a template again, it should succeed.

So you have setup your Metadata Service Application (including the content type hub url), you configured the proxy (making sure to check the consume content type checkbox), and you have published your content types!  So everything is working right?  Wrong.

What site did you use as the site collection root?  If custom, what was the site used for your template?  Turns out that not all site definitions have the TaxonomyFeatureStapler, including the Blank Site.  This feature is required to work with the Managed Metadata service.

There is a powershell command to add the missing feature:  Enable-SPFeature –Url “http://sitecollection” -Identity “TaxonomyFieldAdded”

Additional information: http://www.novolocus.com/2011/04/06/why-blank-root-sites-dont-work-with-the-managed-metadata-field/

Detail:  Following databases have large amounts of space allocated on the disk but not in use. This may be due to recent deletion of data form the database, or because the database has been pre-grown to a larger size. This database will take up a larger amount of space on the file system unless it is shrunk down to a smaller size.

• WSS_Content on Database Server/Cluster

Solution:  This occurs when the recovery mode is set to Full and a transaction log backup has not occurred for quite a while.  As part of a transaction log backup the sql logs are truncated.  If this does not occur for a while, the log files will continue to grow.  Even after a transaction log backup, the log files will remain at the enlarged size until shrunk.  While this should in theory be accomplished with Full recovery models, experience has proved it is easiest to switch to Simple recovery and then run the shrink command. 

NOTE:  This should NOT be done until a full backup and transaction log backup has been done, otherwise data may be lost!

1. Backup the WSS_Content database and logs
2. Convert database to Simple recovery mode
3. Shrink the database
4. Convert the database back to Full recovery mode

Detail:  Using built-in accounts like Network Service or Local System as application pool or as service identities is not supported in a farm configuration.  The following services are currently running as built-in identities on one or more servers:

• SPTraceV4(Windows Service)
• SPSearch4(Windows Service)

Solution:  SPSearch4 will be assigned to run under a domain user with no additional priviledges.  This is done through Central Administration -> Manage Service Accounts.  Be certain to register the account as a managed account first at Central Administration -> Security -> Configure Managed Accounts.

SPTracev4 needs to be altered via a powershell command as detailed below:

Original source: http://blog.octavie.nl/index.php/2010/11/12/using-a-domain-account-for-sptracev4-service/

Run the powershell command to change the account to a domain user

1. # Get the tracing service.
2. $farm = Get-SPFarm
3. $tracingService = $farm.Services | where {$_.Name -eq “SPTraceV4″}
4. # Get the “svc_sp_services” managed account.
5. $managedAccount = Get-SPManagedAccount “Domain\account”
6. # Set the tracing service to run under the managed account.
7. $tracingService.ProcessIdentity.CurrentIdentityType = “SpecificUser”
8. $tracingService.ProcessIdentity.ManagedAccount = $managedAccount
9. $tracingService.ProcessIdentity.Update()
10. # This actually changes the “Run As” account of the Windows service.
11. $tracingService.ProcessIdentity.Deploy()

Add the domain user to the Performance Log Users group on all SharePoint servers.

Detail:  A default zone url is pointing to the machine name of a web front end.  Since this installation has more than one web front end, this can result in a variety of errors including incorrect links and failed operations.

Solution:  A unique domain name will be created for the web application and once the Public Url is set to this domain name, the error will clear.  The error exists because there are multiple mapped access points (by server name) instead of a single url.

Detail:  InfoPath Forms Services is not functional on the following Web applications because there is no service connection configured for the State Service.

Solution:  A State Service Application has to be created and associated with the active web applications.  This will be done via PowerShell as follows:

1. Create a new state service application:
   1. New-SPStateServiceApplication -Name “Shared State Service Application”
2. Create a new state service application database:
   1. New-SPStateServiceDatabase -Name “SP_Shared_StateService” -ServiceApplication “Shared State Service Application”
3. Create a new state service application proxy and add it to default application proxy group:
   1. New-SPStateServiceApplicationProxy -Name “Shared State Service Application” -ServiceApplication “Shared State Service Application” –DefaultProxyGroup
   2. Note: Do not add the -DefaultProxyGroup parameter if you do not want the application proxy added to the default proxy group.

Detail: (Truncated due to length)

[MissingFeature] Database [WSS_Content] has reference(s) to a missing feature: Id = [fc5e2840-0b48-42eb-9ad7-076f5add58ad]. The feature with Id fc5e2840-0b48-42eb-9ad7-076f5add58ad is referenced in the database [WSS_Content], but is not installed on the current farm. The missing feature may cause upgrade to fail. Please install any solution which contains the feature and restart upgrade if necessary.

[MissingSetupFile] File [Features\VASCSiteAction\VASC-core.css] is referenced [6] times in the database [WSS_Content], but is not installed on the current farm. Please install any feature/solution which contains this file. One or more setup files are referenced in the database [WSS_Content], but are not installed on the current farm. Please install any feature or solution which contains these files.

[MissingSetupFile] File [themes\THEME\alldaydefault_granite.gif] is referenced [4] times in the database [WSS_Content], but is not installed on the current farm. Please install any feature/solution which contains this file. One or more setup files are referenced in the database [WSS_Content], but are not installed on the current farm. Please install any feature or solution which contains these files.

Solution:  There are several things going on here. 

Firstly the error warning of  [MissingSetupFile] referring to files in the theme directory can be resolved easily.  The THEME folder and all its files needs to be added to all servers configured as web front-ends.  This most likely includes your application servers.  If you do not have the exact theme referenced, try copying an existing theme and renaming its folder in the root (14 hive).

[MissingFeature] Database [WSS_Content] has reference(s) to a missing feature: Id = [fc5e2840-0b48-42eb-9ad7-076f5add58ad] and [MissingSetupFile] File [Features\VASCSiteAction\VASC-core.css] both refer to the same issue.  These errors are due to the farm looking for a feature that was installed but is not present.  A common cause for this is an upgrade from MOSS to SharePoint 2010 without correcting errors found from the pre-upgrade check.  Correct this by adding the missing solution to the farm and re-deploying to the web application.

Detail:  Using highly-privileged accounts as application pool or as service identities poses a security risk to the farm, and could allow malicious code to execute. 

Solution:  The farm account should be removed from the local Administrators group on all servers in the farm.