Recently, I’ve face this issue where user unable to schedule page publishing and got the error message.
User get following error message when schedule publishing SharePoint page.
“An error occurred trying to publish this page on the set schedule.
Republish the page with a new date or view the log if the problem continues.”
Schedule Publishing SharePoint page depends on below SharePoint Timer Job Definition:
- Scheduled Approval
- Scheduled Page Review
- Scheduled Unpublish
- Variations Propagate Page Job Definition
- Variations Propagate Site Job Definition
The problem is when you backup and restore your SharePoint web application, you end up loosing these SharePoint Timer Job Definitions.
- Check whether above SharePoint Timer Job Definitions exists in the web application.
- Check when is the Last run time for each of them to ensure they are run regularly.
1. ReActivate SharePoint Server Publishing Infrastructure from Site Settings > Site Collection Features.
2. Create new site collection using Publishing or Collaboration Portal template in the same / existing web application. This will create required SharePoint Timer Job Definitions in the web application and you could delete the site collection later.
3. If above SharePoint Timer Job Definitions created but still not running regularly, then Check your identity user account used by SharePoint Timer job. Ensure the account got dbowner access to Web Application Content Database.
I’ve recently been asked by Marketing department to loop through all sub sites and pages in our SharePoint site collection. She needs it to update the site map of our SharePoint site.
I’m thinking to utilize PowerShell to do this since its quick and easy.
## SharePoint 2007 DLL
## If you use SharePoint 2010 PowerShell, this is not required
[System.Reflection.Assembly]::Load(“Microsoft.SharePoint, Version=22.214.171.124, Culture=neutral, PublicKeyToken=71e9bce111e9429c”)
[System.Reflection.Assembly]::Load(“Microsoft.SharePoint.Portal, Version=126.96.36.199, Culture=neutral, PublicKeyToken=71e9bce111e9429c”)
$siteURL = "http://localhost/"
set-variable -option constant -name out -value "C:\temp\PrintAllSitesSubsites.csv"
$spSite = [Microsoft.SharePoint.SPSite] ($siteURL)
if($spSite -ne $null)
"Site Collection : " + $spSite.Url | Out-File $out -Append
foreach($subWeb in $spSite.AllWebs)
if($subWeb -ne $null)
#Print each Subsite
"Subsite : " + $subWeb.Name + " - " + $subWeb.Url | Out-File $out -append
$spListColl = $subweb.Lists
foreach($eachList in $spListColl)
if($eachList.Title -eq "Pages")
$PagesUrl = $subweb.Url + "/"
foreach($eachPage in $eachList.Items)
"Pages : " + $eachPage["Title"] + " - " + $PagesUrl + $eachPage.Url | Out-File $out -append
Echo $subWeb "does not exist"
Echo $siteURL "does not exist, check the site collection url"
From my previous article to build SharePoint list event receiver and custom workflow in SharePoint Designer, I start questioning myself …
Which one to use based on business requirement?
I found good msdn article to explain it in more detail, so you could read there. In summary:
- Can only be created in Microsoft Visual Studio.
- Can be executed post or prior the event.
- Support varieties different events include delete.
- Can be created in SharePoint Designer, Microsoft Office Visio and Microsoft Visual Studio.
- Can only be executed post the event.
- Support manual started, item created and item updated.
What happen if I deployed both of them?
I’ve updated the workflow and event receiver solution from my previous article to concatenate the Report Comment column and I could see Workflow run first.
Recently, I faced this issue when user open aspx page in SharePoint 2007 page library. The error message is not really helpful and if you look on SharePoint log, it also provide you with same error message “Some part of your SQL statement is nested too deeply. Rewrite the query or break it up into smaller queries”.
Further googling on the issue, I found other people faced the same issue and it feels related to mine. You could look in here. From that resources, they specified the root of the issue is Workflow History list.
“Workflow History first. The Workflow History list is a hidden list which does exactly what it says on the tin. Items are created each time a workflow runs. It turns out that items in the Workflow History list have a time-to-live and that time is 60 days. That means that any item in the list will automatically be deleted after 60 days. With roughly a 200 item limit before you hit trouble that means about 3 workflows per list item per day is your maximum.”
- Delete items in Workflow History list. You could found simple console application for this here.
- Limit document versions. I deleted old version history and only keep the last 5 major versions.