The SharePoint Farmer's Almanac : Error Messages

Fixing MOSS Search

Shane — Mon, 13 Apr 2009 14:56:13 GMT

Had a client today (last week now) who broke search all the way. And in their attempts to straighten it out they changed some pieces that weren't broken. Then while they were in the process of trying to put it all back together I called and said let me at it so they just stopped. Needless to say I picked up the farm in an odd state or more exactly Search was dead.

So the first step always when Search is broke is to go to the SSP Admin and check out things.

Open the SSP Administration page
Click on Search Administration and see what it has to say. (if you don't see Search Administration this means you have not installed the infrastructure update. I would highly recommend at a minimum you have that installed. Get the latest update install guide here)

When I opened the page I saw a Crawl status of Error. That is about worthless.

That is pretty much as generic as they come. You get the same Error when the server is on fire as you do when there is small hiccup. So a much better thing to do is:

Go back to the SSP administration page
Click on Search Settings (which is what we used pre infrastructure update)

This page does a much better job of giving you tangible errors. Here is what I got:

Error: An indexer is not assigned to the Shared Services Provider 'SharedServices1'.

Link to: Configure an indexer and a search database for this Shared Services Provider

Well that is fixable but how did they end up like this? They stopped the Indexing service in the farm by:

Go to Central Admin
Click on Operations
Click Services on Server
They choose their Index server
Then clicked Stop to the right of Office SharePoint Search Service

This doesn't just stop the service. This actually removes the service completely. This also removes the Index server from any SSP configured to use it. Now if you did want to just start and stop the service there is a way to do this:

Open a command prompt
Type net stop osearch and press enter
Type net start osearch and press enter

This will cycle the search service. Usually the only time you need to do something like this is after installing a new ifilter but sometimes it makes you feel better to give it a shot and see if that helps your problem. I do it more often than I should just for that reason.

Back to the task at hand clearing up that error! I double checked and they had already reconfigured the Office SharePoint Search Service on the Index server so all I need to do is go back to the Index server and re-associate the indexer.

From Central Administration click on Shared Services Administration from the left hand side of the page.
Hover over the SSP name, click the drop down arrow and click Edit properties

Scroll to the bottom of the page and select your Index server from the Index Server dropdown. If you see No Indexers in red you need to go back to your Services on Server and make sure you have the Office SharePoint Search service started and configured for the Index role.
Confirm that you have the correct index location. Usually the C: drive is less than ideal.
Click Ok

The SSP is now configured with an Indexer. Let's go make sure Search is happy.

Now click on the Shared Services Provider name to open the SSP admin site.
Click Search Settings

Don't be surprised if you get this error:

Error: The search service is currently offline. Visit the Services on Server page in SharePoint Central Administration to verify whether the service is enabled. This might also be because an indexer move is in progress.

Typically this is because the wheels of Search can move slowly. I have seen this error come up for 10 minutes or so in some farms. What Search is really telling you is it is busy getting the index and the database ready to go so you can start indexing. Be patient grass hopper. At the client this was gone after about 2 minutes.

Once I was able to get to a happy Search Settings page I went ahead and reset the Index back to zero. Not always necessary but they had 33,000 items in the index and 140,000 or errors. I thought better to start everything back to 0.

In order to reset the Index.

From the SSP admin screen click Search Administration
From the left hand column (quick launch for those who know terminology) click Reset all crawled content
Select Deactivate search alerts during reset
Click Reset now

Now you have a completely blank index. Why did we choose to deactivate search alerts? This is to keep from annoying the users. We don't want them all to get new alerts when new content is discovered when we recrawl in a minute. Once the index is back to normal we will re enable the alerts for them.

Ok so now the next step should be doing a full crawl. So let's try that.

From your SSP Administration home page click Search Administration
From the Quick Launch bar (on the left) click Content Sources
Hover over your Content Source, click the drop down arrow, and select full crawl
Now go back to the home page of Search Administration and watch to see if the crawl is running

Unfortunately in our case after about a minute I was left with 0 items in the index and 3 errors. After checking the errors I got Access Denied. L If you haven't done any monkeying around with changing your default content access account then it should have been automatically granted full access to your content source. You can confirm this by checking your Policy for web application in Central administration. If you forget how to do that check this blog post for a reminder. http://msmvps.com/blogs/shane/archive/2007/01/21/become-administrator-of-the-entire-web-application.aspx

If that checked out ok then the next thing I would check is to make sure your web application is set to integrated authentication and not basic authentication. MOSS will not pass basic authentication by default. So if you changed your web application from integrated to basic, so people users don't have to enter their domain for example, then you need to setup a custom crawl rule to pass basic authentication.

From your SSP Administration home page click Search Administration
In the Quick Launch bar click Crawl rules
Click New Crawl Rule
For path enter your web app URL ex: http://portal.company.com/*
For Crawl Configuration select Include all items in this path
For Specify Authentication select Specify a different content access account
Now fill in username and password remembering your domain\username form. I would recommended using your normal search account as you know it already has read access to the content.
Key step de-select the box to Do not allow Basic Authentication
Now do a full crawl. Also, remember if you have multiple web apps you may need more than one of this rules.

For the client this was not this issue but it is an important and often over looked troubleshooting step so I thought throwing it in here would be helpful.

The next thing I take a look at is the dreaded loopback fix. I showed this one to Todd Klindt one time and he wrote a nice post on the issue and a like to the KB for fixing it. http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=107 It is all but a guarantee these days if you have the WFE and Index role on the same server you are going to need to do this. A lot of farms have ran fine for a long time and just recently they have started requiring it. Must have been a Windows update that is causing this to be needed more but I haven't identified it. Another note even though this fix is only listed as applying to Windows 2003 it also applies to Windows 2008, had a different client need it last week. J

Loopback fix in and the server rebooted I tried another Full crawl. Success! Seems this was the root of their issues but as is often the case that happens to all of us, trying to fix it only made the problem worse. LOL

Don't forget to re-enable those search alerts.

From your SSP administration home page click Search Administration
In the System Status section in the center of the page click Search alerts status Enable

Another troubleshooting step I skipped, because the client had already done it was resetting search permissions. Read the blog post John Ross did summing up the steps to get permissions back on the up and up for the Search Service. http://www.sharepoint911.com/blogs/john/archive/2009/04/03/change-to-group-policy-broke-sharepoint-search-–-thanks-conficker-scare.aspx

Something I learned that was new

I am guessing since I didn't realize this is an option (or more probably I knew and forgot) you probably didn't either. So run stsadm –o help like below and take a look at the output.

Use Stsadm.exe from the 12 hive (c:\program files\common files\Microsoft shared\web server extensions\12\). Actually 12\bin to be exact.

C:\ >stsadm -help osearch

stsadm -o osearch

[-action <list|start|stop|showdefaultsspadmin>] required parameters for 'start' (if not already set): role, farmcontactemail, service credentials

[-f (suppress prompts)]

[-role <Index|Query|IndexQuery>]

[-farmcontactemail <email>]

[-farmperformancelevel <Reduced|PartlyReduced|Maximum>]

[-farmserviceaccount <DOMAIN\name> (service credentials)]

[-farmservicepassword <password>]

[-defaultindexlocation <directory>]

[-propagationlocation <directory>]

[-cleansearchdatabase <true|false>]

[-ssp <ssp name>] required parameter for 'cleansearchdatabase'

So really very similar to the options you have available to you from the GUI. The reason I used it was one of the Query servers was stuck in the starting state. In the GUI there is no stop until the service gets too started, not even a reboot will help. With stsadm you can do a stop and get out of the perpetual starting. J A very helpful trick.

If you are still fighting with Search here are couple of other Search troubleshooting things I wrote a while back

Hope you enjoy what feels like a small book

Shane – SharePoint Consulting

InfoPath Form displayed on anonymous site causes login prompt

Shane — Tue, 13 Jan 2009 01:54:24 GMT

Had this one pop up for a second time today so thought I would blog it this time.

Client created a public website for baseball signups. It was a simply publishing portal with anonymous enabled. He then created an InfoPath form and set it up to generate an email with the info from the form. He published this form to a form library using Forms Services and then embedded the form using a page viewer web part on a new ASPX page so people could just navigate and fill out the page.

The problem – the site would pop up an authentication box every time an anonymous person would visit the site. Even stranger if someone would get the authentication box and then enter proper credentials for the remainder of the day anonymous access worked fine. Then each morning back to the same problem. ODD.

Turns out the issue was the lockdown feature used with the publishing portal. Not everyone realizes it but when you create a site collection using the publishing portal there is a hidden feature that fires called ViewFormPagesLockdown. This feature, among other things, sets it so /_layouts directory is not available to the anonymous user. For more details see the ECM Team blog post. So we simply deactivated the feature and reset the anonymous permissions and life was good again.

One thing to pay particular attention to with this feature every time you toggle this feature on or off you need to disable and enable anonymous access for the new settings to take effect. That part can drive you bonkers.

Shane – SharePoint help

Windows Server 2008 WFE will not allow large file uploads

Shane — Wed, 17 Dec 2008 18:51:35 GMT

I had a client a couple weeks ago who upgraded from SPS 2003 to MOSS 2007 using the database attach method. This means the MOSS farm was built on new hardware which we chose Windows Server 2008 for. This was a very challenging upgrade for several reasons but primarly because the 2003 site database was in bad shape. Once we worked through the issues and got things up we noticed strange behavior. When uploading a large file (anything larger than 28 MB) the browser would instantly come back with a 404 error. So our first thought was check the three normal settings for large uploads.

Central Admin > Application Management > General web application settings. By default this is 50 MB. You can increase to 2 GB.
Then you can go into IIS. Find your web application and go to properties. Then change the IIS timeout from 120 seconds to a much larger setting.
Upload.aspx is an application page. Application pages have their own web.config which controls their timeout. The default for these pages is 360 seconds. You need to increase this.

All of these settings apply whether you are using w2k3 or w2k8 and are covered in this kb http://support.microsoft.com/kb/925083

We made all of those changes and no change in behavior. And besides we didn't have a timeout issue because on a 27 MB file is processed for a few seconds and then uploaded no problem. On a 30 MB or greater file it failed instantly.

Todd Klindt to the rescue he pointed me at this KB944981 - You cannot upload files that are larger than 28 MB on a Windows Server 2008-based computer that is running Windows SharePoint Services 3.0

So I gave it a try and it actually made things worse. What the heck? Well then I reread it. They tell you to make a change to the web.config and say just put the change in the <configuration> section. WRONG! Well kind of. You need to make the change in the <configuration> section but it has to be after the </configSections> tag. So I recommend you paste their change between </configSections> and the <SharePoint> tag.

Now everything works great. Do note their change only allows you to upload files with a size of 50 MB. If you want larger you will need to increase the maxAllowedContentLength=.

If you are going to be playing with Windows Server 2008 and SharePoint I recommend you go poke around the SharePoint and w2k8 resource center at http://technet.microsoft.com/en-us/office/sharepointserver/bb735844.aspx. Thanks to Emily Schroeder for the tweet on that page which she runs. J

Even better yet Todd and I have some fun new stuff coming on Windows Server 2008 and 64 bit before the end of the year.

Shane – SharePoint Consulting

Whole farm is down because timer jobs are not running

Shane — Thu, 09 Oct 2008 19:50:04 GMT

One of my clients this week managed to take his entire farm offline this week by upsetting the timer service. First a little background – currently they are scrambling to get SharePoint back to a happy state. Why? Well, as happens with lots of customers, SharePoint is too successful. When we originally setup their farm and upgraded from SPS2003 to MOSS 2007 they had about 20 GB of content that was growing at a very controlled pace. Fast forward a little more than a year and their content database is about 320 GB. YIKES! Even scarier most of their data is in one site collection. This is bad, very bad! Typical guidance is your content databases should be less than 100 GB.

Part of this growth has forced some moving of the databases to different drives and a database restore to deal with another issue. Well, anytime you want to move SharePoint databases around you should run the command stsadm –o preparetomove as documented by Cory Burns in the post Detaching databases in MOSS. If you didn't you will start getting sync errors once an hour such as:

Failure trying to synch web application 09a21da5-4485-4b00-8268-772aea7fea12, ContentDB 65301403-c277-4b4c-ad5a-e822572d10ea: A duplicate site ID 3b3a4372-aa91-4e0c-ba57-2567958d81bb(http://portal/sites/test1) was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue.

Cory then goes on how to fix it using stsadm –o sync. This is where my client was. He ran this command but for some reason (possible him specifying the wrong switches and accidently deleting a content db) the command hung up for a long period of time, and the portal users were unable to access the environment. So he killed the stsadm process. From that point all hell broke loose.

For several hours they attempted a lot of fixes found on the web. One of the fixes had them rename the folder located at C:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\<guid>\. This was a bad option. The folder contains XML files for all of the timer job definitions that need to be ran and the idea was renaming the folder would cause SharePoint to create a new empty copy of the folder and then it could start creating the xml files again and get back to work. Nope, that isn't how it works. What they needed to do was delete all of the XML files and leave the folder alone. Then when they restarted the timer service the proper XML files would have magically reappeared.

Hope this helps you

Shane

SharePoint Consulting

Error using Stsadm –o restore

Shane — Wed, 20 Aug 2008 19:17:00 GMT

Got this email earlier this week.

Shane,

I am using the Microsoft Site Undelete tool (download from here) you recommended. I had user delete his site accidently and I am trying to restore it. It was successfully backed up by the tool to a file called sitename.bak. So I ran the command:

Stsadm.exe –o restore –url http://portal/sites/sitename -filename sitename.bak

When I ran the command I got the error:

Your backup is from a different version of Windows SharePoint Services and cannot be restored to a server running the current version. The backup file should be restored to a server with version '1178817357.0.105904.0' or later.

What gives? Shouldn't my version be 12.0.0.6318 or 12.0.6219.1000?

Thanks

Well after scratching my head for a few minutes I realized the mistake. He was trying to restore an individual site instead of a site collection. The undelete tool is smart enough to know when you do a delete if you are deleting a site or a site collection. When you delete a site the tool will actually do a stsadm –o export before deleting the site, this is what happened to our guy. So to restore the file he simply needed to run the command:

Stsadm –o import -url http://portal/sites/sitename -filename sitename.bak

(Thanks Jeff)

That is all it takes. So don't get your site collection backups (stsadm –o backup) confused with your site backups (stsadm –o export).

Also, worth noting because I can hear Todd complaining now. If you will call your sub-sites web and call your site collections sites like the developers do your life will be easier.

Also, also I only have one more chapter on the SharePoint Admin Book to go.

Shane

SharePoint Consulting

Error message in multi server farm

Shane — Mon, 28 Jul 2008 00:23:20 GMT

I was adding a new web front end (WFE) server to a farm last week and ran into this error while running config wizard.

Task configdb has failed with an unknown exception

07/21/2008 14:18:39 8 ERR Exception: System.IO.IOException: The device is not ready.

at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)

at System.IO.Directory.InternalCreateDirectory(String fullPath, String path, DirectorySecurity dirSecurity)

at System.IO.DirectoryInfo.Create(DirectorySecurity directorySecurity)

at Microsoft.SharePoint.Administration.SPProvisioningAssistant.CreateDirectory(DirectoryInfo di, Boolean secureAdminAccess)

at Microsoft.SharePoint.Administration.SPServer.CreateDirectory(String path, Boolean secureAdminAccess)

at Microsoft.SharePoint.Administration.SPServer.CreateDirectory(String path)

at Microsoft.SharePoint.Administration.SPUsageSettings.EnsureLogFileDirectories(SPFarm farm)

at Microsoft.SharePoint.Administration.SPWebApplication.Provision()

at Microsoft.SharePoint.Administration.SPWebServiceInstance.Provision()

at Microsoft.SharePoint.Administration.SPFarm.Join()

at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.CreateOrConnectConfigDb()

at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.Run()

at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask(

After some poking around the net I found that my buddy Eric Shupps had seen this error before also. http://www.binarywave.com/blogs/eshupps/Lists/Posts/Post.aspx?ID=139 The issue stems from the fact that WFE1 had the usage logs set to go to the D:\ drive in Central Admin. When config wizard tried to provision this folder on WFE2 it errored out because the server did not have a D:. Whoops.

Thanks Eric!

Shane

SharePoint Consulting

Another Error Message – Access Denied on Profile Import

Shane — Mon, 30 Jun 2008 15:56:31 GMT

I noticed the error message below repeatedly in event viewer and realized it was happening every time a profile import was happening.

Event Type: Error

Event Source: Office SharePoint Server

Event Category: Office Server General

Event ID: 7888

Date: 6/27/2008

Time: 11:37:17 AM

User: N/A

Computer: ServerName

Description:

A runtime exception was detected. Details follow.

Message: Access Denied! Only site admin can access Data Source object from user profile DB.

Techinal Details:

System.UnauthorizedAccessException: Access Denied! Only site admin can access Data Source object from user profile DB.

at Microsoft.Office.Server.UserProfiles.SRPSite.AdminCheck(String message)

at Microsoft.Office.Server.UserProfiles.DataSource._LoadDataSourceDef(IDataRecord rec)

at Microsoft.Office.Server.UserProfiles.DataSource._LoadDataSourceDef(String strDSName)

at Microsoft.Office.Server.UserProfiles.DataSource..ctor(SRPSite site, Boolean fAllowEveryoneRead)

at Microsoft.Office.Server.UserProfiles.DataSource..ctor(SRPSite site)

at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager.GetDataSource()

at Microsoft.Office.Server.UserProfiles.BDCConnector.RefreshConfiguration(String sspName)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Turns out that on this server they had a least privileged install done. In this case you need to make sure that within the SSP you have granted your default content access account and your SSP application pool account the manage profile permission. If you need help with that check out this article I wrote on SSPs and their rights. http://msmvps.com/blogs/shane/archive/2007/08/06/give-a-user-access-to-the-ssp.aspx

Shane – SharePoint Consulting

The Trial Period For This Product Has Expired.

Shane — Tue, 05 Feb 2008 01:43:30 GMT

Even after I put in a good MOSS Enterprise key, did and iisreset, and rebooted. UGH. Why?

Well, it turns out as a final reminder this server once was setup as a basic install, my Central Admin app pool was running as Network Service instead of my farm account. And for some reason Network Service did not have the rights to license the product. Change the app pool, recycle the app pool, and no more error message. UGH

Another new error message because of the Central Admin App Pool being wrong:

An unhandled exception occurred in the user interface.Exception Information: Unable to load DLL 'Microsoft.Office.Server.Native.dll': The specified module could not be found. (Exception from HResult: 0x8007007E)

This message occurred when you went to Application Management > Check services enabled in this farm

Hope this helps people when they are searching the web. I couldn't find any help. S

Shane – SharePoint Consulting

Errors installing after uninstalling

Shane — Mon, 04 Feb 2008 05:42:52 GMT

Once again it is midnight on a Sunday evening and I find myself working. Oh the joys. :) Anyway, a quick post for you.

SharePoint911 got a new client this week and like many of them they had someone in to do SharePoint before us. And I am the lucky guy who gets to clean up after someone else's half ass attempt to be SharePoint consultants. (I will save my rant for another day.) But as normal even though the client has SQL Server running on the SharePoint box the "consultant" did a basic install of MOSS Enterprise which puts SQL Express on the machine and uses it. As anyone who has taken my class or seen one of my admin presentations this annoys me more than anything. SQL Express has a 4 GB HARD LIMIT on database size! But worse than that basic install uses local system for EVERYTHING which works correctly for about 5 minutes, then the first time you try to do anything with the product it explodes. UGH. So before we start the project I am backing up all of their content and then uninstalling and reinstalling. To me this is the only clean way to get rid of the basic install.

After a reboot to make the server stable again I ran the uninstaller from add/remove programs. This will also automatically install SQL Express. After the uninstall another reboot.

Then I reinstalled MOSS choosing the Complete option. When the installer finished it launched Configuration Wizard.

After specifying the database server, farm account, and password I was prompted to setup Central Admin

Here when I clicked next I got the error message.

An exception of type System.Runtime.InteropServices.COMException was thrown. Additional exception information: The system cannot find the path specified.

Why? Because for some reason during the uninstall SharePoint failed to remove the old Web Applications (IIS Sites). So SharePoint couldn't create a Web Application for central admin because a dead one was already in its place. So I went into IIS, deleted everything from the previous install and reran configuration wizard. Everything ran like a charm.

Hope this saves someone a few minutes.

Shane SharePoint Consulting

Weird error due to permissions

Shane — Thu, 10 Jan 2008 06:45:09 GMT

So it is 1:30 am and I am sitting here trying to hodge-podge a medium server farm together to test a Kerberos issue/theory. My environment is a Windows Server 2008 box as my central admin, WFE, Excel, and query server (physical hardware), Windows Server 2003 VPC as the Index server, and a another VPC (running on another host) playing the role of SQL Server 2005 and Domain Controller. Does it sound like fun? Yeah right.

Anyway, I started getting the error below whenever I tried to start the Office SharePoint Server Search service on the index box.

An unhandled exception occurred in the user interface.Exception Information: Unable to generate a temporary class (result=1).
error CS2001: Source file 'C:\Windows\TEMP\xm7qyq1x.0.cs' could not be found
error CS2008: No inputs specified

Quick search? Nothing. A little playing and guessing and the issue turned out to be permissions. For some reason WSS_Admin_WPG and WSS_WPG did not have the any rights to c:\windows\temp on the central admin server. So I gave wss_admin_wpg full control and wss_wpg read & execute. Fixed everything instantly. I am guessing this is an issue with my random servers (not clean installs for this test) and not a W2K8 issue. Anyway, hopefully the error message and fix saves someone else some time.

Shane

SharePoint Consulting

Kerberos and MOSS case sensitive?

Shane — Thu, 27 Sep 2007 05:30:07 GMT

Warning I am not a Windows AD Security "expert", I don't play one on TV, and I did not stay at a Holiday Inn Express last night. :)

Ok, so it is 1 am in the morning and I am working on my labs for Professional SharePoint Administration. In the class we do a least-privilege install where we end up with about 8 different accounts. Then we configure the whole farm to use Kerberos authentication. Lots of fun and I really think it is important to understand. It isn't hard to do, just tedious. Anyway.

I do my setspn.exe for central admin as setspn.exe –A HTTP/server.tpg.local tpg\sp_farm and again as setspn.exe –A HTTP/server tpg\sp_farm no problem. I log onto the server as tpg\sp_farm and open Central Administration. It takes me to http://server:5555 and all is well. I then make Bob Farmer a member of the farm administrator group. Then I hit the sign in as a different user and input tpg\bob. Nothing but errors. What the heck?

After 5 minutes of cussing I see this error message in Event Viewer.

The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/server.tpg.local. The target name used was HTTP/server.TPG.local. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (TPG.LOCAL), and the client realm. Please contact your system administrator.

I am the system administrator. Who do I see? Do you see the issue? Apparently the proper FQDN is server.TPG.loca instead of server.tpg.local. Surely that can't be the problem? Let's see. I run setspn.exe –A HTTP/server.TPG.local tpg\sp_farm Then I try to login again. It WORKS!!!

So I have read lot of contradicting stuff about if SPN's are case sensitive or not. I still don't know. What I do know what setting a new SPN with TPG fixed my problem immediately. If you have 2 cents to add I would love to hear it.

Back to work with me. Now it is 1:30 and I still need to play Halo 3 some more before I go to bed. Good thing the wife is already asleep. ;)

