Archive

Archive for June, 2009

Conficker Virus Fix Problems

June 26, 2009 Leave a comment

I received an email from a user saying that newly added documents were not showing up in the search results. I opened up Central Admin and the Crawl status was “Error” – and the Active crawls and Recently completed crawls were blank –

Even worse, clicking on “Content sources” returned a 404 Forbidden page. The Event Viewer was a red dot horror story.

Something had changed. We had recently migrated SharePoint 2007 sites from a farm that will shutdown to our new SharePoint farm. I thought there might be some problem with permissions, causing the crawler to fail. While the problem is a permissions problem, it was not a SharePoint permission problem. I checked our test server and found the same errors. This is a MOSS install. There were both Windows SharePoint Search Service and Office Search errors.

These errors also affected SharePoint search capabilites. The scopes stopped working, unless they were site level scopes. ‘All Sites’ searches returned no results – with a note that “Scope in your query does not exist.”

I did som Google searches, and got all the usual stuff about account rights and CSLID errors. Next I checked our test server. It has the exact same code base, but is on a single server (production has one WFE and one Application server). Same errors. Since we had not performed any imports into test when these errors started, I knew there was an external cause.

I discovered that the LAN team (who had been struggling with the conflicker virus) had changed a Group Policy that did not allow write access for System and Administrators to the c:\WINDOWS\Tasks directory. A quick search revealed the following link –

http://www.sharepoint911.com/blogs/john/archive/2009/04/03/change-to-group-policy-broke-sharepoint-search-%E2%80%93-thanks-conficker-scare.aspx

However, the fix used here did not work in our environment (the fix suggested is to give write access on the directory to WSS_WPG). This could be because of the way they installed SharePoint and exactly what service accounts they used – the memebers of the group WSS_WPG might be different from ours).

On SoapBox

Installing SharePoint would be much cleaner and easier if Microsoft would use the same name for the same account on all screens and documentation REGARDLESS of whether you are installing WSS or MOSS.

Off SoabBox

The only way we could resolve the error was to remove the restrictive Group Policy.

Categories: SharePoint 2007

SharePoint Search Results Are Empty!

June 10, 2009 Leave a comment
I deployed SharePoint in a multi-language environment (French and English). This was a medium size farm, with a dedicated index and query server. Since my French is almost non-existant, we enlisted the help of a Canadian quality manager to help set up the sites that were required for the Quebec employees.

I installed the French language packs for both WSS and MOSS. Once a site is created in a language, it is always in that language. I worked with the quality manager to define the sites that would be needed for the French speaking employees and showed him how to create sites, document libraries, add content, create metadata etc. He dove right in and started creating French sites and libraries, and loading documents.

He emailed me about a week later complaining that the SharePoint search did not work correctly. He was correct – search returned results for documents in a document library that was located in a subsite only if you were not in that subsite (or the document library containing that document). In otherwords, if you searched from the top level site, you would see the correct results. If you navigated to the site containing the document library and used the scoped search, no results would be returned.

The problem turned out to be URL related. The Canadian manager used ‘special’ characters (with accentegues) in the URL when the sub site for ‘Qualité’ was created. So a search for ‘feuille’ –

 
Categories: SharePoint 2007 Tags:

Search Results Empty

June 9, 2009 Leave a comment
I deployed SharePoint in a multi-language environment (French and English). This was a medium size farm, with a dedicated index and query server. Since my French is almost non-existant, we enlisted the help of a Canadian quality manager to help set up the sites that were required for the Quebec employees.

I installed the French language packs for both WSS and MOSS. Once a site is created in a language, it is always in that language. I worked with the quality manager to define the sites that would be needed for the French speaking employees and showed him how to create sites, document libraries, add content, create metadata etc. He dove right in and started creating French sites and libraries, and loading documents.

He emailed me about a week later complaining that the SharePoint search did not work correctly. He was correct – search returned results for documents in a document library that was located in a subsite only if you were not in that subsite (or the document library containing that document). In otherwords, if you searched from the top level site, you would see the correct results. If you navigated to the site containing the document library and used the scoped search, no results would be returned.

The problem turned out to be URL related. The Canadian manager used ‘special’ characters (with accentegues) in the URL when the sub site for ‘Qualité’ was created. So a search for ‘feuille’ –

returned this –

The problem is the URL for the site –


does not match the encoding for the result page (OSSSearchResultes.aspx) –

http://artie/canada/quebec/laval/qualité/_layouts/OSSSearchResults.aspx?k=feuille&cs=Ce%20site&u=http%3A%2F%2Fartie%2Fcanada%2Fquebec%2Flaval%2Fqualit%C3%A9


Solution – I changed the URL for this site to be ‘/canada/quebec/laval/qualite’ and then performed a full crawl on the SharePoint sites.

Categories: SharePoint 2007