Assistance in spec'ing a new server

[Coup27]

Work have finally given me enough budget to overhaul our current peer to peer with a NAS drive system into a client/server setup with an SBS2011 server and new standard computers for everyone where they will be setup on a standard image with restricted access. I could do with some help in accurately gauging the specs of the required server.

The server will centralise file and print access and management and run exchange for 10 users. Expansion needs to be also considered. Emails is a bit of a sticky wicket. We work in engineering and people often send large attachments. My users aren't the most computer literate at the best of times so getting them to move emails into the project folder and then delete them isn't going to happen, so I need to work around this. The MD's PST file is currently 10GB. I have two more between 5-10GB, a couple between 2-5GB and then rest <500MB. User data, company data etc is loosely 70GB. This does not include images of the users machines. This will either be one image or 10, depending on the issues with licence keys.

So far I have been recommended a Fujitsu TX200 S6:

1 x Xeon E5645
1 x Dual socket motherboard
2 x 8GB RAM ECC (not sure how that works in tri-channel )
4 x 300GB 15K 3.5" SAS HDD's
2 x PSU for redundency

2 x HDD in RAID1 for SBS2011, exchange, WSUS
2 x HDD in RAID1 for data and various backups

Initially the price I was quoted by an IT provider for this was nearly £2000 more than I could get it from a server e-tailer. The same server e-tailer also said it was massively overkill for our needs. He said we could easily do with 3x4GB RAM and 10K HDD's instead. He said 15k HDD's are only needed in heavy load database servers which ours isn't. He also said the CPU was OTT.

The same bloke said the Xeons offered in the TX150 S7 are too weak. HP's ML350 offers the same range of CPU's as the TX200.

I would have liked to have found a way of having Samsung 830 SSD's in there instead but if I go put that in an OEM server I may as well rip up my warranty, thats even if I managed to get them to fit. Fujitsu SSD's are all SLC so are mega money.


We are not tied to an OEM server as theres many options available and it doesn't have to come from one of the big boys. I am after some assistance in calculating the hardware requirements from some unbiased people.

Thanks.

 

[blckgrffn]

PST files suck when it comes to having them on your NAS. They are so freaking IO intensive, indexing, updating, etc. I would really recommend not having the PSTs on the server. Horrible experiences there, but that was a much larger deployment then you are talking about here.

 

[tynopik]

shouldn't the main email storage be in exchange and not outlook?

 

[Ferzerp]

Just gonna leave this here

http://support.microsoft.com/kb/297019

Additionally, the one supported scenario for networked .pst files is described in this article. The scenario is using Microsoft Outlook 2010 remotely on a Windows Server 2008 R2 Remote Desktop Session Host (RDSH).

It's never going to work well.

 

[blckgrffn]

Just gonna leave this here

http://support.microsoft.com/kb/297019



It's never going to work well.

I pointed that out (with KB) in my organization after they had migrated us to Exchange w/PST files in our "My Docs" - that was redirected back to our then Novell file servers (actually, pretty stable for the ancient tech...) and then our file servers started dying in cruel, cruel ways...

No one wanted to take responsibility. Eventually they condemned the file servers, bought a huge NetApp and only had to deal with locked files every now and again. I mean, I was in the freaking group, having to deal with the server outages AND the people who made the decision with the PSTs, it was very uncomfortable. At least the VMware environment and block storage (what I "owned") was free from the disaster.

I moved my .pst to my C: drive so it didn't suck so bad to look through....

 

[Coup27]

Either people have gotten the wrong idea or I havent explained that bit very well.

The PST's larger than say 1GB will be archived as "year dot to 2012" PST. They will then begin again using exchange with an OST on their local machine. The PST's will sit on the server and Outlook will point back to them but the files will be made read only. This way they can still occasionally look back at an old email but all new ones will go through exchange and the OST method.

PST's a 1GB and under will probably be imported into their OST and done away with.

Or something like that

 

[Ferzerp]

When I designed our 2010 install, I gave specific instructions for all the techs to inject any PST encountered back in to the mailbox and delete the PST. The load was never much of an issue as the network itself was always the bottleneck, but the location they'd managed to find a home on was all backed by 15k FC drives, whereas the 2010 databases are on much cheaper 7.2k SATA 1TB drives. Going from 900Mb of cache (the 2003 max) to around 30GB of cache per mailbox server along with the changes to the jet db that Exchange uses allowed for much better performance on bulk disks capable of far fewer iops than the old install. Of course, at the end of the day, it's still taking up far too many disks for my liking, but at least it runs well.

They publish a IO reduction of 90% from 2003 to 2010. In my experience, that number is pretty accurate. I don't know how many iops we *needed* with 2003, but the entire install was pushing 3,000 most of the time during business hours (the max those disks could handle). Now it's something like 400 total with better performance.

edit: to clarify, the load wasn't much of an issue on the file servers, but the performance of the app itself was still rubbish.

 

[Ferzerp]

Either people have gotten the wrong idea or I havent explained that bit very well.

The PST's larger than say 1GB will be archived as "year dot to 2012" PST. They will then begin again using exchange with an OST on their local machine. The PST's will sit on the server and Outlook will point back to them but the files will be made read only. This way they can still occasionally look back at an old email but all new ones will go through exchange and the OST method.

PST's a 1GB and under will probably be imported into their OST and done away with.

Or something like that

This will not work. A PST will not open if it is truly read only. Try opening a PST off a CD if you don't believe me. If you're marking the file read only, and it still opens, that means that the application isn't respecting the read only flag. If it's enforced, it won't work.

 

[mv2devnull]

1 x Xeon E5645
2 x 8GB RAM ECC (not sure how that works in tri-channel )

One CPU and two RAM makes a dual channel. 5600-series can run non-tri configurations.

 

[Coup27]

This will not work. A PST will not open if it is truly read only. Try opening a PST off a CD if you don't believe me. If you're marking the file read only, and it still opens, that means that the application isn't respecting the read only flag. If it's enforced, it won't work.

I'll gladly take your word on that. It was only a suggestion to prevent them from moving new emails into old folders thats all.

 

[Ferzerp]

If you're using Exchange 2010, you can use the poor man's archiving built in, just be careful not to expose any features that require an e-cal unless you're paying the extra $30 or whatever per mailbox to use it. You can dump them off to different storage, they've available via OWA, and the client when online, but not available when offline (but neither are networked PSTs). Or just re-inject the mail if volume isn't an issue.