LEAP wireless clients work, then fail, Using WISM blades HELP

Question

I am at a complete loss. Calls to Cisco, working with different vendors, nothing has worked to solve the problem. This is what we see, and we see this at every single one of our hospital sites.
All hospitals used to run just IOS code on their AP's. Some hospitals used the older 1200 series AP's, which have been upgraded from B only radios to A/B/G. Some hospitals were rolled out with newer 1240 series AP's. Every single hospital was just fine when using IOS code on the AP's. Users never disconnected or disassociated. They were fine. Clients run a mixture of the old Cisco 350 series cards, or Ubiquiti A/B/G cards.
Now, fast forward and we started installing WISM blades in all the 6509 distribution switches at each hospital. AP's were then upgraded to lightweight code and at first everything seemed great. Then the calls started.
All clients at all hospitals will just disassociate. It is completely random. Some machines can see it once, others 50 times a day, then tomorrow, totally different. I have witnessed the same thing with my laptop. We have 3 WLAN's in the hospitals. One that uses LEAP authentication, one that uses Certificates, and one that is our Patient WiFi. Both LEAP and Certs have the issue. I have never been kicked off of the Patient WiFi system. Not once.
LEAP clients use the same exact ACS servers they have always used. Nothing changed in the configs. Same goes for the clients using certificates.
I have upgraded code on the WISM blades 3 times now. Currently we are using the 5.187 code. I have tried forcing all AP's to use only B/G radios, tried using only A, doesn't matter. Same problem happens.
What is even worse, when this event happens, 50% of the time you have to actually reboot the workstation to get it to log back onto the wireless network. It fails the attempt and it just stops. This is not everyone at the same time either. There seems to be no event that I can find where all clients have the problem at the exact same time. I can have two devices side by side, same exact NIC, same software, everything. One will disassociate, the other is just fine.
I am out of ideas. Everyone I talk to at Cisco says never heard of this before. I just can't believe we are the only ones that have ever seen this problem.
I can take the same workstation that is breaking left and right on our wireless networks using the WISM blades, go to a site with AP's still in IOS mode, it will never disassociate and disconnect.
Has anyone heard of this, have any ideas of something I could try. Would you like to see any other information about this? I can post whatever you like to help. I am looking for any assistance on this.
I have been trying to do some searches on this forum, but for whatever reason it seems to be very slow so thought I might post my issue as I search around, maybe if it has already come up and there is a fix, someone could direct me right too it.
Thank you in advance.

Answer 1

I tried that in the beginning. Put all ap power and channel as hard set. It did not change anything. I am not sure if we have tried the 4.2.207 code. I know we went through several 4.x.x codes in testing. Cisco recommended the lastest one that we are on now.
What really gets me is how everything worked just fine until the WISM upgrade. No AP placement changed, no additional AP installs, we just installed the WISM blades, migrated code to lightweight and everything started flaking out.
What other NIC's do people use? Maybe the brand we use is not any good? I have been up and down with the vendor, tried different drivers, nothing seemed to change anything.
It looks to me like the WISM sends out some kind of response that the workstation NIC's do not understand, so they just sit there. On wireless sniffer traces, you can see where the request goes out to the workstation, but the workstation just never responds, hence the lockup so to speak. It will just sit there until a reboot of the PC.