Category Archives: Sharepoint 2010

How to configure running PowerShell script in Windows Scheduler for non-geeks

So you have a PowerShell Script file c:\program files\my awesome scripts\script1.ps1

You want it to run every day at 7.30 am.

Open  Windows Scheduler. Create Task..

Provide typical info, good to describe your task very well, just like I did below 😉 When you run mission critical tasks, make sure to choose account that will have access to all resources, also select “Run with highest privileges” and “run when user is logged or not”

In triggers section, choose when it runs

Now is a tricky part. In Actions, youneed to Start a program, provide a path to Powershell which is

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

If your script path have spaces, add ampersand (&) and wrap with single apostrophe. It is important, if you don’t your script will not execute properly (non-geeky character of this post does not allow me to explain why)

You are done. Test run your task.

The URL is invalid. It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not in the current Web.

I did not write for a while, but it does not mean I quit SharePoint war, oh, no. I am still in first line.

Today is a good one.

When I edit page I get:

The URL 'Pages/Page.aspx' is invalid.  
It may refer to a nonexistent file or folder, 
or refer to a valid file or folder that is not in the current Web.

When i try to check out, I get same error.

Well, don’t panic ,check your ULS log.

You may find that

System.Data.SqlClient.SqlException: 
The transaction log for database 'SharePoint_Config' is full.

You look on you DB server and your disk has ZERO disk space left.

Here you go, another cause of this error (you may find more). This is probably the easiest one.

SharePoint 2010 Search is not working – no results

Scenario and investigation of the problem:

You created search service application and your search service is running correctly. Your crawl is indexing sites, you have many items in index. Your ‘All sites’ scope has many items.

Users get no results when searching for content. There is no error on a results page, just saying that there are no results. Users get correct results when searching for people.

You go to site settings >Search scopes and see that All Sites scope has ZERO items, unlike Central Administration.

You try to create a new scope to separate your site content, again, it show items in Central Admin but after scopes update, it still shows ZERO elements in site collection search scopes, scope status in READY.

There are no errors in Event Log.

There are no errors in ULS.

You try to create a new Search Service Application but you get same results.

Google has pointed me into right direction but it was really long process and many clues in between.

First important fact:

You should reconfigure your diagnostic logging to show Verbose for Search Service. you can restart SharePoint Timer Service to start a new log file

After I did that I get interesting log in ULS:

Query Processor                                 Unexpected       AuthzInitializeContextFromSid failed with 2. The querying user’s Active Directory object may be corrupted, invalid or inaccessible. Query results which require non-Claims Windows authorization will not be returned to this querying user. 

This has pointed me into the right direction to this thread

http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/2d903f8a-f74b-48e6-9b3e-b9461ae3fa5e

Also, this is really good stuff on Search service issue resolution:

http://www.cleverworkarounds.com/category/sharepoint/application-development/

And, at the very end, this is official technet KB:

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

So basically, this was fix:

1.Write and run a script:

$ssa = Get-SPEnterpriseSearchServiceApplication “<Your Search Service Application Name>”   #you find search service application name on a list of all service applications

$ssa

$ssa.SetProperty(“ForceClaimACLs“,1)

$ssa.GetProperty(“ForceClaimACLs”)

2.Run full crawl on all your data sources

3.Look at your site collection scopes – they should now have >ZERO count 🙂 – search is working and returning results (yuppie!)

4.One glitch that I noticed – now in Search service application – View scopes, they show ZERO… hmmm… no idea why, before running this script situation was opposite… but search is now finally working for all users and this is what counts!!! Client is happy!!!

Now, why would this happen to you, providing your search was working, you remember it working correctly. Well, I did not find direct reason but it this particular setup, domain controller and all users in Active Directory were maintained by other company – service provider. I am only guessing that they may have changed service account policies, domain trust levels etc. In similar scenarion, the keyword to diagnosing it is AuthzInitializeContextFromSid

“The formula contains a syntax error or is not supported” when creating a site from your custom site definition

If you get this message, it is related to one or more custom calculated fields in custom content type that you are binding to, say Page library.

<ContentTypeBinding ContentTypeId=0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900934580F187BC9D41A93CD80922ACB14D0020A6F4BF761A71479762484F9359D4CBListUrl=Pages/>

Check your field schema, it may be broken. Unfortunately, ULS logs will not give you details what field is broken, only this stacktrace

System.Runtime.InteropServices.COMException: The formula contains a syntax error or is not supported.    at Microsoft.SharePoint.Library.SPRequestInternalClass.UpdateField(String bstrUrl, String bstrListName, String bstrXML)     at Microsoft.SharePoint.Library.SPRequest.UpdateField(String bstrUrl, String bstrListName, String bstrXML)     — End of inner exception stack trace —     at Microsoft.SharePoint.SPGlobal.HandleComException(COMException comEx)     at Microsoft.SharePoint.Library.SPRequest.UpdateField(String bstrUrl, String bstrListName, String bstrXML)    

