Deploying an InfoPath form involves examining the type of InfoPath development that was performed, whether the forms you developed were codeless or code-bound. When developing custom forms that don’t hook into any backend business logic, the forms can simply be deployed to the server by an end user for consumption by other organizational units. However, if the .XSN contains backend business logic, a server administrator must intervene in the deployment process in order to deploy the form, providing the vital step of allowing activation of the form before the form is consumed by the user base. Server administrator intervention is also required when other conditions for form deployment are met, namely if the form being deployed requires full-trust, since Forms Services offers domain trust or restricted security as the only other options. Server administrator intervention is required if the form is leveraging a data connection that is building a sensitive data pipe, and therefore is managed by the server administrator. These data connections are usually managed through the use of a Data Connection Library, and the relevant data connections must be approved before they are available for users that are using the SharePoint Form Designer.

Form Verification

As pointed out earlier in this section, there are several deployment considerations to take into consideration when deploying an InfoPath XmlFormView control. The first to consider is the list of unsupported controls that HTML cast forms are subject to. The following is a list of the controls that are supported within Forms Server as well as those that are not supported.

Supported and Unsupported Controls

When deploying a form to the Forms Server, it will verify that you are not using any of the above controls along with the warning and errors that are thrown for your custom form, going back to the “Design Once” principle that was introduced earlier.

Form verification can be performed by the server administrator prior to the deployment of a form by using the STSADM command line tool provisioned by SharePoint by navigating to the

1) %system%
2) Program Files
3) Common Files
4) Microsoft Shared
5) web server extensions
6) 12
7) BIN 

directory. In order to verify a form from the command line, the verifyformtemplate command can be used by specifying the filename as a parameter. The complete command structure will take on the following form.

stsadm –o verifyformtemplate –filename

Deploying InfoPath Form Templates

Deploying an InfoPath form template requires examining whether the form is bound to backend code and thereby requiring administrator approval, or is a simple form and can be uploaded into a Forms Library. When deploying a complex form, one that has backend code bound to it, a simple checklist can help to quickly get it available to users.

Deploying Templates Checklist

Following, the form will be available to site owners in the advanced settings of the form library.

InfoPath Security

InfoPath provides three main modes of security, each of which has its own implications that must be considered when examining how data is being brought into them. Generally, the domain security setting is sufficient as it will prompt the user if a sensitive action is going to take place.

InfoPath Security Modes

Each of these security modes can be seen within the InfoPath client interface under the Form Options in the “Security and Trust” option (see Figure 14-12)

Figure 14-12

Cross Domain Access

Besides the security modes, there are some important security considerations to take into account when using the browser cast InfoPath forms that deal with inherent domain principles. When you are deploying an InfoPath forms that is targeting users that will be using the browser, it is important to realize that data that is outside the local domain from which the form is running is not accessible to the form. This however is not the case with the InfoPath Smart Client, which can functionally massage data from other domains. When constructing InfoPath forms, this is an important concept for the developer to consider, since if the data does not lie within the local domain a replication method in order to push the data would have to be constructed in order to surface the relevant values into the local domain so that the browser can get access to the values.