Posts tagged SharePoint

Calling SharePoint Services with WCF and Impersonation

Feb 5th

Posted by Chris in SharePoint

No comments

After battling with error 0×80004004 the WCF client I was testing started received a new error.

Could not load file or assembly ‘System.Web.Services, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. Either a required impersonation level was not provided, or the provided impersonation level is invalid. (Exception from HRESULT: 0×80070542)

A search yielded this post, which contained some key information.  Interestingly enough, we were seeing the “White Screen” issue on our local instance under similar circumstances: a WCF client calling the list service.

Since the behaviors section is not specifying the clientCredentials, the allowedImpersonationLevel is set to Identification.  This means that the server can get the Identity of the user, but it is unable to impersonate the user.

This was almost identical circumstances to our problem except that we were not running in the context of Biztalk.  The solution was to allow Impersonation by adding an endpoint behavior.

<endpointBehaviors>
  <behavior name="ImpersonationBehavior">
    <clientCredentials>
      <windows allowedImpersonationLevel="Impersonation" />
    </clientCredentials>
  </behavior>
</endpointBehaviors>

Once this was set the service client began working and it was back to the SharePoint dev races.  For more on calling SharePoint Services with WCF check out this post.

, , , ,

Calling SharePoint Services Over SSL with WCF (WSS 3.0)

Feb 4th

Posted by Chris in SharePoint

No comments

While troubleshooting another SharePoint WSS issue (related to DCOM permissions) I had to test calling the List Service against an Instance of SharePoint that was running over SSL.  I was using WCF as the client and the biggest pain was the configuration (which is usually the case with WCF).  Based on several other posts, here is what I tried.

1. Added Service Reference which generated configuration info for the service

2. Changed the config and set the security model to “Transport” and clientCredentialType to “Ntlm”.  “Transport” is required when calling over SSL.

    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="ListsSoap" closeTimeout="00:01:00" openTimeout="00:01:00"
                    receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false"
                    bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                    useDefaultWebProxy="true">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                        maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                    <security mode="Transport">
                      <transport clientCredentialType="Ntlm"/>
                    </security>
                </binding>

            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="https://someserver/somesite/_vti_bin/lists.asmx"
                binding="basicHttpBinding" bindingConfiguration="ListsSoap"
                contract="SharePointServices.ListsSoap" name="ListsSoap" />
        </client>
    </system.serviceModel>

3. In code, the only trick I had to use was to AllowNtlm by setting the property on the ClientCredential object.


            using (var client = new SharePointServices.ListsSoapClient())
            {
                try
                {
                    client.ClientCredentials.Windows.ClientCredential 

                 = new NetworkCredential("username", "password", "domain");
                    client.ClientCredentials.Windows.AllowNtlm = true;
                    var lists = client.GetListCollection();
                    var listsXElement = XElement.Parse(lists.OuterXml);
                    Console.WriteLine(listsXElement);
                }
                catch (Exception ex)
                {
                    client.Abort();
                    Console.WriteLine(ex.ToString());
                }
            }
, , ,

Troubleshooting 0×80004004 in WSS 3.0 (SharePoint)

Feb 3rd

Posted by Chris in SharePoint

2 comments

Today I spent some time working through a few issues with SharePoint and DCOM permissions.  Hopefully this helps another developer on a quest to solve this issue.

If you’ve found 0×80004004 then you are already pretty far along to the solution.  While testing calls to the List service in SharePoint using WCF for the client I received the following error from the List service which I captured by enabling tracing on my WCF client.

<soap:Fault>
    <faultCode xmlns="">soap:Server</faultCode>
    <faultString xmlns="">Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException' was thrown.</faultString>
    <detail xmlns="">
      <errorstring xmlns="http://schemas.microsoft.com/sharepoint/soap">Operation aborted (Exception from HRESULT: 0x80004004 (E_ABORT))</errorstring>
      <errorcode xmlns="http://schemas.microsoft.com/sharepoint/soap">0x80004004</errorcode>
    </detail>
  </soap:Fault>

Repeated searches on Bing and Google yielded nothing with a direct solution.  But I did find a few pointers that helped my quest.

Digging through program files\common files\Microsoft Shared\Web Server Extensions\12\LOGS I found log files with rows looking similar to this:

w3wp.exe (0×1718) 0×1418 Windows SharePoint Services General 8e2s Medium Unknown SPRequest error occurred.  More Information: 0×80004004

This confirmed the error, but wasn’t helpful.  However, the line just above that was slightly more revealing:

w3wp (0×1718) 0×1418 Windows SharePoint Services Database 6f8g Unexpected Unexpected query execution failure, error code 11.  Additional error information from SQL Server is included below. “[DBNETLIB][ConnectionWrite (WrapperWrite()).]General network error.  Check your network documentation.” Query text (if available): “{?=call proc_GetTpWebMetaDataAndListMetaData( [some values here] ) }

My immediate thought was, “ok, database permissions”.  I was able to locate the stored procedure in question as belonging to the Administration database (SharePoint_AdminContent).  I tweaked a few permissions to no avail.

The project architect suggested I try the same code against a different SharePoint instance.  Sadly, when I tried that the only problem I had to fight was getting the NTLM credentials to work using WCF and SSL.  Things worked flawlessly after that.

With the assistance of our IT pro, he found this article which discusses DCOM permission issues with SP.  Unfortunately we found ourselves unable to change the IIS WAMREG permissions until we found this article which helped us slay that problem.  After taking ownership of the appropriate registry key, we were able to change permissions on the IIS WAMREG DCOM component to allow the SharePoint WPG groups to have Local Launch and Local Activate.

Apparently this issue stems from how the local SharePoint install was configured.  Seems that many people run into this issue when trying to consume SharePoint services on a local machine.

After a reboot and an IIS reset the problem went away.  Sadly, my WCF client received a new error which I will cover in a future post. 

, ,