The Windows SharePoint Services adapter runtime does not have permissions to invoke the adapter Web service

I recently was working through a lab integrating BizTalk Server 2010 with SharePoint Server 2010. The idea  was to have an InfoPath form submitted to an http end point. Biztalk would receive the InfoPath form, transform it, and then upload the form to a SharePoint document library.

This would make use of a send port configured to use the SharePoint Services Biztalk Adapter.

However, when I submitted the InfoPath form, it successfully submitted to the HTTP endpoint, but it did not upload to the SharePoint library. Further digging produced the following error:


Error details: The Windows SharePoint Services adapter runtime does not have permissions to invoke the adapter Web service. In order to fix this issue, you have to add the ADVENTUREWORKS\BizTalkHost Windows account to the "SharePoint Enabled Hosts" Windows group on the Windows SharePoint Services machine. This operation will allow BizTalk host instances running under ADVENTUREWORKS\BizTalkHost Windows account to invoke the adapter Web service in order to send and receive messages to or from SharePoint sites. The group membership will not take effect until you restart the BizTalk host instance.


Basically, this error is caused by the fact that when you enable the SharePoint Services BizTalk adapter, it creates a local security group on the server called "SharePoint Enabled Hosts". The account that BizTalk is running under must be a member of this group. Since I was running my lab on a single VM that was also a domain controller, I wasn't able to access the local users and groups using the server management console.

Thanks to Craig Harvey at Reserved Words, I found a very simple and elegant solution. You can edit the web.config file in the virtual directory that the BizTalk web service is running in.

The default authorization tag looks like this:








Change it to look like this:








Once I made this change and restarted the Host Instance, I re submitted the InfoPath form, and got a slightly different error:

The adapter failed to transmit message going to send port "CreditOrdersSharePoint" with URL "wss://biztalkdemo:80/LoanApplications". It will be retransmitted after the retry interval specified for this Send Port. Details:"The Windows SharePoint Services adapter Web service encountered an access-denied error accessing site http://biztalkdemo/. The BizTalk host instance account requires Contributor-level permissions. 

This was a rather obvious reference to the fact that the BizTalk Service account needed permission to contribute documents to the form library. Once I granted AdventureWorks\BizTalkHost contribute permissions, everything started working as designed.

Info Path Forms Using SharePoint Web Services Over SSL

I recently upgraded a client's MOSS 2007 farm to SharePoint Server 2010. The web application in question was using SSL. We had installed a wildcard cert and everything was working properly.

Part of the migration process included upgrading their Info Path forms to 2010 and making sure that everything worked properly. Upgrading the forms involved little more than downloading the xsn and republishing the forms to the new libraries.

One of the forms used a web service call to the User Profile Service to extract information about the currently logged in user. When I opened the form I received the following error:

You do not have permissions to access a Web service that provides data required for this form to function correctly.


Further digging in the Server Event Viewer produced the following:

An operation failed because the following certificate has validation errors:\n\nSubject Name: CN=, OU=<*****>, O=<*****>, L=<****>, S=<*******>, C=<******t>\nIssuer Name: CN=<******>, O="<*****>", C=US\nThumbprint: \n\nErrors:\n\n The root of the certificate chain is not a trusted root authority..


Further research pointed to the fact that although the SSL certificate was functioning properly in IIS, SharePoint requires that the SSL certificate be imported into the SharePoint Trusted Root Store in order for the SharePoint web services to function properly.

In short, I had to export the cert and then import it.

To export the cert, open the site in your browser, click on the lock icon to the right of the address bar, and choose "View Certificates" :

Next, select "Details" tab and choose "Copy to File". Save the file to your selected location.

Next step is to import the cert into the SharePoint Trusted Root Authority. This is done using the Power Shell script below, making sure you reference the correct cert. 

$cert = New-Object 

System.Security.Cryptography.x509Certificates.x509Certificate2("<path to cert file exported above>"); New-SPTrustedRootAuthority –Name “<pick a name for your cert>” –Certificate $cert;

