Known issue with web gardens / garden / farms & load balancers :
Server Error in '/' Application

The issue with web gardens / garden / farms is the result of known problems with the way the Application and Session are handled in IIS. Essentially, although session state is kept since you are running a state server, application state gets lost when the user goes from one server to another. This is because Izenda Report uses a server's memory to cache objects and server memory is not mirrored on a web farm.
Microsoft recommends using web gardens only in cases where there non-managed code is executed that runs for an exceptionally long period of time outside the .NET framework. Essentially both session and application state get lost when the user goes form one server to another. There is potentially significant overhead in keeping multiple processes synchronized. Since managed code is already multi-treaded it performs better in a multi-threaded rather than multi-process environment within the same server because memory is shared among the managed threads.
With that in mind, you could use session affinity on your web farm. We do not know whether IIS natively supports this. However, ISA server does and is designed to manage a web farm for this purpose.
Web Server Farm Load Balancing
Network Load Balancing Integration Concepts for Microsoft Internet Security and Acceleration
It uses a cookie to ensure that the request is always routed to the same webserver.
To recap, here are three known solutions:
1. Place Managed Code Applications (like Izenda) in a separate Application pool on one server.
•Since IIS 6.0 is multi-treaded, this will actually perform faster than using a web garden/farm
•Because managed code support garbage collection, there is no need to recycle processes to conserve memory
2. Use Microsoft ISA Server to control the web farm and set session affinity
3. Use A Distributed State Server 3rd party product
•ScaleOut software makes a high-performance distributed state server that supports clusters and gardens.
•These products are designed to solve state management for all ASP.NET objects, not just session
4. Use Microsoft StateServer/SQL State for session handling and apply any AdHocSettings items in OnPreInit() for every page. You use the OnPreInit() since Izenda Reports caches items in server memory, they must always be guranteed to be there if server affinity is not being used.
•To prevent duplicated code, create a static method and place all items normally in Session_Start in that method
•Call this method from the Pre-Init event by overriding the OnPreInit() method for every page that connects to Izenda
•Ensure that any any references to Izenda's API do not run until after Pre-Init has executed for that page.
•The ASP.NET state or SQL State service must be started on the server
Session-State Modes