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.
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.
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):
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
Whether or not a user should see a prompt before a ClickOnce application can be installed is determined by the security zone as follows:
Default Trusting Prompt Behavior
Allow user prompting
No user prompting allowed unless the solution is signed by a certificate whose issuer is a trusted Certificate Authority (CA)
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:
To get around the deployment failure described above, then you can choose to do any of the following:
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:
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:
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