Shane – SharePoint Help

Another day, another new error message

Shane — Mon, 23 Jul 2007 14:05:12 GMT

After upgrading from SPS 2003 to MOSS 2007 we had an issue with the index process. After starting a full crawl it would peg the server out and would have a status of Crawling – Local Office SharePoint Server sites | computing ranking. And while it would index most of the items it never would actual finish. UGH. So after trying all of the normal tricks like resetting the index, stopping the search service and restarting it, etc nothing would work. So then we went digging in the logs and found this beauty.

07/19/2007 15:03:35.65 mssearch.exe (0x0DEC) 0x0E88 Search Server Common GathererSql 0 Monitorable CSqlCrawl::ExecuteCommand fails Error 0x80040e2f - File:d:\office\source\search\search\gather\server\gathersql.cxx Line:407

A quick web search found nothing. How rude. A lot more random search combinations did net me this though.

I first found Mike Hanley's Blog SharePoint 2007 Search Never Stops Crawling which didn't exactly get me fixed but did lead me to find http://support.microsoft.com/kb/930887/en-us from Microsoft. Also, Andrew Woodward had put the two together SQL Maintenance Plans and MOSS give 100% CPU error.

So really I say all of this to get the error message out here and in the Web Search indexes so next time someone has the issue they don't spend hour searching.

