احصائيات المدونة

Saturday, December 22, 2012

The sandboxed code execution request was refused because the Sandboxed Code Host Service was too busy to handle the request

http://sharepointinfoit.wordpress.com/2011/12/27/the-sandboxed-code-execution-request-was-refused-because-the-sandboxed-code-host-service-was-too-busy-to-handle-the-request/


hi there i am writing this blog in regards following error in Sharepoint 2010 SandBo,i am assuming that your Microsoft SharePoint Foundation Sandboxed Code Service is run
“The sandboxed code execution request was refused because the Sandboxed Code Host Service was too busy to handle the request”
Some developers are getting this error whenever they try to use a sandboxed solution, or sometimes when they add a sandboxed Web Part to a page, even in circumstances in which the service could not be busy. There seem to be multiple things that can cause this. The following are some solutions that have worked for me
when you try to add sandbox web-part to page it try’s to check for certificate revocations at crl.microsoft.com
so you need to make entry in C:\Windows\System32\drivers\etc host file
127.0.0.1 crl.microsoft.com
then save the file and you can either run below Script or cope this script and save it in PS1 format and run it directly on server
This Code from another site, I tried it first but it did not work
----------------------------------------------------------------------------------

$uc = [Microsoft.SharePoint.Administration.SPUserCodeService]::Local
$uc.WorkerProcessExecutionTimeout = 5000
$uc.Update()

$tier = $uc.Tiers[""]   # default Tier has no Name
$tier.MaximumWorkerProcesses = 2    # number of CPU Cores + 1
$tier.Update()
---------------------------------------------------------------


This is the script:

Write-Host -ForegroundColor White “Getting ‘Sandboxed Code Service’ instance on current server…”
$srvInstance = Get-SPServiceInstance -Server $env:ComputerName | where {$_.TypeName -eq “Microsoft SharePoint Foundation Sandboxed Code Service”}
Write-Host -ForegroundColor White “Getting SID of process identity that runs Sandbox service instance…”
$sid = $srvInstance.Service.ProcessIdentity.CurrentSecurityIdentifier.Value
$path = “Registry::HKEY_USERS\$sid\SOFTWARE\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing”
$key = “State”
$oldValue = (Get-ItemProperty -path $path).$key
$newvalue = 0x00023e00
$hexOldValue = “{0:x}” -f $oldValue
$hexNewValue = “{0:x}” -f $newvalue
Write-Host -ForegroundColor White “Current registry value is: $hexOldValue”
If ($oldValue -eq $newvalue)
{
Write-Host -ForegroundColor White “No change is required.”
} else {
Set-ItemProperty -path $path -name $key -Type DWORD -Value $newvalue
Write-Host -ForegroundColor White “Registry value is set to: $hexNewValue”
If ($srvInstance.Service.Status -eq “Online”)
{
Write-Host -ForegroundColor White “Restarting Sandbox service…”
Restart-Service SPUserCodeV4
Write-Host -ForegroundColor White “Restarting IIS…”
iisreset -noforce
}
}

Monday, September 24, 2012

Multiple SSL Sites on a Single IIS Server Using Host Headers

http://lanestechblog.blogspot.com/2008/03/creating-self-signed-wildcard-ssl.html
 Multiple SSL Sites on a Single IIS Server Using Host Headers

Wildcard SSL certificates can allow you to publish multiple IIS web sites--all using SSL on port 443--that are accessible by host headers. That is, if you're running on IIS 6 or above.
 So you read about these things, wildcard certificates, but mostly you read about how to buy them. It is possible (and easy) to create one for yourself, however, so long as you don't mind it not being trusted by folks' browsers. There are some really good uses for these, not least in a test environment in which you don't care about the trust. 
Production environments need them, too, sometimes, such as when you're using a network appliance like a Netscaler or F5 load balancer. Those devices allow you to point multiple URLs (cnames, really) to a single (or multiple) server(s). Very handy.
In our case, we have several web sites that we'd like to secure using SSL. Problem is: they're all on a single server. There are several options for dealing with such a case: assign multiple IP addresses to the server, use different SSL ports for each IIS site, or (definitely the coolest option) use a wildcard certificate on the server to allow IIS to decipher the http host header. This option, by the way, is a new feature with IIS 6, so if there's anyone out there still using IIS v5, this is another reason to upgrade.

Background
A little background on the problem might be in order: a SSL certificate is used to encrypt the http data. Normally, in setting up a IIS web site, we differentiate that site from all the others by assigning unique host headers to each site. IIS can use those host headers to determine to which site to route any given http request.
When the site is using ssl, however, the host header is encrypted, which introduces something of a chicken-and-egg thing: since the host header (along with all the rest of the data) is encrypted, IIS can't use that to determine which site to send the request to. And, since a SSL certificate is site-specific, IIS can't use a certificate to decrypt the data until it knows which site the request belongs to.
Thus, it widely is reported that it isn't possible to have multiple SSL sites on a single server, all sharing the same port. Enter wildcard SSL certificates and secure server bindings.
The wildcard certificate allows IIS to use the same certificate for all of the sites on a particular port. That takes away the requirement that IIS know which site's certificate to use in decrypting the data.
Secure server bindings help IIS in securing the wildcard certificate, a requirement for setting this up.
Note that a similar solution is available to apache. You can read about it here.
Thus, it is very possible to have multiple SSL sites on a single server, all sharing the same port.

Configure your sites to use host headers
Host headers are the backbone of this. Open the properties window for each site in IIS and click the advanced button. There, you can add the appropriate host header on port 80.

Creating a self-signed wildcard SSL certificate
The next step in this process is to make sure that all of the relevant sites have the same SSL port assigned to them.
In IIS, go to each site's properties and enter the appropriate port number (the same one for each site) in the SSL Port field. 443 is the default SSL port.
Note that once you do this, all but one of the affected sites will stop. That is because, at this point, IIS isn't configured to allow multiple sites to share the same SSL port. 
That's OK; we'll take care of that in a moment. 

