In this case, they had tested DR strategy etc in place. Unfortunately when it came to doing it for real (onto the same backup hardware the DR plan was tested against), TSHTF and Windows threw an obscure COM error loading the AD catalog. That required contacting MS 1st line who didn't know what it was so had to escalate it to the AD guys. One obscure registry key change and an ACL change (related to ESE) and it was back.
All best practices followed, yet complexity, poor design and secret knowledge crept in and shot the whole process.
Stuff like that scares the shit out of me having been on the end of it way too many times now.
Many a night have I spent up at 2AM trying to work out why the hell something odd has gone on inside Windows and taken something out in production. Not once in 20 years has a proper Unix (Solaris/FreeBSD) box woken me up or shafted me for hours.
The DR environment was the staging environment for the patches. Periodically the production kit would be block copied back to the DR environment and sysprepped.
Every step to prevent differences between the two clustered environments were taken.
Every system has bugs.
Never been a fan of Xen. It doesn't strike me as quality software. Then again no virtualization solution has to me, yet. I'd rather just deploy all the services to the base machine and use MAC to isolate them.
I'd be overjoyed if I never had to admin Windows again, but it's a bit unfair to frame that as an OS comparison.
The most basic of direct from TechNet 'best practices' would reduce the impact of a failure of that sort to minutes.
That said, that sort of failure not at all uncommon. Further, I expect such disasters would happen far less often if an existing, poorly implemented Microsoft environment could be remediated into something better as directly as anything unix-like.