Do an IIS Reset and test your form. It should be able to communicate with the SharePoint web services successfully now. 

The only gotcha I have encountered is that if there are multiple certs, or a chain of certs; you'll have to repeat this process for them all. 

Link to top level of a site collection Using SPUrl

Recently I was coding a branding package that deployed several master pages, image files and css files. The package was scoped to the site collection level, of course.

In addition to the top level site collection, there were multiple site collections located in various managed paths. I made sure my package deployed the relevant files to the root of each site collection in the Style Library and master page gallery. The next step was to make sure that the master pages were properly referencing the files in that site collection, and not in the root site collection.

A link such as shown below will not work. It will point to the Style Library at the root site collection, not necessarily to the Style Library where the feature is being installed.

<div class="interiorHeaderLogo"><a href="/"><img src="/Style Library/InteriorPageBrandingPackageAssets/images/interiorTopBar.png" border="0" style="background-position:left top"></a></div>

Many blogs correctly pointed out that I needed to use SPUrl  and reference the site collection. The problem was getting the syntax right. Most examples I found were relatively simple and were focused on simple links. I was dealing with a clickable image, which is a little more involved. Incorrect syntax will throw an error similar to:

Parser Error
Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.


Parser Error Message: Literal expressions like '<% $SPUrl:~SiteCollection/%>' are not allowed. Use  <asp:Literal runat="server"  Text="<%$SPUrl:~SiteCollection/%>" />   instead.


The proper form for the link above is:

<div class="interiorHeaderLogo">
<asp:Literal runat="server" text="<a href=&quot;/&quot;> <img src=&quot;"/>
<asp:Literal runat="server" text="<% $SPUrl:~sitecollection/Style Library/InteriorPageBrandingPackageAssets/images/interiorTopBar.png%>"></asp:Literal>
<asp:Literal runat="server" text="&quot;/&gt;&lt;/a&gt;"/>
</div>

               
This will reference the image in the Style Library in the site collection the feature is being installed to, will eliminate the parser error and will properly display a clickable image in your branding package.

Unexpected error on server associating the workflow

Recently we had to throw together a SharePoint Designer workflow in a hurry for a client. It consisted of 20 plus If Then Else statements that then triggered a separate custom task process.

About halfway through designing it, it started throwing the following error when publishing:

Unexpected error on server associating the workflow

I was able to determine that there was a default limit of 7000 on the UserDefinedWorkflowCompexity property of the web application. I used the follwoing PowerShell script to increase the limit and get passed the error:

$app = get-spwebapplication http://sharepointwebsiteurl/


$app.UserDefinedWorkflowMaximumComplexity = 30000

$app.Update()

After running this script, do an IISRESET and try publishing your workflow.

The Quick and Dirty Guide to Recreating the User Profile Service

It's no secret that the User Profile Service is probably the most fragile aspect of a SharePoint Server 2010 installation. It's been my experience that you either get it right the first time - or you have a difficult road ahead of you. 

It goes without saying that when implementing the User Profile Service, you should read, re read and then follow Spencer Harbar's definitive  Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization. 

However, in my work I often encounter client installations that were done improperly or the environment itself has issues. In that case I've found that it is often quicker and easier to simply delete the User Profile Service and recreate rather than attempt to troubleshoot it. 

What follows is my quick and dirty guide to deleting and recreating it. 

When deleting and recreating the User Profile Service the following steps should be performed:

• Stop the User Profile Synchronization Service from within Central Administration.

• Stop the User Profile Service within Central Administration.

• Check the Timer Jobs and make sure that the setup synchronization job is not hung. If so delete it.

• Open the MMC and add the certificates snap in as detailed here. 

• Delete all Forefront Identity management certificates you can find. They are under the Trusted Root, Trusted People and one other place. Delete them all.

• Make sure both FIM services are disabled in the services console.

