Archiwa tagu: WSS

MOSS Search web service – impersonation problems when calling from an external application

Hi there,

A while ago I was implementing a search functionality within an ASP.NET application. The plan was to use the SharePoint Search for crawling and indexing the contents, and afterwards, from my application, connect to the MOSS web service and perform the needed query upon it.

I had some web sites and BDC applications prepared within a scope; everything crawled and indexed – so far so good.

In the ASP.NET application, the service reference to the exposed asmx has been added (e.g. http://sharepoint/_vti_bin/search.asmx ).
Then I tried to invoke the service sending a query packet xml object:
[csharp]QueryServiceSoapClient client = new QueryServiceSoapClient();

client.Query ("<QueryPacket>….");[/csharp]
At this stage, the following exception occurred:

Retrieving the COM class factory for component with {CLSID BDEADEE2-C265-11D0-BCED-00A0C90AB50F} failed due to the following error: 80070542

It doesn’t say much, does it? After some reading, it came out that the app could not authenticate itself against the MOSS webservice in a correct manner – the credentials for the webservice weren’t passed as one would expect.
Of course, an explicit assignment of username and password was not the way I wanted to go. I needed the application pool account (which had all needed permissions on the webervice) to be used and impersonated on every call to the asmx.

Changing the client’s impersonation level to ‚Delegation’ solved the issue:
[csharp]client.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Delegation;[/csharp]
Exception gone, search results present.
Hope this helps,

SharePoint: access denied when trying to copy a list (item)

Hey there,

Lately, while trying to copy a SharePoint list from one site to another (or later also single list items), I got this infamous “Access denied” SharePoint error. At first of course the idea is to log in as a super-user. But when this operation failed also with the account of Site Collection Admin and/or Site Owner role, it seemed less trivial than just a missing permission within the site collection.

Unfortunately, a quick jump into the SharePoint logs didn’t bring me much further:

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

Since this problem has occurred in more than one application on our SharePoint server, I was assuming it to be a global misconfiguration. Hence, had to check out the Central Administration. There was the solution:

In Central Administration > Operations > Service Accounts I checked which account actually is responsible for the communication with Windows SharePoint Services on our server. So, in the Web application pool section, I selected the WSS Web application and the application pool of the application which was giving me this “Access denied” message.

The account was the predefined one – the Network Service.

There’s the rub! Since we’re using own domain accounts for such cases and only they’re enabled to access the WSS, the Network Service account was actually getting the “Access denied” message (when trying to connect to one of the SharePoint Web Services).

Changing the account from predefined one to the configurable one with our username and password did the trick. I just had to do an iisreset after this change.

Probably this solution also fixes some other problems we might have encountered, where the communication between application and WSS would fail.

Hope this helps,