Corey Roth [MVP] : MOSS, Error

COMException (0x80004005): Cannot complete this action after installing Service Pack 2

CoreyRoth — Tue, 22 Sep 2009 19:13:48 GMT

It’s a known fact that MOSS 2007 Service Pack 2 hates me. Today, I was excited when I upgraded a server to SP2 and the configuration wizard didn’t fail. I was even more excited to see that my SSP and Central Administration still worked after the upgrade as well. Unfortunately, when I hit my main web application, I got a yellow screen with the following error.

COMException (0x80004005): Cannot complete this action.

Please try again.]

Microsoft.SharePoint.Library.SPRequestInternalClass.GetFileAndMetaInfo(String bstrUrl, Byte bPageView, Byte bPageMode, Byte bGetBuildDependencySet, String bstrCurrentFolderUrl, Boolean& pbCanCustomizePages, Boolean& pbCanPersonalizeWebParts, Boolean& pbCanAddDeleteWebParts, Boolean& pbGhostedDocument, Boolean& pbDefaultToPersonal, String& pbstrSiteRoot, Guid& pgSiteId, UInt32& pdwVersion, String& pbstrTimeLastModified, String& pbstrContent, Byte& pVerGhostedSetupPath, UInt32& pdwPartCount, Object& pvarMetaData, Object& pvarMultipleMeetingDoclibRootFolders, String& pbstrRedirectUrl, Boolean& pbObjectIsList, Guid& pgListId, UInt32& pdwItemId, Int64& pllListFlags, Boolean& pbAccessDenied, Guid& pgDocId, Byte& piLevel, UInt64& ppermMask, Object& pvarBuildDependencySet, UInt32& pdwNumBuildDependencies, Object& pvarBuildDependencies, String& pbstrFolderUrl, String& pbstrContentTypeOrder) +0

Microsoft.SharePoint.Library.SPRequest.GetFileAndMetaInfo(String bstrUrl, Byte bPageView, Byte bPageMode, Byte bGetBuildDependencySet, String bstrCurrentFolderUrl, Boolean& pbCanCustomizePages, Boolean& pbCanPersonalizeWebParts, Boolean& pbCanAddDeleteWebParts, Boolean& pbGhostedDocument, Boolean& pbDefaultToPersonal, String& pbstrSiteRoot, Guid& pgSiteId, UInt32& pdwVersion, String& pbstrTimeLastModified, String& pbstrContent, Byte& pVerGhostedSetupPath, UInt32& pdwPartCount, Object& pvarMetaData, Object& pvarMultipleMeetingDoclibRootFolders, String& pbstrRedirectUrl, Boolean& pbObjectIsList, Guid& pgListId, UInt32& pdwItemId, Int64& pllListFlags, Boolean& pbAccessDenied, Guid& pgDocId, Byte& piLevel, UInt64& ppermMask, Object& pvarBuildDependencySet, UInt32& pdwNumBuildDependencies, Object& pvarBuildDependencies, String& pbstrFolderUrl, String& pbstrContentTypeOrder) +215

That’s just great I figured. I checked the logs folder in the 12 hive and all I could find was an entry with the same text “Cannot complete this action”. Quite useless. After doing some searching, I encountered the following KB article. This articles applies to WSS2, but I noticed a lot of things mentioning the word impersonation, so I decided to have a look in my web.config. Sure enough, this server had impersonation turned off for some reason (no telling why). I set it back to true and the error went away.

Issue when querying on a Managed Property of type Decimal

CoreyRoth — Mon, 22 Jun 2009 20:05:37 GMT

