Original Post: http://technet.microsoft.com/en-us/library/gg251984(v=office.14).aspx

Convert SharePoint Foundation 2010 Web applications that use classic-mode authentication to use claims-based authentication

Perform the steps in the following procedure to use Windows PowerShell to convert existing Web applications to claims-based authentication.

To convert Web applications to claims-based authentication

1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

2. On the Start menu, click All Programs.

3. Click Microsoft SharePoint 2010 Products.

4. Click SharePoint 2010 Management Shell.

5. From the Windows PowerShell command prompt, type the following:

   Copy

   $WebAppName = "http:// yourWebAppUrl"
   $account = "yourDomain\yourUser"
   $wa = get-SPWebApplication $WebAppName
   
   Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default
   
   

6. At the Migration prompt, click Yes to continue.

7. From the Windows PowerShell command prompt, type the following to set the user as an administrator for the site:

   Copy

   $account = "yourDomain\yourUser"
   $account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()
   $zp = $wa.ZonePolicies("Default")
   $p = $zp.Add($account,"PSPolicy")
   $fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
   $p.PolicyRoleBindings.Add($fc)
   $wa.Update()
   
   

8. From the Windows PowerShell command prompt, type the following to configure the policy to enable the user to have full access:

   Copy

   $zp = $wa.ZonePolicies("Default")
   $p = $zp.Add($account,"PSPolicy")
   $fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
   $p.PolicyRoleBindings.Add($fc)
   $wa.Update()
   

9. From the Windows PowerShell command prompt, type the following to perform user migration:

   Copy

   $wa = get-SPWebApplication $WebAppName
   $wa.MigrateUsers($true)
   

Note:
We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

 

Additional migration guidelines

Original Link: http://techtrainingnotes.blogspot.ca/2012/01/sharepoint-move-add-new-link-to-top-of.html

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!
Dave

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

SystemUpdate()
• 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)

Update()
• New Version
• Update the modified and modified by fields

UpdateOverwriteVersion()
• 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]

Reference
1. http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.splistitem.systemupdate.aspx

Original Post: http://thesharepoint2010.wordpress.com/2012/09/26/update-systemupdate-and-updateoverwriteversion-splistitem/

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 http://talesfromitside.wordpress.com/2011/12/06/log-on-as-a-batch-job-permissions-removed/

Usually you will see this if the user does not have rights to the SharePoint config database, or if the .NET 4.X framework is not installed.

All the Best
Dave

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

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.

ANSWER:

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.

http://technet.microsoft.com/en-us/library/ee924649.aspx

This resolved my issue. I hope this helps.

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
}

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.