SharePoint: Move the “Add New” Link to the Top of the Web Part

Original Link:

So you want to "MOVE" that Add Item/Add Document Link to the top of the View because your customer is so annoyed that they have to scroll to the bottom all the time. Mike has written a brilliant script that does this for you! Now my customer is happy again.

Hey, also check out Mike's Book at Amazon.

Hope this helps some else out there like it helped me!



Update , SystemUpdate and UpdateOverwriteVersion : SPListItem

In order to update the list we can either use SPListItem.update or SPLIstItem.SystemUpdate or UpdateOverwrite version
The basic difference between these three methods is as follows

• Update the database with the fields you want to change
• Modified and Modified By fields not changed
• No new version (You can pass false to the method just to enable generating a new version)

• New Version
• Update the modified and modified by fields

• No new version.
• Updates the item without creating a new version of the item
• Update the modified time and modified by fields

“If you are stuck trying to update a field for a document library, please be aware of two things in Sharepoint 2007/WSS 3.0.

1. Even if you are NOT using Checked out/checked in, the document still has a SPCheckOutStatus.ShortTerm attached to it for a brief period of time. Trying to SPListItem.Update or SPFile.Item.Update at this point will likely tell you that the file is locked for editing. There is a .checkoutexpires property to check if you absolutely must wait for the item to be checked back in. (e.g. Are they really done with that darn thing?)

2. Even if you do NOT have versioning turned on, you are, in fact, working with a new version of the document. Use SPListItem.SystemUpdate(false) in order to bypass a short term locked document. “[1]


Original Post:

Log on as a Batch Job permissions Removed

Note: This issue is also related to -> An exception occurred when trying to issue security token: The HTTP service located at http://localhost:32843/SecurityTokenServiceApplication/securitytoken.svc/actas is too busy

Recently I had a client where their virtual environment failed due to a hardware failure. After they brought everything up and fixed the hardware issue SharePoint was not working. Specifically SharePoint Central Administration, Security Token Service App Pool, the main SharePoint web application and My Site web application would not start.

Based on numerous blog posts and my experience with IIS I started down the typical fixes:

  • Manually start the individual web application
  • Make sure the Identity on the web application was correct and the right credentials were in place
  • Even running the SharePoint Configuration Wizard to fix any issues

After each one of these I would try hitting SharePoint Central Administration and would get a Server Not Available 503 error then go back into IIS and the web application would be stopped.

I then started looking into the ULS and Event Viewer to dig a little deeper.I started to see a pattern of something did not have permissions across these multiple web applications. Finally I searched the webs on a Application Event ID error of 5059 that basically said that “Windows Process Activation Service (WAS) encountered a failure when it started a worker process to serve the application pool.” Luckily this error pointed me to the follow SharePoint Forum post that got me on the right direction.

In essence there was a specific permission needed by SharePoint to allow the Identity for the web application to work. The local security policy of “log on as a batch job” user permission needs to be in place. My theory is when the domain went down a older version of the domain policy was pushed out and removed those permissions.

I ended up going into Group Policy Management console and had to find the policy where this was set. In this case the Domain Default Policy. The Log on as a batch job setting is found in Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Log on as a batch job. Add the SP Admin accounts to the list and also add the IIS_IUSRS local Group as ith should contain the accounts for all the SP Application Pools. Afterwards I did a gpupdate /force and restarted the SharePoint server and everything was happy.

Hope this helps somebody else!

Thanks to Don Donais

Run all SharePoint 2010 Health Analyzer checks / jobs

When you install a new farm, you might be curious to find out what the Health Analyzer results are. Instead of waiting for the checks to happen (basically timer jobs scheduled at different intervals), you could force them to run all at one go, so you can review the results and address them.

You can easily run this in PowerShell. All it does is start all the timer jobs with ‘Health’ in its name. That fires off all SharePoint 2010 Health Analyzer jobs for your new farm in one go.

