Partager via

Behind the Scenes of Administrator-Approved Form Templates

  • Article

If you’re a server administrator for Microsoft Office InfoPath Forms Services 2007, there may be a time when you’re tried to perform some action on a form template and received an error message that looks like the following:

“Form template was deployed as part of the 9b518781-2fcd-40fe-a1f4-964b2cd4c0b8 feature”

This feature name probably doesn’t mean a whole lot to you, and the error message could be a bit more actionable, right?  What the heck is this feature thing that the message refers to?  You might also have come across other IDs or other weird timing issues on a multiple server farm.
 

Starting the Tour

So, to shed some light on this, let’s go back-stage to see a little of what’s going on behind the scenes.  The stage is Windows SharePoint Servers Central Administration, where you will find 5 options in the Microsoft Office InfoPath Forms Services group on the Application Management landing page. This tour will mainly be concerned with the Upload Form Template page and a little bit with the Manage Form Templates page. 

Let’s start at the Upload Form Template page, which is how a form template gets approved by the administrator.  Each new form template uploaded to the farm also adds a new FormTemplate object to the FormsService.FormTemplates which is the singleton FormTemplateCollection object for the farm’s administration object model.  This FormTemplate object allows the same manipulation that is available through the UI.  It also contains a lot of information used only internally to InfoPath Forms Services.  The most important internal property is the converted file, which is essentially a compiled version of the form template that can quickly render as a form template in the browser.

When InfoPath form templates are uploaded to a server, the Windows SharePoint Services solution deployment and featurization infrastructures are being used to turn the form template into an administrator-approved form template..  Behind the simple click of the Upload button, InfoPath Forms Services creates a feature to deliver the form template (.xsn file).  The feature is then wrapped in a Windows SharePoint Services solutions package which is a .wsp file (just a renamed .cab file) that contains the feature and some other packaging information.

The Solution Package

This solution package is the means of deployment to all of the servers in a farm.  All Web front-end servers will have the form template propagated to their file systems, via the solution’s package.  So, there may be a delay in showing up on a multiple-server farm, hence the ellipsis in the “Installing…” status which remains until the form template is deployed to all machines in the farm.  These are propagated via the SPTimerv3 service which runs on each box and is scheduled to pick up jobs from servers running the central administration Web Application (where the Upload took place) and it uses the SPAdmin service to install the solution on the machine, via the administrator account.  So, InfoPath Forms Services deployment needs these services running on each machine, just like WSS solution deployment, because it’s actually the same thing.  Once deployment is completed, the form template is marked with “Ready” status.

[Side Note: An implementation just like what we use for solution deployment is also available to you.  Our shipping documentation covers how to create features and solutions from scratch.  You might want to do this to bulk deploy many form templates at the same time, to indicated InfoPath form templates in other features or solutions, or to create a custom workflow that contains custom InfoPath form templates.  These custom-created solutions are still registered into the InfoPath Forms Services OM, but will be treated a little differently in IPFS, for instance, you cannot activate/deactivate/remove/upgrade these form templates through IPFS management, because that might invalidate the overall solutions that were constructed.  The whole features must be activated the same way that other custom features are activated (see Ready for Activation, below).]

Ready For Activation

The Ready status indicates that the form template can be used and is in normal operation.  The feature created, is a site collection-scoped feature (that’s SPSite-scoped in WSS OM-speak), which can be activated on an site collection like most other site collection-scoped features.  If you are a site collection owner, navigate to Site Settings, and see Site Collection Features under the Site Collection group heading.  Every form template that was administrator-approved through the upload page is available here along with the other site collection scoped features.

You can also activate and deactivate features from the Manage Form Templates page in Central Administration.  This is exactly the same thing, and is provided as a courtesy for farm administrators who are also site collection owners.

Behind the Scenes of Activation and Invocation

