Tag Archives: Sharepoint 2010

PowerShell error: The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered.

When you run SharePoint management powershell on your SharePoint 2010 server you get the following error:

The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered

SharePoint_2010_shell1

Solution:

Make sure the logged in user has the correct rights to the SharePoint_Configuration database

  • SharePoint_Shell_Acces or:
  • DB_reader or DB_writer

Use the following Powershell cmdlet to give this user the correct databases permissions, since Direct database changes are not supported by Microsoft: Add-SPShellAdmin (http://technet.microsoft.com/en-us/library/ff607596.aspx)

SharePoint_2010_shell2

sql maintenance plan

SQL Maintenance Plan SharePoint 2010 databases

To maintain good overall databases performance of the SharePoint 2010 databases I use the following SQL maintenance plan. This plan consist of two main parts: – The configuration of each separate databases and database properties settings – The automated maintenance plan, to perform database maintenance task once a week.

Please note: For most of the SQL tweaks to perform on a LIVE SQL database you will need the Enterprise edition of SQL 2008 R2. Otherwise you need to put the databases offline before executing the maintenance plan as described in the article.

Databases Types SharePoint 2010 has three types of databases: – System/Configuration databases (do not include these databases in the maintenance plan) – Service Application databases – Content Databases

Powershell created databases I always create SharePoint databases with a powershell script and not with the default auto-provisioned functionality. The advantages of this approach are: – guaranteed control over database names (no GUIDs in the database names) – guaranteed control over database sizing – procedural separation of control over application and data environments

Data Integrity To prevent database corruption we need to protect the SharePoint databases. There are two kinds of database corruption: – Physical corruption, might occur when the disk that holds a log file or data file has been altered. This type of physical corruption tends to affect sectors on a disk due to problems in the I/O subsystem, such as the physical network hardware and disk drives themselves. – Logical corruption is caused by data being altered in some unanticipated way that severs a data relationship. This type of corruption usually is caused by an application error or human error that causes data problems but doesn’t affect the physical structure of the database.

To prevent and detect any kind of databases corruption issue I use the SQL function DBCC_CHECKDB in the maintenance plan. The only downside is that if any error occurs from this check the only solution will be to restore the database from a backup.

Managing Database files The recommendation for the SharePoint SQL environment is to place log files and data files on different disks and to ensure that no other application uses those disks. This setup minimizes overall write access to the disks, and lessens the opportunities for file fragmentation.

Measuring and Reducing database index Fragmentation Index fragmentation can result in performance degradation and inefficient space utilization, and indexes may become quickly fragmented on even moderately used databases. In SharePoint 2010 a table that often becomes fragmented is AllDocs, which contains document libraries, their associated documents and lists and list items, and their respective metadata.

SQL Server Fill Factor The fill factor of each SharePoint databases needs to be set to default. Default the way the database fill factor defines how much free space is required on a database page during an index rebuild before moving to a new database page. Otherwise the database takes more database space because the database pages are larger. Instead we sill set the default fill factor for the whole SQL server, a server-wide setting of 80% is optimal to support growth and minimize fragmentation.

Shrinking Databases SQL Server 2008R2 has the ability to shrink data files, which recovers disk space by removing unused data. The best way is not to set the shrinking of the databases in SharePoint to automatically shrink the data files. Also not to configure a maintenance plan that does it automatically on a SharePoint database. The reason is that the database auto-shrink ignores the fill factor setting and causes all the indexes to become fragmented. Then, when you run a rebuild indexes command, the database grows back to its original size. 

Instead of auto-shrinking databases on SQL, it’s safer to partition content databases or to remove data from existing databases on SharePoint 2010 level.

Recommended Database Maintenance plan for SharePoint 2010 All tasks to prevent the issues that can occur are being automated within a SQL 2008 R2 maintenance plan. Normally I will schedule this maintenance plan for once a week but in some environments (where there are a lot of changes in the SharePoint environment) you can choose to execute the maintenance plan more often.

1. The maintenance plan contains the following steps:

  • Remove excessive transaction log file fragmentation by ensuring the appropriate recovery model and backup schedule.
  • Turn off any scheduled shrink operations to reduce the risk of unnecessary index fragmentation.
  • Put a regular process in place to detect and remove index fragmentation.
  • A process to run DBCC CHECKDB.
  • A maintenance plan should include either index reorganization or index rebuilding (never use both).
  • Update Statistics

2. The configuration of each database:

  • Turn on AUTO_CREATE_STATISTICS and AUTO_UPDATE_STATISTICS, and have a regular process in place to update statistics.
  • Turn on instant file initialization such that database auto-growth is an instantaneous operation rather than a slow operation that requires zero-filling new space.
  • Place Database and log files on different SAN disks.
  • Set auto-growth correctly by using a predetermined set file size rather than a percentage. Follow this up by periodically examining database sizes and determining whether manual database growth is necessary to ensure optimum Performance.
  • Turn on page checksums.

Access denied: Business Data Connectivity

After creating an External Content Types and connecting the ECT to a list I received the folloing error: Access denied by Business Data Connectivity

Business-Data-Connectivity-1

I created the ECT with SharePoint designer and give the correct users the correct permissions. Somehow when I saved and modified the ECT from SharePoint designer again,  the permissions got lost. I found out that if you modify the ECT in SharePoint designer you need to go back into Central Administration and set permissions again for the Business Data Connectivity Service application.

Follow these steps to give the correct permission on the ECT:

Open the  SharePoint 2010 Central Administration on the server  and click on Manage service applications.

Business-Data-Connectivity-21

Then click on Business Data Connectivity Service:

Business-Data-Connectivity-31

Select the External Content Type and click Set Object Permissions

Business-Data-Connectivity-41

Add the correct users and give them the right permissions:

Business-Data-Connectivity-61

SharePoint 2010 Error (in CoreResultsWebPart::OnInit) when searching

After installing a fresh SharePoint 2010 standard farm I kept on receiving this error when I try to search something in the search center:

CoreResultsWebPart::OnInit: Exception initializing: System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.SetPropertiesOnQueryReader() at Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.OnInit(EventArgs e)

After trying the following actions:

  • ensuring that hotfix 976462 is installed
  • ensuring that the “SharePoint Server Search” and “Search Query and Site Settings Service” services are running, both are up and running
  • removing and reinstalling the search application
  • ensuring that the application pool is assigned correctly
  • restarting the timer service
  • restarting the search service
  • rebooting

Still no luck, than I figured that the Search webpart wasn’t activated. So activating the site collection Search Webpart solved this issue.

SharePoint PowerShell Backup Script with Windows Scheduler

An easy script to backup your SharePoint farm with Windows scheduler. First create a powershell script:

1-Backup a site:
Add-PSSnapin Microsoft.SharePoint.PowerShell
backup-spsite -identity $args[0] -path $args[1] -force

2-Backup the complete farm:

Add-PSSnapin Microsoft.SharePoint.PowerShell
Backup-SPFarm -Directory $args[1] -BackupMethod full

Next, create a .bat script to start the powershell script:

@echo off
SET SOURCE_SITE=http://sharepointfarm/
SET DEST=E:\SQLBackupFolder\
echo “Backup SharePoint Started at” %DATE% >> E:\SQLBackupFolder\Logs\Log.txt
powershell -command E:\SQLBackupFolder\SPbackupScripts\backupSP.ps1 %SOURCE_SITE% %DEST%
echo “Backup completed successfully at %DEST%” on %DATE% >> E:\SQLBackupFolder\Logs\Log.txt
@echo on

Now you can use the .bat start script in Windows Scheduler to backup your sharepoint farm. In the Task Scheduler, the account needs to be set with admin permissions to run it properly.

To clean up older sharepoint backups, schedule the following powershell script. This script checks the spbrtoc.xml for the number of sharepoint backups.

# Location of spbrtoc.xml
$spbrtocXML = “\\UNC backup folder\spbrtoc.xml”
# 10 Days of backup will be remaining after backup cleanup.
$days = 10
# Import the Sharepoint backup spbrtoc.xml file
[xml]$sharepointlist = gc $spbrtocXML
# Find the number of backups in spbrtoc.xml
$oldbackups = $sharepointlist.SPBackupRestoreHistory.SPHistoryObject |
? { $_.SPStartTime -lt ((get-date).adddays(-$days)) }
# Delete the backups from the Sharepoint backup spbrtoc.xml file
$oldbackups | % { $sharepointlist.SPBackupRestoreHistory.RemoveChild($_) }
# Delete the folders of the old backups on file level
$oldbackups | % { Remove-Item $_.SPBackupDirectory -Recurse }
# Save the changed spbrtoc.xml
$sharepointlist.Save($spbrtocXML)