Jingmei Li's MSDN Blog : Troubleshooting

SQL Server 2005 Maintenance Plans and MOSS 2007 Databases

jingmeili — Mon, 26 Feb 2007 22:45:00 GMT

Earlier I saw one crawling error in my customer's new MOSS environment after upgraded from SPS 2003. It's not necessary related to the upgrade though.

I saw the following error in the crawl log:

sps3://domain.company.com
Exception from HRESULT: 0x80040E2F (Exception from HRESULT: 0x80040E2F)

From the event viewer on the index server:

The start address <sps3://domain.company.com> cannot be crawled.

Context: Application 'sharedservices1', Catalog 'Portal_Content'

Details:

Value violated the integrity constraints for a column or table. (0x80040e2f)

I just found out there’s potential issue when there’s a SQL maintenance plan in place that rebuilds the indexes including SharePoint 2007 databases. The error we saw earlier about integrity violation (0x80040e2f) may occur after the SQL maintenance plan changes the index properties that SharePoint expects to be in place.

I would suggest that you change your SQL maintenance plans to exclude the SharePoint databases from receiving an Index rebuild. At least until more guidance is available from Microsoft on how to use SQL Maintenance and SharePoint 2007.

Our product team have reviewed the SQL maintenance tasks and have made the following recommendations.

Tasks Considered Safe

- Check DB Yes

- Shrink DB Yes

- Reorganize Indexes Yes

- Cleanup History Yes

- Update Statistics Yes but unnecessary since timer service does this automatically.

- Rebuild Indexes No, if the task that ships with SQL 2005 management studio is used. Using scripts that restore all options is allowed.

Although this known issue seems to the cause of my customer's crawl error but before we tried contacting the Premier support for a fix, we worked around the issue and now the crawling and people searching are working just fine :-).

The trick we did was:

Delete the existing People scope from Search settings, re-create a new People scope using the exact same settings as before. Restart the full crawl. The People scope should display a non-zero number of items. When it failed, it displayed 0 items in the View Scopes area.

The maintenance plan issue is still a good thing to know for future reference and I would try to pay attention to additional advice from Microsoft for this.

Common security related errors in MOSS 2007

jingmeili — Mon, 26 Feb 2007 22:27:00 GMT

Access denied error when clicking Edit Schedule in Content Sources and Crawl Schedules within Search Settings.

It's a known issue. Here's the fix http://support.microsoft.com/default.aspx?scid=kb;en-us;926959&sd=rss&spid=11373

Event Error with ID 6482 on Search query server(s)

Error description: Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (1a646aac-52e4-4742-8bea-fd2dc3d87249).

The error may be a result of Group Policy setting and can be resolved by giving “logon as a batch job” permission to Farm and SSP accounts.

Access denied when clicking Search Usage Reports in SSP admin

Click here for my blog from earlier on this issue.

More to be added...

Search Usage Report in MOSS SSP Admin prompts for credentials and .NET 2.0 Fatal Execution Engine Error is seen in the Event Log

jingmeili — Mon, 26 Feb 2007 22:22:00 GMT

My customer's new MOSS production environment has been upgraded from SPS 2003 and went live this morning, yes!

Some minor issues remain though.

Here's one SSP issue I just fixed temporarily.

I went to the SSP Admin site, clicked on Search Usage Report under Search section, then I was prompted for credentials. I tried putting in all kinds of accounts including the SSP app pool account but nothing worked. Eventually it errored out with 401.1 access denied page.

When I looked at the Event Log in the Central Admin server, I saw the following error:

Event Type: Error
Event Source: .NET Runtime Event
Category: None
Event ID: 1023
Date: 1/26/2007
Time: 10:01:42 AM
User: N/A
Computer: MOSS02
Description: .NET Runtime version 2.0.50727.42 - Fatal Execution Engine Error (7A05E2B3) (80131506)
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

I looked it up and seems like this is a bug in .NET 2.0 and there's a HotFix for it.

http://support.microsoft.com/kb/913384

The error occurs when there's a no user profile associated with the application user account context.

So the official solution would be obtaining the hotfix and see if that fixes the problem. In the meantime I just worked around the problem by adding the SSP account to the local admin group on the Central Admin server. Right now if I login to the SSP admin using the correct SSP account and then click on Search Usage Report link under Search, I can see the Search Queries Report.

People Picker in MOSS 2007 can't find people in non-default domains

jingmeili — Mon, 26 Feb 2007 22:01:00 GMT

Customer is seeing the following behavior:

"We went to SSP and clicked on User Profiles and Properties under the “User Profiles and My Sites” section and then clicked on View Import Connections and then added domain1.company.com to the Import Connections list and I started a full import. It completed in about an hour and imported users from the domain1 domain.

The problem we run into is that when I go to add them to a site to give them access, we are unable to find the users by using People Picker. We only find users from the domain0 domain which the moss server is on. "

I found out that by default People Picker can only find people in the resource domain - the domain that MOSS servers are in. For other domains/forests, you'll need to run the following command:

Stsadm.exe –o setproperty –pn peoplepicker-searchadforests –pv <list of forests or domains> -url <webapp>

The format of <list of forests or domains> is a list of

forest:DnsName,LoginName,Password

domain:DnsName,LoginName,Password

separated by semicolon.

If they are trusted domains/forests, then it is not necessary to pass in the LoginName or Password, just in the format of

forest:DnsName

domain:DnsName

If the Password is specified in the forest:DnsName,LoginName,Password or domain:DnsName,LoginName,Password, please run

stsadm.exe -o setapppassword -password <somekey> first. <somekey> could be any string. We will use <somekey> to encrypt the Password in domain:DnsName,LoginName,Password or forest:DnsName,LoginName,Password and stored the encrypted Password in the database. Also, please use the same <somekey> to run stsadm.exe -o setapppassword -password <somekey> on all machines where SharePoint is installed. For different web farm, please use different <somekey>.

*Note: My customer's problem still remains after running the command due to some "invalid binder credentials" issue in their Global Directory. I'll post an update later.