MOSS: The system cannot find the file specified

Problem:
When having two WFE servers configured so that one acts as Search Indexing server and the other acts as Search Query server, you get multiple errors in event log and the search does not work.

On the Indexing server, errors are:

10038: Query machine 'IndexingServer' has been taken out of rotation due to this error: The system cannot find the file specified. 0x80070002. It will be retried in N seconds. Component:

10039: Retry of query machine 'IndexingServer' has failed with error: The system cannot find the file specified. 0x80070002. It will be retried again in N seconds. Component:

10040: The last query machine has been taken out of rotation. Check previous event logs to determine cause. Propagation may be necessary. Component:


On Query Server the errors are:

6482: Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance ().
Reason: Object not found.
Techinal Support Details:
System.Collections.Generic.KeyNotFoundException: Object 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)

10039: Retry of query machine 'QueryServer' has failed with error: The system cannot find the file specified. 0x80070002. It will be retried again in N seconds. Component:

Solution:
Make sure the permissions are set correctly. More exactly see that the Farm Search Service Account is in Administrators group and in WSS_ADMIN_WPG group on the Indexing and Query servers. After that stop and start the Office SharePoint Server Search service in Central Admin.

MOSS: Cannot define same Internal and Public URL in AAM

Background:
We have a LB (Cisco CSS11503) in front of our two WFE's. The LB device functions also as SSL Offloader. The URL of our service for the internal users is https://service.company.com.

Upon page request, SSL Offloading and load-balancing takes place on Cisco, and the requests are redirected to one of the WFE's. Cisco device cannot modify the HTTP-Header of the request, so while the requests are redirected to one of the WFE's, the Request-URI of the request itself is the same FQDN but with http protocol, http://service.company.com.

Problem:
There are some good blog posts about how to configure MOSS AAM in NLB senarios. However, none of them explains how to make the previously mentioned case working. In AAM you just cannot define (or so it seems) Internal URL FQDN to be the same as Public URL FQDN so that in Internal URL the protocol is http and in the Public URL the protocol is https.

Solution:
The order in which you define the URLs is important. The key is that you must first have a single URL in a zone which is using https protocol. After that you may add another URL and define it's protocol to http.

1. In the beginning you only have one URL defined, and this URL is the one you want to use, but you just would like to have the Public URL for Zone URL to say https://service.company.com.





2. No worries, select the Internal URL link http://service.company.com and change the Internal URL to https://service.company.com (or something else than the URL you want to use for the service), click OK.





3. Select "Add Internal URLs" link and type in the http-URL of your service, http://service.company.com, and select Default zone. Click Save.





Now you have the same FQDN for the service, but different protocol in Internal and Public URLs.

We did also define "Front-End-Https: on" header on Cisco, but I don't know if it is required.

MOSS: Deleting site gives error message

Problem:
When deleting a site, you get error: 500 INTERNAL SERVER ERROR. Error is just black text on white background, nothing else.

Some errors are logged into MOSS log:

There is no Web named "/SiteA/testi/_layouts/webdeleted.aspx".

Possible mismatch between the reported error with code = 0x81070504 and message: "There is no Web named "/SiteA/testi/_layouts/webdeleted.aspx"." and the returned error with code 0x80070002.

Thoughts:
Simple.master page has been altered to brand the layout of different pages, which is causing the problem.

Workaround:
Revert Simple.master to original version that came with MOSS.

Solution:
You cannot have

<wssuc:Welcome id="IdWelcome" runat="server" EnableViewState="false"></wssuc:Welcome>

on the simple.master page. Remove it and it works, if not, remove controls from the page one by one until you find out the one causing the error.

MOSS: Backup and restore path-scoped and host-scoped site collections

Problem:
You cannot backup a host-based site collection and restore it as a path-based site collection. For example, you cannot backup site collection from http://service.company.com and restore it to http://anotherservice.company.com/sitecollection.. You could restore it without problems to http://anotherservice.company.com.

The backup and restore procedures will most probably succeed, but you will run into strange "File not found" errors when accessing some sites. Some sites work fine, but others give the error. When you run IISRESET sites that were working might start giving the error as the sites that were giving the error might start working.

Workaround:
According to MS Support, the site structure must be the same in source and destination environments. So, what it means, is that you cannot really use stsadm backup/restore for moving content between different environments if the structure of the web applications differ.

According to MS Support, the following steps should function as a basis for a workaround, although I haven't tried it. Basically what you do is that you alter the web application site collection structure in source environment before taking the backup. If you have tried this and it worked, please let me know.

Source environment:
Site collection 1: http://serviceA.companyA.com
Site collection 2: http://serviceB.companyA.com

Destination environment:
http://serviceA.companyB.com/serviceB
(where http://serviceA.companyB.com is site collection 1 an /serviceB is site collection 2)

So, the two site collections are backed up from source environment and combined under the same URL in destination environment so that source's site collection 2 is located under the site collection 1.

And finally, the steps for the workaround:

1. In source environment, create another site collection underneath the Web application where your site collection 1 is located (http://serviceA.companyA.com/serviceB)
   
2. In source environment, backup site collection 2
   
3. In source environment, remove site collection 2, the web application it belonged to and associated Databases
4. In source environment, restore the backup of the site collection 2 to the new site collection you created under site collection 1 (http://serviceA.companyA.com/serviceB) in step 1.
   
5. Backup and restore to the destination environment.

Solution:
Unknown