Cisco :: WLC Fail-Back With 1140 APs

We've recently sold and implemented a wireless solution using a WLC, WCS and 1140 APs.
 
There is a HQ site where the WLC, WCS, DNS and DHCP reside. Active Directory and a RADIUS server are also located there. There is then a WAN link to remote sites which sometimes fails. At the remote sites you'll just have a router, switches and the APs. The intention is for the APs to work in lightweight mode, falling back to H-REAP when the WAN link fails.That works fine, but what doesn't work fine is the APs rejoining once the WAN link is restored.
 
They just don't. Even days later, the APs are still all disassociated from the controller despite the WAN link being up. I've 'hardcoded' the controller IP into the AP configuration, while the APs initally get the IP for the WLC from DHCP using Option 43. Despite the APs therefore knowing where WLC is, once they're disassociated from it (WAN link failed) they will not reassociate by themselves. Restarting the APs is the only way to get them to rejoin.
 
With hundreds of APs and in excess of 30 switches, restarting all the APs each time the WAN link fails is pretty ridiculous.
 
I've logged a TAC case and gone through the whole rigmarole, this is an offical bug and Cisco have informed us that it's due to be fixed sometime early 2011, but besides that there is nothing they can do. So to be perfectly clear, Cisco have sold and shipped a product that doesn't work as advertised and they best they can offer us is a promise to fix it soon. I'm pretty shocked, I've never had this experience with Cisco in the past.
 
Ok, so now I've got to come up with a decent workaround until we get a firmware release where this is fixed. I'm looking at using CNA to automate the reloading of all the switches, I guess when an outage is reported I'll just write a procedure for the client to follow to reload all their APs.
 
A script that can query the associated status of APs and reload them as needed, automatically, would be pretty cool. Perhaps that can be done with SNMP.