Now, to generate the certificate: using SelfSSL, generate the certificate for one existing IIS site.
SelfSSL is a tool that's a part of the Microsoft IIS Resource kit.
If you haven't downloaded and installed it, you'll need to do that first.

Here's the syntax:
selfssl /n:cn=*.server.edu /s:1 /P:443 /v:3650
Where *.server.edu would be your own URL. So if you had these sites: 
mysite.sharepoint.com 
portal.sharepoint.com 
auth.sharepoint.com 
you'd use this code:
selfssl /n:cn=*.sharepoint.com /s:1 /P:443 /v:3650
It's the * that makes it a wildcard certificate. 
The /s:1 is the site identification. There are a variety of ways to view a site's identifier, but the easiest simply is to open the IIS manager and click on the "web sites" tree on the left. The right-hand pane will show the description and identifier. The default site has an identifier of 1; the other sites have very long identifiers. 
/P: is the SSL port you're using, and /V: is the number of days for which this cert is valid. Why would you want it to expire, anyway? 
 Now you've generated a wildcard certificate. 

Assign the Certificate to your sites 
 The easiest way to assign a certificate to a site, having already created it, is to view the site properties in IIS Manager. 
Click on Directory Security, and then on the Server Certificate button. This will start the wonderful wizard of IIS. You already have created a certificate, so when the wizard prompts you, choose "Assign an existing certificate." When you click next, you'll see a list of available certs, including the wildcard certificate you created. 
Select this certificate, click next, and make sure you assign it the same port that was assigned to the first site.  
That's it: once the wizard has finished its magic, you've assigned the cert to your site. Repeat this for all of the sites you want to secure on this port with SSL. 
Configure Secure Server Bindings 
 This is the final step. It involves running a vbs script to set up secure bindings, which allows IIS to use host headers with SSL and secure the new wildcard certificate you created and installed. 
 The syntax is like this:
cscript adsutil.vbs set /w3svc/844934796/SecureBindings ":443:mysite.sharepoint.com"
The adsutil.vbs script, at least on my systems, is at C:\Inetpub\AdminScripts. You'll need to run the script command from that location. 
 The syntax breaks down like this: 
844934796 is the site ID. Substitute your own site identifier there. 
443, again, is the port 
mysite.sharepoint.com is the host header for the site. 
Make sure that you have this host header configured in the site properties in IIS, as well. 
Run this script for each of your IIS sites. That should be all you need to do. 
Start up the stopped sites after you've run cscript, and you should be good to go. 
 Microsoft has a few documents that run through this, but they don't really put the pieces together for you. Here they are: Configure SSL Host Headers (IIS 6.0) Configuring Server Bindings for SSL Host Headers (IIS 6.0) Obtaining and Installing a Wildcard Server Certificate 
 By the way: if you've done a lot of testing, and you've generated a bunch of certificates you're no longer using, you can delete them. Run mmc.exe and add the certificates snap-in. You'll want to choose the "local computer" version. Using that, you can manage all of your local certificates, including deleting the ones you no longer need.

Monday, September 10, 2012

How to install and configure Adobe PDF iFilter 9 for SharePoint 2010

http://support.microsoft.com/kb/2293357
To install and configure Adobe PDF iFilter 9 in SharePoint Server 2010 and SharePoint Foundation 2010, follow these steps:
  1. Install Windows Server and SharePoint. This step includes the following tasks:
    • Install Windows Server 2008.
    • Install the SharePoint prerequisites. To do this, run the Microsoft SharePoint Products Preparation tool.
    • Install SharePoint 2010 and run the SharePoint Products Configuration Wizard.
    • Configure a server farm topology. For example, configure a Single Server Farm.
    • Create and configure a new Search Service application.
  2. Download and install Adobe PDF iFilter 9. For more information about how to download PDF iFilter 9, see Adobe PDF iFilter 9 on the Adobe Downloads website.
  3. Download the Adobe PDF file icon. For more information, see Use of Adobe icons and web logos on the Adobe website.

    Note Save the Adobe PDF file icon to the following file location:

    \Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\IMAGES\
  4. Add the mapping entry to the docIcon.xml file. To do this, follow these steps:
    1. Open the docIcon.xml file in Notepad.

      Note The docIcon.xml file is located in the \Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\XML folder.
    2. Type the following entry in the docIcon.xml file:

      <Mapping Key="pdf" Value="pdf16.gif" />
    3. Click Save.
    4. Exit Notepad.
  5. Add the .pdf file type to the SharePoint content index.
  6. Click Start, type regedit in the Search programs and files box, and then press Enter.
  7. Locate the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Setup\ContentIndexCommon\Filters\Extension
  8. Right-click Extension, click New, and then click Key.
  9. Type .pdf, and then press Enter.
  10. Click .pdf, right-click (Default), and then click Modify.
  11. Type the following GUID in the Value data box:

    {E8978DA6-047F-4E3D-9C78-CDBE46041603}
  12. Exit Registry Editor.
  13. Restart the SharePoint Search Service.
  14. Restart all the SharePoint servers in the server farm.

Sunday, August 26, 2012

Code Block are not allowed in this file


http://svengillis.blogspot.com/2008/03/code-block-are-not-allowed-in-this-file.html
Code Block are not allowed in this file
If you want to add some inline code in a masterpage or pagelayout file... you probably get the following error message:
An error occurred during the processing of blabla.aspx. Code blocks are not allowed in this file.
To get this working you need to modify the web.config of your web application. For instance, if you want to allow server side script on pages from the masterpage & pagelayout gallery you have to modify the PageParserPaths into:

