There are several directions that you could go that would qualify as a good approach. As much as all of us will build up one solution over another, none of us have enough information to tell you definitely that "this" is the direction you should go. From my experience, you will end up with the best "fit" if you focus on the business needs and drivers first. Then look at what technology best aligns with those. Don't get caught doing technology for technology's sake (aka, cause it's cool). That being said, here are some of the main points that you should consider when choosing the direction to go (this is not intended to be a ranking order, you are the only one that would know the order these should go in): Price, Expected Growth, Support Staff Knowledge Base, RTO/RPO, Cost of Down Time, Work Load (IO, CPU, RAM, GB Capacity), Expectations of Users, Regulatory Requirements. Price: If your budget is tight, but your technical feature needs are complex, Hyper V would be good to look at. Be cautious in pricing with AWS, there are a lot of unforeseen costs if you are not careful. If you have a large budget, and high end technical needs, VMware is hard to beat (thought the technology gap is closing fast on them). Growth: Any virtualization platform with noticeable market share will be able to accommodate this, but you should still go into this with an idea of where you need to be 1, 3 and 5 years down the road. Support Staff: If all they know is Linux, Hyper V will not be "fun" and if all they know is windows, there will be a learning curve on anything other than Hyper V (how difficult that is to over come depends on the staff), and if no one knows storage architecture, you will need to add this to your team either buy hiring, training or outsourcing. Return Time Objective, Recovery Point Objective and the Cost of Downtime: Don't make assumptions here. I have seen sock mills in the middle of nowhere Alabama that would lose $23,000,000 an hour in orders if they went down. These 3 things need to line up. If you want an RTO of 5 minutes and an RPO of 1 hour, but only lose $1,000 an hour, you will likely not be able to cost justify the RTO/RPO. Work Load: Make sure you are not under spec'ed, and don't waste money on features you don't really need. User Expectations: If most of your students are remote to your infrastructure, then, from a total cost of ownership standpoint, you probably should not be looking at purchasing your own gear, as they would see no performance lose if you moved it off site, but you would likely see a cost decrease. If this is the case, look to an out sourced solution (AWS, Rackspace, Latisys (yes I work here...), etc.). Regulatory Requirements: If you are storing student SSNs or payment information, then the design gets a bit more complex (hooray HIPAA and PCI). Sorry for the novel of a post.

Just be prepared for poor performance and a noticeable amount of troubleshooting (particularly around the NICs) before it functions in the way that you desire.

If the title of this post had been: "TN Bill Helps Science Teachers Avoid interference" then 90% of you would not have even reacted. Just because you respond like a mob with pitchforks, does not magically make this bill an attack on all that is your holy shrine of science...The bill does expressly prohibit a teacher to push a religion of any kind. As many of you have aptly pointed out, this bill protects the teaching of evolution just as much as it does the teaching of creationism. If a teacher addresses creationism, they are required to do so only in terms of its scientific strengths and weaknesses. The bill expressly only protects the relaying of scientific information.