Some things to try first:
- Running an incremental crawl again
- Running a full crawl
- Adding a crawl rule specifically for that site, then running an incremental crawl
In our case, we did not want to do full crawl in production because we didn't want to lose any more of the index (we have problems with the full crawl.. but that is another story). For most people, I think that is the recommended option.
Unfortunately, nothing was working so we had to take drastic measures.
First a warning.. Always have backups, use a non-production environment and do this at a time when you won't impact your users. 1
- Create a new content DB for the site collection in pre-production
- Create a BLANK site collection in the new content DB (so that it gets a new site ID)
- Restore using STSADM and overwrite the blank site collection with the backup
- Delete the site collection from production using STSADM
- Run STSADM -o enumsites to make sure the site is really deleted
- Restore the content database to production using SQL backup/restore
- Add the content database to production using addcontentdb (always use STSADM command, not central admin!)
Restoring the site didn't work because the site collection wasn't actually deleted. We ran into two issues:
- We couldn't see the site collection in the new content database. Turns out this was caused by #2...
- Deleting the site "failed" with HRESULT: 0x80070003 issue
- After getting the site actually deleted, restoring the site to the same URL resulted in the same crawl error
In retrospect, however, I think the addcontentdb command would have actually worked if the site collection was actually deleted. This is why I recommend running stsadm -o enumsites after deleting the site collection.
We then tried restoring the site to a different URL. Then it started working and we got results. However, restoring to a different URL is causing RDL reports to fail (the site is integrated with Report Server).
We had to setup all the data sources and upload all of the RDL reports again.
1. Technically you could do this directly in production without the need for the SQL restore between environments.. However, I think "better safe than sorry" applies here. Plus this way you can test it out first. :)