whilst on the surface this seems easy, consider the hardware/effort required. As the current hardware is 2 webservers/1 database server to add a seperate qa environment you need 3 new machines (2 will do if everyone accepts reduced performance - which history shows they will not). The site and datbase are quite large, so a simple backup and restore is not possible, instead the site would need a full restore, after which the site is immeadiately switched off.

Then once you've done the NAT change, you'd have to do an incremental restore to pick up any changes between the time of the restore and the time of the switch off. This could be done via replication , but of course it adds an overhead itself (plus may require a higher cost version of sql server). Once you then switch on, you have to monitor and if theres an issue, switch back (switch the site off, and change the nat) . At this point you now need to restore the database to the original version, but also have to integrate any valid data that's changed such as users, forums, blogs etc., This would be scripted, but would still take some time.

Note: the period of time you'd have to test would be hard to predict - when the site was first updated to 5.1, it ran fine for a few hours due to low traffic, then slowed down, then topped out, so 15 minutes may not be enough, and the current practice of doing it at quiet times may not work, requiring it to happen during weekday high traffic

Of course none of this would help for some of the other recent problems i.e the denial of service attack against the sql server.

I'm not saying that it's not possible to improve this, but it's not as easy as it looks, is a non-trivial problem, and does cost a lot of money (and time/effort) neither of which was available until recently. It's also only the 2nd time that serious problems have occurred in over 4 years of dogfooding.

Personally I'd like to segment sections of the site into totally seperate sites such as a seperate forum, seperate homesite and perhaps seperate documentation/pe sites. That itself has a problem as you then have to syncronise users, and people typically prefer all functions to exist under 1 area, rather than seperate sites.

I think adding a load testing environment where the load scripts replicate similar traffic to dotnetnuke.com is the best first step.

Cathal

If the SQL Server is behind a firewall, it shouldn't be exposed to a DOS attack.. SQL Server should respond to requests coming from the web servers only. Good setup routers and firewalls should be able to block these attacks. If there are too many requests coming from the same ip addresses in a predetermined period of time, a firewall can automatically block the ip address(es). I am not familair with routers but these have their own defensive mechanisms. Second layer is the web server. By then, sql server is well protected. Maybe you have sql server open to the net.