Shane Young – SharePoint Help

A very common prescan problem that stops you from doing your upgrade

Shane — Sun, 15 Jul 2007 19:30:00 GMT

I have gotten the same email from several people and the fix has been the same just about every time so I thought I would publish the conversation here. Hopefully some searching of the web will help save a couple of email stamps. ;)

Mr. Pugglesworth: What should I do if I want to find out if my SharePoint (WSS v2 or SPS 2003) is ready to be upgraded?

Shane: Use my post here to Download Prescan.exe and then use Joel Oleson's post for the exact syntax.

Mr. Pugglesworth: I ran prescan.exe and then I get these error messages in my prescan log. Can you help?

07/05/2007 15:16:32 Skipping virtual server: http://portal.company.com/. Server

state = NeedUpgrade. Most likely this virtual server is not extended

with WSS v2.

07/05/2007 15:16:32 Scan finished without failure.

07/05/2007 15:16:32

===============================Logs===============================

07/05/2007 15:16:32 Log file:

C:\DOCUME~1\puggle\LOCALS~1\Temp\3\PreupgradeReport_633192453889379947_L

og.txt

07/05/2007 15:16:32 Summary file:

C:\DOCUME~1\puggle\LOCALS~1\Temp\3\PreupgradeReport_633192453889379947_S

