A duplicate content type “Enter Name” was found
If you’ve gotten this error and come to this site looking for answers, chances are it isn’t simply because the name you’re trying to give a new content type is already in use. On the contrary, you are probably sitting there saying that you know without a doubt the name you are entering is not in use, and you have probably even pounded a random value out on your keyboard just to prove the point.
Maybe you’ve come across forum posts like the following that suggest you make an update directly to the content database (MSDN Forum Post). I never go this route, because it is going to take you out of support with Microsoft, since working with the database is specifically prohibited.
I have, however, created a way to overcome this error utilizing perfectly legal methods.
What Does This Error Mean?
There are 2 ways to create an ID for a content type (MSDN Site). One involves assigning a child id based off a numerical sequence, and the other involves utilizing a unique guid. If you are developing your own content types, I highly recommend always creating your id’s with the unique method because you don’t risk conflicting with another developer or a 3rd party solution, but if you are creating content types through the UI, you have no choice – the UI method always creates children id’s based off of a numerical sequence (until it runs out of numerical values).
Another new feature in SharePoint 2010 also seems to add to this problem, as when utilizing a Content Type Hub, you essentially end up with 2 different sources (the hub and the site) trying to issue children content types and keep track of what the next numerical id should be. The content database has a field on the dbo.ContentTypes table called “NextChildByte” and that is what lets SharePoint know what that next numerical value should be. This is the heart of our problem. Sometimes SharePoint gets out of sync with itself, and “NextChildByte” indicates a value that already is in use. SharePoint is not intelligent enough to continue looking sequentially until it finds the next available byte sequence. Instead, it throws the error you see at the top of the page. That is why the posts online about updating this value in the database work – because the heart of the problem is this value, which is incorrectly telling SharePoint what the next numerical value for a child of this content type should be.
The Solution
I looked at this solution from a few perspectives, but ultimately knew I needed to get this “NextChildByte” value to change without issuing a command on the database. I discovered through testing that every time a content type is created programmatically (where you set the ID – either in the numerical format OR the unique guid format) this value gets incremented by 1. This is an increment of 1 each time – it doesn’t recalculate this value based on the content types already in the site. Essentially what we need to do is create enough “dummy” content types to increment this value up to a point where those numerical values have not yet been used in other content types.
I’ve written a PowerShell function that takes in an SPWeb and SPContentType that you are having trouble creating child content types of through the UI, and it simply adds 10 “dummy” child content types with random id’s and then removes them (thereby also freeing the random id’s it added). This ends up incrementing “NextChildByte” in the database by 10 and fixing your issue. If incrementing by 10 isn’t enough for you, or you run into the problem again down the road, you can update the script to suit your needs and re-run it. You may be wondering what happens after you reach the end of the numerical range expressed by a hexadecimal value (FF). At the point you run off the track (which would seem unlikely) SharePoint is intelligent enough to just create the children with Unique ID’s after that point. “NextChildByte” in the database then sits at 0, even as you add more content types.
function FixContentTypeForChildCreation { param( [Microsoft.SharePoint.SPWeb]$web, [Microsoft.SharePoint.SPContentType]$ct ) #Grab the ID of the CT you need to fix for child creation $ctID = $ct.ID.ToString(); for($i=0;$i -lt 10; $i++) { #Create a new child content type with a unique guid and then delete it $newCTID = new-object Microsoft.SharePoint.SPContentTypeId($ctID + "00" + [Guid]::NewGuid().ToString("n")); $newCT = new-object Microsoft.SharePoint.SPContentType($newCTID, $web.ContentTypes, "Temp Content Type - Auto Deleted"); $addedCT = $web.ContentTypes.Add($newCT); $newCT.Delete(); } Write-Host "Content Type Fix for Child Creation is Complete" }
Example Usage
$web = get-spweb "http://yoursite" $ct = $web.AvailableContentTypes["YourContentType"] FixContentTypeForChildCreation $web $ct
I hope that this solution is able to help you through what can certainly be a frustrating time for users who are unable to create content types in the UI.
Cheers,
Matt
