also 40...you said to use ntfs permissions to control users...the dev says the opposite. he says to use sharing permissions and leave ntfs fairly wide open. and i think that's because of the way he has designed his software, in his words, to play "fast and loose" with ntfs permissions. this raid solution is like this...you can pull out a drive and access the files no problem any time. so all his raid is doing is like merging the same directories on different drives together (like windows libraries). so i think that has to do with why he recommends the sharing.
If he does, that doesn't give me warm fuzzies about his technology...but what can you do?
Ok...if that's the case, do it his
way. My point was, when implementing access security, primarily use NTFS permissions - or
share permissions - but don't get too fancy with both. Keep one side dirt simple. There are arguments for both approaches. I prefer NTFS permissions, but it would take me a while to explain why. And it's mostly because I'm more familiar and comfortable with that approach.
If you're getting drives, maybe consider opting for "server grade" or "enterprise" drives if you're getting big ones. They're not that much more expensive. A few bucks at most - and they're far better built and reliable. These are the drives primarily engineered for NAS and related applications. A 4TB runs for around $200 - $225 (street) last I looked.
I'd check with your RAID solution first to see if these are a potential problem for it. Because it's generally best to go with the recommended brands and model numbers when doing RAID. Some cards are extremely fussy about the drives that get plugged into them.
Maybe somebody can shake JavaJones's tree and see what he thinks about all this? He's in the "biz" too. But he deals with a greater variety of client types - and sees a broader range of oddball projects - than I do.
P.S. Your first act after you have a server up and running, plus
all the Microsoft updates installed, and
all your hardware drivers checked and updated, is to make a system image and create a recovery repair disk. Do it before you add any users, create shares, etc. You want a pure vanilla "known good configuration" and properly functioning server image to fall back on if your project one day decides to all go sideways. That way, if you (or somebody else) borks something big time, you have a "genesis image" to reload and be on your merry way with. Figure twenty minutes to put your server back up vs several hours doing it from scratch.