A PowerShell script to determine if accounts are locked

With all of the service accounts that SharePoint 2010 uses and the fact that our infrastructure people are useless, I created this little PowerShell script so I could quickly identify any issues with our service accounts:

cls

$accounts = "sps10_config,sps10_farm,sps10_services,sps10_apps,sps10_sql"

foreach ($account in $accounts.Split(",")){
Write-Host "$account - " -NoNewLine
NET USER $account /DOMAIN | FIND /I "Account active"
}

Write-Host "Press any key to continue ..."
$x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")

Clear Timer Job Cache with PowerShell!!

Here is a little script I developed to clear the SharePoint Timer Job cache which sits in the %ALLUSERSPROFILE%\Microsoft\SharePoint\Config\{guid} directory. You often need to do this when deploying sites and generally doing stuff within SharePoint to prevent random OWSTIMER issues that interfere with your junk.

I use another script that stops and restarts all SharePoint services so stopping the SharePoint Timer Job Service is not part of this script. You may want to edit this script to stop this service at the beginning and start it again at the end. It's a one-liner to do...

$timerServiceName = "SharePoint 2010 Timer";
$timerService = Get-Service -Name $timerServiceName

if ($timerService.Status -eq "Running")
{
Write-Host -ForegroundColor Red $timerServiceName "is still running";
Break
}

$configDb = Get-SPDatabase | ? {$_.TypeName -eq "Configuration Database"}
$guid = $configDb.Id

Remove-Item "$env:AllUsersProfile\Microsoft\SharePoint\Config\$guid\*.xml"
Set-Content "$env:AllUsersProfile\Microsoft\SharePoint\Config\$guid\cache.ini" "1"

Migrate User Account

I am moving users from one domain to another. I am using SPFarm.MigrateUser.

Why, oh, why did Microsoft make the SPSite.MigrateUser internal?? All the farm level migrate user does is loop through all site collections updating users at a site level, so why not allow the developer the flexibility to manage this themselves.

I have a situation where some users need to get migrated to newdomain\username and other users to a claims-based user id of i:0#.w|newdomain\username.

Using the farm level migration, the migration of users needs to be managed very carefully now otherwise windows authenticated and claims authentication user ids can get mixed up!!!

A fix for Content Type Inherits True with Pages

A few of you may have come across issues with SharePoint 2010 and the handling of Inherits="TRUE". When you inherit from the Page content type, you now get all sorts of unexpected issues. The big issue we had was when we overrode a fieldref in a child content type, (eg changing display name or whether it is required) the field was duplicated in the Pages library.

It's weird, in some respects SharePoint knew they were the same field, in other places it thought they were two different fields. eg. it displays the field twice while editing, but both fields have the same display name/required field.

So to fix the problem, when overriding a field ref in a child content type you need to add ShowInEditForm and ShowInDisplayForm to FALSE (yes in capital letters!)

eg.

<FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" DisplayName="Title" Required="TRUE" ShowInEditForm="FALSE" ShowInDisplayForm="FALSE"/>
<FieldRef ID="{9da97a8a-1da5-4a77-98d3-4bc10456e700}" Name="Comments" DisplayName="Description" Required="FALSE" ShowInEditForm="FALSE" ShowInDisplayForm="FALSE" />

Content Types in SharePoint 2010

It appears in 2010 when you have a boolean in your ContentType definition, the value MUST be in UPPERCASE.

In 2007, it respected any variation of True, true, TRUE etc. In 2010, you get no errors with having booleans in another case, it just does not work.

The object specified does not belong to a list

I started getting the "The object specified does not belong to a list" error on a SharePoint site I migrated from 2007 to 2010. The code I "inherited" worked fine in 2007 but raised an error in 2010.

After some investigation, the problem ended up being that an SPFile was constructed in a parent web instead of the web in which the actual file resided using SPWeb.GetFile(url).

So to fix the problem, make sure you construct your SPFile object (using GetFile anyway) in the SPWeb in which the file resides.

eg. if the file lives here: \ParentSite\SubSite\Pages\Page.aspx, make sure the SPWeb you are using is "Subsite".

Setting Version on Masterpage

Pretty simple one here that I had trouble finding anything while googling so I thought I'd add it. If you want to mark a masterpage (or custom action or whatever) as a v4 (SPS 2010) item while provisioning a site, you use the "UIVersion" property.

<File Url="SomeV4.master" Type="GhostableInLibrary"/>
   <Property Name="Title" Value="Some Master Page v4" />
   <Property Name="MasterPageDescription" Value="SomeMaster Page" />
   <Property Name="ContentType" Value="Publishing Master Page" />
   <Property Name="UIVersion" Value="4" />
</File>

(sorry about formatting - I don't have my nice VS add-in installed)