Installing Exchange
-
I'm upgrading my Exchange from 2010 to 2016 and found this group of articles that I more or less like.
http://www.msexchange.org/articles-tutorials/exchange-2016-articles/migration-deployment/migrating-small-organization-exchange-2010-exchange-2016-part1.htmlMy question this morning - Is it really necessary to create all of the partitions this guy does?
Now my install isn't nearly as large the author's, but the Exchange Calculator still saying I should create 2 DB's and split my users over them.
So following that and the author's logic he thinks I should create 2 DB partitions and 2 Log partitions. This seems like over kill to me.
What have you done and why?
-
Seems like a bad idea to me. From a quick look it feels like the author is trying to cover up for not properly sizing, monitoring or managing through partitioning. That's a bad idea.
-
To me it feels like the author is still approaching it from an old school disk performance perspective. One that perhaps wasn't ever really valid (but maybe it was).
-
I would keep at most 1 log drive, and 1 mail drive... (underlying raid, yada, yada)... Anything more than that tends to get way over complicated.
Splitting users of mail stores is easy enough though.
-
@Dashrender said:
To me it feels like the author is still approaching it from an old school disk performance perspective. One that perhaps wasn't ever really valid (but maybe it was).
I wouldn't call it old school. This was always a silly practice. It's more of just not understanding why things were done and applying them at the wrong time. He is, I think, confusing 1990's array tuning with partition log growth protection.
-
@Dashrender said:
To me it feels like the author is still approaching it from an old school disk performance perspective. One that perhaps wasn't ever really valid (but maybe it was).
Which was always a fallacy anyway. By making lots of partitions on a drive you could actually force thrashing on the poor drive. If you had different drives it would've actually made sense. Back in the day people would do all sorts of crazy partitioning on Linux as well, never really made sense to me on a single drive.
-
@travisdh1 said:
@Dashrender said:
To me it feels like the author is still approaching it from an old school disk performance perspective. One that perhaps wasn't ever really valid (but maybe it was).
Which was always a fallacy anyway. By making lots of partitions on a drive you could actually force thrashing on the poor drive. If you had different drives it would've actually made sense. Back in the day people would do all sorts of crazy partitioning on Linux as well, never really made sense to me on a single drive.
That's a great point - I had forgotten that Linux install instructions often recommended many partitions...
-
@travisdh1 said:
@Dashrender said:
To me it feels like the author is still approaching it from an old school disk performance perspective. One that perhaps wasn't ever really valid (but maybe it was).
Which was always a fallacy anyway. By making lots of partitions on a drive you could actually force thrashing on the poor drive. If you had different drives it would've actually made sense. Back in the day people would do all sorts of crazy partitioning on Linux as well, never really made sense to me on a single drive.
Exactly. This is the author not understanding things he learned by rote... Incorrectly. He's got one bad practice misunderstood and another one at the wrong time. What he is doing was always wrong.
-
@Dashrender said:
@travisdh1 said:
@Dashrender said:
To me it feels like the author is still approaching it from an old school disk performance perspective. One that perhaps wasn't ever really valid (but maybe it was).
Which was always a fallacy anyway. By making lots of partitions on a drive you could actually force thrashing on the poor drive. If you had different drives it would've actually made sense. Back in the day people would do all sorts of crazy partitioning on Linux as well, never really made sense to me on a single drive.
That's a great point - I had forgotten that Linux install instructions often recommended many partitions...
Yes. From the big iron days for tens of thousands of users in the 1980s before RAID. Not applicable at all.
-
So now I'm debating - do I need a new thread for different part of this install discussion? LOL
For the DB's themselves - do I really need to have two as the Exchange Calc tool from MS is suggesting?
FYI - Currently we limit non admin users to 200 MB of Mail, and admin are more or less unlimited. our current Exchange DB is 40 GB
-
@Dashrender Does Exchange still have a limit to how big the database can be? If so it might be a good idea to go ahead and use two databases. If I'm remembering wrong then whatever.
-
@travisdh1 said:
@Dashrender Does Exchange still have a limit to how big the database can be? If so it might be a good idea to go ahead and use two databases. If I'm remembering wrong then whatever.
Well, the author - someone we've already shown we can't really trust - says that if you're doing traditional full/incremental type backups, one should use multiple DBs.
-
The author is also suggesting the use of the new ReFS filesystem with data integrity features disabled.
I guess I need to read about ReFS to see if that's really worthwhile or not?
-
@Dashrender said:
The author is also suggesting the use of the new ReFS filesystem with data integrity features disabled.
I guess I need to read about ReFS to see if that's really worthwhile or not?
I'd avoid it till Microsoft decides to make ReFS the default instead of NTFS. I haven't heard of many people using it yet, which means that some bugs are still hanging around that need put down.
-
@Dashrender said:
FYI - Currently we limit non admin users to 200 MB of Mail, and admin are more or less unlimited. our current Exchange DB is 40 GB
Wow, that's tiny. Surely at that size it doesn't really matter what you do, you'll never have any issues? How do users cope with just 200mb?
Rightly or wrongly, I've always believed calculation tools always massively over-spec. I've always started small with the knowledge that I can expand later if I hit any problems (I never do). So for example, is there any reason you can't start with one DB and add another at a later date if you're unhappy?
I'm no expert, just an interested by-stander, by the way.
-
It's kind of in a blogger's interest to make things as complicated as possible isn't it? The more complicated it is, the more he has to explain...
I find the same with cookery writers (my other interest) - why use one pan when you can write complicated recipes that use three?
-
@Carnival-Boy said:
I find the same with cookery writers (my other interest) - why use one pan when you can write complicated recipes that use three?
Your other interest is cookery, or writing about cookery?
-
@scottalanmiller said:
Your other interest is cookery, or writing about cookery?
Both. I cook and I collect cookbooks.
-
@Carnival-Boy I definitely could start with one (that's what I have today) and expand if needed.
How do my users live with so little email - the reality is that they don't. One good thing about this is that email doesn't collect a lot of misc junk that will never be referenced again. If it's that important, it's saved off and put on the network - at least for the typical staff.
Email for those users is more of a notification board - and a way to send stupid cat pictures. If a user ever came forward and said they needed more email space, a process has been put in place to do an overview of what the user is saving and if it's legitimate, they are given more space. In 6+ years of Exchange, that has never happened.
Before that, users didn't have email access here. More and more systems are requiring unique email for password resets, etc - so we've opened email to everyone company-wise.
-
@Carnival-Boy said:
@scottalanmiller said:
Your other interest is cookery, or writing about cookery?
Both. I cook and I collect cookbooks.
Ah. I thought you collected cookery. Cooking makes more sense :)
I'm sure someone collects cookery as well.
