Sharepoint Administration

IIS Service Unavailable

Paul Lee — Wed, 09 Dec 2009 19:39:00 GMT

I found a great post on how to troubleshoot the "503 Service Unavailable" error.

http://blogs.iis.net/brian-murphy-booth/archive/2007/03/22/how-to-troubleshoot-an-iis-event-id-1009-error.aspx

I'm putting this link up mostly so I can easily find it next time I have this issue. :)

Sharepoint cannot resolve AD security group

Paul Lee — Tue, 21 Jul 2009 22:15:04 GMT

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.

MOSS - corrupt memory errors

Paul Lee — Mon, 08 Jun 2009 16:26:38 GMT

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:

Event ID 6398

Event ID 6482

Event ID 7076

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

Sharepoint Datasheet view errors

Paul Lee — Fri, 01 May 2009 15:42:38 GMT

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

Stsadm createsite doesn't create default groups

Paul Lee — Wed, 29 Apr 2009 21:11:53 GMT

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:

/_layouts/permsetup.aspx

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.

Sharepoint Crawls stop working - Part 2

Paul Lee — Thu, 23 Apr 2009 01:38:03 GMT

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...

Sharepoint lists stop receiving emails

Paul Lee — Wed, 22 Apr 2009 17:47:45 GMT

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?

Sharepoint crawls stop working after server patch

Paul Lee — Wed, 22 Apr 2009 16:18:39 GMT

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:

Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (0x80041205)

My error from the crawl logs:

Deleted by the gatherer (This item was deleted because its parent was deleted.) Huh?

The fix

Apparently, now you have to Disable the Loopback Check.

- Open regedit

- Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

- Under Lsa, create a DWORD value called DisableLoopbackCheck

- In Value, type 1

- Close regedit

Crawls work as normal.

Update:

I wrongly blamed the Feb CU for this. It was just a coincidence as I see the problem with one of my servers without the patch. I'm now thinking it was one of the recent (conflicker?) patches put on by the server boys...