Avoid Application Pool Conflicts
In IIS 6.0, different versions of the .NET framework can co-exist on the same website but must use separate application pools. Once a .NET process "grabs" the app pool, other .NET processes are denied its use and report generic server errors in the browser. Which .NET process gets an app pool first depends on which is first requested after an application pool recycle. For example the .NET 2.0 process might get the application pool first, and all .NET 1.1 applications that rely on the application pool fail to run; end users see generic server errors that do not report what is really going on.
Installing Inmagic Webpublisher or Genie
Although Webpublisher inmagicbrowse and Genie inmagicgenie virtual directories are correctly set to use .NET 2.0, the installer lets the parent website determine which application pool to use. A typical Windows 2003 Server might have .NET 1.1 and DefaultAppPool as the default on new websites. If there are any .NET 1.1 applications already on the server that rely on DefaultAppPool, then inmagicbrowse and inmagicgenie are setting the server up for an application pool conflict.
Separate Application Pools
Set up a separate application pool just for Genie, and one for Webpublisher. This way you avoid any conflict with applications currently on the server, but also allow for changes in .NET dependency in future: when Genie starts using .NET 3.5 you won't have to worry about re-organizing application pools. It's also good practice to isolate applications like this so that when one does go down, it doesn't take other applications with it.