Last week I was working at a client who just restored one of their SharePoint environments because of a site error. Everything was functioning like normal, until we discovered a major issue with the InfoPath forms publishing mechanism.
For some of the Infopath forms we received an error while upgrading the form to a newer version. The error statement told us that we could not update the form because of an object in the database with the same ID.
To resolve the error we tried to remove the existing form, but instead of removing the form, SharePoint decided to do the opposite and it tried to start some kind of upgrade process. We had no more options to upgrade or even delete the existing form.
We knew that SharePoint generates a WSP for each InfoPath form that is published in the Central Administration. The deployment status of each WSP file can be seen in the Solution Management section. Right here we found the source of our problem. The Solution Management page informed us that the WSP package of the forms where Globally deployed, but they gave an Error status. The error status blocked every option to retract or re-deploy the WSP. Looking at the error details the following message was displayed:
Somehow the environment was thinking that the content of the missing WSP package was deployed.
Finally the IT Pro of our client found the solution for the problem in KB939308. It turns out that after a database restore, the contents of the file system cache on the front-end servers can be different from that of the contents of the configuration database.
The only way to fix this is by performing some manual steps:
- All the XML configuration files have to be removed from the SharePoint config directory.
- The contents of the cache.ini file has to be cleared.
- The Windows SharePoint Services Timer has to be restarted.
A detailed guide of these steps is provided in the description of KB939308.
So next time if you have to do a database restore of your SharePoint Server, keep in mind some cache problems might occur.
