Since installing Internet Explorer 8 on my Windows Server 2003 development machine I’ve been unable to use Explorer View, with the error:
Please wait while Explorer View is loaded. If Explorer View does not appear, your browser may not support it.
Searching around, the main reasons seem to be:
- SharePoint site behind SSL – no fix at time of writing
- IE security level changes – fixable by adjusting security levels or adding SharePoint site to Trusted Sites zone
- WebClient service not running – fixable by starting this Windows service and ensure it is set to start automatically
For me the problem was #3, however attempts to start WebClient resulted in “File not found”-type errors. The following error was logged in the Event Viewer:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{BA126AD1-2166-11D1-B1D0-00805FC1270E}
to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20). This security permission can be modified using the Component Services administrative tool.
This familiar problem usually occursin SharePoint installations with the IIS WAMREG admin Service in Component Services. However this time searching the registry for the GUID in the error I had came up with the “Network Connection Manager Class”. Then searching for the GUID in its AppID key of {27AF75ED-20D9-11D1-B1CE-00805FC1270E} resulted in the netman component.
I then configured the security as described by the error in Component Services:
After stopping and restarting MS DTC I was able to start WebClient successfully and Explorer View worked again.
Tags: error, Internet Explorer, SharePoint
Do you ever find that your solution files have been “successfully deployed” according to SharePoint, yet the updated code isn’t taking effect? Perhaps you are trying to debug but breakpoints aren’t being hit when normally there’s no problem. Yet for some reason rebooting the server fixes the problem…
If that’s the case, the reason is probably file locking, most likely to occur if you have assemblies that need to be deployed to the Global Assembly Cache (GAC). If you ever find yourself in this situation, download a copy of the excellent Process Explorer tool, and follow these steps to verify:
- Start Process Explorer on the server affected.
- Press Ctrl+F, or in the menu click Find, Find Handle or DLL…, or just click the binoculars icon on the toolbar:
- Type the name of the assembly DLL and click Search.
- Under the Handle or DLL column, look for any assemblies located in the path C:\WINDOWS\assembly\temp. These lines tell you what process is locking the assembly.
OWSTIMER.EXE is the culprit!
The C:\WINDOWS\assembly\temp folder is Windows’ equivalent of “assembly purgatory” where the assembly will sit until Windows can deploy it. If the currently deployed assembly cannot be overwritten as it is already locked by a process then the DLL will stay there until the process releases the lock or ends, or until Windows is restarted (also ending the process).
One example where this problem can occur is when a WSP solution containing custom e-mail event receivers is upgraded. The timer service, OWSTIMER.EXE, executes event receivers via the Windows SharePoint Services Incoming E-Mail job. As the OWSTIMER.EXE process isn’t restarted when a solution is deployed, it will always hold onto the lock for the DLL containing the event receivers. The solution is to restart the Windows SharePoint Services Timer service on each web front end server. If you’re finding this problem in development, WSPBuilder v1.06 adds a “Recycle the Windows SharePoint Services Timer” option.
This problem can also occur when using Visual Studio if certain combinations of add-ins are installed. You can again check this by using Process Explorer and verify if DEVENV.EXE is the locking process. If so, take a good look at the add-ins you actually need. Regularly restarting Visual Studio is very frustrating and will severely cut your productivity!
Tags: debugging, deployment, development, SharePoint
SharePoint 2007 seems to have some real weirdness going on with configuring SSO. I’ve been setting it up in a test environment in a very simple way, using the farm administrator account for everything: Microsoft Single Sign-on Service account, Single Sign-On Administrator Account, Enterprise Application Definition Administrator Account, etc… Note that this is for testing only and is not best practice! Here are the problems I’ve found…
Weirdness #1: Error 0×80630005. Verify this account has sufficient permissions and try again.
Resolution: Log in to the server as the “Microsoft Single Sign-on Service” service account. As described by Frank Grossmann.
Weirdness #2: Error 0×8063064a. Verify this account has sufficient permissions and try again.
Resolution: Remote desktop to the server’s console (i.e. use mstsc /console) or physically log in to the server. As described by Dave Sobel. The Microsoft documentation for configuring SSO implies this but is not explicit:
Note that you must be logged into the SharePoint Central Administration Web site on a farm server to configure single sign-on (SSO) for Office SharePoint Server 2007. If you attempt to configure SSO on a workstation or any computer that is not a farm server, you will see an error message that reads “Single sign-on cannot be configured from this server. To configure single sign-on, go to the computer running the single sign-on service and specify these settings locally.”
I haven’t finished the configuration yet but hopefully there won’t be more problems. The best guide I’ve found is MOSS Single Sign On Setup Step-By-Step and beats what Microsoft provides.
Tags: SharePoint, SSO
Encountered a strange problem copying and pasting between the datasheet views of two contact lists. Only the Contact and Country fields were showing in the datasheet view.
When doing the paste, the following error appeared:
The rows you modified could not be saved to the server due to validation errors. This is usually caused by invalid default values.
The error gives some clue as to the problem. I then attempted to add a single entry manually (without the paste) and received a new error:
Columns that require data are not included in this view. If you want to edit rows that are missing data in these columns, or add new rows, you must first add the required columns to the view.
Finally, I added all of the columns to the view and at last found the column causing the problem:
You must specify a non-blank value for Title.
Setting the Title field to not be required fixed the issue!
Tags: error, SharePoint
Alex is a SharePoint and Project Server consultant, developer and administrator, contracting in London, United Kingdom.
