Finally, now that our InfoPath forms have been completed, it’s time to cover form deployment. (I’m going to skip SharePoint deployment for now, as that will be discussed in a later posting.) If you are going to use straight InfoPath with no managed code, then a lot what I discuss here will not be a worry for you.
As advertised, certificates are the ideal way to go when it comes to developing fully-trusted forms. The work to be done here in InfoPath itself is minimal; the fun actually takes place on the server. There are three main steps to complete to sign and publish a “certified” form:
Unfortunately, (and inevitably) the Code Signing template is not available by default on a Windows 2003 Server that has been promoted to a CA. Therefore, we’ll need to get onto this machine first and work some magic to allow it to be requestable on the CA’s web enrollment interface. This is not too horrible a task for a Windows 2003 Server Standard Edition machine.
If your CA is the Enterprise Edition of Windows 2003 Server, life gets a little more interesting. The Code Signing template is actually in a Windows 2000 Server formant, and therefore needs to be “duplicated” in order to be to a 2003 Server-compatable template. The exact steps on how to do this are beyond the scope of this posting.
(However, there is one quick hint that I leared after serveral calls to Microsoft's InfoPath team: try right-clicking on the Code Signing certificate on the server, and select "Allow Web Enrollment" or something along those lines. Hopefully, this will save you some of the trouble - and dirty looks from the network team - that we had to deal with...)
Once this certificate is available, the next step is to log onto the CA’s web enrollment interface and install it onto your development machine. This interface is actually just a wizard-like ASP web application that allows users to create and install certificates for various usages that are guaranteed to be from a trusted source.
Again, this is beyond the scope of InfoPath form deployment, and can vary from network to network. But most of the default values (key length, encryption type, etc.) can be left as they are for this purpose. The only major thing to be sure of is to select a Code Signing certificate. Once you save and install the form (which will be done on your development machine), InfoPath will automatically make it available.
Finally, we can load up our form, sign it, and deploy (for forms with managed code-behind).
There is one interesting footnote here. It is actually possible to deploy forms signed with InfoPath home-grown certificates. Back on Step 6 above, you can optionally click “Create Certificate.” This will generate a legitimate certificate from the <insert your name here> Certificate Authority. When users access your form for the first time, they will have to manually import and install this certificate.
Although not necessary a difficult process, this importation is certainly beyond the expected ability of our standard user, and really is just bad deployment etiquette. However, if you are in a pinch and need to quickly roll out a form to a test group for example, and you don’t have time (or access rights) to mess around with the CA, this method works great and doesn’t sacrifice any functionality or security policies.
Finally, whenever a user downloads any form for the first time signed with a new certificate, a familiar Internet Explorer security window pops up, asking if they want to “Always trust content from…” you. All they have to do is check the box and hit OK. This certificate will (almost) never again bother them. This may not even come up at all, if your root CA on the domain is already trusted. If, however, you deployed with an InfoPath-generated certificate, you’ll find that this box is grayed out the first time. Here is what users must do to trust your form in this case:
Finally, regardless of where your certificate came from, there are some things to keep in mind:
There are certain scenarios in which certificates aren’t the preferred deployment method. For example, if you are not on a domain, or on a domain without a CA machine. When budget time comes around, you’ll find third party certificates coming in with a hefty price tag. Perhaps a client does not have a network or Internet connection, and InfoPath forms designed for them are intended for purposes other than information sharing.
If this is the case, then fully-trusted forms still have a way to be distributed. The answer is creating an MSI to manually install the form on each client’s machine. Installed forms have all the same permissions as certified forms, so security implementation and form functionality concerns are not issues when making this deployment decision.
I also feel that the standard Windows installation wizard is not outside the expected knowledge of a user. Closing their eyes and clicking “Next” until the window disappears should be a familiar procedure for them to follow. Like certificates, this only has to be completed one time, until updates are available.
Updates, actually, are the only drawback to form installation deployment. A bit of background: whenever you open a form template (XML) file, InfoPath searches your computer for the corresponding executable (XSN) file. They are matched based on a Universal Resource Name, or URN, that is specified in the metadata of each file. Therefore, if version numbers and URNs don’t match up, the form will not open. What this means to us is that to properly update a form, it needs to be uninstalled and reinstalled.
I have barked up the tree of trying to write a little pseudo update manager that manually copies a new XSN file onto the client’s machine and keeps the same URN and version number. But in order to keep the template and the executable on decent speaking terms with each other, it requires too much coordination on the user’s part. If they are used to merely clicking a link and then an “Open” button on a popup window to download a form, a user won’t take kindly to having to download multiple files and placing them in certain places.
Here is how to create an InfoPath MSI package. For SharePoint deployment, there are a few additional considerations, which will be covered later. Basically, you use a command-line utility dubbed the InfoPath Form Registration Tool. I'll let Microsoft get into the details for this procedure here.
Finally, there are some requirements for code behind to work that are not intrinsic to InfoPath development itself. First of all, and this might not be obvious, but InfoPath needs to be installed on the client’s machine; the shared location of a published form will not host the application. Next, the .NET Framework 1.1 has to be installed BEFORE Office 2003. Although the setup program of Office has the options to rectify the situation resulting from incorrect installation issues, life is much easier if they are installed in this order. And lastly, Office 2003 Service Pack 1 is required for code-behind to work.