Unfortunately I don’t have any new information. At this point I wouldn’t anticipate a fix until 2012. Are you in the position where your production farm has this issue, or is it in a dev / test environment?

I’m facing similar issue. but my error log shows some different error message. I’m not able to figure out the reason for this issue

There was a form postback error. (User: BP1\username, Form Name: Template, IP: , Request: http://listurl/editifs.aspx?List=b908c38e-9b03-453d-8c76-7fa165caf21f&ID=1197&Source=http://siteurl/SitePages/pagename.aspx?RootFolder=http%253A%252F%252Faaa%252Eaaaa%252Ebb%252Ecom%252FLists%252FITK%2520List%252FFork&ContentTypeId=0x010040BA53AE3BDFC3489727B1FAA33792DC003ACC2928E153B94584C40840570E0C52, Form ID: urn:schemas-microsoft-com:office:infopath:list:-AutoGen-2011-09-09T11:21:57:155Z, Type: OverflowException, Exception Message: Value was either too large or too small for a UInt32.)

I (as well as others) have reported the issue to Microsoft, and they were able to reproduce the error. At this point, they are looking into it, and I will update this post when I receive more information.

do you already have any news regarding this issue? I also have this problem and would need a solution for it.

Kind regards
Gottfried

Unfortunately it does not apply directly to MOSS 2007 as there are no public constructor for SPContentType that take a SPContentTypeId as a parameter.

I was able to instanciate child content types with a given id using reflection and an internal constructor (and some internal properties too).

I wonder whether such kind of object model “hacking” is supported or not but at least I was able to fix my site without touching to the content database.

This alleviates the need to do the file copy and IIS changes completely.

Note: Any customization done in IIS Manager or manually to files would be lost.

Any advice you take from this blog is done at your own risk, but if you make the update in your production environment, I would strongly urge you to plan accordingly in terms of first pre-testing in a UAT environment, taking proper disaster / recovery steps, as well as scheduling a good amount of time to make the update. Make sure that the appropriate changes are made on all of your WFE’s – i.e. copying the current directory of files over to your new location as well as changing the path in IIS. I would take the other comments on this post into consideration, in terms of looking at first-hand experience of users who have performed the operation. I also have not personally done this in SharePoint 2010, so keep that in mind if that is your case. If you do decide to go forward with this method, good luck to you, and be sure to report back here with how it went!

We are also in the need of changing the root directory of the web application on our production server(large farm). Is it safe to go ahead with your approach? Your suggestions are highly appreciated.

Thanks
Shwetha

[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”)

function Change-Path([string] $WebAppUrl, [string] $NewPath) {

if ([String]::IsNullOrEmpty($WebAppUrl) -or [String]::IsNullOrEmpty($NewPath)) {
write-host “Usage: Change-Path Web_path_URL New_Physical_Path”
return
}

$di = new-object System.IO.DirectoryInfo $NewPath
if ($di.Exists -eq $false) {
write-host “Path “, $NewPath, ” does not exist”
return
}

Write-Host “Moving “, $WebAppUrl, ” to “, $NewPath

$WebApp = [Microsoft.SharePoint.Administration.SPWebApplication]::Lookup($WebAppUrl)

$IISSettings = $WebApp.IisSettings[[Microsoft.SharePoint.Administration.SPUrlZone]::Default]
$IISSettings.Path = $NewPath

$WebApp.Update()
}