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:

1. All the XML configuration files have to be removed from the SharePoint config directory.
2. The contents of the cache.ini file has to be cleared.
3. 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.

The exported database will contain your users, but they are no longer connected to valid SQL Server logins. Even if the same users are existing on the new SQL Server, their ID’s might be different. One of the options is to just recreate and configure the users, but sometimes this is not an option; You might have a lot of users or complicated user rights that you don’t want to check, test and document.

SQL Server contains stored procedure in the Master database to connect your database users with the available SQL Server users. This stored procedure is called “sp_change_users_login”. Just take the steps below to attach your users:

1. Create the (new) required login in the Security database if it doesn’t exist.
2. Run the following SQL and replace the coloured items with your values:
   USE [Your database]
   go
   EXEC sp_change_users_login ‘Update_One’, ‘Original username‘, ‘SQL Server user name‘

Narayana Vyas Kondreddi has written more detailed information about this subject at his website which contains a handy stored procedure “ShowOrphanUsers” which provides you with a list of all unconnected users.

Documentation about the “sp_change_users_login” stored procedure can be found at the MSDN website.