ummary.xml

07/05/2007 15:16:32

==============================Totals==============================

07/05/2007 15:16:32 Number of sites skipped (already scanned): 0

07/05/2007 15:16:32 Number of sites scanned: 0

07/05/2007 15:16:32 Number of broken sites: 0

07/05/2007 15:16:32 Number of webs scanned: 0

07/05/2007 15:16:32 Number of broken webs: 0

07/05/2007 15:16:32 Number of webs using custom template: 0

07/05/2007 15:16:32 Number of pages scanned: 0

07/05/2007 15:16:32 Number of unghosted pages: 0

Shane: Usually that message only shows up when WSS truly isn't installed or your virtual server didn't get upgraded after you installed WSS SP2. Try this to confirm my suspicions:

Go to v2 central admin. Then click on Windows SharePoint Service on the left:

Now click on Configure virtual server settings.

Now please take a screenshot of the screen that looks like this and send it back to me.

This will help me tell you what to do next.

Mr. Pugglesworth: Here is what I get. Please help. :)

Shane: You have some form of this problem http://msmvps.com/blogs/shane/archive/2005/11/02/74038.aspx

Essentially, you need to run stsadm.exe –o upgrade –forceupgrade from the 60 hive before you will be able to do an upgrade to MOSS. While this command is running your SharePoint will be unavailable so plan accordingly. Also, please make sure you have a backup before you start running stsadm commands. They are safe but very powerful.