Page layout is empty after ghosting (uncustomising = reseting to definition)

Symptom:

You have a page layout deployed in a custom feature. At some time there were some SharePoint Designer modifications to it, then there was SP 2007 > 2010 migration through database attach. You want to reverse page layout to definition. You have done it and all all the sudden you have nothing on the page: no content, no webparts, nothing!

You look at page layout content and it only has this code:

<%@ Page language=”C#”   Inherits=”Microsoft.SharePoint.Publishing.PublishingLayoutPage,Microsoft.SharePoint.Publishing,Version=14.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c” %>
<%@ Register Tagprefix=”SharePointWebControls” Namespace=”Microsoft.SharePoint.WebControls” Assembly=”Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %> <%@ Register Tagprefix=”WebPartPages” Namespace=”Microsoft.SharePoint.WebPartPages” Assembly=”Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %> <%@ Register Tagprefix=”PublishingWebControls” Namespace=”Microsoft.SharePoint.Publishing.WebControls” Assembly=”Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %> <%@ Register Tagprefix=”PublishingNavigation” Namespace=”Microsoft.SharePoint.Publishing.Navigation” Assembly=”Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %>
<asp:Content ContentPlaceholderID=”PlaceHolderPageTitle” runat=”server”>
 <SharePointWebControls:FieldValue id=”PageTitle” FieldName=”Title” runat=”server”/>
</asp:Content>
<asp:Content ContentPlaceholderID=”PlaceHolderMain” runat=”server”>
</asp:Content>

Not your code! No zones, no webparts, no content controls.

I looked in SharePoint Manager 2010 and what I noticed is that vti_setuppath points to standard SharePoint resource and not my custom feature Features\MyFeature\CustomLayout.aspx  I don’t have a clue why it happened for this particular page layout. It may have something to do to the fact that layout was customised and/or it was once deployed with dreadful meta tag produced by SharePoint designer “meta:progid=”SharePoint.WebPartPage.Document”

Image

 

Anyway,

to fix the issue, what I did was:

1. Add additional File to my feature elements:

 <File  Url=”CustomLayout2.aspx”  Path=”CustomLayout.aspx” Type=”GhostableInLibrary” IgnoreIfAlreadyExists=”TRUE” >
      <Property Name=”Title” Value=”Bla bla title” />
      <Property Name=”ContentType” Value=”$Resources:cmscore,contenttype_pagelayout_name;” />
 </File> 

Note: you dont need to add phisical file to this module, you are just tell SharePoint to instantiate a file in masterpage gallery pointing to your CustomLayout.aspx

2. ReDeploy a new solution, and reactivate feature

3.Run this script, here I used help from this post: http://www.insidesharepoint.net/post/2011/06/21/How-to-fix-renamed-page-layout-features.aspx

But with some modifications. All it does is to Move good content of file 2 to corrupted file 1. So at the end of the day, CustomLayout2.aspx will not be there, only CustomLayout.aspx but with right properties and content.

function overwritePageLayout($oldFilePath, $newFilePath)
{
    $spsite = Get-SPSite -Identity $projectUrl;
    $web = $spsite.OpenWeb(“/”);

    if ([Microsoft.SharePoint.Publishing.PublishingWeb]::IsPublishingWeb($web) -eq $true)
    {
        $pubsite = new-object Microsoft.SharePoint.Publishing.PublishingSite($spsite);
        $pubweb = [Microsoft.SharePoint.Publishing.PublishingWeb]::GetPublishingWeb($web);
        $pageLayouts = $pubsite.GetPageLayouts($true);
                 
        $oldFile = $null;
        $newFile = $null;

        $nrOld = 0;
        $nrNew = 0;
        
        $pageLayouts | ForEach-Object {
            $file = $_.ListItem.File;
            if($file.Name -eq $brokenlayout)
            {
                $oldFile = $file;
                $nrOld += 1;
            }
            if($file.Name-eq $replacinglayout)
            {
                $newFile = $file;
                $nrNew += 1;
            }
        }
        if($newFile -ne $null -and $oldFile -ne $null)
        {
            Write-Host “–> Moving file” $oldFile.Properties[“vti_setuppath”]
            $newFile.MoveTo($oldFile.Url, $true);
        }
        elseif( $oldFile -ne $null -and $newFile -eq $null)
        {
            Write-Host “Could not find correct file ($nrOld invalid files found)”;
        }
        if ($nrNew -gt 1)
        {
            Write-Host “Multiple files ($nrNew) with same setuppath found”;
        }
    }
    $web.Close();
    $spsite.Close();
}

Write-Host “This script will fix broken page layout”

$projectUrl = “http://siteURL

