Paul Lee

I've fixed this error so many times and have had to search the internet for the fix everytime that I've finally decided to log it into my own blog.  Mainly so I can easily find it. 

Here's the problem.  As a general rule, all https applications do not cache any pages for security reasons.  This leaves the issue of downloading files from a https site.  For example, if you try to download a file (pdf, xls, doc, etc) from any site, your computer will download it to cache before opening it with the associated application.  So specifically in a Tomcat ssl site, you will get this error (or something like this):

Tomcat is automatic adding a Pragma: no-cache header to your page.  Here is the link with the fix. 

So where ever the <context> of your web application is defined, you want to add something like this:

<Context>
<Valve className="org.apache.catalina.authenticator.BasicAuthenticator"  disableProxyCaching="false" />
</Context>

And of course you can change BasicAuthenticator to FormAuthenticator or DigestAuthenticator depending on what you are using. 

Hopes this helps someone.

I was banging my head against the wall over this one for a few days.  There was a particular AD security group (over 1000 users) that sharepoint could not resolve.  Nothing about it (so I thought) was different than any of the groups that sharepoint could resolve.  Same setup, OU and everything.

Finally, I realized that the Alias name was not the same as the standard object name which is called the "Pre-Windows 2000" name in Active Directory. 

In 99% of all the cases, these are the same.  For some reason, this time they weren't. 

Hope this saves someone some grief.

Today my index server started to show this error in the event logs:

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

More or less the same error in three separate events:

I did a quick search on the web and found this fix: http://support.microsoft.com/default.aspx/kb/946517

Seems to work but I'm still not sure why this started to happen all of a sudden. 

My environment: Server 2003 SP2, MOSS SP1, Feb CU

Here's the error from one of my users:

The list is displayed in Standard view. It cannot be displayed in Datasheet view for one or more of the following reasons: A datasheet component compatible with Windows SharePoint Services is not installed, your browser does not support ActiveX controls, or support for ActiveX controls is disabled.

This just started happening this week.  Only for one user.  No recent patches on the sharepoint server.

If you search this on the internet, you get tons of results but nothing simple.  I went through this good article, http://www.sharepointblogs.com/wsspectacular/archive/2008/04/14/when-datasheets-go-bad.aspx but nothing worked.  Frustrating....

Then a local IT guy asked me if I tried clearing the Internet Explorer cache.  Tried it and it worked!!!

Lesson: Try clearing the IE cache first before trying all the other stuff.  May save you alot of time.

Server environment:  WSS 2.0, server 2003

Client environment: XP, Office 2003

If you use:

     stsadm -o createsite [required fields] -sitetemplate STS#0

to create your site collections, the default groups are missing (Owners, Visitors, Members). 

If you create your site collections without the -sitetemplate option, when you first visit the site, you get a page to choose a site template followed by a page to to setup the default groups for the site.  Nice.

If you're like me, you create 50 sites with the -sitetemplate option before figuring out there are no default groups.... 

So what I figured out was that you can paste this to your groupless site collection url:

This will get you to the default group creation page.  Just click OK.  Hopes this helps someone.

My environment: MOSS with Feb CU on server 2003.

Environment: SIngle server farm - Windows 2003 - MOSS SP1

I found another server with the same "access denied" error in the crawl logs.  So I applied the Loopback fix but then another error:

The system cannot find the path specified. (Exception from HRESULT: 0x80070003)

After searching the internet, I found the solution.  You have to make sure the "gthrsvc" folder exists under your search account's Temp directory.  Then restart the search service. 

CMD> net stop osearch

CMD> net start osearch

Then run full crawl.  Worked for me. 

I think this is another side effect of one of the recent server patches.  This particular server has been around for a while and the crawls never had a problem until now.  Going to check the rest of my MOSS servers now...

Got woken up this morning by frantic people in Amsterdam.  Their document libraries stopped receiving emails! 

First thing I checked was to make sure emails were still making it to the sharepoint server.  To the IIS drop box at least...  So I sent a test email there.

Yep, they were definitely getting there.  And they were disappearing too so that means the timer service was working and picking them up.  So where the hell were they going? 

So I throttled the email events:

After sending another test email, here's what showed up in the event logs:

Event Type: Warning
Event Source: Windows SharePoint Services 3
Event Category: E-Mail
Event ID: 6873
Date:  4/20/2009
Time:  3:15:26 PM
User:  N/A
Computer: XXXXXXXXXXX
Description:
An error occurred while processing the incoming e-mail file C:\Inetpub\mailroot\Drop\f83e047f01c9c1b9000000bb.eml. The error was: Unknown alias..

The event type was Warning.  This is just a Warning?!?!?

Here's what I found out before calling premier and before doing any more research on this.  If you go to the Incoming email settings of the document library:

You can just click OK on the settings page without changing anything and emails will magically start working again.  Wow.  What a fix!  The best thing is that the end users can do this themselves.  :)  So I called them and asked them to go to each of the document libraries and do this. 

Here's the real cause and fix for this after doing some research.  Occasionally, the email addresses in the config db can get deleted (corrupt) without warning. 

The quick fix is:

stsadm -o refreshdms -url <url of web application>

The permanent fix is to install the hotfix http://support.microsoft.com/kb/961750 or even better, install the Feb CU and get it over with.

Apparently, if sharepoint doesn't know what to do with an email or there is some kind of error (or warning) it will just be launched into orbit.  Never to be seen again.  Shouldn't it go into the Badmail folder or something?

Environment: MOSS SP1 with Feb CU - WIndows Server 2003

I noticed this issue today after installing the Feb CU last week.  The sharepoint crawler was not crawling any sites that had a DNS alias to itself.  For example, my servername was myserver01 and I have a DNS alias called myportal.  The crawler would not crawl http://myportal and anything under it.  This sucks. 

My error from the event viewer: