InfoPathology - Part 10 - Form Deployment

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:

• Enable Code Signing certificates on the Trust Root Certificate Authority machine in your domain (referred to as the CA machine from here on in).
• Install the certificate onto your development machine via the Windows Certificate Server's web enrollment interface.
• Sign the form and deploy it via the InfoPath Publishing Wizard.

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).

1. Open the form in InfoPath.
2. Click “Tools” and then “Form Options.”
3. Click the “Security” tab.
4. Make sure to uncheck the “Automatically determine security level…” box and see that the “Fully Trusted” radio button is selected beneath it.
5. In the bottom section, check “Sign this form.”  The three buttons on the bottom light up.
6. Click “Select Certificate.”
7. On the next window, select the certificate that you requested from the CA and hit “OK.”  
8. Hit “OK” on the “Form Options” window.  This puts the focus back on the form.
9. Under “File,” click “Publish Form.”  This will first recompile your Visual Studio solution.  Before doing this, make sure your Configuration Manger is properly set up to build only the projects necessary (especially this form’s projects).  Otherwise, you’ll be waiting around for a possibly large solution to compile completely, or wasting time chasing bugs caused by assembly version conflicts since they weren’t complied.
10. The Publish Wizard appears.  This is actually one of the most intuitive pieces of InfoPath.  Use this wizard to plop your form wherever appropriate.  You don’t have to worry about coping or deploying assemblies or content files; everything is wrapped up the .XSN executable file.

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:

1. Click "Details."  An Internet Explorer form pops up with information about the certificate and its chain up to the root CA.
2. Click "Install Certificate."
3. This begins a short wizard.  Select "Automatically install the certificate..." and it will place it in the Trusted Root Certificate Authority Store.
4. Click "OK" on any security pop ups and finish the wizard.
5. This will put the user back at the "Always trust content..." pop up in InfoPath, and the checkbox will still be disabled.  Unfortunately, they will have to hit "Cancel" at this point, and close InfoPath.  
6. Have them redownload the form, and this time, they will be able to trust the certificate, and never be bothered by it again (on that machine).

Finally, regardless of where your certificate came from, there are some things to keep in mind:

• Forms must be resigned EVERY SINGLE TIME they are published.  Publishing or saving your form strips off the certificate.  Nothing makes the tech support line come to life faster than forgetting to sign a form before deploying it, and having users get an InfoPath soap exception that reads: “This form is trying to access files and settings on your computer…”
• Certificates can expire.  This adds some long term maintenance considerations to your solution.  This is not an onerous ordeal; all you need to do is acquire a new certificate and resign and publish your forms with it.  However, it is one more thing to add to your task list.
• When you request a certificate on a Windows domain, your user name will show up on that Internet Explorer security window.  I’ve found it best to create an account on the domain with a user name such as “<company name> Security Team” to be used to sign and deploy the forms.  This way, the <your name here> Certificate Authority won’t make users squeamish about allowing your content onto their machines.

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.