It is useful to be able to change the Content Type for each document in a library to a new Content Type. Perhaps you are consolidating, or just moving to a new Content Type hierarchy. There are a few tricks to changing a Content Type for a document. First, you’ll need to force a check-in if a document is checked out. Next, you’ll want to reference the Content Type by ID, specifically using this method: $list.Items.GetItemById($item.ID). Any other attempt to reassign a Content Type will fail. Lastly, either do a systemupdate() or clean up after yourself by restoring the timestamp, editor, and delete interim versions. Note there needs to be sufficient metadata, or the change will result in an error and/or the document being left checked out. This function traps and reports this condition. Here’s the function we will use:

function Reset-SPFileContentType ($WebUrl, $ListName, $OldCTName, $NewCTName)
{
    #Get web, list and content type objects
    $web = Get-SPWeb $WebUrl
    $list = $web.Lists[$ListName]
    $oldCT = $list.ContentTypes[$OldCTName]
    $newCT = $list.ContentTypes[$NewCTName]
    $newCTID = $newCT.ID
    
    #Check if the values specified for the content types actually exist on the list
    if (($oldCT -ne $null) -and ($newCT -ne $null))
    {
        #Go through each item in the list
        $list.Items | ForEach-Object {
            #Check if the item content type currently equals the old content type specified
            if ($_.ContentType.Name -eq $oldCT.Name)
            {
			    $ForcedCheckin=$false;
                if ($_.File.CheckOutType -ne "None")
                {
                   try { 
                     $_.File.CheckIn(“Checked In By Administrator”);
                     
                     write-host -foregroup Yellow "Forced checkin for $($_.File.Title)"
                   }
                   catch { 
                     
                     write-host -foregroup Red "FAILED to Force checkin for $($_.File.Title)"
					 $ForcedCheckin=$false;
                   }
                }

                #Check the check out status of the file
                if ($_.File.CheckOutType -eq "None")
                {

                   $item=$_
                   [System.DateTime]$date = $item["Modified"]
                   $user = New-Object microsoft.SharePoint.SPFieldUserValue($web, $item["Editor"])

                   try { #untested try, failure could be due to inadequate required metadata
                    #Change the content type association for the item
      [Microsoft.SharePoint.SPSecurity]::RunWithElevatedPrivileges(
      {
        $item2 = $list.Items.GetItemById($item.ID);
#CHECKOUT NOT REALLY NEEDED, IF MUSTCHECKOUT IS DISABLED EARLIER
#        $item2.File.CheckOut()

#write-host $item2['Name']
Write-Host "." -NoNewline

        
        $item2["ContentTypeId"] = $newCTID
        $item2.Update()

        $item2["Modified"] = $date;
        $item2["Editor"] = $user;
        $item2.Update()

        #get rid of the last two versions now, trapping any errors 
        try { $item2.Versions[1].delete() } catch {write-host -foregroundcolor red "Error (1) could not delete old version of $($item2['Name'])"}
        try { $item2.Versions[1].delete() } catch {write-host -foregroundcolor red "Error (2) could not delete old version of $($item2['Name'])"}
		if ($ForcedCheckin)
		{try { $item2.Versions[1].delete() } catch {write-host -foregroundcolor red "Error (3) could not delete ForcedCheckin version of $($item2['Name'])"}}

#get rid of the last version now

#        $item2.File.CheckIn("Content type changed to " + $newCT.Name, 1)
     } )

    } catch { write-host -foregroundcolor red "Error (possibly inadequate metadata) updating file: $($_.Name) from $oldCT.Name to $($newCT.Name)"
              
             }

            }
                else
                {
                    write-host -foregroundcolor red "File $($_.Name) is checked out to $($_.File.CheckedOutByUser.ToString()) and cannot be modified";
                   
                }
            }
            else
            {
                 #Write-Host -ForegroundColor DarkRed "File $($_.Name) is associated with the content type $($_.ContentType.Name) and shall not be modified `n";
            }
        }
    }
    else
    {
        write-host -foregroundcolor red "One of the content types specified has not been attached to the list $($list.Title)"
        
    }

  $web.Dispose()
}

