Moving from "a sharepoint user" to "a sharepoint power user", I now am facing the world of Powershell and more. One thing that really puzzles me is the following.

Ok, so I have a document library containing many document sets, containing many files. I've added several content types to the document library. So far so good, works like a charm. When I go to site settings, site content types and select one of the content types, I see the content type ID appear in the url of the page. This ID is equal to the one I see if I make a complete dump in powershell of all the content types. The script I use for that is:

$sites = get-spsite -Limit All
foreach ($site in $sites)
$ctypesWeb = $site.rootweb.ContentTypes
$mydata += $ctypesWeb | Select-Object Id, Name
$mydata | Export-Csv –Path D:\cTypeDump.csv

When performing some tests, I e-mail several documents to the system, and an event handler (or something, not sure) moves them to the right document set and assigns a specific content type to the files based on some business rules. After this has been done, I know (based on the file names I used in the test) exactly which files should have which content type assigned to it. Now i thought, lets be clever and write a powershell script which loops through all documents in the document library and extracts the document name, file name and content type id. With that information, it should be easy to compare the assigned content type ID's with the ones I expect to be assigned, but here comes the problem.

Say content type "A" has ID: 0x010100F3598766C83A4F4FAC86046B0D90C73E(...)00F1874B3A14B1483482679A5610BC1BD5. One of my test files has correctly been assigned content type "A" as well, but now when I compare the two IDs, I see they are different: 0x010100F3598766C83A4F4FAC86046B0D90C73E(...)00F1874B3A14B1483482679A5610BC1BD500A35A8DB61EC99847B34A51066EDEEC3D

So it appears the content type id I find in the file properties is somehow seen by SharePoint as a child of the parent, but that doesn't make sense because imho it is not. Anyway, the script I use to pull the content type id from the files is:

$web = Get-SPWeb "http://sp/myWeb"
$list = $web.Lists | ? {$_.Title -eq "myDocLibrary"}
$rootFolder = $list.RootFolder 

foreach ($docsetFolder in $rootFolder.SubFolders)
$files = $docsetFolder.Files

foreach ($file in $files) 
$cTypeID = $file.properties["ContentTypeId"]
$myData += $docsetFolder.Name + "," + $file.name + "," + $cTypeID + "`n"
$myData |  Out-File D:\fileCTypeIDs.txt

This is probably a really stupid question, but I hope someone has an answer.

Many thanks in advance!

2 Answers 2


Based on your code I am assuming this is Sharepoint 2010..... Content types have various levels such as: Library, web, and site. All ContentTypes eventually roll up to the item content type at the Site Collection Level. This means that if you iterate through the parents until you get to the Site level you SHOULD find an ID within your dump.

Since you are trying to compare you could use this code structure:

#get file
$ctyp = $file.item.ContentType
while($ctyp.ParentList -ne $null){ #a site level content type 
                                   #will have a null parentList property
   $ctyp = $ctyp.parent
$ctypid = $ctyp.id
#set $mydata

Please note this code is untested.



Content Type IDs


So it appears the content type id I find in the file properties is somehow seen by SharePoint as a child of the parent, but that doesn't make sense because imho it is not.

Actually, it is a child.

When you add a content type to a list or library, SharePoint makes a copy of the site content type into the Content Types collection of the list (SPList.ContentTypes). So what you are seeing is the expected behavior.

For more explanation, see the MSDN article on Site and List Content Types.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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