An activated form template is added as an item in the Form Templates library at the root site of the site collection (SPSite.rootWeb) in the /formservertemplates path.  The form template is not actually present in the content database for the library, it is stored as a ghosted entry.  A user invoking the form template with the Microsoft Office InfoPath 2007 rich client is actually pulling the form template from the file system of the Web front-end server where it was placed by solution deployment.  Invoking the form template via the browser will pull the converted file from the FormTemplate object in the administration object model.

The Form Templates library is special in a few ways.  The most important special aspect is that activated form templates cannot be unghosted.  This is to ensure that the converted file version and the on-disk version cannot be different, so that no matter what client you fill the form in, it’s the same form. 

Be a Better IPFS Admin with this Knowledge

Our hope is that this article will make our behavior more clear and expose a few tricks to help you be better Administrators.  Here are a few tricks in how to use that information to your advantage.

Handle the error:  “Form template was deployed as part of the 9b518781-2fcd-40fe-a1f4-964b2cd4c0b8 feature”

If you receive this, you most likely want to remove the form template and start over.  Here’s the action to take, and it’s only available from the command line:
"%ProgramFiles%Common FilesMicrosoft Sharedweb server extensions12BINSTSADM.EXE" -o uninstallfeature -filename 9b518781-2fcd-40fe-a1f4-964b2cd4c0b8feature.xml

Form template’s status never leaves “Upgrading…” or “Removing…” states

These states seem to indicate that you're running a multiple-machine server farm, and on your server farm, you're running into some issues in propagating changes to all of the machines.  If you have not done so already, I highly recommend turning on the following services on each machine: SPAdmin, and SPTimerV3 You can do this by running:
                net start SPTimerV3
                net start SPAdmin
On each machine.  Net start is a ensure semantic, so this will not inadvertently toggle or cause any damage if run on a machine where the service is already started.  Now that that's done, you can go on to correcting the problems that you have.

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.

Ed EsseyProgram Manager Alexei LevenkovSoftware Design Engineer

Comments

  • Anonymous
    June 09, 2008
    PingBack from http://sharenotes.wordpress.com/2008/06/09/infopath-managed-form-templates-upload-status-stuck-or-remains-forever-in-installing-or-deleting-state/
  • Anonymous
    August 10, 2009
    hello infopath team, alexei --i have been encountering the same problem described above with regards to the form template's status never leaving "Installing" and never becoming "Ready". i have ensured that all the jobs listed under "timer jobs status" have a "Succeeded" status and i have ensured that the two required services (SPTimerV3 and SPAdmin) were running prior to uploading the form template in each of the web and front-end servers -- except the database server since those services do not exist within the DB Server.I read somewhere that the "SPTimerV3 and SPAdmin" services should be running within our DB Server and could not understand why this was a requirement. Can you please help? Do we really need to install SPTimerV3 and SPAdmin within our DB Server?appreciate the help in advance.-Gezelle RiveraManila, PhilippinesAvanade/Accenture
  • Anonymous
    June 27, 2010
    Hi,You have post good information.
  • Anonymous
    March 30, 2011
    I run net start commands, change form name, remove job and add it again. remove form template and upload again.etc...but no one help me! :(
  • Anonymous
    June 25, 2011
    Very informative, however, I need to go through it again tomorrow in order to understand better.Thanks
  • Anonymous
    October 20, 2011
    The timer job status for  Microsoft SharePoint Foundation Solution Deployment for "e33d9ecb-ffe5-81e9-9c32-e3fbd8892154.wsp" is "Succeeded".  Is there anything else we could try to have this template removed? The template is forever stuck in the "Deleting" state.
  • Anonymous
    January 27, 2013
    Can we rename the WSP to something meaningful in InfoPath 2010 & SharePoint 2010?
  • Anonymous
    January 27, 2013
    Can we rename the WSP to a meaningful word in SharePoint 2010 and InfoPath 2010?
  • Anonymous
    June 19, 2015
    Thanks for explaining in such details, this gives the insight what is actually happening in background