Iis 7 application pools not starting after installing ibm client access

You have a fairly unique situation where COM becomes a bottleneck so that you can't simply scale up. Ideally improving performance with the COM objects or replacing them with managed code would scale even better, but you're on the right track for a COM performance workaround.

1. IIS is able to handle hundreds of app pools, so that's not a problem. It will add a few MB of RAM with each app pool but no extra performance overhead.

2. Sure. By app pool, I assume that each is a full site with its own app pool. That's all good.

3. If you don't have to, don't change the processor affinity because it means that you need to maintain and tweak it forever. If the CPU utilization is pretty flat, then you're good with the defaults. If you have other applications on the server or if you see a big imbalance, then consider processor affinity. IIS does a good job of utilizing them for the most part though, so it's best to let it do the heavy work if possible.

4. As you say, sticky sessions addresses that, so you're good. Web gardens may have solved your COM issues if you didn't have InProc session state to worry about. As a side, you can consider using ASP.NET's state server. Have each server use the local state server and have the load balancer use sticky sessions with 1 binding per server. That would address session state (as long as everything serializes, which it usually does) and it will allow you to easily play with the web garden settings without having to mess with the load balancer.

Make sure that your IIS_WPG group has read/write access to your deployment directory