I’ve been working on putting some stuff together for my talks at SharePoint Saturday Ozarks (#SPSOzarks) and ran into this interesting issue. Now this may just be an isolated incident, but I have discovered a few errors that occur when trying to query a managed property of type decimal. To start out, I created a custom content type with a site column called DocumentPriority (name doesn’t really matter obviously). I configured the site column as a number with 0 decimal places. Search picks this up as a crawled property but it determines it is of type decimal instead of number. I go ahead and map this to a managed property of the same type and then attempt to query it in the usual manner:

DocumentPriority:5

I expected to see some results or at least the message saying no results were available but in fact I get the following error message.

Your search cannot be completed because of a service error. Try your search again or contact your administrator for more information.

That of course confuses me, so I try the query again and I get:

The search request was unable to connect to the Search Service.

This confuses me even more. I start to wonder what is going on. I try some different searches and discover other queries work fine, but when I try this query again, I get the same error messages. I decide to do some more research and check the Event Log. I find the following events

The last query machine has been taken out of rotation. Check previous event logs to determine cause. Propagation may be necessary. Component: 68105977-f711-43b5-a25e-4f2d210625e1

Query machine 'MOSS-SERVER' has been taken out of rotation due to this error: Values of this type are not turned into strings necessary to generate scope information. The item will not be locatable in all of the appropriate scopes but this is not a serious error. 0x80044100. It will be retried in 15 seconds. Component: 68105977-f711-43b5-a25e-4f2d210625e1

This means that the query server is dying anytime it receives a query like this. That is extremely bad. I haven’t resolved the issue yet, but I think updating will help. This particular server does not have SP2 on it which I think will resolve it. Well technically I think it was the August Cumulative update from last year that fixes it, but I thought it was worth noting. I thought it was worth noting none the less in case you haven’t updated yet. I am going to update this server and see what happens. I’ll post an update if anything changes.

The object was not found. (The item was deleted because it was either not found or the crawler was denied access to it.)

CoreyRoth — Tue, 19 May 2009 20:03:42 GMT

I’ve seen a few people asking about this in the Crawl Logs and thought I would take a few minutes to address it. First and foremost this is a warning and not an error message. Sometimes when you receive this message, it is the crawler behaving normally. Other times it is because of an issue. I’ll first talk about when it is a normal behavior. When an item is deleted, it is perfectly normal to see this in your logs the next time a crawl occurs. This is simply indicating that SharePoint is removing the record from the search index. If you see an occasional one of these, then you can assure your administrator that things are probably fine.

Other times it can indicate another issue. In the situation where you already have your index built and your crawl log is filled with nothing but this warning, that is usually indicative of a problem (not to mention your index is empty). Before you do anything, the first thing I always recommend is just try crawling again. It might just fix it. If it doesn’t then more than likely you have a permissions problem. If you are dealing with a SharePoint content source, verify that the crawl account can still access SharePoint, the password hasn’t expired, it isn’t locked out, etc. Get the credentials for your crawl account and actually make sure you can log into a SharePoint site. While I am here, I’ll remind you again to never give this account administrator level privileges as it causes your search index to have deleted an unapproved files in it. After you make any necessary changes, try to crawl again (twice if necessary) and see if that resolves your issue.

If you are crawling a Business Data Catalog content source, make sure that the content access account has access to the BDC itself first by going to the Business Data Catalog permissions page on your SSP. Then also verify that the content access account also has permissions to the BDC application itself as well as its child entities. If you make any changes, be sure and crawl again.

If none of this has helped, my recommendation of course it to go to the 12 hive’s LOGS folder. You will need to sift through this file and see if you can find anything potentially permissions related with Search. Don’t follow any advice to reset your index unless absolutely necessary. More than likely your index is already effectively reset and doing this probably won’t get you any where. There are some other causes of this in your logs I am sure, but hopefully this will give you a good start in resolving this issue (if there is one to begin with).

Error: This crawl has been paused by the search system while a new query server is added. After the new query server is online, the crawl will be resumed.

CoreyRoth — Wed, 25 Mar 2009 15:20:38 GMT

This is kind of a strange error that I sometime receive when trying to startup a crawl in Enterprise Search. I have only received it on MOSS servers with the Infrastructure Update applied, but it might occur on other versions as well. The issue is when I try to start a crawl (on a BDC content source for me in this case), I get the following JavaScript alert.

Of course, I know a new query server isn’t currently being added. Sometimes, you can just try the crawl again and it will work. Eventually, I noticed that this only seems to occur when other crawls are running. For example, my main SharePoint sites content source was doing an incremental crawl as shown below.

When that crawl finishes, I can start my crawl without any issues on the other content source. As a workaround, I have also discovered that I can start the crawl by editing the content source and checking the Start full crawl of this content source checkbox. Quite the weird issue. I didn’t see much on Google about it, so I figured I better post something on it.

Don’t forget SharePoint Saturday Tulsa this weekend as well as DotNetMafia’s Beer and Code social afterwards.

Follow me on twitter.

MOSS Setup.exe – The Parameter is Incorrect

CoreyRoth — Tue, 03 Mar 2009 16:04:17 GMT

This is kind of a weird issue and I ran into it the last two times I setup a MOSS virtual machine, so I thought I would take a moment to tell about it today. I am a Windows Server 2008 virtual machine. This server is a DC and also has SQL Server 2008 installed. In my particular case I have the setup files for MOSS extracted onto a folder on my external hard drive so that I can do a slipstream install of SP1 and the Infrastructure Update. To access the files I am using Virtual PC’s Share Folder feature to provide access to the install files inside the virtual machine.

I created a setup account for MOSS to do the install since that seems to be a best practice. This account has administrator privileges. Here is where the issue comes in. When I login with my setup account and try to run setup.exe for MOSS, I get the following error.

Setup.exe. The Parameter is Incorrect.

In attempting to troubleshoot the issue, I noticed that if I ran it with the actual administrator account, everything works fine. However, this is not the account I wanted to install on. No matter what I could do, I could not get setup to run as a shared folder. Instead, what I ended up having to do was map a folder over the network to the host machine and install the files that way. Not sure what would cause this, but I assume it has something to do with Virtual PC. Anyhow, if you run into this issue, it’s easy to work around.

ArgumentNullException when calling Enterprise Search Web Service

CoreyRoth — Thu, 26 Feb 2009 22:14:56 GMT

Last week, I demonstrated how to call the Enterprise Search web service to get search results to a colleague. I pointed him to my post on querying a web service and he was able to easily put the code together to call the web service. However, when his code called the service, he got the following error.

<ResponsePacket xmlns="urn:Microsoft.Search.Response">
    <Response domain="QDomain">
        <Status>ERROR_SERVER</Status>
        <DebugErrorMessage>System.ArgumentNullException</DebugErrorMessage>
    </Response>
</ResponsePacket>

When I tried my code to call the web service, everything worked fine. After a bit of troubleshooting, I remembered him saying that he was going to specify the web service address by IP because he wanted to call the web service over the VPN and DNS hasn’t worked so well lately over it. I immediately though to have him change to the server name (as I have experienced other issues with IP addresses in the past) and everything immediately began to work. The lesson to be learned is again, never try to access a SharePoint server by IP address. Although some things might work, many things don’t. This might be solvable with an alternate access path, but I find it easier just to avoid the IP thing all together.

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.

CoreyRoth — Tue, 24 Feb 2009 19:45:00 GMT

There seems to be a huge plague of the following error sweeping through the SharePoint community right now. This occurs when you go to the Search Settings page on your SSP. You will probably notice it before this by a user trying to search and getting an error. Here is the text.

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.

It’s also been sweeping through the forums. Here are two posts about it just in the last couple of days.

http://social.msdn.microsoft.com/Forums/en-US/sharepointsearch/thread/da8d8bdc-5788-4992-8245-b98d5341acf8

http://social.msdn.microsoft.com/Forums/en-US/sharepointsearch/thread/17a12447-7c77-492c-a7b9-2269b81cfafa/?ffpr=0

First, let’s start by saying that when this happens to most people that a) the search service is most certainly online and b) an indexer move is not in progress. Google as much as you want, I have yet to see a concrete solution that didn’t result in some poor soul having to rebuild a search index. I have had two clients experience this issue since the beginning of the year, plus I have had other SharePoint consultants tell me of similar horror stories. I think the ultimate cause of the issue may be security related, as there have been some mixed results saying giving your crawl account administrator privileges fixes it (however, you never want to run like this).

