Skip to content

InfoPath Forms Services – The form template is not browser-compatible

Every once in a great while Murphy meets me at my doorstep and decides to do a “Ridealong” all day.  Occasionally I keep one step ahead of him.  Due to some much appreciated help from the InfoPath product team – today is one of those days.

A quick rewind, just more than a week ago I ran out of time before going to the SharePoint Conference.  I was trying to publish an InfoPath form for a client.  I opened in design mode with Infopath that day and I got a complaint about a duplicate key violation.  I quickly change the XSN file extension to CAB, extracted the files, fixed the manifest.xsf (I think it was that file) and used MakeCab to create a new cab file.  I renamed the file to XSN and I thought everything was fine.  InfoPath opened in design mode.  However, as I said I ran out of time before publishing the form.

I arrived at the client this morning to publish the form and started by getting some drop down list data on to their environment.  During this process I noticed something was wrong.  Knowing that I hadn’t rebooted in several days I decided to reboot my laptop.  For good measure once my laptop was rebooted I decided to take the virtual machine I developed the form in and restart it.  I figured I’d start clean to eliminate problems.

It’s at this point in the story that Murphy decided that he needed to get involved.  So what happened was I got a Check disk happen when I restarted the VPC.  Normally I don’t pay much attention.  When I started seeing it scrolling the screen with sequential sector numbers I sat up and paid attention.  Somehow a substantial amount of the master file table and directory structure was unreadable.  I’m still not sure what caused this melt down.  So after quite some time I got the system to boot up and I got logged in.  There was, however, a serious problem.  Explorer couldn’t start because SHELL32.DLL was missing.  It turns out that Task Manager (Ctrl-Alt-Esc) also needs SHELL32.DLL.  So I have an unbootable system.

I attached the drive as a secondary drive to a working VPC and turned on undo disks… of course the files that I needed were gone.  I tried a file recovery tool that I bought and it didn’t work.  That’s surprising because I’ve seen it bring back entire directory structures in the past.  I’m becoming impressed at the amount of damage that Murphy did in really short time.

I come back to my office … I look to my backups and find that I have a backup of the image from a week ago – after I had done all my work.  After some restore time … I had nearly (if not everything) that I had lost.

So I start working on my publishing in my test environment – so I can verify that I have everything.  Here’s where Murphy thought he had me.  I publish the form and get a message on the Upload Form Template page:


The form template is not browser-compatible.  It might be possible to correct the problem by opening the form template in Microsoft Office InfoPath, and then republishing it.


So I go back to InfoPath and rerun the Design Checker.  I got 8 messages about some post backs that needed to happen – and no errors.

So I open the ULS Logs (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS) and find an interesting error:

Help Your SharePoint User


GetSolutionInformation failure: The following file is either missing or is not part of included in the form template: OSD220.OSD To add a file to the form template in design mode, use the Resource Files dialog box on the Tools menu, and then add the file you want.


So I crack my XSN by renaming it .CAB and see that the file it’s complaining about actually exists. it looks like this:


<?XML version=”1.0″ ENCODING=’UTF-8′?>


<?XML::namespace href=”” as=”MSICD”?>

<SOFTPKG NAME=”Cab1″ VERSION=”1,0,0,0″>



<CODE NAME=”AddMoveChangeRequests”>


<CODEBASE FILENAME=”AddMoveChangeRequests.dll”>






Well, at this point I’m stumped.  So I drop an email to some very nice folks (Thanks Nick & Brian).  The inform me that InfoPath will show the same error if I try to fill the form out (and not use Preview as I’m in the habit of doing.)

It seems that when I put the file back together from fixing the duplicate ID problem I somehow accidentally sucked up the OSD file and it’s not supposed to be there.  (Because it’s not listed in the manifest.xsf)

They are kind enough to tell me how to fix it too.  Take the form in design mode and do a File-Save as Source Files.  Then open up the Manifest.xsf in design mode and finally doing a Save As to turn it back into a packaged XSN file.

Apparently the OSD file is an Open Software Description file … I still don’t know exactly what it’s supposed to be.

So here’s what I learned today:

  1. If you get a message that a form isn’t browser enabled… Check it.
  2. If you check it and see that it is browser enabled and there are no errors check the ULS logs
  3. If you get a message about a missing file in the ULS logs it could be the file is present and shouldn’t be.
  4. You should always try to fill out the form.  Just testing with Preview isn’t enough.
  5. It helps to have good people willing to bail you out when Murphy tries to do a “Ridealong”


No comment yet, add your voice below!

Add a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share this: