Thursday, December 31, 2009

The form template associated with this form was moved or cannot be accessed. The form template on your computer has the same form ID as the template

Many of you might have come across this shitty error while developing custom InfoPath forms and deploying them to SharePoint. I have spent ages in playing with InfoPath in troubleshooting this error and many others. I will explain quick fix for this error for the moment.

"The form template associated with this form was moved or cannot be accessed. The form template on your computer has the same form ID as the template associated with the form, but it is from a different location."

Now, lot of times you would deploy InfoPath form to SharePoint document library or content type using the Publish wizard feature. In my case I had to deploy my custom DIP (Document Information Panel) to a custom content type. Now I had written a feature receiver for content type which assigns my custom DIP to the content type once the content type is created by feature. Since I had developed InfoPath form on my dev machine and deploying it to dev SP site it complains about Form ID as in above error. This error means that when you developed a form on your machine and saved it, it has added a publishURL attribute as the saved location. Now even if you publish this form to SharePoint, the publish URL remains the same. So the buggy publishing wizard doesn't update this attribute. So when my document with custom DIP is opened it tries to fetch the InfoPath form from SharePoint location where publishedURL is a path on my machine where the form was developed and saved and it gets confused when trying to create it from SharePoint location.

So we know the fix now its easy : Remove the publishURL from the form isn't it?
YES and NO, the solution is easy but actually fixing it is not. To change this URL its pain in right place!!! If you use InfoPath designer option of "Save as source files" and then change the manifest.xsf and then save it again using InfoPath designer then the publishURL attribute is repopulated. So you have to do this removal outside of InfoPath.

Below are the steps to remove publishURL attribute from the form:
  1. Rename .XSN form to .CAB
  2. Extract all files from CAB file to a temporary folder.
  3. Open manifest.xsf file using Visual Studio or in a notepad.
  4. On the very first node (root node), remove name and publishURL attributes. Just get rid of those devils!!!.
  5. Now you need to repackage those files into a cab file - So we will use makecab.exe tool.
  6. Create text file in same location where your folder with extracted files are. Name it something like makefilename.txt. This file is like .ddf file if you have played with generating .wsp packages. Anyways, lets not get distracted, so what will go in this file? Well just copy following script and replace the names:
  7. ;************************************************************
    ; MSDN Sample Source Code MakeCAB Directive File


    .Set CabinetNameTemplate=Replacefilename.XSN

    ; Change DiskDirectoryTemplate to where you want the CAB/XSN saved.
    ;********Replace this path with your where you want to create the cab file********
    .set DiskDirectoryTemplate="C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates"
    .Set Cabinet=on
    .Set Compress=on

    ; List Every File You Want Added To The CAB (XSN)

    "C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\AO.xsl"
    "C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\Context.xml"
    "C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\Context.xsd"
    "C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\dc.xsd"
    "C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\dcmitype.xsd"
    "C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\dcterms.xsd"
    "C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\GetUserProfileByName1.xml"
    "C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\GetUserProfileByName3.xsd"
    "C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\min1\GetUserProfileByName4.xsd"

    ; End Of The File
  8. You will notice in your folder you have either more or less files to be packaged, if they are less then its easy to put them manually, but if the form is higly customised like mine was I had like 20 files to be packaged. You can get all the filenames in a text file easily by running DOS command from the folder location as mentioned below:
  9. dir "." /b >>fileListing.txt
  10. Now you can copy the filenames form filelisting.txt and place them in above makefilename.txt file with paths appended in front
  11. Now run makecab utility as: makecab /f C:\Documents and Settings\kk\Desktop\ContentTypes\DocumentTemplates\makefilename.txt
  12. You can find your new xsn file at the mentioned location.
Now in many cases this problem wouldn't arise because usually you publish the form directly from InfoPath. But since in my case I have to deploy everything as a package I have to make these changes in my .xsn file after it has been designed finally and then generate a deployment package. I will explain you in my next post on how to package your custom InfoPath DIP and apply it to you content type as part of a feature.

Thursday, October 22, 2009

SharePoint 2010 Secrets

Any one interested in knowing about what to expect from SP 2010. Read here:

And look for more sneak peek videos here:

Thursday, September 10, 2009

Error while trying to run project: Unable to start debugging ... The components for the 64-bit debugger are not registered

I had installed Visual Studio 2008 64 bit version on Windows Server 2008 and after install it complains about this error. Tried the specifed solution but remote debugging components are not a part of the features list in install setup. So digged down the install cd and found
"Remote Debugger/x64" folder. There we go found the installer about which Visual Studio was complaining. Error is gone! And I can hit F5 in my project without any errors :-).

Thought I will post this if someone might end up in same situation and so don't have to waste time digging around for solutions.

Wednesday, September 9, 2009

Could not normalize the SPItem after installing SharePoint Connector for FAST

I had setup SharePoint connector on my FAST server and provided SharePoint username and password which has go read access to sharepoint site. However, when starting the document processing the content retreiver fails and complains about not being able to retreive content because of unauthorized access to the item its trying to retrieve. Following is the exact error details: com.fastsearch.esp.connector.sharepoint2007.adapter.SPAdapterController: Could not normalize the SPItem 3b370549-3f6f-4d3f-b7c8-1d98884101ce;450526c0-5b6c-452a-a655-b1093b7e9d46;1. Exception: com.fastsearch.esp.cctk.framework.NormalizationException: Could not get content for the url: 'http://moss/Lists/Announcements/DispForm.aspx?ID=1'. Exception: com.fastsearch.esp.cctk.framework.AdapterException: Error downloading file: http://moss/Lists/Announcements/DispForm.aspx?ID=1 from server: HTTP Status code: 401. HTTP Status msg: Unauthorized Looking on the IIS logs for the get request for "'http://moss/Lists/Announcements/DispForm.aspx?ID=1" no username is associated. Not sure which user account document processing stage is using to retrieve the content.

So investigated further on this issue and ended up solving it by configuring Web Authentication Proxy. For some reason one of the dcoument processing stage when requesting content from sharepoint was not using the SharePoint username/password specified in the configuration. So have to setup Web Authentication Proxy to force it to use a specified account while retrieving content.

Hope it might help some one, sometime :-)

Friday, August 28, 2009

“Could not connect to config server at 16005”

Today I dived into installing FAST evaluation version at my home server. First thing I see in the Admin GUI Logs is an error thrown something like below:

“Could not connect to config server at 16005”

Initially the error doesn't tell you much about the real issue, but having a closer look at logs list it was complaining something about "License file cannot be checked out".

Well there can be few reasons for this license file complaint, either the format of port details or FQDN or any other entry is not right as it should be or something else that could be missed easily. So I went into the /etc directory where FAST was installed and looked at fastsearch.lic fileAt closer look only (or may be because of my dumbness LOL!!) I found that the license file was expired. So there we go all I have to do is to request for another evaluation version and upgrade my license file at this location:
FASTSEARCH%\etc\fastsearch.lic and restart FAST installation. (restart is done by simply going into Start->Programs->FAST ESP->Stop FAST->Start FAST)

Note: Even the evaluation version is not freely available you will have to be a partner or customer of FAST/Microsoft to be able to get a valid license.


Tuesday, July 7, 2009 ajax client-side framework failed to load

" ajax client-side framework failed to load"

Many of you must have seen this error on some occasions or the other. While there are many posts if u google regarding this error, saying different things. For me it was a strange situation, so the solution provided in this post might be or might not be applicable in your case. But it's worthwhile to give it a go as there is a reason why this error came up in my situation.

Little bit of background: I had this web app running on my VM. Project was created using VS 2008 and VM was having upto .Net 3.5. And the ajaxcontroltoolkit.dll was in the bin folder.

Now I moved this visual studio solution into my home server having VS 2008 and .Net 3.5 SP1. Everything running fine on home server.

Next day I had to take the solution back into my VM on work machine. So copied the solution, opened it and hit F5 (to run the web app!). And what is see on my face is " ajax client-side framework failed to load".

I tried looking for various solutions by googling it. But none of the solutions made sense to me or didn't fit my situation. Then I thought of leaving the google aside and stressed my mind trying to find the differences. Offcourse .Net 3.5 SP 1 was not available on my VM, but then why should it effect ajaxcontroltoolkit assembly? Still trying to go with gut feeling, I applied .Net 3.5 SP 1 on my VM and saw that the error ranaway.

Now my web app runs fine and the ajax controls were loading fine. Apparently the assembly was JiTed on my home server with SP1 updates which I have to bring to same state on my VM.

Another option you could also try is to repair your .Net 3.5 or .Net 3.5 SP1.

Tuesday, January 20, 2009

Is MOSS a Records Management System?

I have been asked now and then from my clients and friends a question: Whether MOSS is a Records Management System?

To answer the question in 2 letters. "NO" its not a Records Management System. Having said that MOSS does provide lot of features and capabilities to work as a records management system. Out of the box MOSS provides us with a Records Centre Site template which gives great deals of webparts and features that suits Records Management System. Want to see in detail? Check Here:

As per some of the requirements in Commonwealth Government Archiving policy following statements has to be met for a records management system:

· management and tracking of both physical and electronic documents and records, specifically semi-active and inactive records
· records disposal
· document and records metadata and classification
· conversion of record types, other than those created with MS Office products, to long-term, open preservation formats
· reporting for records management purposes
· electronic recordkeeping storage for automated workflows which would enable documents to be captured as records as part of normal business processes, and
· maintain records in series, consignments, unit for archiving.

More details on the archiving policy is found here:

Lot of the requirements as per the policy can be achieved with MOSS by having a Record Centre portal where documents or records can be directed from main MOSS portal. Check here .Now depending upon to what level the policy needs to be met, customization will be required. Customization could involve following:

-Redirection code from MOSS portal to MOSS records center.
-Records disposal can be achieved by using the Information
-RightsManagement Policy – Expiration policies.
-Metadata information can be stored with the document using content types in MOSS.
-Conversion of records created from Office products will involve custom code or use of conversion tools.
-Reporting of records management is available to an extent for any further reporting it will involve development of custom reports.
-Workflows can be initiated to divert documents to records centers from MOSS portal.

However, TRIM is used as a records repository in most of the government departments. If we need documents in MOSS portal to be integrated with TRIM, then there are 3rd party solutions available which does seamless integration between MOSS-TRIM. These solutions can be leveraged to achieve the desired requirements, some of them available and know in the market are as follows:

TiPS for SharePoint from Infocentrik : . This tool does the integration and automatic routing in a great way. Also provides search capabilities and more.

HP TRIM Module: . This is a well known tool as well which does routing of documents and other integration levels.

There is a solution provided by TowerSoftware for TRIM Context.

So in nutshell if just MOSS needs to be used for Records Archiving to meet the archiving policy we need some customization. If TRIM is being used then we need to look for options for integration.

Saturday, January 3, 2009

How to repair a SUSPECT SQL database

Firstly a very Happy and a Prosperous new year to everyone!

As usual I was doing things on my VPC and I noticed that one of my SQL database was marked suspect. After some thought I guessed that the reason for the database to be marked suspect is because of me turning off my VPC without proper shutdown. The same reason why a DB can be marked suspect after a power failure. Now I was in a fix because I didn't had backup (Another dumb thing to miss on my part). So what should I do now? Well some research brought me good results, ended up framing following query:

EXEC sp_resetstatus ‘DBname’;
DBCC checkdb(’DBname’)

So all you have to do is copy and paste above query in query analyzer and replace DBName with your database name. And you are good to go now!