So how do you fix it? Well as I implied, I do not know of a way to fix it which allows you to keep your search index. This part is mainly hearsay, but one of my clients was instructed by Microsoft support to rebuild their SSP. This did in fact fix it, but it also meant I had to reconfigure everything in the BDC as well as the Search content sources, scopes, managed properties, etc.

Another slighlty less painful method is to stop the Office Search Service in Central Administration. When I say this, I mean clicking stop in Central Administration which deconfigures the service, not by stopping the service in the Services control panel. Then, you reconfigure the Office Search Service with a new database. Again you have to reconfigure all of your search settings, but you don’t lose any BDC, Excel Services, and other items.

UPDATE: I was talking about this issue with a client and he was told by Microsoft support that this can occur when you have a farm and some of the servers aren't all on the same patch level in the farm. In this case Infrastructure Update was applied on some servers, but not all of them. I haven't confirmed this myself, but this does make a lot of sense and I have seen other posts out there that seem to imply this. I would certainly check this first before rebuilding your search service.

I am just trying to bring visibility to this issue, because honestly I am tired of reconfiguring SSPs. This issue is way out of hand right now and I really think it needs to be addressed by Microsoft.

Error: HRESULT E_FAIL has been returned from a call to a COM component

CoreyRoth — Thu, 01 May 2008 19:15:04 GMT