Next, let’s just call the function passing in the old name and the new name:

reset-spfilecontenttype -weburl $weburl -listname $JPlib  -oldctname "Documents" -newctname "DOCS"

Having a single content type in a library can make a library sing for end-users, by avoiding choices and prompts. However removing an existing Content Type can be a problem. Primarily, if it is still in use, SharePoint will not allow its removal with “Content Type is Still in Use”. The first thing to do is to clear the recycle bin, if feasible. Microsoft reports this isn’t necessary, but when the Content Type hits the fan, we have to try a few things.

I recently found a case where the following PowerShell still failed, when trying to delete two ways, even with enabling unsafe updates:

$web = Get-SPWeb $WebUrl
$web.set_AllowUnsafeUpdates($true)
$list = $web.Lists[$ListName]
$oldCT = $list.ContentTypes[$OldCTName]

$oldCTID = $oldCT.ID   #fails, still in use
$list.ContentTypes.Delete($oldCTID) #fails, still in use
$oldCT.delete()
$web.set_AllowUnsafeUpdates($false)
$web.Dispose()

I finally tracked it down to documents that were checked out to a user, and had never before been checked in. Without a checked in version, they weren’t visible. The trick is to take ownership of these, then change their content types. Only then can the unused Content Type be deleted.

To automate the reassignment of a Content Type, see my next blog article: Reassigning Content Types programmatically.

Hidden fields do not appear in the user interface when viewing Library settings. One reason to delete a hidden field is after a field is removed from a Content Type in a syndication hub, the field remains in the libraries associated with the original Content Type, although it is now “orphaned” and unrelated to the Content Type. The solution is to remove the field itself from each and every library. The script commands below can easily action all libraries based on an iteration through all Web Apps, Sites, Webs and Libs.

A hidden field can be deleted via PowerShell, but one should note a few obstacles to work around. First, the field needs to be unhidden, albeit temporarily. Then the field object needs to be updated. Only then can the field be deleted. Here’s how:

First, let’s get the Web, the list within it, and the target field:

$JPWeb = Get-SPWeb "http://sharepoint/div/Path/Site"
$lists = $JPWeb.lists
$list = $lists["MyList"]
$fields=$list.fields

Let’s have a peek at the friendly name and internal name of each field in the list, by piping to a select:

$fields | select title, staticname

Let’s grab the target field, and start by unhiding it, updating the field, then deleting it:

$field = $fields["FieldToDelete"]
#$field.delete() #can't delete a hidden column
$field.set_Hidden($false)
$field.Update()
$field.delete() 

The above code has a bit of a risk. External field names can change. Oddly a number of internal field names have the same external name. These are known as “Title” values in the object model. The best approach when deleting a field is to use the Static name. Here’s how:

$field = $list.Fields.GetFieldByInternalName("InternalFieldName")

Best practice is to use a try/catch, as the above function will throw an error if the field is not found.

That’s it. No further updates are necessary to the List or Web objects. If you have content types referencing this field, the local copy of the content type within the List is customized via the removal of this field.

Sometimes I get challenged with questions as to which fields are used in which Content Types.  All too often I need to know quickly know the internal name of fields used in Content Types.  I wrote a script that generates a report that you can run to generate a CSV that can easily be Pivoted in Excel for answering such questions. I’m a huge fan of using a Content Type Syndication Hub. With all the Content Types in one location, this report becomes very useful.

$rootwebname="http://SharePoint"
$rootweb=Get-SPWeb $rootwebname
$MyCTSummaryCSV="L:\CTSummary.CSV"
Add-Content  $MyCTSummaryCSV "CT Name,CT Group,Parent CT, CT Read-Only,CT Hidden,Field Internal Name,Field Title,Field Type,ShowInDisplayForm,ShowInEditForm,ShowInNewForm"