The End

Hopefully this will help you out also. If nothing else I don't have to have this email conversation too many more times. ;)

Shane Young – SharePoint Help

Problems with licensing MOSS

Shane — Tue, 29 May 2007 15:11:56 GMT

So today had someone who had used the 180 day trial key of MOSS to its end. Apparently their key expired while we were all grilling out this weekend whoops.

Well, no problem. Just use my blog article How do I find out when my MOSS trial expires? And it has a section on "How to update from MOSS trial to MOSS Standard or Enterprise". Crisis averted.

Not so fast. She was now getting the error message:

Your license conversion operation failed. Check the error logs for details.

Upon looking in Event Viewer (eventvwr) she was getting

Event Type: Error

Event Source: Windows SharePoint Services 3

Event Category: Timer

Event ID: 6398

Date: 5/29/2007

Time: 8:36:17 AM

User: N/A

Computer: SERVER1

Description:

The Execute method of job definition Microsoft.Office.Server.Administration.LicensingConversionJob (ID b535873a-5ff6-434c-b694-6e19eb40da4e) threw an exception. More information is included below.

Arithmetic operation resulted in an overflow.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Interesting…. Upon further examination it seemed that her collaboration portal was working fine but her publishing portal still thought it was using an expired trial edition. If you checked Central Administration (check above article if you need help doing this) it said everything was fine.

