June | 2008 | Srinivas Varukala's Bits & Bytes

The standard approach to upload any managed form template is to go to central admin and select ‘Manage form templates’ and upload the form template. The process isn’t complete, the ‘status’ column should show as ‘Ready’, only then we can activate it to a site collection. Once we upload the status shows as ‘Installing’ and once the SharePoint timer job kicks in it completes the installation behind the scenes and the status is changed to ‘Ready’. The same happens with ‘Deleting’ which completes only when the timer job completes it.

This whole process is long and gruesome if we have to repeat for many forms so I posted some time back on how to use stsadm.exe script to upload/delete/update the managed form templates. That works great.

But it didn’t work for few days back, once the upload is done, the status remained as ‘Installing’ forever . I ran the ‘stsadm.exe -o execadmsvcjobs’ command which forces the timer jobs to complete. Even that didn’t help. Just to get rid of the form, I opted to remove the template which changed the status column to ‘Deleting’ which remained like that forever.

I then started looking out for the reasons behind this weird behavior, and I see that either there should be a problem with the form template itself or the server farm. I ruled out the first reason because, I was not able to complete the upload process for none of the forms.

So, the problem is with the server farm, in which we have a single application server, a single front end web server and a database server. For the upload process to complete, the form template has to be propagated properly to all the servers in the farm. For this propagation, there are 2 important services which should be ON and working, they are:
SPTimerV3 and
SPAdmin
Run the following command to make sure those services are up and running on the servers in the farm:

net start SPTimerV3
net start SPAdmin

I checked the both on App and Front end servers and both those services were up and running. I was taken aback because this leads me to no where but back to the problem. After some time I ran those commands on the Database server too and I found that the SPAdmin service was not started on it. Once it is started all my form templates worked like a magic.

So just make sure the above services are up and running on not just the application and front end web servers but also on the database servers. Here is a good post which talks about the same.

UPDATE: I completely missed writing about how to undo the stalled status after uploading the form. Please follow the below instructions as per the post I mentioned above:

From Central Administration, go to the Operations page, under the Global configuration group, click on Timer Job Status. On that page, look for timer jobs that have the name in the following formatting. If you filename is FOO.xsn, it will look like:
Windows SharePoint Services Solution Deployment for “form-FOO.wsp”

See if there was a failure. If so, go back a page, and go to Timer Job Definitions. Drill down in the timer job definition that you care about and you can perform the following:

>> For the case of status stuck on “Uploading”:
1. Try to restart the job if that is available.
2. If restart is not available, delete the job, then attempt to upgrade again.

>> For the case of status stuck on “Upgrading”:
1. Try to restart the job if that is available.
2. If restart is not available, delete the job, then attempt to upgrade again.

>> For the case of status stuck on “Removing”:
1.       Try to restart the job if that is available.
2.       Else, Remove the job. (continue to step 3)
3.       Then, go back to the Manage Form Templates and try again to Remove the form template.

In simple terms, open the Timer Job Definitions and open the wsp entry you are having the problem with and delete it. Now go back to the ‘Manage Form Templates’ page and delete the problematic form template.

Choosing between InfoPath forms and ASPX pages, depends totally on the nature of the problems we are solving on one side and level of skill set we are investing in solving that problem on the other side. Usually, in most cases, any manager or developer would want to use InfoPath Forms part of Office 2007 because it’s quick and easy. But, as the requirements get more complex and requires more and more customization, one might feel its better to go with ASPX pages and Visual Studio 2005 and SharePoint designer. Technically, InfoPath Forms by itself is incomplete; It needs a container which is again an ASPX web form using the XmlViewer web part. If we go with custom ASPX form, then it has to be designed either using SharePoint designer or Visual Studio leveraging web parts to show the required forms. So for this, developing web parts and its complexity needs to be taken into consideration.

So, to decide on one, we may have to take the decision step by step.

If the requirement is for a single form and showing data from an external data store or from within SharePoint, then going with InfoPath Forms is recommended.
If it’s a single form and needs complex actions, to and fro between the form and the data store, then choosing custom aspx pages is recommended.
If the requirement needs wizard kind of feature i.e. which requires user to go through multiple screens, then custom aspx is the solution.
If the data submitted through the form has to be saved to multiple locations (database, SharePoint, file storage) then InfoPath Forms is a good solution.
If the requirement is for designing numerous forms which are simple enough and well documented, then InfoPath Forms should be considered. InfoPath can help deliver the solution in a short time period.
InfoPath browser based forms has few limitations on the repository of controls one can use. For example: combo box, master/detail view control and many advanced controls are not supported in browser based InfoPath Forms. Depending on these limitations we have to decide on InfoPath or ASPX. ASPX has no such limitations.
InfoPath forms is based on XML. The form is rendered using XSLT stylesheets and the data submitted through the form is available in XML format. The data is well structured to retrieve later on and dump the data/forms in some external system. This in combination with BizTalk server is a perfect architecture for document transition through multiple levels.
InfoPath forms certainly have an edge over ASPX forms as a quick and neat solution. It has some complex out of the box controls, like date picker, file attachment control, repeating sections. InfoPath forms can also have code-behind if needed to manipulate the data on the form or behind the form.
ASPX can have and do everything InfoPath Forms does, with an exception of additional development effort. Apart from it, the deployment process of aspx forms is much better and easier than InfoPath Forms.

Below are some of the excerpts from few blogs I follow which provides some valuable input comparing InfoPath and ASPX forms. Below are the Pros and Cons in using InfoPath Forms:

Pros:

Ideal for simple forms
Easy to build a form – no coding involved
InfoPath form itself is an xml document.
Support versioning
Works very nicely with SharePoint custom workflows as a workflow association tool.
Fully integrated in Microsoft Office 2007 suites like Outlook e-mail messages that can be deployed as Outlook e-mail messages, so colleagues can complete forms without leaving the familiar Outlook environment.
Firewall friendly. InfoPath Forms Services make it easy to extend forms solutions beyond firewall because of using many different Web browsers and mobile devices.
InfoPath can easily convert Word documents and Excel spreadsheets to forms and build templates to work with.
InfoPath provides data integrity and version control for document management purposes, and add structure to information gathering by converting legacy documents to rich InfoPath form templates.
Design of a form is much easier in InfoPath forms with a simple drag-and-drop interface and provides support for prebuilt template parts and shared data connections.
Creates PDF or XPS and other important document formats and is extensible by addition of a free plug-in to install third party tools and components for document, archival and records management
Fully integrated with MOSS 2007 and capable of using integrated workflow management tools in Office 2007
Fully Web browsed technology, includes a design checker to help ensure consistency for forms.
Support for information rights management to help manage permission control and building a powerful document management team site.
Fully centralized for entire organization and enables organizations to centrally

Cons:

A web browser-enabled InfoPath form does not support all features of InfoPath client.
Inflexible — Difficult or impossible to customize (well, you can argue that you can hack the xsl file of InfoPath)
No support for image buttons
No support for html
No support for tree control
Difficult to support Forms Based Authentication
By default, InfoPath cannot support SharePoint web services data connections in FBA.
Forms Services does not support username() function in FBA. This means that InfoPath form does not recognize the current user.
Difficult to perform automated web test against Forms Services.
Difficult to support automated deployment. Basically, you have to unzip the xsn file and programmatically modify the manifest.xsf file, and zip back to the xsn file for automated publishing.
The way that Forms Services supports deployment of InfoPath forms is quirky – It creates SharePoint solution packages with GUID and creates features with meaningless names on the SharePoint Features folder.