<.pageparserpaths>
<.pageparserpath virtualpath="/_catalogs/masterpage/*" compilationmode="Always" allowserversidescript="true" includesubfolders="true".>
<./pageparserpaths>

Sunday, June 17, 2012

Enabling or Disabling Claims Based Authentication


Enabling or Disabling Claims Based Authentication

Author: Luis Kerr
Claims Based Authentication is becoming so popular these days and enabling a SharePoint site to authenticate users no matter what authentication system is involved just got easier. I will not digress on Claims Based Authentication, not the point of this article, but I will focus on how to enable or disable CBA using PowerShell since there is no GUI available for this trick.
First, make sure your site (web application) does not have the CBA enabled. Go to Central Administration >> Manage web applications and click on the site you’re planning to enable CBA. Under Web Applications tab click on the Authentication Providers icon and a small window will pop-up. Under Default you should see Windows.
Claims Based Authentication
Claims Based Authentication
Next, create a PowerShell (.ps1) file using Notepad and paste the following code into it:
$setcba = Get-SPWebApplication "http://YourSiteURL"
$setcba.UseClaimsAuthentication = 1;
$setcba.Update()
Give it a name, like SetCB.ps1 and save in under C: on your SharePoint 2010 server.
Claims Based Authentication
Open SharePoint 2010 Management Shell, make sure you’re under C: (use CD.. to move under C:)and type or Copy and right-click Paste this command./SetCB.ps1
Claims Based Authentication
Hit Enter and after few seconds your SharePoint site should have Claims Based Authentication enabled.
Repeat the previous steps to check if your site has CBA enabled, Central Administration >> Manage web applications and click on the site, click on the Authentication Providers icon and under Default you should see now Claims Based Authentication.
Claims Based Authentication
To revert back to Classic mode authentication (disabled Claims Based Authentication) just change the 1 to a 0:
$setcba = Get-SPWebApplication "http://YourSiteURL"
$setcba.UseClaimsAuthentication = 0;
$setcba.Update()

Wednesday, June 6, 2012

Search Issue in Claims Based Application

http://www.codeproject.com/Tips/95049/Search-Server-2010-and-Claims-Based-Authentication


Problem

If you install Search Server Express 2010 on a SharePoint farm that has a web application using claims based authentication, you will get access denied in Central Administration when trying to manage the search service application.

Solution

To work around this issue, the user logged in to Central Administration must be added with permissions directly on the claims based authenticated web application. This cannot be done in the central administration UI even if ntlm authentication is enabled on the web application. The claims based user is not perceived by SharePoint as the user logged on to the windows authenticated Central Administration, i.e. 'i: 0#.w|domain\user' is not the same as 'domain\user'.

