andrewmilsark.com

Problem

If you are seeing 401.1 unauthorized event log entries by the SharePoint Gatherer in your event log, this article may be what you've been googling for.

Are you able to browse to your sharepoint site from the server logged in as the search crawling account?  No luck?  Keep reading.

Reason

With the Windows Server 2003 SP1 ( or possibly just the .Net Framework 3.5 SP1), Microsoft introduced a new security feature that checks for loopbacks (making calls to web applications locally from thet server).  If your search service is running on the same server that is hosting your web applications (which is best practice for indexing speed), you'll most likely recieve this unauthorized error.  You may also see this error for any custom applications which use the SharePiont web services locally. This security fix is meant to block malicious applications from infultrating your web sites from within, which is a good fix in my opinion.

How to I get around this 401 unauthorized then?

Microsoft recommends two fixes.  Both of them are registry modifications.

One turns off the Loopback check altogether which shouldn't be done on external facing production servers for obvious reasons.  The other is to specify the sites that allow loopback from the server.

Here's the instructions for the registry modifications required for both methods:

MS KB Article 896861

Tags: sharepoint, wss 3.0, sharepoint search, disableloopbackcheck

Microsoft SharePoint (WSS 3.0) search is probably one of the most common points of failure and source of support tickets for our customers.

Here are some of the major points to check when troubleshooting this service.

1. Make sure the content database is assigned an indexer.

      Open SharePoint Central Administration > Application Management > Content Databases

      Select your web application if it is not already selected.

      Click on the content database. 

      Make sure that the Search Server dropdown has the servername selected which is running the WSS Search Service.

2. Make sure you have implemented the DisableLoopbackCheck registry entry.

     Check out this blog post.

3. Make sure your search service is running as a domain account and that the account credentials were entered correctly (with DOMAIN\serviceaccount) in Central Administration.

4. Make sure your alternate access mappings in the default zone are accessible from the server.

5. If using forms authentication, use windows authentication in the default zone, and then extend the web application to the internet zone which uses forms. 

6. If pdf files are not being indexed correctly on 64bit systems, there may be a registry entry that you are missing.

    Note there is an extra registry GUID change for the 64bit Adobe I filter.  Here'a a link to a well written post : Here

7. After all these are verified and\or changed to the correct configurations, run an stsadm full crawl.

    This is performed by opening a command promt  on the server running the Windows SharePoint Services Search Service then:

    Type cd C:\program files\common files\microsoft shared\web server extensions\12\bin

    Hit Enter

    Type stsadm -o spsearch -action fullcrawlstart

    Hit Enter

    Your content should begin the indexing process

    Check the event lot to see if the 401 unauthorized messages have gone away.

I hope this helps you guys out there in the field.

Tags: sharepoint, wss 3.0, sharepoint search

The fabulous 40 site templates are a set of Sharepoint site templates released by Microsoft that provide enhanced functionality to sharepoint without developing custom sites and lists. 

Some examples of sites that come in this package: 

Absence Request and Vacation Schedule Management, Help Desk, Budgeting and Tracking Multiple Projects, Inventory Tracking, Bug Database, IT Team Workspace, Call Center

We have encountered an issue on our server farms that have these templates deployed.  It seems as though the deployment package does not deploy some of the US English resource files to the sharepoint resources directory (C:\program files\common files\Microsoft shared\web server extensions\12\resources).

If you see errors in the Sharepoint logs like: "Cannot open tsa.en-US.resx: no such file or folder" I can help you out.

To resolve this issue, you'll need to deploy the resource files  to their required location.

It turns out that the English resource files are actually deployed, but they are named incorrectly.  From my Sharepoint development background in multi-language software, it is a common mistake to  to leave your default English .resx file named xxxx.resx.  Sharepoint requires xxxx.en-US.resx to load the English resource strings for English regional settings in its applications.

So enough background, let's fix this thing!

Open up the command prompt WSS 3.0 or MOSS Web Front End server:

Start > run > cmd

Change the directory to the sharepoint resources folder

cd /d "C:\program files\common files\microsoft shared\web server extensions\12\resources"

Then make copies of the resources files with the copy named with a xxxx.en-US.resx

copy avm.resx avm.en-US.resx
copy compproc.resx compproc.en-US.resx
copy ep.resx ep.en-US.resx
copy er.resx er.en-US.resx
copy hlpdsk.resx hlpdsk.en-US.resx
copy itteam.resx itteam.en-US.resx
copy proj.resx proj.en-US.resx
copy pws.resx pws.en-US.resx
copy rer.resx rer.en-US.resx
copy tsa.resx tsa.en-US.resx

 And there you have it, you should have all the required English resource files in their required location.

Also note that you can create a batch file with the above commands if you have multiple web front end servers to speed up the fix.

I hope this helps someone!

Tags: sharepoint, wss 3.0, moss, fabulous 40, site templates