One of my clients recently needed help with restoring a WSS 3.0 site collection to a separate content database in order to migrate it (via detach-attach method) to a new SP Foundation environment. This obviously could be achieved by splitting the content database if the site collection already exists in one. However, if you are trying to work with a site collection that has been previously backed up, then you would have to resort to restoring the site collection to a new content database.
Microsoft has a very detailed Technet article that outlines how to perform a backup and restore of site collections in WSS 3.0. While my client was following the steps outlined in it, he still ran into an Access Denied error while trying to perform the restore via STSADM.
Microsoft clearly states the following as the only requirement to perform a site collection restore (Apart from returning the site lock setting to its pre-backup status).
Membership in the Administrators group on the local computer is the minimum required to complete this procedure.
However, turns out this is not the case. After digging into ULS logs and going over permissions in Central Administration, I was able to figure out that in order to successfully restore a site collection, the current user has to be a site collection administrator for the particular site collection. This is obviously an oversight from Microsoft’s part (probably due to the fact that, in most cases, the admin account ends up being a site collection admin. But not in this scenario).
Even though WSS 3.0 is slowly going into extinction, I hope this will be useful for someone who runs into the same issue.
Deployed SharePoint 2010 using least privileged method? If you created a Managed Metadata Service Application and try to access the Term Store Management Tool you might run into the following error.
Managed Metadata Service or Connection is currently not available. The Application Pool or Managed Metadata Web Service may not have been started. Please Contact Your Administrator.
You will also notice the Event ID 8077 logged in your application log with the following description.
There are no instances of the Managed Metadata Web Service on any server in this farm. Ensure that at least one instance is started on an application server in the farm using the Services on Server page in Central Administration.
The most common cause for this error is due to the service account that’s running the Managed Metadata service does not have enough permissions to do so on the machine that’s running the service. To resolve this you will have to grant the service account the log on locally right via Group Policy or Local Security Policy on that machine.
- Security Settings -> Local Policies -> User Rights Assignment -> Allow Logon Locally
- Add the Managed Metadata Service account
- Run gpupdate to refresh policy change
- Log off and log back on to apply the changes
Go back to the Term Store Management Tool and it should be able to find the service application now.
If you are using STSDEV to create your workflow templates, I bet you’ve run into errors (Most common being “Could not resolve field type”) when executing workflows that reference the workflowProperties object. Turns out that STSDEV does not bind the workflowProperties object to the SPWorkflowActivitationProperties object during activation.
In order to resolve this problem, simple add a OnWorkflowActivated event control to the workflow (if not already present) and under Properties, bind the workflowProperties object (member in your workflow class) in to the WorkflowProperties property (control in workflow) as show below.
(Click image for full size)
SharePoint 2010 RTM English bits went live last week (official launch on May 12). Though it will only be available for general use somewhere in June, you can try out SharePoint Foundation (previously WSS) and SharePoint Server using the links below.
- SharePoint Server 2010 (Requires MSDN subsription).
- SharePoint Foundation 2010 (x64 | Free)
- SharePoint Designer 2010 (Free) - x64 | x32
I recently went through the event log on one of my dev servers running 2008 R2 and realized that the Application Server has been quite active in logging errors about not being able to start the following services.
- NetTcpPortSharing
- NetTcpActivator
- NetPipeActivator
- NetTMsmqActivator
The errors were along the lines of what’s shown below.
Error: Installation of [Application Server] TCP Port Sharing failed. Attempt to install TCP Port Sharing failed with error code 0x80070002. The system cannot find the file specified
It turns out that when I updated .Net Framework 4.0 to the latest version, windows did not automatically change the location of the service libraries to reflect the updated version.
To fix this, open the the registry (regedit) and go the following location.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
Select the Services listed above and make a not of the file path for the Description, DisplayName and ImagePath keys.
Now open up windows explorer and navigate to,
C:\Windows\Microsoft.NET\Framework64\
and copy the latest version number of the .Net framework (mine was v4.0.30128). Change the version number in the registry keys to match this number and try starting the services manually.
That’s it! The next time you restart the server, your Application Server should be running without any errors!
If you have tried to develop custom definitions/features for SharePoint in Visual Studio (using VSeWSS) and have run into one of the following errors, it’s most likely you have not completed the post-installation checklist.
The content type text/html; charset=utf-8 of the response message does not match the content type of the binding (text/xml; charset=utf-8).
This error is mainly due to the WCF HTTP Activation feature not being enabled. Go to you’re Server Manager (or Control Panel -> Add Windows Features) and Install the WCF HTTP Activation feature under .Net Framework 3.0 Features.
After enabling the WCF HTTP Activation feature, if you run into the following error, chances are the service account running the SharePoint Central Administration v3 Application Pool does not have local admin access to the machine you’re trying to deploy to.
VSeWSS Service Logging Error: Access to the path ‘C:\Windows\system32\config\systemprofile\AppData\Roaming\Microsoft\VSeWSS 1.3’ is denied.
Logging failed attempting to write to C:\Windows\system32\config\systemprofile\AppData\Roaming\Microsoft\VSeWSS 1.3\VSeWSS1.3 service.log. This may occur because the VSeWSS WCF Service does not have local administrator permissions.
To fix this error, you need to provide admin access to the service account running the application pool. Most folks have suggested the use of Network Service to run SharePoint Central Administration which is not a good practice (and should be avoided, specially in a production environment). The best way to workaround this is to create a new Application Pool called “VSeWSS” in IIS. Go to Advanced settings in the AppPool and set the Identity to your local admin account. Now, under Sites, select “VSeWSS” and click on Advanced Settings. Change the Application Pool from “SharePoint Central Administration v3” to “VSeWSS” and perform an IISRESET.
You should now be able to deploy your custom features within Visual Studio without a problem.
I guess people are causing too much havock in Twitterland.
