Deploying BCS Simple Solutions

Previous posts have mentioned how to represent business data as external content types, creating external lists out of these external content types, and how to eventually make this business data available offline in Office applications like Outlook and SharePoint Workspace. The posts showed that this data is taken offline in form of a BCS simple solution which the user then installs on the client machine. In this post I will talk a little bit more on the nature of this BCS solution and point out some information that is important to know to ensure that you have a seamless experience deploying simple solutions.

When you click the “Connect to Outlook” or “Sync to SharePoint Workspace” button on an external list, the first thing we do is to package all the artifacts relevant to this external list into a ClickOnce application package, which then constitutes our BCS solution. As such, a BCS solution is inherently a ClickOnce application, and all the rules, regulations and limitations that govern general ClickOnce applications are applicable to our BCS solutions. Once this ClickOnce application has been successfully created, and the necessary prerequisites are met on the client, then the Visual Studio Tools for the Office system (VSTO) installer is launched to install the application.

Security in ClickOnce Applications

ClickOnce security model relies on trusted publishers or user prompting to determine elevation of privileges that would allow a ClickOnce application to be deployed to a client. If a ClickOnce application has been signed by a trusted publisher, then the application, without prompting, automatically elevates its own privileges and goes ahead with the installation. However, if the application has not been signed by a trusted publisher, then ClickOnce does not automatically trust this application, and you are prompted to confirm that you want to install the application. However, this prompting is neither automatic nor is it guaranteed: it is determined by the security zone from which the ClickOnce application is being installed from, as explained below.

User Prompting Based on Security Zones

ClickOnce makes use of Code Access Security (CAS) to determine the deployment experience, for instance whether or not you should see a prompt asking if you want to install a solution. By default, ClickOnce relies on the five built-in security zones that are defined in Internet Explorer (IE):

• MyComputer
• LocalIntranet
• Internet
• TrustedSites
• UntrustedSites

These zones are used by CAS to make trust decisions for prompting level and behavior. Each zone is determined by the full path address of the deployment manifest file (in the BCS case, this is the URL of the BCS solution in the external list.) Below is an example of some URLs and their corresponding security zones:

ClickOnce application URL	Security Zone
C:\contoso\clientsolution\customer.vsto	MyComputer
https://contoso/clientsolution/customer.vsto	LocalIntranet
\\contoso\clientsolution\customer.vsto	LocalIntranet
https://fabrikam.contoso/clientsolution/customer.vsto	Internet
https://www.contoso.com/clientsolution/customer.vsto	Internet
\\127.0.0.1\clientsolution\customer.vsto	Internet

Whether or not a user should see a prompt before a ClickOnce application can be installed is determined by the security zone as follows:

Security Zone	Default Trusting Prompt Behavior
MyComputer	Allow user prompting
LocalIntranet	Allow user prompting
Internet	No user prompting allowed unless the solution is signed by a certificate whose issuer is a trusted Certificate Authority (CA)
TrustedSites	Allow user prompting
UntrustedSites	No user prompting allowed unless the solution is signed by a trusted certificate whose issuer is a trusted CA

The MSDN article “Configuring ClickOnce Trusted Publishers” has more information on security zones and how to deal with prompting (pay special attention to the “Get into the Zone” section).

Our out-of-box deployment experience uses a self-signed certificate to sign our BCS solutions. Being self-signed, therefore, the certificate is not from a trusted CA. This leads to the following default experience for LocalIntranet and Internet zones:

1. If your external list is in a LocalIntranet zone when you take it offline, then you’ll see a prompt like the following:

   

2. If your external list is in an Internet zone then you won’t be prompted, and deployment will thus fail with an error like the following:

   

Avoiding Deployment Failures due to Default Prompting Policy

To get around the deployment failure described above, then you can choose to do any of the following:

1. In an enterprise scenario, administrators can provide CA-issued certificates to be used to sign their BCS solutions. Another post on our BCS blog, “How can I get rid of the “Publisher cannot be verified” message when taking external lists offline?” explains how to do this.
2. In an enterprise scenario, administrators can also push a Trust prompting policy through their Group Policy infrastructure if they want different prompting policy than the default ones explained above.
3. Users can add the SharePoint site to the list of Trusted sites or the Local intranet sites in IE. Needless to say, this is not recommended for every site and should only be done for sites that the user can vouch for.
4. Users can add a PromptingLevel registry key that defines the behavior that they want. The MSDN article “How to: Configure Inclusion List Security” explains how to do this. Something to note here is that if you have installed the 32 bit version of Office on a 64 bit machine, then the registry key needs to be created in the corresponding Wow6432Node node.

Prerequisites for BCS Solution Deployment

It is worth mentioning that connecting an external list to either Outlook or SharePoint Workspace can only be done from a SharePoint Server 2010 with Enterprise Client Access License – all other servers such as SharePoint Foundation 2010 will not be supported. Now, for a BCS solution to be deployed to a client machine, it needs to have Office Professional Plus 2010 or Outlook 2010 standalone already installed. Other requirements for connecting an external list to function are the following:

1. .NET Framework 3.5 (.Net 3.5)
   Service pack 1 is also supported. If .Net 3.5 is not installed, then you will see this error message when you try to connect an external list to Outlook:

   

   SharePoint Workspace will show the following error:

   

2. Business Connectivity Services (BCS) feature

   • BCS feature is installed by default when Office Professional Plus 2010 is installed. However, the feature is dependent on .Net 3.5, so if .Net 3.5 is not installed at the time of Office installation, then BCS will not be installed. You will therefore see the above error message if you try to take an external list offline as we’ll first detect that .Net 3.5 is not installed.

   • If you eventually install .Net 3.5 and then take an external list offline, the first thing we do is to perform BCS Install on Demand. You will at this point see Office being configured, and once this is done, VSTO installer will be launched to install the solution.

   • If you have .Net 3.5 installed but choose not to install BCS (by marking it as “Not Available” in Office Installation Options under Office Shared Features) then you will see the following error message when you try to take the external list offline to Outlook:

     

     SharePoint Workspace will show the following error:

     

Browser Support for BCS Solution Deployment

Our mechanism for taking external lists offline makes use of an ActiveX control to check the prerequisites mentioned above. Since only IE supports ActiveX controls, taking external lists offline is only supported in IE. The experience in non IE browsers like Firefox is that the “Connect to Outlook” and “Sync to SharePoint Workspace” buttons will be disabled as shown below:

Summary

In this post, we discussed the nature of BCS solutions and pointed out that they are essentially ClickOnce applications. We talked about the security model surrounding ClickOnce applications, including using trusted publishers to sign the applications, and making use of the various security zones to determine the default prompting behavior. We provided some ways of avoiding deployment failures due to default prompting policy, and finally, we mentioned some prerequisites that are necessary for successful deployment of BCS simple solutions.

- Sam Kabue, Software Development Engineer in Test