Jamik

Activate SharePoint CmdLets in PowerShell:

Add-PSSnapin Microsoft.Sharepoint.Powershell

Permanently register the SharePoint CmdLets in your ISE profile:

if (!(test-path $profile ))
{
    new-item -type file -path $profile -force
} 
 
$cmd = 'if((Get-PSSnapin | Where-Object {$_.Name -eq "Microsoft.SharePoint.PowerShell"}) -eq $null)
{
    Add-PSSnapIn "Microsoft.SharePoint.Powershell"
}'
 
out-file -FilePath $profile -InputObject $cmd -Append

via Points to Share

Problem:
If you’re trying to open an Office Document in SharePoint 2010 with the included WebApps you might encounter the following error in the diag log/screen:

Corresponding diag log entry:
System.Data.SqlClient.SqlException: Cannot open database "CONTENTDB" requested by the login. The login failed. Login failed for user 'DOMAIN\ACCOUNT'.

Description:
If you’ve not used the Farm Configuration Wizzard the service accounts you’re using for the Web App Service Applications might not be provisioned correctly and have not the neccessary rights to connect to the content database.

Fix:
Grant at least read/write permissions to the service application account at the corresponding content database.

PS: There might be an PowerShell CmdLet for this operation – this post will get updated if i have found a better solution.

Update:
As promised – the PowerShell Script:

$w = Get-SPWebApplication -identity  http://URL
$w.GrantAccessToProcessIdentity("DOMAIN\SERVICEAPP")

The session state service is an application service in SharePoint 2010 which is used by many components (eg Infopath Forms Service) to store temporary data accross related http requests. If you’ve used the farm configuration wizzard the state service is installed and configured automatically. Otherwise you have to activate the state service with PowerShell CmdLets.

The following snippet creates a state service application and the corresponding proxy group with the name “State Service Application” and associates them to the default proxy group:

$serviceApp = New-SPStateServiceApplication -Name "State Service Application"
New-SPStateServiceDatabase -Name "StateServiceDatabase" -ServiceApplication $serviceApp
New-SPStateServiceApplicationProxy -Name "State Service Application" -ServiceApplication $serviceApp -DefaultProxyGroup

Get-Command *spstate*

gives you a complete list of state service related CmdLets.

Problem:
Object Cache: The super user account utilized by the cache is not configured. This can increase the number of cache misses, which causes the page requests to consume unneccesary system resources...

Fix:
stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue DOMAIN\ACCOUNT -url http://URL

The Superuseraccount should have “Full Control” permission but should not operate as system user.
Corresponding permissions should be set as “User Policy” of the Web application.

Update:

Due popular demand here are the steps you have to complete to get rid off these warning message(s):

1. Create two service accounts
   1. a superreader account
   2. a superuser account
      Both serviceaccounts should not be member of your webapplication(s) nor should be application pool accounts or farm admins. Two simple serviceaccounts with no rights will do the job.
2. Go to “Manage Webapplications” and select the desired web application
3. Create two user policies
   1. Add the superuser service account and grant him “Full Control” permissions
   2. Add the superreader service account and grant him “Full Read” permissions
4. Set the superuser and superreaderaccount either by stsadm or powershell
   1. stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue DOMAIN\ACCOUNT -url http://URL
   2. stsadm -o setproperty -propertyname portalsuperreaderaccount -propertyvalue DOMAIN\ACCOUNT -url http://URL

Note: If you are using claims authentication use the claims naming format instead of the DOMAIN\ACCOUNT format. Otherwise your webapp may become inaccessible.

Problem:
Numerous errors in the event log of a SharePoint 2010 server with the following error event descriptions:

Load control template file /_controltemplates/TaxonomyPicker.ascx failed: Could not load type 'Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker' from assembly 'Microsoft.SharePoint.Portal, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c'.

and

Load control template file /_controltemplates/ScenarioNavigation.ascx failed: The 'wssuc:ButtonSection' tag has already been registered.

Fix 1:
Locate the file “TaxonomyPicker.ascx” in the Controltemplates directory of the 14 Hive, search for the following line

<%@ Control className="TaxonomyPickerControl" Language="C#" Inherits="Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker&#44;Microsoft.SharePoint.Portal, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

and replace ‘,’ with ‘,’.

The correct line should look like

<%@ Control className="TaxonomyPickerControl" Language="C#" Inherits="Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker,Microsoft.SharePoint.Portal, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

Fix 2:
Locate the file “ScenarioNavigation.ascx” in the Controltemplates directory of the 14 Hive, search for a duplicate line of

<%@ Register TagPrefix="wssuc" TagName="ButtonSection" Src="/_controltemplates/ButtonSection.ascx" %>

and delete the second one.

Update:

The second problem seems to be fixed in the RTM version. The “TaxonomyPicker.ascx”-Problem still persists.

Update2:

Fix 1 (“TaxonomyPicker.ascx”) doesn’t apply to the RTM Version anymore as the “TaxonomyPicker” Class seems to be obsolete.
If you want to fix this error simply rename the “TaxonomyPicker.ascx” to something like “TaxonomyPicker.ascxBACKUP” to prevent recompilation by the CLI and the error is gone.

If you like to use the taxonomy feature in SharePoint 2010 and try to create a Managed Metadata Column in a list or document library you may encounter the problem that this feature is not enabled by default:

At this time (Beta2 & RC) you have to activate this feature using PowerShell:

List all Features with the name *Tax*:

PS C:\> Get-SPFeature | where {$_.displayname -like "*tax*"}
 
DisplayName                    Id                                       Scope
-----------                    --                                       -----
TaxonomyFeatureStapler         415780bf-f710-4e2c-b7b0-b463c7992ef0     Farm
TaxonomyTimerJobs              48ac883d-e32e-4fd6-8499-3408add91b53     WebApplication
TaxonomyFieldAdded             73ef14b1-13a9-416b-a9b5-ececa2b0604c     Site
TaxonomyTenantAdmin            7d12c4c3-2321-42e8-8fb6-5295a849ed08     Web
TaxonomyTenantAdminStapler     8fb893d6-93ee-4763-a046-54f9e640368d     Farm

Activate “TaxonomyFieldAdded”

PS C:\> Enable-SPFeature -Identity 73ef14b1-13a9-416b-a9b5-ececa2b0604c -url http://betaplace

List all registered SharePoint application pools:

Get-SPIisWebServiceApplicationPool

Delete a specific Application Pool:

Remove-SPIisWebServiceApplicationPool -Identity "NAME"

UPDATE:
The release version has slightly different names for the cmdlets.

List all registered SharePoint application pools:

Get-SPServiceApplicationPool

Delete a specific Application Pool:

Remove-SPServiceApplicationPool -Identity "NAME"

 
For a full list take a look at MSDN.

Problem:
If you try to install SQL Server 2008 (without SP1) on a Windows 2008 R2 Server the setup fails with an application error.

Fix:
Install SP1 before starting the installation of SQL Server 2008. SP1 updates the required components which are used by the setup. Rerun SP1 after setup is finished.

References:

• http://support.microsoft.com/kb/955725