This error kept our team occupied for some time before finding a solution.
Error description:
A custom application on SharePoint copies some documents form one library to another after a button is pushed on a form button. When the button is pushed the application behaves as expected and the files are copied. For some reason now, the operation fails if the number of files being copied is quite a lot.
We were originally thinking about a timeout issue, an upload limit issue or the antivirus software interfering. After investigating all of these cases, we were unable to find a solution. A lot of research and some days later, we went back in to the problem before calling PSS and I found the solution on a blog post
Solution:
You need to define the executionTimeout parameter in the web.config file of the web application where the custom application is running. This parameter is not there by default. From what I have read out there, it seems that if this parameter is not defined, then a default value is assumed of 110 seconds
<httpRuntime executionTimeout="200" maxRequestLength="51200"/>
Source for execution timeout:
http://blogs.msdn.com/pedram/archive/2007/10/02/how-the-execution-timeout-is-managed-in-asp-net.aspx
It has been a while since my last post and since then, I encountered some interesting issues, worth writing about. This one amazed me.
One of our users complained that he was unable to edit a standard choice field that he just created in a document library. Whenever he tried to edit the filed he got the dreadfull "Unknown Error" from SharePoint.
A little research and some adjusting of diagnostics logging when reproducing the error, showed the following error in the ULS logs:
Application error when access /_layouts/FldEdit.aspx, Error=Object reference not set to an instance of an object.
at Microsoft.SharePoint.ApplicationPages.BasicFieldEditPage.get_ContentTypeId()
at ASP._layouts_fldedit_aspx.__Render__control433(HtmlTextWriter __w, Control parameterContainer)
at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children)
at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children)
at System.Web.UI.HtmlControls.HtmlContainerControl.Render(HtmlTextWriter writer)
at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children)
at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children)
at Microsoft.SharePoint.WebControls.UnsecuredLayoutsPageBase.RenderChildren(HtmlTextWriter writer)
at System.Web.UI.Page.Render(HtmlTextWriter writer)
at Microsoft.SharePoint.WebControls.UnsecuredLayoutsPageBase.Render(HtmlTextWriter writer)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
Exception Type: System.NullReferenceException Exception Message: Object reference not set to an instance of an object.
Now this error does not say much, so I started to look for it in blogs. Now it turns out that someone had faced the exact same issue with oddly enough the exact same name of the column causing the issue. My user had called the column 'doctype' . According to the blog post, the name doctype is a reserved word in SharePoint and strangely enough SharePoint does allow you to create a column with that name, but then you will no longer be able to edit it again.
As suggested in that post, I was also able to delete the column using SharePoint Manager 2007 (http://spm.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=22762)
My source: http://www.ureader.com/msg/123210106.aspx.
for my first day at work, I want to start of by wishing you all a Happy 2010.
May all your wishes come true and of course may you all enjoy the new and fun stuff in SharePoint 2010.
For myself, 2009 has been a great year with a lot of changes:
- I quit my job at BT to become a freelance IT Consultant, which was quite a big change
- I became a licenced firefighter next to my paramedics licence at the local fire department in my home town?
- I had the luck of being asked by Microsoft to do a mini project for them again, which is always a great learning experience 
I hope I can continue to bring some great content to this blog this year.
I finally found some time to get the Office Web Apps working on one of my servers running SharePoint Foundation 2010 beta
This is the server that I had upgraded from WSS 3.0 etc. As you may recall, I had completely uninstalled my SharePoint 2010 Foundation and WSS 3.0 after successfully having upgraded my WSS 3.0 site collection to SharePoint 2010. This enabled me to have a "clean" installation of Foundation. After all that, I decided to give Office Web Apps a try. The installation went smoothly and after running psconfig, all service applications were up and running.
So I gave it a try and as expected it did not work....bummer ... That was some weeks ago. I finally found the time to get this fixed. I googled around a bit and found an article by Kylie Richardson.
She had run into the same issue I had, where the Word Viewer refused to render the document. Apparently this is an issue if you are running SharePoint Foundation on a Domain Controller. The system I am running is running so much more than that :)
In my case the solution did not work. I got error messages in the eventlogs stating that my Excel services and Word Services were not properly registered in the Config database.
Finally I decided to follow Kiley's article all the way where she installed Foundatation and Office Web Apps before running the SharePoint 2010 Products and Configuration Wizard to create the farm.
The steps I took:
- took a backup of my site collection
- uninstalled Office Web Apps
- then uninstalled SharePoint Foundation 2010
- reinstalled SharePoint Foundation 2010 without running SharePoint 2010 Products and Configuration Wizard
- reinstalled Office Web Apps
- ran SharePoint 2010 Products and Configuration Wizard
- restored my site collection
- executed the suggested commands by Kylie:
$e = Get-SPServiceApplication | where {$_.TypeName.Equals("Word Viewing Service Application")}
$e.WordServerIsSandboxed = $false
$e.WordServerIsSandboxed
#(Please use the below script for PowerPointServiceApplication - You need to enter "Y" for the answer of each cmd)
Get-SPPowerPointServiceApplication | Set-SPPowerPointServiceApplication -EnableSandboxedViewing $false
Get-SPPowerPointServiceApplication | Set-SPPowerPointServiceApplication -EnableSandboxedEditing $false
In the server’s c:\windows\system32\inetsrv\config\applicationHost.config
Add the line below in the end of the dynamicTypes.
<add mimeType=”application/zip” enabled=”false” />
IISRESET
So there I was with my completely reinstalled SharePoint Foundation
Cool. So now Office Web Apps works.....or NOT!
After having doen all these actions, it still didn't work. I remebered for Excel Services that you need to configure the Trusted File Locations, so I went to the Service Applications, Selected Excel Services and added a trusted file location for my site collection --> No Luck, still didn't work.
At this point I went back to basic troubleshooting...Eventlog and bam! There was an error indcation that my SharePoint Farm Service account was unable to open my content database, which was not there before having reinstalled everything. As a fix I added my SharePoint Farm Service account in the permissions of my content database and voila, Office Web Apps works!
As it turns out, I am using different accounts for my Application Pools as everyone should and the Excel Services and Word Viewing Service seem to use the default SharePoint Farm Service account for accessing the content.
So again, nice to know, isn't it ?
So I ran into this issue after having installed my SharePoint 2010 farm with 3 servers. At first I did not want to spend a lot of time troubleshooting this and I solved it be reprovisioning my Central Admin which solved the issue. However one day later, the issue was back. after further investigatioàn this time I got an error indicating:
--> Retrieving the COM class factory for component with CLSID {BDEADF26-C265-11D0-BCED-00A0C90AB50F} failed due to the following error: 800703fa
When performing an IIS reset, the error disappears. You could schedule a iisreset, but hey let's try to fix this. My good friend Google, found the solution on the blog of Kasper de Jonge.
(http://business-intelligence.kdejonge.net/sharepoint-2010-beta-error-retrieving-the-com-class-factory-for-component-with-clsid-bdeadf26-c265-11d0-bced-00a0c90ab50f-failed-due-to-the-following-error-800703fa)
The solution:
Go to IIS Manager, select the Application Pool for your central administration web application and click Advanced settings, change the value for “Load User Profile” to “true”
Thanks Kasper for this one
This question came up in one of my comments recently and I wanted to find out if it was even possible to reveert the look back of a SharePoint 2010 site that has been upgraded from WSS 3.0 or MOSS2007
Thanks to Corey Roth and a comment on his post about I found out the following:
"In SharePoint 2010, there is the concept of a UI Version and it has a value of 3 or 4. When you upgrade your existing site, it will leave you at Version 3 which looks just like WSS3. However, you have the capability to upgrade to the new SharePoint 2010 visualizations which is version 4. If the administrators have the options enabled, you can change your UI version using the UI itself. It provides the capability to run on Version 3 but get a preview of 4 and then ultimately they can convert to version 4 completely. However, you may want to do this programmatically or you may want to revert back to version 3 after you have turned off preview mode. "
So there are already two possible ways of doing it:
1. Using Code: (thanks to Corey Roth)
using (SPSite siteCollection = new SPSite("http://server/site"))
{
SPWeb site = siteCollection.OpenWeb()
{
site.UIVersion = 3;
site.UIVersionConfigurationEnabled = true;
site.Update();
}
}
2. Using Powershell: (thanks to Tobias Zimmergren)
$site = Get-SPSite("http://portal")
$web = $site.OpenWeb()
$web.UIVersion = 3
$web.Update()
$web.Dispose()
$site.Dispose()
This is my frustration of the week!
Don't you just hate it when you are on the nice Microsoft Download Center www.microsoft.com/downloads website, that when you search for a download, like Sharepoint Language Pack, that you get a blank page? Well I do!
I blame it on Bing....
That's why I decided to kill my Bing ringtones from my cell phone and use Google by default for my Microsof Download searches
I found myself looking for this query for the second time now and finally decided to post it on my blog 
This query enables you to find out if your connections towards your SQL server are using Kerberos instead of NTLM. This may help in your troubleshooting or confirmation for your Kerberos implementation on SharePoint.
If found it back this time on the blog of Marc Valk (http://www.marcvalk.net/2009/04/sql-query-to-identify-kerberos-or-ntlm-connection/)
SELECT
s.session_id,
c.connect_time,
s.login_time,
s.login_name,
c.protocol_type,
c.auth_scheme,
s.HOST_NAME,
s.program_name
FROM sys.dm_exec_sessions s
JOIN sys.dm_exec_connections c
ON s.session_id = c.session_id
I was asked this question yesterday and I remember having tried to find out how to do it. Finally I took some time to search around on the net and found a post by Patrick Heyde.
http://blogs.technet.com/patrick_heyde/archive/2009/09/30/sharepoint-blow-up-in-daily-business-and-nobody-writes-important-stuff-to-the-farm-documentation.aspx
which says the following:
3. Which SharePoint language packs were installed?
Answer: check registry
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS\InstalledLanguages\<LCID>
here you will see something like this:
LCID - Reg_SZ - {language pack build level}
1033 - Reg_SZ - 12.0.4518.1000
1031 - Reg_SZ - 12.0.4518.1000
...
or
LCID - Reg_SZ - {language pack build level}
1033 - Reg_SZ - 12.0.6219.1000
1031 - Reg_SZ - 12.0.6219.1000
...
Note: It's important to have all language packs on the same build level!
To get an overview about all Microsoft LCIDs you can use this article: Local ID (LCID) chart
Thanks Patrick, in my case the build version was set to 12.0.6425.1000 which turns out to be SP2
I thought I'd share with you guys what I had experienced during the upgrade from my WSS 3.0 server to SharePoint Foundation 2010 beta.
First of all, my WSS 3.0 is quite small. There's only One site collection in there of any significance en some other site collections for testing purposes. So with this in mind I thought this would be a piece of cake.
After having made a stsadm backup of every site collection and a backup of all my SharePoint databases, I was ready to start. After having read though the deployment docs, I found out that if you are running SQL 2008, that it needs to be at least SP1. I was already running that build so I was good to go for that. I must admit that the prerequisite installer runs smoothly. It does detect your missing prerquisite software and goes out to the interent to download the missing bits. The installation of SharePoint Foundation went flawlessly. I was quickly able to start up the Products and Configuration wizard.
The upgrade wizard quickly failed, telling me that I need to install the Dutch Language Pack as it is also installed for WSS 3.0. A quick look on the web showed me that there isn't one yet available. Hmm.. problem number 1. I had to uninstall the Dutch language Pack before I could continue. Since all my site collections are also created in Dutch, I needed to convert them to an Englich version, so I decided to do some unsupported stuff and change the language of my site using the following SQL command on my content database:
UPDATE dbo.webs set language = 1033
Sure enough, my sites are now back in English. I ran the uninstall for the dutch WSS Language Pack and again I was good to go.
My next attempt for running teh upgrade failed as well, complaining about an incorrect SQL version. What the h***? Hadn't I checked that already before? As it turns out you do not only need SQL 2008 SP1, but it also needs the Cumulative Update 2 for SP1 installed. So I got to download those bits, install them and voila, we are back in business.
The final attempt for the upgrade succeeded. The upgrade process ran successfully, giving no errors and I was soon presented with the new Central Admin site.I quickly checked the look of my sites, which was as expected still the same, although if you go through to Site Settings, you immediately notice that something has changed. It isn't quite the old version anymore.
So all I needed to do is play aroud with the Visual Upgrade Preview and fin out how my sites will look in their SharePoint 2010 version.
so that's it for my first upgrade experience.
Well actually it isn't, because after all my sites had been upgraded I decided to take a backup of my new site collections using stsadm and remove everything. I uninstalled SharePoint Foundation 2010, WSS 3.0, deleted all my SQL databases and started a clean install of SharePoint Foundation 2010. After that I restored the site collections and there I was again: up and running. I don't like running some hybrid versions with both WSS and Foundation installed and prefer a clean install
I am going through some of the SharePoint Conference 2009 Videos I recently got from a colleague of mine that was lucky enough to be there, and I am pleased to have learned that STSADM will not be gone in SharePoint 2010. Simon Skaria confirmed this in his IT Pro Overview session.
Great. Now I don't need to look for a new subtitle for my blog.
But I Simon Skaria also encourages everyone to move on to Powershell because of its auto-complete capabilities.
Yes, finally, I have found the time and means to attend a conference again. This time I did not have much difficulty convincing my boss, being selfemployed and all.... I just had to check with my COO that I married today, eight years ago. Congratulations to you too my dear 
So if you haven't heard, you can register for the SharePoint 2010 Evolution Conference in London starting April 19th for a 3-day conference.
Find out all about it at http://www.sharepointevolutionconference.com/
My registration is complete and confirmed, so if you guys are out there as well, then print a large copy of my picture, carry it with you at all time and say "Hi" if you bump into me. I'll buy you a free drink at the conference 
I was recently facing an issue as described in http://stackoverflow.com/questions/809179/saving-a-document-to-sharepoint-brings-up-web-file-properties-dialog-with-incor
Recap from original post:
Situation:
- A custom "Master Document" content type inherits from Document
- The "Master Document" content type has five additional choice fields
- There are five custom "Document Template" content types that inherit from the "Master Document" content type
- Each of the "Document Template" content types uses a different Word document template (.dot) file
- Each of the "Document Template" content types have been added to a document library
Problem:
- I click on a document in the library
- Document opens up in Word 2003 for me to edit
- I make some changes and save
- A box pops up called "Web File Properties". The window contains all of my custom metadata properties and the ContentType field. The ContentType field is set correctly to the current content type. The other fields are reset to their default values. This same window can apparently be opened by going to File -> Properties
This window by itself would be fine except for two reasons:
- It includes the ContentType column
- All of my custom metadata properties are visible but are reset to their default values instead of whatever values were previously selected. This means, every time the user wants to save the document, they have to remember what properties were tagged and set them back.
Question:
- Can I disable this Web File Properties box?
- If no... can I get the fields that show up to be populated to their correct values?
- If no... is there a way to disable my fields from displaying in this window?
- If no... is this a SharePoint page that I can modify?
***Edit with some more information***
It looks like this only happens in Office 2003 and looks like it affects Choice fields. If I create the same column as a Lookup field, it seems to work.
Edit again
Looks like if the lookup field is a multi-select field then it will not show up in the Web File Properties box at all (single select lookups still work).
edit 10/14/2009
Link to the KB Article mentioned below by Brenda: http://support.microsoft.com/kb/971500/
My Solution:
Of Course the suggested hotfix, which in fact is the June Cumulative Update for WSS did not fix my issue, but I did find a solution at the end.
What really happens when you call the Web File Properties box is that your client will download 3 javascript files from the server: bform.js, core.js and init.js. You can check this by by opening up the document library causing the issue and clearing your temporary internet files at that time. When you now call the Web File Properties in Word 2003 through File --> Properties, you will notice these 3 script files being downloadin in your temprary internet files folder.
On the SharePoint front-end servers, you can find these files in the 12-hive\Template\Layouts\<LCID> folders, where you have to replace <LCID> with your language codes installed (1033, English; 1043, Dutch; .... you get the picture, right?)
So the problem is most likely caused by one of those javascript files. Now we have had the issue since we had installed SP2 and the June Cumulative Update. So I decided to restore these 3 script files and play aroun with these files for a while.
As it happens, my problem went away by replacing the bform.js file with a pre-SP2 version and clearing my
So if your issue does not get resolved by the suggested method of Microsoft, which is installing the latest Cumulative Update, then try restoring a previous version of this file and remember that you will need to clear this file from your client's Temporary Internet Folder to force a download of the latest version from the server.
I'm on a roll ...
I just discovered the new SharePoint Server 2010 site of Microsoft. Lots and lots of information to catch up on....
http://sharepoint2010.microsoft.com/
For me the most valuable information is the ability to preregister for the beta version, scheduled to be available in November.
The new name for the next version of Windows SharePoint Services has been set to SharePoint Foundation 2010.
Microsoft has published all you need to know about it on:
http://sharepoint2010.microsoft.com/product/related-technologies/Pages/SharePoint-Foundation-2010.aspx
and for thos of you still wondering, I read the next lines on MSDN here
"The Microsoft SharePoint Foundation 2010 technology helps teams stay connected and productive by providing easy access to the people, documents, and information that can help in decision making and getting work done. (Microsoft SharePoint Foundation 2010 will be available as a free download in November 2009.) "
Wow, I am discovering 
More Posts
Next page »