• Create a new User Profile Service.

• Make sure that you create a new application pool each time you create the service!

• Make sure it is running under the farm account, and that the farm account is a member of the admin group on the server.

• Go to 'Manage Services on Server' in Central Administration.

• Start the User Profile Service in Central Administration.

• Start the User Profile synchronization service in Central Administration.

• Open the Services console and watch and see if the 2 FIM services change state. 

• Open the certificate snap in and make sure certs have been created properly.

• Wait a long time.
• When the User Profile Synchronization Service shows 'started' instead of 'starting', open the services console and make sure that both FIM services show enabled and automatic.
• Do an IIS reset.
• See if you can now open and manage the User Profile Service. 

Dynamic Hyperlinks in Calculated Columns

I recently was faced with an interesting problem. I needed to create a list column that referenced a field in the list and then dynamically constructed a URL to a filtered view of a document library. Specifically, the users needed to be able to enter the title of a company in a list item, and then have clickable links created that would take them to a separate document library, and only show them documents that belonged to that company.

The solution I implemented was developed by Christophe at Path To SharePoint. His solution was a lifesaver. I give full credit to him. I did find that I had trouble following some of his instructions, so I'm going to post a simplified version of how I implemented it here, along with a few pointers that I uncovered along the way.

The solution is two fold:

1. Create the list that will hold the name of the company and the hyperlink field
2. Embed a Content Editor web part in the page that contains a JavaScript that will render the hyperlinks in a friendly manner.

Creating the list:

For illustration purposes, we'll have a list that holds the titles of websites and builds links to their websites dynamically. 

Create a list with a field called "Title". This will hold the name of the website. Next create a field called "Hyperlink". This field will be a calculated field that will dynamically build the hyperlink to the website of that name. 

Enter the following formula in the definition of the Hyperlink field: 

This will  dynamically build a hyperlink of http://www.[Title].com. It will also open the link in a new window. However there's a problem. I created a list item and entered "ESPN" as the website title. Here's what it looks like:

As you can see, the hyperlink isn't exactly user friendly, and it also isn't a clickable link. There is no way I know of to make a dynamically built hyperlink in a calculated field that is user friendly and clickable. Christophe came to the rescue by pointing out that you could embed a content editor web part at the bottom of a page that holds a script that will render the hyperlink correctly.

So, create a web part page, place a list view at the top of the page and place a CEWP at the bottom of the page. You can grab his script at using calculated columns to write html. Make sure that the CEWP is at the bottom of the page. Also, make sure you set the Chrome to 'None' so that the CEWP is completely invisible to the users.

Now when you view your page, it will look like this:

You can see the link now renders correctly, and it is also clickable. Since the hyperlink is a calculated field, you can edit the list item and change the title from ESPN to MSDN. The hyperlink will automatically update.

This is a powerful tool. I was able to use it to link to a filtered view of other document libraries so that only documents belonging to the item in question were displayed.

Thanks to Christophe for the great work.

Creating Managed Paths Using SQL and STSADM

I recently had to stand up a WSS 2.0 development environment for for a client. They had multiple web apps with over a thousand site collections - each with a managed path. Creating a thousand managed paths in Central Administration manually would not only be time consuming, but if a manually typed in managed path contained a typo, the content would not render in SharePoint when the content database was attached.


To resolve this problem I used the following process to create over a thousand managed paths in a few minutes using SQL and STSADM.

• Execute the following query against the content database:

○ Select 'stsadm -o addpath -url ' + FullUrl + ' -type explicitinclusion' from Sites Order By FullUrl

• This results in a list of stsadm commands that will create the desired managed paths as shown below:

 
The next step is to copy the resulting text into a batch file. Give the batch file a descriptive name and place it into the directory alongside the STSADM.EXE file.

The final step is to simply open a command prompt and execute the batch file. Once the operations complete, open Central Administration and your managed paths will be installed.

This was a quick, easy way to automate what would have been a tedious task.