So how do we fix this horrible problem? IISRESET.exe

I am going to do some more digging to see if I can find out why or what happened but best I can tell all is well.

Shane Young – SharePoint Help

Setting up SharePoint? Accounts need their domain.

Shane — Wed, 07 Mar 2007 17:11:00 GMT

I have been meaning to post this forever and keep forgetting. A very common issue I am seeing people have when setting up and configuring SharePoint is the way they are specifying account names. You must always specify domain\username. Even though SharePoint will never tell you this is the problem it is. Many users are tempted to just type in username for a service and then the password then they are greeted with a random/cryptic error message. After about an hour (or a day of reinstalling) they realize it was because they forgot to specify the domain name.

I will attempt to compile a list of error messages that have been caused by this issue and post them here. If you have one please post it in the comments and I will update the post. Thanks

Sample Error:

An unhandled exception occurred in the user interface.Exception Information: OSearch (SPSearchAcct)

Anyway, just a heads up!

Shane – SharePoint Help

NT4 domain and SharePoint 2007 don’t play nice

Shane — Thu, 25 Jan 2007 02:53:09 GMT

So after really beating my head on the table for a while my conclusion is you cannot install MOSS 2007 or WSS v3 in an NT 4.0 domain as anything but a single server. If you choose multiserver you will get the error below. I got this error while trying to connect to the SQL Server using windows authentication in the configuration wizard. :(

01/09/2007 10:36:27 10 ERR Exception: System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated.

at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)