Use the following powershell script to add the windows authenticated user to the web application:
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = new-Object Microsoft.SharePoint.SPSite("http://SitesCBA.domain.no")
$wa = $site.WebApplication
$user = "domain\user"
$policy = $wa.Policies.Add($user, $user)
$policy.PolicyRoleBindings.Add($wa.PolicyRoles.GetSpecialRole(
[Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullControl))
$wa.Update() 
$site.Dispose() 


Disable mobile browsers in SharePoint


  • We too encountered this problem. After a few hours of research and diving into the SharePoint assemblies with reflector I have found a way to get it to work. As in, to display the normal website on all mobile devices. This was our goal, so I didn't research options to get the mobile view to work on a public facing site.
    For this, add within the web.config file of the WebApp in the section configuration/system.web:

     <browserCaps>
      <result type="System.Web.Mobile.MobileCapabilities, System.Web.Mobile, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
      <filter>isMobileDevice=false</filter>
    </browserCaps>

    This method is officially deprecated since the .NET Framework 3.0, but works like a charm. Needless to say that one could easily wrap this in a feature event receiver to adjust the web.config files upon deployment.

Tuesday, May 29, 2012

The EXECUTE permission was denied on the object proc_EnumResourcesAtScope

http://kjellsj.blogspot.com/2011/02/help-content-cannot-be-displayed-in.html



[Alert] : SharePoint: Insufficient Permission To Connect To The SQL Database



[Alert Description] : A critical incident has occurred where services are not able to login to the database on server
Event ID: 5214
Event Description: Insufficient SQL database permissions for user 'Name: DOMAIN\Account SID: S-1-5-21-830005768-197582238-3774774025-5022 ImpersonationLevel: Impersonation' in database 'AdminContentDB' on SQL Server instance 'SQL Server'. Additional error information from SQL Server is included below.

The EXECUTE permission was denied on the object 'proc_EnumResourcesAtScope', database 'AdminContentDB', schema 'dbo'.



Solution:

After a iisreset this doesnt work anymore.

A solutions: locate the WSS_Content_Application_Pools role in the admin db database roles.

In the properties go to securables and search (add) the stored procedures proc_EnumResourcesAtScope and proc_EnumResourceValuesForAllLangs. Grant them execute permissions.

Sunday, May 13, 2012

Event 6398 and 5586 SharePoint Foundation


Problem
Event logs were getting filled with the following errors:
Event 5586, SharePoint Foundation
Unknown SQL Exception 2812 occurred. Additional error information from SQL Server is included below.
Could not find stored procedure ‘dbo.Search_GetRecentStats’.
Event 6398, SharePoint Foundation
The Execute method of job definition Microsoft.Office.Server.Search.Monitoring.HealthStatUpdateJobDefinition (ID 3ed3dbdc-bbc4-45b6-8e84-449cdd2997f4) threw an exception. More information is included below.
Could not find stored procedure ‘dbo.Search_GetRecentStats’.
Solution
I tried the following without any success (although it has worked for some).
  1. Go to Central Administration -> Manage Service Applications -> Usage and Health Data Collection Service Application -> Uncheck everything. Restart the Timer Service. Re-check everything.
  2. Recreate the Usage and Health Data Service Application. Delete the Service Application in Central Administration and re-create it using the PowerShell command: New-SPUsageApplication -name “Usage and Health Data Collection Service Application” -database server “dbserver” -databasename “dbname”.
  3. Check that the Timer Job service account has sufficient permissions to the UsageAndHealthDataCollection database.
What worked:
  1. Go to Central Administration -> Monitoring -> Review job definitions
  2. Look for the job: Search Health Monitoring – Trace Events and see when it was last run. Chances are the job is set to ‘Disabled’ and never ran.
  3. Enable the job and click on ‘Run now’.
  4. The errors should stop appearing in the event log.
Cause
The Search Health Monitoring – Trace Events jobs creates the stored procedures in the UsageAndHealthDataCollection Database needed to run the job definition Microsoft.Office.Server.Search.Monitoring.HealthStatUpdateJobDefinition job.

Tuesday, March 13, 2012

SharePoint Restore Error: Your backup is from a different version of Microsoft SharePoint Foundation and cannot be restored to a server running the current version. The backup file should be restored to a server with version '14.0.0.5050' or later.

http://ranaictiu-technicalblog.blogspot.com/2010/11/sharepoint-restore-error-your-backup-is.html
I had needed to move my dev environment from one Virtual machine to another. So I took backup from source server and tried to restore the backup in new server. However, I have got the error “Your backup is from a different version of Microsoft SharePoint Foundation and cannot be restored to a server running the current version. The backup file should be restored to a server with version '14.0.0.5050' or later.” I was totally confused as I had the same version of SharePoint in both server. Then I double checked the version and it was 14.0.4762.1000 for both servers.
Getting confused I googled and found that solution. This is a bug which is fixed by SharePoint 2010 August cumulative update. The updates are available in the following link:

SharePoint Configuration Wizard errors

http://support.microsoft.com/kb/944267

After you install one of the following updates or service packs on a computer that is running Windows SharePoint Services 3.0 or SharePoint Server 2007, you may have to rerun the SharePoint Products and Technologies Configuration Wizard (Psconfig.exe):
  • Windows SharePoint Services 3.0 software update
  • Windows SharePoint Services 3.0 service pack
  • SharePoint Server 2007 software update
  • SharePoint Server 2007 service pack
If the SharePoint Products and Technologies Configuration Wizard detects a problem, the wizard does not finish. Also, users who try to visit the SharePoint Web site may receive "404" errors. These errors occur until the wizard has finished successfully.

To troubleshoot this problem, obtain the following SharePoint log files:
  • PSCDiagnostics_Datecode.log
    By default, this file is located in the "Program Files\Common Files\Microsoft Shared\Web server extensions\12\LOGS" folder.
  • Upgrade.log
    By default, this file is located in the "Program Files\Common Files\Microsoft Shared\Web server extensions\12\LOGS" folder.

How to identify and resolve the problem

This section lists various problems that may be detected by the SharePoint Products and Technologies Configuration Wizard. Symptoms are listed for each problem to help you identify it.

The Web.config file is read-only

Symptoms
If the Web.config file is read-only, the Upgrade.log file will contain an error message that resembles the following:
[IisWebSiteSequence] [ERROR] [10/17/2007 11:38:22 AM]: Access to the path 'C:\Inetpub\wwwroot\wss\VirtualDirectories\5003\web.config' is denied.
Cause
This problem occurs when the Web.config file has been configured as read-only. This problem may also occur when a custom management program or a virus scan program locks the Web.config file.
Resolution
Make sure that everyone has write access to this file before you run the SharePoint Products and Technologies Configuration Wizard. Also make sure that the read-only check box is not enabled in the Web.config file properties dialog box and that no other process locks the Web.config file.

ASP.NET is registered incorrectly in the Internet Information Services (IIS) metabase

Symptoms
If ASP.NET is registered incorrectly in the IIS metabase, the Upgrade.log file will contain an error message that resembles the following:
[SPIisWebSiteWssSequence] [ERROR] [10/10/2007 10:21:25 AM]: Action 3.0.3.0 of Microsoft.SharePoint.Upgrade.SPIisWebSiteWssSequence failed. [SPIisWebSiteWssSequence] [ERROR] [10/10/2007 10:21:25 AM]: InstallAspNet 566609673 failed. [SPIisWebSiteWssSequence] [ERROR] [10/10/2007 10:21:25 AM]: at Microsoft.SharePoint.Upgrade.EnsureAspNetScriptMapInstalled.Upgrade() at Microsoft.SharePoint.Upgrade.SPActionSequence.Upgrade()

In this case, the number between "InstallAspNet" and "failed" in this message is the ID of the affected IIS Web site.
Cause
This problem occurs because ASP.NET is registered incorrectly in the IIS metabase.
Resolution
To resolve this problem, follow these steps:
  1. Click Start, click Run, type cmd, and then click OK.
  2. At the command prompt, move to the following folder:
    %windir%\Microsoft.net\framework\v2.0.50727
  3. At the command prompt, type the following command, and then press ENTER:
    aspnet_regiis.exe –s W3SVC/number/ROOT
    Note number is the ID of the affected IIS Web site.
A second cause can be a timing issue in the Windows SharePoint Administration service. To address this cause, set the following registry subkey:
Software\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS\SPAdmin
DWORD value: SleepOnStart set to 20000 decimal

The Web Service Instance has not provisioned successfully

Symptoms
The following error message is logged in the Application log on the computer that is running Windows SharePoint Services 3.0 or SharePoint Server 2007:
Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Topology
Event ID: 6800 Date: 10/17/2007
Time: 8:09:40 PM
User: N/A
Computer: ComputerName
Description: The database WSS_Content on ComputerName\Microsoft##SSEE is not accessible to missing Windows Internal Database signatures.

Also, the Upgrade.log file contains the following error message:
[SPServerSequence] [DEBUG] [10/22/2007 7:44:21 AM]: Web service Instance SPWebServiceInstance Parent=SPServer Name=ComputerName not added. Status = Provisioning
Cause
This problem occurs when the initial provisioning of the Web service instance has not completed successfully. This behavior causes the upgrade process to skip the Web service instance.
Resolution
To resolve this problem, follow these steps:
  1. Click Start, click Run, type cmd, and then click OK.
  2. Locate the "Program Files\Common Files\Microsoft Shared\Web server extensions\12\BIN" folder.
  3. At the command prompt, type the following commands, and then press ENTER after each command:
    stsadm -o provisionservice -action stop -servicetype spwebservice -servicename ""
    stsadm -o provisionservice -action start -servicetype spwebservice -servicename ""
  4. After the SPWebService service is started, type the following command at the command prompt, and then press ENTER:
    psconfig -cmd upgrade -inplace b2b -wait -force

The Web.config file is missing

Symptoms
The Upgrade.log file contains an error that resembles the following:
[AssemblyReferenceFixUp] [3.0.4.0] [ERROR] [10/18/2007 11:47:40 AM]: Application Web Config for this IIS site (944564711) could not be found at \wwwroot\wss\VirtualDirectories\5003\web.config.
Cause
This behavior occurs when the Web.config file has been deleted or moved.
Resolution
To resolve this problem, make sure that the Web.config file is located in the Wwwroot\Wss\VirtualDirectories\xxxx folder before you run the SharePoint Products and Technologies Configuration Wizard.

Note xxxx represents the virtual server physical location for the SharePoint Web application. In IIS, the virtual server physical location is listed next to Local path on the Home Directory tab in the virtual server properties dialog box.

The SharePoint Products and Technologies Configuration Wizard does not finish successfully

Symptoms
You run the SharePoint Products and Technologies Configuration Wizard (PSConfigui.exe) to upgrade the databases. When you do this, the wizard does not finish successfully. Also, the following error message is logged:  
Date Time 8 ERR An exception of type Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException was thrown.
Additional exception information: An update conflict has occurred, and you must re-try this action. The object DiagnosticsService Parent=SPFarm Name=SharePoint_Config is being updated by Domain\User, in the w3wp process, on machine SERVER.
View the tracing log for more information about the conflict.
Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object DiagnosticsService Parent=SPFarm Name=SharePoint_Config is being updated by Domain\User, in the w3wp process, on machine SERVER.
View the tracing log for more information about the conflict.

This message is logged in the following log file:
Drive:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS\PSCDiagnostics_Datecode
Cause
This issue occurs because a lock exists on the SPFarm object. Therefore, the SharePoint Products and Technologies Configuration Wizard cannot update the databases.
Resolution
To resolve this issue, clear the Windows SharePoint Services configuration cache.

For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
939308  (http://support.microsoft.com/kb/939308/ ) Error message when you try to modify or to delete an alternate access mapping in Windows SharePoint Services 3.0: "An update conflict has occurred, and you must re-try this action"

You cannot browse a Central Administration or SharePoint website, and you receive a "Server Error" error message

Symptoms
When you try to browse a Central Administration website or a SharePoint website, you may receive the following error message:
Server Error: http://go.microsoft.com/fwlink?LinkID=96177 (http://go.microsoft.com/fwlink?LinkID=96177)

Or, the following message is logged in the Application log:
Event Type: Error
Event Source: Windows SharePoint Server
Event Category: Topology
Event lD: 5617
Description:
The schema version (3.x.x.x) of the database SharePoint_AdminContent_123fda45-f456-fad5-de45-7891d2asd455 on ComputerName is not consistent with the expected database schema version (3.x.x.x) on ComputerName. Connections to this database From this server have been blocked to avoid data loss. Upgrade the web Front end or the content database to ensure that these versions match.
Cause
This problem may occur when an upgrade fails to install either manually or through Windows Update. The installation failure puts the farm into an inconsistent state that must be resolved by a successful upgrade operation.
Resolution
To resolve this problem, follow these steps to run the upgrade:
  1. Click Start, click Run, type cmd, and then click OK.
  2. Locate the following folder:
    "%COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\BIN"
  3. Open a Command Prompt window.
  4. At the command prompt, type the following command, and then press ENTER:
    psconfig -cmd upgrade -inplace b2b -wait -force
After upgrade finishes, make sure that the upgrade was successful.

You cannot browse a Central Administration or SharePoint website, and you receive a "HTTP 404 Not Found" error message

Symptoms
When you try to browse a Central Administration website or a SharePoint website, you may receive the following error message:
HTTP 404 Not Found
Or, the following message is logged in the Application log:
Event Type: Error Event
Source: Windows SharePoint Services 3
Event Category: Topology
Event ID: 6800
Description: The database WSS_Content on ComputerName \Microsoft##SSEE is not accessible to missing Windows Internal Database signatures.
Cause
This problem may occur when you install a patch manually or through Windows Update. If another service has connected to the Windows Internal Database prior to the upgrade, SharePoint cannot make a connection, and the upgrade fails. This puts the farm into an inconsistent state that must be resolved by a successful upgrade operation.
Resolution
To resolve this problem, follow these steps to restart the SharePoint services and to complete upgrade:
  1. Click Start, click Run, type cmd, and then click OK.
  2. Locate the following folder:
    %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\BIN
  3. At a command prompt, type the following command, and then press ENTER:
    psconfig -cmd upgrade -inplace b2b -wait –force
  4. If the upgrade does not complete succussfully, type the following commands at the command prompt, and press ENTER after each command:
    net stop MSSQL$MICROSOFT##SSEE
    net start MSSQL$MICROSOFT##SSEE
    psconfig -cmd upgrade -inplace b2b -wait -force

You cannot browse a Central Administration or SharePoint website, and you receive a "Cannot connect to the configuration database" error message

Symptoms
When you try to browse a Central Administration or SharePoint website, the following error message is logged in the Upgrade.log file on the computer that ran the upgrade for Windows SharePoint Services 3.0 or SharePoint Server 2007 by using the Windows Internal Database:
[SPManager] [ERROR] [6/14/2010 12:00:00 PM]: Upgrade [SPContentDatabase Name=ShareWebDb Parent=SPDatabaseServiceInstance Name=Microsoft##SSEE] failed. [SPManager] [ERROR] [6/14/2010 12:00:00 PM]: Database 'ShareWebDb' is already open and can only have one user at a time. [SPManager] [ERROR] [6/14/2010 12:00:00 PM]: at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj) at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async) at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe) at System.Data.SqlClient.SqlCommand.ExecuteNonQuery() at Microsoft.SharePoint.Utilities.SqlSession.ExecuteScript(TextReader textReader, Int32 commandTimeout) at Microsoft.SharePoint.Utilities.SqlSession.ExecuteScript(String path, Int32 commandTimeout) at Microsoft.SharePoint.Upgrade.SPUtility.ExecuteSqlFile(SqlSession sqlSession, ISqlSession isqlSession, SqlFile sqlFileId, Int32 timeOut) at Microsoft.SharePoint.Upgrade.SPUtility.ExecuteSqlFile(SqlSession sqlSession, SqlFile sqlFileId, Int32 timeOut) at Microsoft.SharePoint.Upgrade.SPContentDatabaseSequence.Upgrade() at Microsoft.SharePoint.Upgrade.SPManager.Upgrade(Object o, Boolean bRecurse)

Also, the following error message is logged in the psconfig.log file:
06/14/2010 12:00:00 1 ERR Failed to upgrade SharePoint Products and Technologies. Failed to upgrade SharePoint Products and Technologies. Further information regarding this failure can be found at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\Upgrade.log. An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException was thrown. Additional exception information: The upgrade command is invalid or a failure has been encountered. Failed to upgrade SharePoint Products and Technologies. Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException: Exception of type 'Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException' was thrown. at Microsoft.SharePoint.PostSetupConfiguration.UpgradeTask.Run() at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()

Also, the following error message may be logged in the Application log:
Event Type: Error
Event Source: Windows SharePoint Services 3
Event ID: 3760 Event Category: Database
Description: SQL Database 'SharePoint_Config_' on SQL Server instance 'ComputeName\Microsoft##SSEE' not found. Additional error information from SQL Server is included below. Cannot open database "SharePoint_Config_" requested by the login. The login failed.
Also, the following error message may be logged in Microsoft SQL Server Management Studio Express:
Cannot show requested dialog.
ADDITIONAL INFORMATION: Cannot show requested dialog. (Microsoft.SqlServer.Express.SqlMgmt)
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.Express.ConnectionInfo)
Database 'SharePoint_Config_' is already open and can only have one user at a time. (Microsoft SQL Server, Error: 924)

Cannot connect to the configuration database.
The database SharePoint_Config_ is not accessible. (Microsoft.SqlServer.Express.ObjectExplorer)
Cause
This problem may occur when you install an update manually or through Windows Update. If another service has connected to the Windows Internal Database prior to the upgrade, SharePoint cannot make a connection, and the upgrade fails. This puts the farm into an inconsistent state that must be resolved by a successful upgrade operation.
Resolution
To resolve this problem, follow these steps to restart the SharePoint services and to complete upgrade:
  1. Click Start, click Run, type cmd, and then click OK.
  2. Locate the following folder:
    %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\BIN
  3. At a command prompt, type the following command, and then press ENTER:
    psconfig -cmd upgrade -inplace b2b -wait –force
  4. If the upgrade does not complete succussfully, type the following commands at the command prompt, and press ENTER after each command:
    net stop MSSQL$MICROSOFT##SSEE
    net start MSSQL$MICROSOFT##SSEE
    psconfig -cmd upgrade -inplace b2b -wait -force

You are prompted for authentication on a SharePoint website

Symptoms
When you try to browse a SharePoint website, you are prompted for authentication.
Cause
Windows Server 2003 SP1 and Windows Server 2008 include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.
Resolution
  1. Workaround


    There are two methods to work around this issue, use one of the following methods, as appropriate for your situation.



    Method 1: Specify host names (Preferred method if NTLM authentication is desired)

    To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

    1.     Set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:

    281308 (http://support.microsoft.com/kb/281308/)   (http://support.microsoft.com/kb/281308/ (http://support.microsoft.com/kb/281308/) ) Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name

    2.     Click Start, click Run, type regedit, and then click OK.

    3.     In Registry Editor, locate and then click the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

    4.     Right-click MSV1_0, point to New, and then click Multi-String Value.

    5.     Type BackConnectionHostNames, and then press ENTER.

    6.     Right-click BackConnectionHostNames, and then click Modify.

    7.       In the Value data box, type the host name or the host names for the sites that are on the local computer, each in a separate line, and then click OK.

    8.       Quit Registry Editor, and then restart the IISAdmin service. ()





    Method 2: Disable the loopback check (less-recommended method)

    The second method is to disable the loopback check by setting the DisableLoopbackCheck registry key.

    To set the DisableLoopbackCheck registry key, follow these steps:

    1.     Set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:

    281308 (http://support.microsoft.com/kb/281308/)   (http://support.microsoft.com/kb/281308/ (http://support.microsoft.com/kb/281308/) ) Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name

    2.     Click Start, click Run, type regedit, and then click OK.

    3.     In Registry Editor, locate and then click the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

    4.     Right-click Lsa, point to New, and then click DWORD Value.

    5.     Type DisableLoopbackCheck, and then press ENTER.

    6.     Right-click DisableLoopbackCheck, and then click Modify.

    7.     In the Value data box, type 1, and then click OK.

How to force the Windows SharePoint Services 3.0 upgrade by using the Psconfig.exe tool at a command prompt

Perform the upgrade by running the Psconfig.exe tool at a command prompt. For example, type the following command:
psconfig -cmd upgrade -inplace b2b –force

How to troubleshoot common errors that occur when you run the SharePoint Products and Technologies Configuration Wizard on a computer that is running Windows SharePoint

http://support.microsoft.com/kb/944267

To resolve this issue, clear the file system cache on all servers in the server farm on which the Windows SharePoint Services Timer service is running. To do this, follow these steps:
  1. Stop the Timer service. To do this, follow these steps:
    1. Click Start, point to Administrative Tools, and then click Services.
    2. Right-click Windows SharePoint Services Timer, and then click Stop.
    3. Close the Services console.
  2. On the computer that is running Microsoft Office SharePoint Server 2007 and on which the Central Administration site is hosted, click Start, click Run, type explorer, and then press ENTER.
  3. In Windows Explorer, locate and then double-click the following folder:
    Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\GUID
    Notes
    • The Drive placeholder specifies the letter of the drive on which Windows is installed. By default, Windows is installed on drive C.
    • The GUID placeholder specifies the GUID folder.
    • The Application Data folder may be hidden. To view the hidden folder, follow these steps:
      1. On the Tools menu, click Folder Options.
      2. Click the View tab.
      3. In the Advanced settings list, click Show hidden files and folders under Hidden files and folders, and then click OK.
    • In Windows Server 2008, the configuration cache is in the following location:
      Drive:\ProgramData\Microsoft\SharePoint\Config\GUID
  4. Back up the Cache.ini file.
  5. Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt.

    Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.
  6. Double-click the Cache.ini file.
  7. On the Edit menu, click Select All.
  8. On the Edit menu, click Delete.
  9. Type 1, and then click Save on the File menu.
  10. On the File menu, click Exit.
  11. Start the Timer service. To do this, follow these steps:
    1. Click Start, point to Administrative Tools, and then click Services.
    2. Right-click Windows SharePoint Services Timer, and then click Start.
    3. Close the Services console.
    Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.
  12.  Make sure that the Cache.ini file has been updated. For example it should no longer be 1 if the cache has been updated.
  13. Click Start, point to Programs, point to Administrative Tools, and then click SharePoint 3.0 Central Administration.
  14. Click the Operations tab, and then click Timer job status under Global Configuration.
  15. In the list of timer jobs, verify that the status of the Config Refresh entry is Succeeded.
  16. On the File menu, click Close.

SPUpdatedConcurrencyException While Installing SharePoint 2010 Service Pack 1

http://sajiviswam.wordpress.com/2012/03/01/spupdatedconcurrencyexception-while-installing-sharepoint-2010-service-pack-1-2/

After installing SharePoint 2010 Service Pack 1 for SharePoint Server, the SharePoint Products and Technologies Configuration Wizard (either from GUI or using PowerShell) may fail throwing the following exception.
An exception of type Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException was thrown. Additional exception information: An update conflict has occurred, and you must re-try this action. The object SPUpgradeSession Name=Upgrade -20110924-194525-15 was updated by DOMAIN\ACCOUNT, in the PSCONFIG (7240) process, on machine SERVER. View the tracing log for more information about the conflict.
Total number of configuration settings run: 3
Total number of successful configuration settings: 2
Total number of unsuccessful configuration settings: 1
Successfully stopped the configuration of SharePoint Products.
Configuration of SharePoint Products failed. Configuration must be performed before you use SharePoint Products. For further details, see the diagnostic log located at [LOCATION OF LOG] and the application event log.
This KB article describes the cause and and solution for this issue. The suggested solution is to clear Windows SharePoint Services configuration cache. Unfortunately, this may not work in most of the cases. If it doesn’t work, there is another workaround. This is by setting the ‘command-line-upgrade-running’ configuration property to ‘No’ and running Configuration Wizard again. Entire steps are given below.
  1. Open command prompt as administrator.
  2. Type in the command: stsadm -o setproperty -pn command-line-upgrade-running -pv No
  3. Restart IIS and SP Timer
  4. Run configuration wizard: psconfig -cmd upgrade -inplace b2b -wait –force

Wednesday, February 29, 2012

SharePoint 2010 – Clearing the Configuration Cache

http://blogs.msdn.com/b/jamesway/archive/2011/05/23/sharepoint-2010-clearing-the-configuration-cache.aspx
There were many common issues that could occur in WSS v3 and MOSS that would require you to clear the configuration cache on your servers. While less common, these issues can still turn up occasionally on SharePoint Server 2010 (And Foundation). While the resolution for these issues might be the same, the steps are a bit different. The main thing to note is that the Configuration Cache is located in a different directory on Windows Server 2008 then it was in Windows Server 2003. The new path for the Configuration Cache under Windows Server 2008 is: %SystemDrive%\ProgramData\Microsoft\SharePoint\Config\<GUID> The overall steps remain largely the same:
  1. Stop the Timer service. To do this, follow these steps:
    1. Click Start, point to Administrative Tools, and then click Services.
    2. Right-click SharePoint 2010 Timer, and then click Stop.
    3. Close the Services console.
  2. On the computer that is running Microsoft SharePoint Server 2010 and on which the Central Administration site is hosted, click Start, click Run, type explorer, and then press ENTER.
  3. In Windows Explorer, locate and then double-click the following folder:
  4. %SystemDrive%\ProgramData\Microsoft\SharePoint\Config\GUID
  5. Notes
    1. The %SystemDrive% system variable specifies the letter of the drive on which Windows is installed. By default, Windows is installed on drive C.
    2. The GUID placeholder specifies the GUID folder. There may be more than one of these.
    3. The ProgramData folder may be hidden. To view the hidden folder, follow these steps:
      1. On the Tools menu, click Folder Options.
      2. Click the View tab.
      3. In the Advanced settings list, click Show hidden files and folders under Hidden files and folders, and then click OK.
      4. You can also simply type this directly in the path if you do not want to show hidden files and folders.
  6. Back up the Cache.ini file. (Make a copy of it. DO NOT DELETE THIS FILE, Only the XML files in the next step)
  7. Delete all the XML configuration files in the GUID folder (DO NOTE DELETE THE FOLDER). Do this so that you can verify that the GUID folders content is replaced by new XML configuration files when the cache is rebuilt.
    Note When you empty the configuration cache in the GUID folder, make sure that you do NOT delete the GUID folder and the Cache.ini file that is located in the GUID folder.
  8. Double-click the Cache.ini file.
  9. On the Edit menu, click Select All.
  10. On the Edit menu, click Delete.
  11. Type 1, and then click Save on the File menu. (Basically when you are done, the only text in the config.ini file should be the number 1)
  12. On the File menu, click Exit.
  13. Start the Timer service. To do this, follow these steps:
    1. Click Start, point to Administrative Tools, and then click Services.
    2. Right-click SharePoint 2010 Timer, and then click Start.
    3. Close the Services console.
  14. Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.
  15. Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.
  16. Check in the GUID folder to make sure that the xml files are repopulating. This may take a bit of time.
For the original steps for clearing out the configuration cache in SharePoint 2007, there are many articles that cover the steps, one of them is the following: http://support.microsoft.com/kb/939308

Sharepoint diagnostic studio (SPDIAG) performance counters have not been provisioned

The error seen as some of the counters  used to create these reports are not added to the  SP Diagnostic Performance  counters .  Below are the steps that fixed the issue in my environment .

1. From the SharePoint Manage shell  run the following commands to add missing SQL counters

Add-SPDiagnosticsPerformanceCounter –category SQLServer:Locks –counter "Average Wait Time (ms)" –allinstances -databaseserver
Add-SPDiagnosticsPerformanceCounter –category LogicalDisk –counter "Disk Reads/sec" –allinstance -databaseserver
Add-SPDiagnosticsPerformanceCounter –category LogicalDisk –counter "Disk Writes/sec" –allinstance –databaseserver

2.  Run the following command to ensure the new counters added are visible in the list , You should get response as below

Get-SPDiagnosticsPerformanceCounter | where  {$_.providername -eq "job-diagnostics-performance-counter-sql-provider"}| FL

InstanceNames               : {_Total}
MonitorAllInstances         : False
CategoryName                : Processor
CounterNames                : {% Processor Time}
LocalizedCategoryName       : Processor
ProviderName                : job-diagnostics-performance-counter-sql-provider
UpgradedPersistedProperties : {}

InstanceNames               :
MonitorAllInstances         : False
CategoryName                : Memory
CounterNames                : {Available Mbytes}
LocalizedCategoryName       : Memory
ProviderName                : job-diagnostics-performance-counter-sql-provider
UpgradedPersistedProperties : {}

InstanceNames               : {*}
MonitorAllInstances         : True
CategoryName                : LogicalDisk
CounterNames                : {Avg. Disk Queue Length, Avg. Disk sec/Transfer,
                              Disk Reads/sec, Disk Writes/sec}
LocalizedCategoryName       : LogicalDisk
ProviderName                : job-diagnostics-performance-counter-sql-provider
UpgradedPersistedProperties : {}

InstanceNames               : {*}
MonitorAllInstances         : True
CategoryName                : SQLServer:Locks
CounterNames                : {Average Wait Time (ms)}
LocalizedCategoryName       : SQLServer:Locks
ProviderName                : job-diagnostics-performance-counter-sql-provider
UpgradedPersistedProperties : {}

InstanceNames               : {}
MonitorAllInstances         : False
CategoryName                : SQLServer:Latches
CounterNames                : {Average Latch Wait Time (ms)}
LocalizedCategoryName       : SQLServer:Latches
ProviderName                : job-diagnostics-performance-counter-sql-provider
UpgradedPersistedProperties : {}


3. Restart the Timer service on  the WFE used to run SPDIAG .

4.  Launch the SQL Diagnostic Studio again , Click on New project & create the project with same name again .  This removes the old project & all the provider configurations are  re-initialized .

5.  The “SQL overview Report” should now work  without throwing any errors .
Thanks!!

Regards,
Manas Biswas
Microsoft Online Community Support


Please remember to click 'Mark as Answer' on the post that helps you or click 'Unmark as Answer' if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Tuesday, February 28, 2012

Troubleshooting SharePoint user profile service – Replicate Directory Changes

http://sriramkunapuli.com/2012/01/04/troubleshooting-sharepoint-user-profile-service-replicate-directory-changes/

I am actually trouble shooting one of the SharePoint 2010 newly setup Service Farm which is causing issues during Replicating the user profile from Active directory.
One simple step that the Administrator of the Farm who installed it forgot was, giving the “Replicate Directory Changes” permission to the user account which is configured as the administrative account for the User Profile Service Application. In order to make the Fore Front Identity Manager properly do it’s job of replicating the content this permission has to be given to the account which is the administrative account that does the replication BETWEEN the active directory and SharePoint.
Login to the Active Directory Server (i am assuming Windows 2008 R2) and perform the following steps to give the permissions.
1) Launch “Active Directory Users and Computers”
2) Right click on the domain which needs to be replicated and click on properties.
3) Click on “Delegate Control”, Add the User Profile administrative account user and click on next.
4) Make sure ”This folder, existing objects in the folder and Creation of new objects in the folder” radio button is selected and click on Next
5) “General” checkbox is checked by default, and from the list of permissions select “Replicating Directory Changes” checkbox and click on next and finish.
This will grant the administrative account to perform the replication of the objects between Active Directory and SharePoint.