# Check to ensure Microsoft.SharePoint.PowerShell is loaded
$snapin = Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.SharePoint.Powershell'}
if ($snapin -eq $null) {
  Write-Host "Loading SharePoint Powershell Snapin"
  Add-PSSnapin "Microsoft.SharePoint.Powershell"
Get-SPTimerJob | Where {$_.Name -like "*Health*" -and $_.Name -like "*-all-*"} | Start-SPTimerJob

SharePoint 2010 Health Analyzer Reanalyze Now and Actions grayed out

QUESTION: I'm using the SharePoint 2010 Health Analyzer and I've noticed that on some of the issues, when I open the Review window either or both of the Actions or Reanalyze Now options are grayed out. The pop up window says I may not have the right permission level to use this, might need to select an dobject or item, or the control might now work in this context. Can anyone explain why I wouldn't be able to do a reanalyze now? It seems strange this would be grayed out at all.


Not only was the reanalyze greyed out but non of the scheduled tasks were running. I was able to trace it down to the account that was used to run "SharePoint 2010 Timer" service was not a local admin. I changed it to an account that is a domain service account that has local admin rights and had the rights outlined below:

1.Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer.

2.Click Start, click Administrative Tools, and then click Services.

3.Right-click Windows SharePoint Services Timer V4, and then click Properties.

4.On the Log On tab, confirm that the account being used is a domain user account and is a member of the following:

dbcreator fixed SQL Server server role
securityadmin fixed SQL Server server role
db_owner fixed database role for all databases in the server farm

 Here is the Microsoft link I used.

This resolved my issue. I hope this helps.

SharePoint 2010 – Database is up to date, but some sites are not completely upgraded

In Central Administration, if you visit Upgrade and Patch Management, Review Database Status and notice some DBs have the status ‘Database is up to date, but some sites are not completely upgraded.’ follow the procedure below to rectify.

If you are attempting to upgrade the Admin Content Database then Get-SPContentDatabase will not work, or at least it didn’t for me so refer to the extra steps at the end of this article.

The upgrade status reflects the current state of the database and hence this is not resolved via PSConfig but  rather by PowerShell.  If you need to perform this on a production or any other important environment, make sure you have an agreed maintenance window plus backups before beginning!

  • Using the farm account or equvilently privileged user, start the SharePoint 2010 Management Shell
  • Enter $DB = Get-SPContentDatabase -Identity [ Your Database Name]
  • Now enter Upgrade-SPContentDatabase -id $DB
  • You’ll now be prompted to confirm, just hit enter to accept the default of Yes
  • The upgrade will begin and a percentage complete will be displayed

When the process completes, return to Manage Databases Upgrade Status in Central Admin and the status will not be No action required.

Upgrading the Admin Content Database

As stated at the beginning of this article, Get-SPContentDatabase will not work with the Admin Content Database so another method needs to be found.  As long as you know the DB GUID, you can still execute Upgrade-SPContentDatabase so a simple query of the Config database could be used to find this.  However a better solution is to use Powershell.

The following script iterates though all Content DBs for a given Web Application, so can be used to upgrade the Central Admin Content Database.  You will need to the replace <WA URL> in the script with your Central Administration URL.

$wa = Get-SPWebApplication -Identity "<WA URL>"
foreach($ContentDB in $wa.ContentDatabases)
  Upgrade-SPContentDatabase -id $ContentDB

SharePoint ItemUpdated fires twice

The ItemUpdated event does fire twice - by design. Once when the item is actually updated, and then again when SharePoint is done checking in the item.
See for more info on that. 
Some people use a workaround like this:
if (properties.AfterProperties["vti_sourcecontrolcheckedoutby"] == null &&    
              properties.BeforeProperties["vti_sourcecontrolcheckedoutby"] != null)
           //This is when the update event is triggered by check-in.
          //This is triggered by events other than check-in action.

Changing the SharePoint wsp file name.

The default file name given to your solution will match the project name.  I.e. a SharePoint project SharePointProject1 will result in a package SharePointProject1.wsp.

If you want VS to spit out a different name, modify the name attribute in the Package\Package.package file for your project.

To open the file mentioned in the above post, use Notepad as Visual Studio will automatically detect the .package extension and open the associatied template file and NOT the .package file itself.

Also be sure to remove the write protection from the file otherwise Notepad cannot overwrite it.

How to hide Revert to Template Status on the SPD Customized Pages

From this link:

But if that's gone here it is:

Here is some information regarding this issue:


When a wiki page is edited by SPD2010 in advanced mode the page will display a status bar message for all users regardless of permission level.

The current page has been customized from its template.

If user has adequate permissions a link to reset the page to site definition will be displayed as well.

The current page has been customized from its template. Revert to template.

1. Since the page is being unghosted anyways, the easiest workaround, without modifying the page with additional CSS to hide the message, is to copy the content of the page into a blank aspx page and the status message will not display since a blank aspx page is not based on a site definition.

a. Open the page in SPD2010.
b. Switch to code view or split view and copy the markup.
c. Click the site pages site object.
d. Right click in some white space to bring up the context menu.
e. Select New > ASPX and this should get you a blank aspx page.
f. Go into code view on the blank aspx page and paste the content you copied in step b.
g. Save the page and set it as the new home page by right clicking on the page and picking set as home page.

2. Option 2 is: Don't unghost the page.

3. Another option is to create a blank web part page and set it as the home page. This can be made easier by disabling the site feature called Wiki Page Home Page and will more in tune with what users are accustomed to from the 2007 days.

This site feature is on by default when an enterprise wiki is used to create a site or a 2010 team site.

Wiki Page Home Page
This site feature will create a wiki page and set it as your site home page.

4. You can use the CSS to hide the div that contains the status bar but this might block status bar messages you may want to see.

Depending on your upgrade scenario some customer's have reported that the default.aspx page found in a team site is not used after an upgrade.

I could not reproduce this but the page should reside in the root of the site and can always bet set back to the home page if this scenario does occur.

During my testing I tested the following scenarios:

1. Unghosted default.aspx and visual upgrade performed from the browser. Could not reproduce the issue. Wiki feature is enabled for new page creation.
2. Ghosted default.aspx and a visual upgrade performed from the browser. Could not reproduce the issue. Wiki feature is enabled for new page creation.
3. Ghosted default.aspx page with UpdateUserExperience flag used Windows PowerShell upgrade. Couldn't reproduce issue and wiki feature was disabled.
4. Unghosted default.aspx page with UpdateUserExperience flag used during Windows PowerShell upgrade. Couldn't reproduce issue and wiki feature was disabled after upgrade.

Each time I performed the upgrade I created a new web application. I didn't test this with web application that already had an upgrade performed against it but had the content database deleted.
If you do the UpdateUserExperience flag during the Windows PowerShell command and then enable the Wiki Page Home Page site feature it will create a page in the site pages library called Home.aspx. Your upgraded default.aspx should still be around but you will have a new home page.
The new behavior that is throwing folks off is because of the SharePoint:EmbeddedFormField. This is what the editable region on a wiki page uses. It does not like JavaScript and will strip it out. This is most likely for security reasons.
Also, if you add an image with SPD 2010 to the editable region it will get removed server side by this control unless you prove a path that that adheres to its standard.
The easiest way to figure this out is edit the page in a browser and take note how the src attribute is built. It should contain a URL like this:
/sites/team site/site assets/image.jpg
If you add it with spd the src attribute will contain a value like this:
../site assets/image.jpg
The SharePoint:EmbeddedFormField does not care much for this and will remove it. Other than JavaScript I could not identify any other markup that is changed.
The idea behind this new wiki feature is to allow users to create content without needing an HTML editor like SPD. More to the point, it is a wiki page and the idea behind wiki is to allow a lot of individuals to add content without allowing for unsafe markup that could harm your users/site due to the open nature of wikis.


Insert a HTML Form web part. Replace the source code with the following:

<style type="text/css">
body #pageStatusBar{height:0px; font-size:0px; padding:0px; border-style:none;}




Open master page through SPD. Goto code view. then ctrl+F "s4-status"
then type in style:display:none
status bar will be hidden.