at System.Security.Principal.NTAccount.Translate(Type targetType)

at Microsoft.SharePoint.Administration.SPProcessIdentity.GetMachineRelativeSecurityIdentifier(SPServer server, Boolean& isMachineAccount)

at Microsoft.SharePoint.Administration.SPProcessIdentity.GrantIdentityDatabaseAccess()

at Microsoft.SharePoint.Administration.SPProcessIdentity.Update()

at Microsoft.SharePoint.Administration.SPWindowsService.Update()

at Microsoft.SharePoint.Administration.SPFarm.CreateBasicServices(SqlConnectionStringBuilder administrationContentDatabase, IdentityType identityType, String farmUser, SecureString farmPassword)

at Microsoft.SharePoint.Administration.SPFarm.Create(SqlConnectionStringBuilder configurationDatabase, SqlConnectionStringBuilder administrationContentDatabase, IdentityType identityType, String farmUser, SecureString farmPassword)

at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.CreateOrConnectConfigDb()

at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.Run()

at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()

Now this is my professional opinion because as best I can tell there is no official Microsoft position on this. If you are on an NT4 domain and really want to try using 1 SharePoint server and 1 SQL server you may be able to use SQL authentication but no promises there. It seems that SharePoint considers NT4 to be the same as a workgroup.

