1

I have looked up a couple of resources on changing Content Types via Powershell without much luck. It seems no matter what I run, it's not changing the content type in a way I would expect.

I got a list of the Content Types for this library that looks like this:

$site = Get-SPWeb http://site.domain/divisions/subsite/
$list = $site.Lists["Library"]
$list.ContentTypes

ID                                                                         Name
--                                                                         ----
0x0101009B1F3022B2A90E49A6CD5145086FDAEC                                   Document
0x01010007720F65506030408FC83D80894F3A1A00DB58F20FB2BAB447A51247E4B3572289 Emptoris Template
0x010104009F19CD75D7052E4493C7E57BC5A1CF9E                                 Unknown Document Type
0x010100F1586A0694934346BEFFFE9F6B8F77F300F242E8A6489E3D45915F1D1401E34581 Excel Document
0x01200040A3BEB3A63808458EC6ED84B5E81E75                                   Folder

And then I used a "where" statement to get my file:

$file = $list.items | where {$_.url -like "library name/folder name/file*"}

This returns the file I am looking for, and nothing else. So I run a foreach loop that returns information on the file, updates the content type, then returns the new information:

foreach($item in $file)
{
$item.Name
$item.ContentTypeId
$itemfile = $item.file
$itemfile.CheckOut()
$item["ContentTypeId"] = "0x010104009F19CD75D7052E4493C7E57BC5A1CF9E "
$itemfile.Update()
$itemfile.CheckIn("")
$item.Name
$item.ContentTypeId
}

This shows updates information in the PowerShell window, but it is certainly NOT what I would expect, and it does not change the Content Type on the GUI interface, regardless of what the PowerShell prompt displays. Here is an example of running this code, where I attempt to change the Content Type to Document:

foreach($item in $file)
>> {
>> $item.Name
>> $item.ContentTypeId
>> $itemfile = $item.file
>> $itemfile.CheckOut()
>> $item["ContentTypeId"] = "0x0101009B1F3022B2A90E49A6CD5145086FDAEC"
>> $itemfile.Update()
>> $itemfile.CheckIn("")
>> $item.Name
>> $item.ContentTypeId
>> }
>>
DocumentName.docx

Parent
------
0x
DocumentName.docx
0x0101

It shows updating the file. But looking on the UI side, it still shows "Emptoris Template" as the Content Type:

First Change Attempt

I can try and change this to any of the Content Types that are shown, and it "changes" in PowerShell, but never to the Content Type ID that I set it to, but instead just the "Parent" Content Type is shown. This is a standard .docx file, so the "Document" content type should definitely be able to be applied.

I'm sure it's simple, but I'm at a loss on this one.

  • Can you check if the same happens with a non-Office file, like plain .txt? I have a hunch it might do with property promotion... – Justas Černiauskas Jan 26 '16 at 15:00
  • I uploaded a txt file with only the word "text" in it. I experienced identical behavior as before. – Chris Patterson Jan 26 '16 at 18:00
  • Ok, scratch that idea then :) I've posted the answer that I'm now almost positive will help you – Justas Černiauskas Jan 27 '16 at 7:34
0

It's most likely because you are updating the $itemfile instead of $item. Try this:

foreach($item in $file)
{
$item.Name
$item.ContentTypeId
$itemfile = $item.file
$itemfile.CheckOut()
$item["ContentTypeId"] = "0101009B1F3022B2A90E49A6CD5145086FDAEC"
$item.Update()
$itemfile.CheckIn("")
$item.Name
$item.ContentTypeId
}
  • This results in an error: Exception calling "Update" with "0" argument(s) – Chris Patterson Jan 27 '16 at 13:34
  • That's strange. It runs on my own machine. Is this content type ID still valid in that list? Maybe you have tried this on another list which already has different content type IDs? What kind of SharePoint version are you using? Any other error messages? Also, let's check what type $item actually is - run $item.GetType().FullName and check that it's Microsoft.SharePoint.SPListItem – Justas Černiauskas Jan 27 '16 at 15:14
  • I am on SharePoint 2013. The Content Types are all still there in name, so I imagine they are still active. I haven't tried it on another list yet. It does show as a Microsoft.SharePoint.SPListItem. – Chris Patterson Jan 27 '16 at 20:48
  • OK, then double check for the correct content type ID. Content type IDs change if you remove/add them again to the list, even if the names stay the same, so it's worth checking. Other than that, there can't be anything wrong. – Justas Černiauskas Jan 28 '16 at 6:54
  • I re-wrote the code so that it uses a variable to select the Content Type ID, converted to a string. The ID and the string I was passing earlier are identical, but this time it seems to have worked while also making the above change to update just the item correct. – Chris Patterson Jan 28 '16 at 13:49
0

The issue has to do with the fact that Office Documents can retain properties associated to it within it's own metadata. This data by design is re-read and can override any number if not all properties associated to a list. The trick I found recently is that every web has a property of $web.parserenabled It can be set to $true or $false. If you set it to $false; SharePoint will not read the data from the file; and you will be able to commit your changes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.