Troubleshooting

Data View Web Part error in SharePoint Designer

shehan — Wed, 14 Oct 2009 09:08:00 GMT

When I updated the ‘Filter Criteria’ of a fully functioning DVWP through SharePoint designer I was presented with the following error:

The server returned a non-specific error when trying to get data from the data source. Check the format and content of your query and try again. If the problem persists, contact the server administrator.

Took me a while to figure it out. This is what caused it and how to fix it:

When you create a DWVP, SPDesigner adds a parameter called ListID and assigns it the GUID value of the list. I’m sure that you know that in order to make a DVWP ‘portable’ you need to replace ‘ListID’ with ‘ListName’ and the GUID value with the name of the list. This doesn’t break the DVWP’s functionality and lets you use in on any site that has a list with the same name and columns.

However, if you try to edit the filter condition of this ‘portable’ DVWP from the DVWP’s common task pane you’re bound to encounter the above error. The way to recover is to change back ListName to ListID and assign it the GUID value of the list. Once this is done you can make the filter changes and SPDesigner will automatically refresh the DVWP with the correct items. Once you’re satisfied with the query make the DVWP ‘portable’ like you initially did and add it to your site.

Technorati Tags: SharePoint Designer,DataViewWebPart,DVWP,Error,List

SharePoint not crawling links

shehan — Tue, 25 Aug 2009 05:30:46 GMT

We have a document library which makes use of the 'Link to a Document' content type which lets users add links to a document library. We noticed that users were using this feature to add links to documents hosted on sites outside of the SharePoint farm. This is all good as far as they are concerned because the content type does its job and end-user can access the external documents by clicking the link.

However, we noticed that none of these links were showing up in the search results. When we looked into the crawl log (/ssp/admin/_layouts/LogSummary.aspx) we found that all these links had an Error status type. The error text was:

This item could not be crawled because the crawler could not connect to the repository. (The item was deleted because it was either not found or the crawler was denied access to it.)

It took some digging, but the issue was because the index server was behind a firewall that was preventing traffic to external sites. Once we made exclusions to the firewall rules (by adding exceptions to the IP address and ports of the external site) and performed a full crawl the links were indexed and started showing up in the search results.

Technorati Tags: Search,Link to a Document,Crawl,Firewall

A little 'gotcha' when restarting the search service

shehan — Fri, 21 Aug 2009 00:15:34 GMT

If you were to restart (i.e stop and then start) the search service, in a SharePoint farm, from the 'Services on server' page in Central Administration chances are that you might encounter both or either of the following errors when yo do a search on your web application:

Your search cannot be completed because of a service error. Try your search again or contact your administrator for more information.

The search request was unable to connect to the Search Service.

This happens because after restarting the service on the index server you need to assign an index server to the SSP. Here are the steps:

1. Start the search services on all the servers that you stopped.

2. Navigate to the Manage SSP page (_admin/managessp.aspx).

3. Place you mouse over the SSP name and select 'Edit Properties' from the drop down menu.

4. In page that opens up, scroll to the end and select the index server from the drop down list box.

5. Hit the OK button to save.

6. Give around 5 to 10 minutes for index propagation and initialization to take place and Search would start working again.

Another 'gotcha' to keep note of is that whenever you restart services or assign an index server to the SSP it should be done at a time when the crawler is 'Idle'. Else there is a high probability of the crawler performing an endless crawl.

Technorati Tags: Search,SSP,Index Server,Error,Crawl

Error Encountered for Approval workflow

shehan — Wed, 03 Jun 2009 06:09:55 GMT

We had configured a publishing site's Pages library to make use of the built-in approval workflow. However, we noticed that when users submits a page in the library for approval the workflow fails with the message 'Error Encountered'. There were no other messages provided by SharePoint explaining as to why an error occurred (and even the workflow history option yielded nothing).

We then went into the workflow settings and started examining all the fields. We noticed that the 'Approvers' field was set to a group called 'Cars & Trucks Owners' where as the actual name is 'Cars & Trucks Owners'. As soon as we changed the name (by replacing '&' with '&') the workflow's started functioning smoothly. It seems that SharePoint uses the ';' as a delimiter and was looking fro two groups (i.e 'Cars &amp' and 'Truck Owners') to assign the workflow task to. Since these groups didn't exist it started erroring out.

Technorati Tags: SharePoint,Approval Workflow,Error Encountered

Invalid host file on index server when using a dedicated crawler

shehan — Thu, 19 Mar 2009 19:07:25 GMT

Incase you didn't know- when you set your index server to use a dedicated server for crawling, SharePoint updates the host file on the index server with the IP address of the WFE. However, there are times where SharePoint adds an invalid host entry when there are 2 or more WFE's.

Example - Say there have 2 WFE's - MOSSWFE01 & MOSSWFE02. Setting MOSSWFE02 as the dedicated crawler will cause SharePoint to update the host file in the index server. It adds an entry for MOSSWFE01 with the IP address of MOSSWFE02. Hence, the index server cannot access the index file location on MOSSWFE01. No use trying to update the host file manually since SharePoint reverts your change every few minutes.

With the invalid host file entry you'll start seeing errors on both the index server and the WFE (see below). The errors are due to the index servers inability to propagate the index file to the WFE. If you modify the index server to use all WFE's for crawling then no entries are added to the index file.

I couldn't find a supported resolution for this, but there is a 'hack' to overcome this! Instead of setting a dedicated crawler, select the option to use all WFE's for crawling. Next open the host file on the index server and add the host names of the web apps along with the IP address of the WFE you want to act as the crawler.

Here is the TechNet article on this:http://technet.microsoft.com/en-us/library/cc261810.aspx

Error on WFE:

Description:
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (4d1c24af-411b-42b0-9f05-f657644e7d4b).

Reason: Object 0ad5f391-9f4b-4f49-8f85-3550343690e1 not found.

Techinal Support Details:
System.Collections.Generic.KeyNotFoundException: Object 0ad5f391-9f4b-4f49-8f85-3550343690e1 not found.
   at Microsoft.Office.Server.Search.Administration.SearchApi.get_App()
   at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
   at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Error in Index Server:
Description:
The Execute method of job definition Microsoft.Office.Server.Search.Administration.AddQueryServerJob (ID bcd3ce3e-b058-46ef-81a9-1bda53fa6c45) threw an exception. More information is included below.

Index location '\\MOSSWFE01\searchindexpropagation' not found on indexer 'M0SSWFE1'. Aborting query server deployment for application SharedServices1.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Technorati Tags: Search,Host File,Index

Manually uninstalling WSS

shehan — Thu, 24 Jul 2008 03:04:33 GMT

Had a situation the other day where, after playing with the different installing options, WSS would not uninstall. Even running the repair option was of no help.

Searching the net for solutions I came across this.

Here are the steps I did:

Disable and Stop the following services (If any):

Windows SharePoint Services Administration
Windows SharePoint Services Search
Windows SharePoint Services Timer
Windows SharePoint Services Tracing
Windows SharePoint Services VSS Writer

Backup and then delete the following registry hives:

HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\WSS

Delete the following folders:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12

Reinstall IIS

Drop the Config and any Content DB's created

After following the steps above you will notice that the entry for WSS in Add & Removed Programs is no longer there. Now you can go-ahead and run the installation again.

Technorati Tags: SharePoint,WSS,uninstall