$brokenlayout = “CustomLayout.aspx”
$replacinglayout = “CustomLayout2.aspx”

   $spsite = Get-SPSite -Identity $projectUrl;
    $web = $spsite.OpenWeb(“/”);

    if ([Microsoft.SharePoint.Publishing.PublishingWeb]::IsPublishingWeb($web) -eq $true)
    {
        $pubsite = new-object Microsoft.SharePoint.Publishing.PublishingSite($spsite);
        $pubweb = [Microsoft.SharePoint.Publishing.PublishingWeb]::GetPublishingWeb($web);
        $pageLayouts = $pubsite.GetPageLayouts($true);
         $pageLayouts | ForEach-Object {
            $file = $_.ListItem.File;
            $file.Name
        }
}

overwritePageLayout($brokenlayout , $replacinglayout)

Page layout is empty after ghosting (uncustomising = reseting to definition)

Symptom:

You have a page layout deployed in a custom feature. At some time there were some SharePoint Designer modifications to it, then there was SP 2007 > 2010 migration through database attach. You want to reverse page layout to definition. You have done it and all all the sudden you have nothing on the page: no content, no webparts, nothing!

You look at page layout content and it only has this code:

<%@ Page language=”C#”   Inherits=”Microsoft.SharePoint.Publishing.PublishingLayoutPage,Microsoft.SharePoint.Publishing,
Version=14.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c” %>
<%@ Register Tagprefix=”SharePointWebControls” Namespace=”Microsoft.SharePoint.WebControls” Assembly=”Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %> <%@ Register Tagprefix=”WebPartPages” Namespace=”Microsoft.SharePoint.WebPartPages” Assembly=”Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %> <%@ Register Tagprefix=”PublishingWebControls” Namespace=”Microsoft.SharePoint.Publishing.WebControls” Assembly=”Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %> <%@ Register Tagprefix=”PublishingNavigation” Namespace=”Microsoft.SharePoint.Publishing.Navigation” Assembly=”Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %>
<asp:Content ContentPlaceholderID=”PlaceHolderPageTitle” runat=”server”>
<SharePointWebControls:FieldValue id=”PageTitle” FieldName=”Title” runat=”server”/>
</asp:Content>
<asp:Content ContentPlaceholderID=”PlaceHolderMain” runat=”server”>
</asp:Content>

Not your code! No zones, no webparts, no content controls.

I looked in SharePoint Manager 2010 and what I noticed is that vti_setuppath points to standard SharePoint resource and not my custom feature Features\MyFeature\CustomLayout.aspx  I don’t have a clue why it happened for this particular page layout. It may have something to do to the fact that layout was customised and/or it was once deployed with dreadful meta tag produced by SharePoint designer “meta:progid=”SharePoint.WebPartPage.Document”

Image

Anyway,

to fix the issue, what I did was:

1. Add additional File to my feature elements:

<File  Url=”CustomLayout2.aspx”  Path=”CustomLayout.aspx” Type=”GhostableInLibrary” IgnoreIfAlreadyExists=”TRUE” >
<Property Name=”Title” Value=”Bla bla title” />
<Property Name=”ContentType” Value=”$Resources:cmscore,contenttype_pagelayout_name;” />
</File>

Note: you dont need to add phisical file to this module, you are just tell SharePoint to instantiate a file in masterpage gallery pointing to your CustomLayout.aspx

2. ReDeploy a new solution, and reactivate feature

3.Run this script, here I used help from this post: http://www.insidesharepoint.net/post/2011/06/21/How-to-fix-renamed-page-layout-features.aspx

But with some modifications. All it does is to Move good content of file 2 to corrupted file 1. So at the end of the day, CustomLayout2.aspx will not be there, only CustomLayout.aspx but with right properties and content.

function overwritePageLayout($oldFilePath, $newFilePath)
{
$spsite = Get-SPSite -Identity $projectUrl;
$web = $spsite.OpenWeb(“/”);

if ([Microsoft.SharePoint.Publishing.PublishingWeb]::IsPublishingWeb($web) -eq $true)
{
$pubsite = new-object Microsoft.SharePoint.Publishing.PublishingSite($spsite);
$pubweb = [Microsoft.SharePoint.Publishing.PublishingWeb]::GetPublishingWeb($web);
$pageLayouts = $pubsite.GetPageLayouts($true);

$oldFile = $null;
$newFile = $null;

$nrOld = 0;
$nrNew = 0;

$pageLayouts | ForEach-Object {
$file = $_.ListItem.File;
if($file.Name -eq $brokenlayout)
{
$oldFile = $file;
$nrOld += 1;
}
if($file.Name-eq $replacinglayout)
{
$newFile = $file;
$nrNew += 1;
}
}
if($newFile -ne $null -and $oldFile -ne $null)
{
Write-Host “–> Moving file” $oldFile.Properties[“vti_setuppath”]
$newFile.MoveTo($oldFile.Url, $true);
}
elseif( $oldFile -ne $null -and $newFile -eq $null)
{
Write-Host “Could not find correct file ($nrOld invalid files found)”;
}
if ($nrNew -gt 1)
{
Write-Host “Multiple files ($nrNew) with same setuppath found”;
}
}
$web.Close();
$spsite.Close();
}

