*Update: InfoPath 2010 is the real cause, please check this post.
I love Microsoft Office 2010. It’s more beautiful and faster than Microsoft Office 2007. I downloaded and installed the product immediately after its RTM version arrived on the MSDN download page. I even installed it on my Windows Server 2003 virtual machine that runs MOSS 2007. At first, I thought it worked great.
Apparently it was not a good idea. Later I realized something was broken. As the VM is my SharePoint sandbox, soon I encountered a problem when I was playing with it. That happened when I executed an stsadm command, a rather simple one actually:
stsadm -o copyappbincontent
But it failed with the following error:
One or more types failed to load. Please refer to the upgrade log for more details.
I found nothing useful in the event log and SharePoint logs to fix this issue. So I googled it and found this thread on TechNet. It was suggested that Office 2010 was the problem and the solution was to uninstall it. Unfortunately it was not explained what the root cause of the issue was. I don’t want to uninstall the whole product just to fix this issue. For now, I can just copy the resource files manually to the App_GlobalResources folder in my virtual directory instead of using the stsadm -o copyappbincontent command. Hopefully there won’t be more issues because of Office 2010 and Microsoft would fix the issue soon.
Recently, a colleague asked me about an error that happened after he moved a WSS 3.0 Web site from the development to the production server.
When logged in as an administrator, all pages can be accessed successfully. But as a regular user, I got an “Access is denied” page when opening some pages containing some custom web parts with the following exception detail: System.ComponentModel.Win32Exception: Access is denied. Below it, in the stack trace, another exception popped: InvalidOperationException: Cannot open log for source ‘Some_webpart’. You may not have write access.
This happens because non-administrator users do not have—by default—the permission to write to the event log. So for this problem, just give the non-administrator users permission to write to the event log. If only it is that simple. Unfortunately, there are no easy (user-friendly) ways. To do this, follow the following steps:
- Fire up the registry editor which is usually located in
- Navigate to:
- Look for the entry
CustomSD, it should contain string similar to:
The string is formatted as an SDDL, you can find more information about the format at Microsoft’s site.
- Now tell Windows to give the event log’s read-write permission to all authenticated users. To do this, append the string
(A;;0x3;;;AU) to the entry
CustomSD thus it becomes:
After following the above steps, retry visiting the pages on your SharePoint site. Now the “access denied” problem should have gone. Hope this will help you running your MOSS 2007 or WSS 3.0 installation on Windows 2003 Server.
Disclaimer: remember to backup your registry before making any changes. I am not responsible for your system damages because of any registry errors.