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

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.