Write-Host “This script will fix broken page layout”

$projectUrl = “http://siteURL

$brokenlayout = “CustomLayout.aspx”
$replacinglayout = “CustomLayout2.aspx”

$spsite = Get-SPSite -Identity $projectUrl;
$web = $spsite.OpenWeb(“/”);

if ([Microsoft.SharePoint.Publishing.PublishingWeb]::IsPublishingWeb($web) -eq $true)
{
$pubsite = new-object Microsoft.SharePoint.Publishing.PublishingSite($spsite);
$pubweb = [Microsoft.SharePoint.Publishing.PublishingWeb]::GetPublishingWeb($web);
$pageLayouts = $pubsite.GetPageLayouts($true);
$pageLayouts | ForEach-Object {
$file = $_.ListItem.File;
$file.Name
}
}

overwritePageLayout($brokenlayout , $replacinglayout)

Content Query webpart error after migration to SharePoint 2010

I had one webpart that displayed error after site migration to SharePoint 2010:

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.

Correlation ID:

I checked webpart properties and noticed:

  • Query was configured to take one list
  • There was grouping applied – grouped by Site

SharePoint 2007 was working fine even grouping was quite silly as all elements were coming from one site only, due to query scope.

In order to fix this problem, you need to change scope of the query to ‘site collection’ or ‘subsite’ and then filter content type or list template. Then option to group by site will be available again. If you scope it to lsit or library, ‘site’ is not available to choose.

Do not change feature Deployment Path (folder name) when upgrading working WSPsolution

Scenario:

You have SharePoint 2007 site that uses some custom build features. Features are providing some custom list templates.

You are refactoring solution for SharePoint 2010, upgrade project to Visual Studio 2010.

You upgraded the site to SharePoint 2010 and you deployed your upgraded solution.

If you didnt pay attention to detail your lists may not work anymore, returning 404 File not found error.

WHen you dig to ULS log you will find something similar:

Relying on fallback logic in VghostPageManager::getGhostDocument() for document: ‘C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\HIVE\Template\Features\FeaureName\ListTemplates\MyList\AllItems.aspx

Go to 14 hive on the server and check what is your folder name where you expect this file to reside. Maybe it is something like: SolutionName_Feature1 ?

If yes, go back to your solution and check Deployment Path for the feature. By default it will be tokenised value built dynamicly from solutionname and feature file name. You can hardcode your old feature name.

Rebuild solution and deploy new version. Your lists will come back.

Unhandled exception was thrown by the sandboxed code wrapper’s Execute method in the partial trust app domain: An unexpected error has occurred.

Let’s start from beginning:

  1. You build sandbox solution that consist of branding feature will provision masterpages to masterpage gallery and styles to style library. Easy
  2. You are deploying solution to the site. You activating solution, all fine, branding feature has been activated automatically.
  3. Some time later you are upgrading a solution because you fixed few issues.
  4. You are deactivating solution, uploading solution, then you click activate. You get: Exception from HRESULT: 0x81070966
  5. Solution seems to be activated even you got this nasty error.
  6. You go to site collection features and you realize that your branding feature is not activated.
  7. You try to activate it and you get: Unhandled exception was thrown by the sandboxed code wrapper’s Execute method in the partial trust app domain: An unexpected error has occurred.
  8. No errors in trace log

When this happens to you, check if your masterpage has not been checked out by someone else. That was true in my case, someone else was provisioning this package and because sandbox files are always checked out to the person deploying it, if one does not remember to publish them manually of through the script, you can get this nasty error.

 

 

People picker not working – it does not find any users

We have noticed a weird behavior, it is very rare scenario we ran into, silly us, it was quite hard to figure out what was going on so I thought I will share it here 🙂

Scenario: We have test SharePoint 2010 farm, all configured and working, user profile synchronization working, profiles imported, we can apply security to users on portal site, we can pick them from people picker.

We go to User profil service application and we want to change Manager for one of the profiles. We type known existing user but people picker control does not resolve the user.

Another day, we did not have troubles with this operation:

What has changed, what broke???

As it come up, we were accessing Central admin site through wrong URL!!!

Lets assume we have Central admin site on address http://servername:port/ We have created another web application for portal site and assigned hostheader to it so we will be able to access portal as http://portalname. This is test environment, so for simplicity, we edited hosts file to map this “portalname” to localhost. Without thinking, we browsed Central admin site by url: http://portalname:port. Surprisingly, it works, you can access Administration. But people picker will not work.