Removing Columns for Content Types

Creating a new custom content type? Have to inherit from something but you don't want to include all the fields/columns from the parent?

Simple (in most cases). Use the following powershell script to remove (note does not delete the column which doesn't belong to you to delete anyway :))

$ver = $host | select version
if ($ver.Version.Major -gt 1) {$host.Runspace.ThreadOptions = "ReuseThread"}
if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null)
{
    Add-PSSnapin "Microsoft.SharePoint.PowerShell"
}

#Attach to the web and content type
$web = Get-SPWeb http://intranet.contoso.com/
$ct = $web.ContentTypes["Content Type"]

#Insert name of column to remove from Content Type
$columnName = "Comments"

#Get link to the columnn from the web
$spFieldLink = $ct.FieldLinks[$columnName]
#Recently I tried to use this script and this line failed, I replaced it with the one above and its fine.
#$spFieldLink = New-Object Microsoft.SharePoint.SPFieldLink($web.Fields[$columnName])

#Remove the column from the content type and update
$ct.FieldLinks.Delete($spFieldLink.Id)
$ct.Update()

#Test that the column was successfully removed from the Content Type
if ($ct.Fields[$columnName])
{
    Write-Host "$columnName was not removed"
}
else
{
    Write-Host "$columnName was removed"
}

Note: Only issue I have found so far is that I still cannot remove all fields that I want removed. In my case I wanted to remove the "Comments" field from a content type but for some reason it won't remove.

EDIT: Figured out how to delete/remove the Comments field from my content type.
First make it hidden (you can do this through the UI or in a script) then the above script can be used to remove it. Weird by it works

SharePoint Permissions Tip: Leave the Style Resource Readers group alone

I've spent quite a bit of time tracking down issues that all relate to permissions for the Style Resource Readers group. My number 1 permissions tip: Don't change anything to do with this group!!!

There are several ramifications when this group's permissions change, users may start reporting that they have 'Access Denied' errors trying to edit or create pages. Or if you have a structure where you want users to only be able to access a sub site and you don't give any permissions to the Root site, then they will get 'Access Denied' everywhere.

Create / Edit publishing pages

What that meant was, because SharePoint was trying to render the masterpage and page layout on either the page they wanted to edit or a new page, it couldn't because they didn't have access to them, regardless of the fact they had access to the page library.

It's a weird error to try and track down because the user will report that they still have access to create/edit items in a list, they can still see Site Settings, they still seem to have enough privelages to do it, but get an outright 'access denied' error.

Access Denied to sub sites

I had created a group just for a sub site to have view only permissions however users were reporting that they got 'Access Denied' messages. Again it turns out that although the Style Resource Readers group existing in the Root site with all authenticated users it didn't have any permissions on the Style Library document library itself, hence why access didn't work in the sub site.
Just ensure that the Master Page Gallery (Style Library) has the Style Resource Readers group as having restricted read permission on the library.

SharePoint 2010 Web Services and Anonymous Access

Looks like SharePoint 2010 still has issues with Anonymous Access and its web services.
There are a fwe articles out there pointing at this issue in 2007 but I'm afraid its no better in 2010 (SharePoint 15?).

This article (Trinkit HQ) is short and sweet, and gets right to the point. Basically if your Web Application has Anonymous Access turned on, you will experience the 'Attempted to perform an unauthorized operation' error.

There are a few ways to deal with it, extend another web app, muck around with IIS (not recommended) but the bottom line is:
Anonymous Access = No Web Services