Hope this saves someone some grief.

Shane – SharePoint Help

Upgrade error and prescan.exe

Shane — Wed, 07 Jun 2006 01:59:00 GMT

So you tried to run MOSS 2007 beta 2 install and do an upgrade but you got an error. The error said something like:

Failed to initialize SharePoint Products and Technologies upgrade.

An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException was thrown. Additional exception information: The pre-upgrade scan tool has not yet been run on all servers in the farm. You must run the pre-upgrade scan tool before you can continue with the upgrade process. Run the tool from the following path: c:\program files\common files\Microsoft shared\web server extensions\12\bin\prescan.exe. After you have reviewed any issues found by the tool, you can run psconfig.exe again to continue the upgrade process.

So you took the error message to heart, found the prescan.exe, double clicked on it and then tried to double click on psconfig.exe and nothing happened. Sounds about right to me. What the error message should have told you to do is:

1. Open a cmd prompt
2. Type cd\ and press enter
3. Type cd program files\common files\microsoft shared\web server extensions\12\bin and press enter
4. Now type prescan.exe /c preupgradescanconfig.xml /all and press enter
5. Now when it completes it will give you a log file to review for errors. Assuming you have no errors you can move to the next step. If you do have errors then deal with them. :) Aren't I helpful?
6. Type in psconfigui.exe and press enter.
7. Now go back through the upgrade process hopefully without error this time.

These are the instructions that Microsoft meant to include. :) Hope they help you.

Shane
SharePoint Help

The SharePoint Farmer's Almanac : Error Messages

Fixing MOSS Search

InfoPath Form displayed on anonymous site causes login prompt

Windows Server 2008 WFE will not allow large file uploads

Whole farm is down because timer jobs are not running

Error using Stsadm –o restore

Error message in multi server farm

Another Error Message – Access Denied on Profile Import

More Problems with SQL Server High CPU and MOSS Search

The Trial Period For This Product Has Expired.

Errors installing after uninstalling

Weird error due to permissions

Kerberos and MOSS case sensitive?

Another day, another new error message

A very common prescan problem that stops you from doing your upgrade

Problems with licensing MOSS

Setting up SharePoint? Accounts need their domain.

NT4 domain and SharePoint 2007 don’t play nice

Upgrade error and prescan.exe