Archiwa tagu: central administration

SharePoint: backup failed – the current operation timed-out after 3600 seconds

Hi,

A short though maybe a helpful one:

Symptoms:
1. MOSS 2007 central administration states: backup failed. One or more databases weren’t properly backed up.
2. Backup logs contain following message:

Error: Object Shared Search Index failed in event OnPrepareBackup. For more information, see the error log located in the backup directory.
WebException: The current operation timed-out after 3600 seconds

3. Similar message (timeout) regarding the SSP’s database.
4. SSP administration page indicates one or more apparent  endless crawls running, on content sources which are rather small.

Resolution:
1. Restart the Office SharePoint Search service.
2. Clear search index – reset crawled content in SSP’s search administration.
3. Start full crawls on your content sources.

Best,
Łukasz

Posted from WordPress for Android

“The specified address was excluded from the index”

Hello,

an issue that occurred recently was that a content source within our SSP for search (MOSS 2007) did not include any items. The crawl log of the SharePoint’s Central Administration stated the following:

The specified address was excluded from the index. The crawl rules may have to be modified to include this address. (The item was deleted because it was either not found or the crawler was denied access to it.)

Interestingly, some of the content sources we already had before were crawled without any obstacles, thus the (mis)configuration of the problematic application seemed suspicious. After checking the permissions of service accounts involved in the crawling process (not the cause), and after comparing the settings between the apps (not the cause as well) – the problem was in the crawl rules set up for this content source. The option for crawling complex URLs hasn’t been activated for the subdomain URL we wanted to crawl. Enabling the “Crawl complex URLs (URLs that contain a question mark (?))” option under Shared Services Administration: SSP > Search Administration > Crawl rules > Add or Edit Crawl Rule and starting the full crawl from the beginning solves the problem.

But still the question was, why the non-complex, normal URLs could not be crawled by the service. The cause was in our IIS configuration, which is globally set up to automatically detect cookie mode for session state. This results in appending a query string parameter to the URL at first request. So that the URL looks similar to this: http://www.ourdomain.com/index.html?AspxAutoDetectCookieSupport=1 .

Now it seems pretty clear why the crawler without the rule mentioned before had problems. It failed at the first request to the root URL, since the rule has not been met. Hence, it could not continue crawling and left the index empty with the error/warning message.

Hope this helps,
Łukasz

SharePoint: access denied when trying to copy a list (item)

Hey there,

Lately, while trying to copy a SharePoint list from one site to another (or later also single list items), I got this infamous “Access denied” SharePoint error. At first of course the idea is to log in as a super-user. But when this operation failed also with the account of Site Collection Admin and/or Site Owner role, it seemed less trivial than just a missing permission within the site collection.

Unfortunately, a quick jump into the SharePoint logs didn’t bring me much further:

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

Since this problem has occurred in more than one application on our SharePoint server, I was assuming it to be a global misconfiguration. Hence, had to check out the Central Administration. There was the solution:

In Central Administration > Operations > Service Accounts I checked which account actually is responsible for the communication with Windows SharePoint Services on our server. So, in the Web application pool section, I selected the WSS Web application and the application pool of the application which was giving me this “Access denied” message.

The account was the predefined one – the Network Service.

There’s the rub! Since we’re using own domain accounts for such cases and only they’re enabled to access the WSS, the Network Service account was actually getting the “Access denied” message (when trying to connect to one of the SharePoint Web Services).

Changing the account from predefined one to the configurable one with our username and password did the trick. I just had to do an iisreset after this change.

Probably this solution also fixes some other problems we might have encountered, where the communication between application and WSS would fail.

Hope this helps,
Łukasz