I was working on an Enterprise Search deployment the other day and I encountered this lovely error. I found the answer buried in some forum posts, but I wanted to tell you what side effects I found when implementing the solution (and I wanted to make sure I could find the answer again someday when I forget it). In my case I configured my Content Source to crawl a remote SharePoint farm (although I don't think being on a remote farm has anything to do with it). When I started the crawl, I saw the following error in my crawl log.

HRESULT E_FAIL has been returned from a call to a COM component

The reason this error occurs is because, I did not have impersonation enabled in my web.config. I needed a line that looked something like this.

<identity impersonate="true" />

However, before you are doing that, you need to know that this really changes the way security works on the site. When impersonation is enabled, it means the Application Pool account will no longer be used to execute ASP.NET page requests. It also means that if you are using Integrated Security with your connection strings, that you will most likely end up with an error message such as the following.

Login failed for user 'NT AUTHORITY\NETWORK SERVICE'

Additionally if you are using the SqlDataSource, it is most likely mapped to the SpSqlDataSource (unless you removed the tag mapping) and will get a message like the following.

This control does not allow connection strings with the following keywords: ‘Integrated Security’, ‘Trusted_Connection’.

I talked about the above message in the past. On a related note, I have discovered (assuming Impersonation is off), that you can enable Integrated Security with the SPSqlDataSource control by setting the AllowIntegratedSecurity property to true.

So what is the bottom line? Well, from my personal attempts as well as from what I have read in forums, it is not possible to have Impersonation enabled as well as use Integrated Security with your connection strings. In theory, I do believe it could be possible if you were to give all of your SharePoint users the same permissions as your original application account on your SQL Server. What I mean by that is give DOMAIN\Domain Users permission directly on the database. I don't really like that idea though. This, unfortunately, left me to breaking a best practice (come on not like SharePoint hasn't made you do that before) and use an internal SQL account for authentication.

I am out of ideas on this one, so currently this seems to be my only answer. Once, I changed my connection string and turned impersonation off, I recrawled and everything works great.

Tracing Service lost trace events

CoreyRoth — Thu, 17 Apr 2008 16:02:19 GMT

If you are like me, you go to the SharePoint logs folder often in an attempt to try and resolve various errors you may encounter when working with SharePoint. I noticed on some of my servers, that I was receiving an entry similar to the one below in my log file.

04/17/2008 10:45:52.99 wsstracing.exe (0x06BC) 0x2498 ULS Logging Unified Logging Service uls1 Monitorable Tracing Service lost trace events. Current value 13.

I did a quick Google search and was unable to find an answer. I did however notice that people did encounter this error after upgrading to SP1. This was definitely also the case with these particular servers. I got lucky and the solution to solving this is simple. I just restarted the Windows SharePoint Services Tracing and the Windows SharePoint Services Administration services. Once I did that, a new log was created and I was getting all of my trace information again.

Help! My SearchBox Web Part won't Submit

CoreyRoth — Thu, 28 Feb 2008 20:12:41 GMT

I have caused this to happen a number of times and the answer isn't obvious at first, so I thought I would post on it and explain what causes it and how to fix it. The behavior usually occurs for me when I am deploying a SearchBoxEx web part via a feature using an elements.xml file. What you will see is the web part gets deployed fine, but when you try to submit a query, it doesn't do anything and you get the following JavaScript error.

'options' is null or not an object.

The reason this happens for me is because in my configuration file I am setting the scope dropdown mode to Show, do not include contextual scopes and I have specified a ScopeDisplayGroupName that does not exist yet in my site collection. Actually any setting for the scope dropdown that displays a dropdown will cause this behavior when the scope display group does not exist. To fix it quickly, you can either change the scope dropdown mode or create the scope display group on your site collection. However, the correct way for me to fix this would be to include something in my feature receiver that creates the scope display group.

BDC: Could not create profile page for Entity

CoreyRoth — Wed, 27 Feb 2008 14:53:53 GMT

I have seen quite a few searches for this warning in our stats, so I thought I would address the following message received when importing an application definition into the Business Data Catalog.

Could not create profile page for Entity MyEntity. The error is: Default action exists for application 'MyInstance', entity 'MyEntity'. Profile page creation skipped.

When you import your application definition, this kind of looks like an error but in fact is not. This is just the message MOSS gives when you add a default action to an entity. I describe how to do that in the linked blog post. Unfortunately, this appears as an error in the Event Log instead of a warning. This is unfortunate, because your MOSS administrator will likely ask you about it (my last one did). The long story short. Don't worry about this message. It is perfectly normal to receive it when you have specified a default action.