$CTs=$rootweb.contenttypes

for ($i=0; $i -lt $CTs.count; $i++)
{
	$CT=$CTs[$i];
	$CTName=$CT.Name;
	$Fields=$CT.Fields;
	for ($j=0; $j -lt $Fields.count; $j++)
	{
		$Field=$Fields[$j];
		
		$OutStr="$($CTName),$($CT.group),$($CT.Parent.Name),$($CT.ReadOnly),$($CT.Hidden),$($Field.staticname),$($Field.Title),$($Field.type),$($Field.ShowInDisplayForm),$($Field.ShowInEditForm),$($Field.ShowInNewForm)"
		Write-Host "." -NoNewline
		Add-Content  $MyCTSummaryCSV $OutStr
		#write-host "$($outstr)"
	}
}

It’s easy to then import this into an Excel file and Pivot away.

Once again I was compelled to swoop in to fix a managled set of Metadata and Content Types for a key document library.  The simplest of the challenges was removing metadata from Folders, or so I thought.  In this case, somehow, all the fields in the Document Library were associated with the Folder Content Type, so adding a new folder presented the user with roughly ten fields to complete; which were not needed.

First attempt was to hide the fields, which didn’t succeed:

$Fields=$tContentType.Fields;
$Fields[$Field].set_showinaddform($false);
$Fields[$Field].set_showineditform($false);

I then tried the old standby of  trying to remove the field, where $i is the index of the field within the Content Type:

$Fields=$tContentType.Fields;
$Fields.item($i).remove()

I then tried my usual approach to redo the FieldLinks that is the list of fields to present for forms, by removing the selected fields, to no avail:

$fieldLinks = $tContentType.FieldLinks; #simple shortcut reference $fieldList = New-Object 'System.Collections.Generic.List[System.String]' #new ordered list of fields 
# add everything to the list EXCEPT the fields to be removed
for ($i = 1; $i -le $FieldLinks.Count; $i++) {
  $FieldName=$FieldLinks[$i - 1].Name;
 If ($FieldsToEliminate -notcontains $FieldName)  #if this is a field that belongs     
   {$fieldList.Add($FieldName);
}
$FieldLinks.Reorder($fieldList.ToArray())  #convert fields to array as we trigger Reorder method on fields  
$tContentType.Update()

By this time, I was getting pretty hot under the collar, spending hours wrestling with removing a few fields from a Folder Content Type.  This simple script did the trick.  Here it is as a function.  Note how I defined the parameter types, and also take care to clear and restore the ReadOnly flag, for any Content Type that started out Read-Only:

Function Eliminate_Visible_Fields_ContentType( [Microsoft.SharePoint.SPContentType]$tContentType
                                        , [System.string]$tFields
                                        ) {
 $originallyReadonly = $tContentType.readonly;
 if ($originallyReadonly) {$tContentType.set_readonly($false)};

 $FieldsToEliminate = $tFields.Split(“,”) #convert set of fields into array
 $Fields=$tContentType.Fields;
 foreach($field in $FieldsToEliminate)     {
   $tContentType.FieldLinks.delete($field); }
 Write-Output([System.String] "Content Types stripped!")

 $tContentType.Update()
 if ($originallyReadonly) {$tContentType.set_readonly($true)};
}

A few points to note:

• The input parameter tFields is a comma separated string of field names
• The field name expected is the “Internal” field name.  That means the ugly name with the internal hex characters.  So my field “Project Num” can be deleted only by referencing “Project_x0020_Num”.
• SharePoint Manager can be used to derive the intername field names
• Referencing the RootWeb Field list can get you the internal field names programmatically
• Trying to delete the public and internal names is safe.  Best is to add them both to the list to be deleted; the correct one will be deleted.