The phrase “best practice” is like fingernails on a chalkboard to me sometimes.. why?  Because it’s like an excuse to shut the brain off and not think.

Take for example.. this nugget of a ‘best practice’:

+ Single partition with SBS on a drive larger than 6G not recommended.

If you are concerned that you wanted the entire drive as 14G, you don’t. If you think a single partition makes more sense, it doesn’t. Separating the system drive into separate partitions from the user data drives is much smarter. It solves technical and planning problems down the line.

Uh huh…blast from the SBS 4.5 era of what the ‘best practice’ was then.  And is that 6 gig a ‘best practice’ now?  Oh my goodness no.  The other day in one of the threads Brian said his normal C partition was 15 gigs.. and I had to adjust my brain from SBS view of the best practices to ‘big server view’ where each separate server did a unique role.

…it’s funny isn’t it.. now days 14 gigs for a C drive is way too small.


5 Responses to Okay so THAT’s not a best practice anymore

  1. Russ Grover says:

    I’d have to agree Best Practice is over used.
    Because I always have Minor Differences in Clients.

    However, the one best Practice I recommend is Install EVERYTHING! (Even if you don’t use it.)

    Other than that there’s pros and cons to things and each client should be treated different.

    I ran into a IT company that Did this “Cookie Cutter” approach to SBS, And Installed NOTHING, and treated like a normal 2003 Server. (Yes this is insane.) I hope I never run into any of their clients because I’ll tell them what they are missing.

    So Best Practices? Install Everything, and ask someone who knows about SBS and not an ordinary IT person.

    I really wish Microsoft would Advertise, this is what SBS Does, have a Microsoft Specialist install it. Even a sticker on the box would be great.

  2. I want to clarify a point that Russ made – “one best Practice I recommend is Install EVERYTHING! (Even if you don’t use it.)” I agree with this to a point, but, being in the business of only seeing broken servers, I can tell you that I’ve seen a lot of people shoot themselves in the foot by checking every check box in Add/Remove Components\Windows Components. I believe that Russ is refering to the SBS components list as opposed to the Windows optional components (i.e. Exchange, WSS/Companyweb, ISA, etc). I’m pretty sure that Russ was talking about the former, but I want to make sure anyone reading this is perfectly clear on what you should and should not install.

    I make this distinction because of the number of servers I’ve seen with networking difficulties where, for instance, when you get on the box, you notice that IPV6 and AppleTalk are installed. Can you configure SBS to work with these components? Yes. Have you just increased the complexity and decreased your chances of others being able to help you because you are now in a semi-unique configuration? Yes. Likewise, I’ve seen a huge number of servers where the general complaint is that the server is slow or even sometimes unresponsive, and you get on only to realize that Windows Media services, Themes, and a half-dozen other services that aren’t doing anything for you, but are taking up resources are installed. It should also be pointed out that every component you install is another thing to patch, document, and configure. At the end of the day, you are increasing your cost of ownership for zero benefits.

    So, my advice is this – absolutey complete the SBS installation, but do not fall in to the trap of installing non-essential components without knowing why they are going on the box. Doing so will successfully install all of the SBS components in a supported configuration. Do not, however, install Windows or other component (Exchange, SQL, etc) parts without having a business justification for doing so. If you don’t need a service at the time of installation (for example, if you are not going to use Exchange), by all means install it and then disable the services.

    And that is my best practice 🙂

  3. NA says:

    So what does everyone use now? I like a 30GB partition for the OS/SBS2003. But I’ve seen differing opinions from others… one guy I was talking to the other day just want one partition of 100+GB (the whole HD), and argues strongly against any other type of partitioning, saying that there’s no need anymore.

  4. I was amused when Susan forwarded a link to that URL mentioned in the blog. (If you didn’t notice, that link was a pair of documents I wrote in late 1999.)

    I didn’t have the courage to actually read the documents, because for me _that_ would be like fingernails on the chalkboard. Come to think of it, isn’t it interesting that this idiom about chalkboards is itself becoming dated. Should we use “fingernails on a whiteboard”, or “death by powerpoint” as a more current metaphor?

    Best practices are an interesting attempt to capture habits and preferences in a bottle that means something for a limited amount of time when the technology applicable to it is in dramatic flux.

    As such, I know the question about partition sizing definitely needs to be revisited, but does that imply that the “best practice” on partitions count, distribution, and purpose is now outdate? In a word, no.

    What hasn’t changed since 1999 regarding SBS 4.x and remains relevant to SBS 2003 (and R2 if we must futurecast a bit) is that SBS is a combined DC and application server.

    It remains:

    – DC
    – File Server
    – Exchange Server
    – Web Server
    – Internet/Remote Access Gateway
    – SQL/MSDE host
    – Collaboration Server (think: public folders, company folders, user collaboration moving forward into Sharepoint while still offering the historical uses.

    SBS is many more things, but what it really still is as much as ever is a disaster recovery connundrum. It is this point that drives the logic of partition allocation separations even if the partition sizes have grown 10x or even 100x in size.

    It has never made sense to put everything related to an SBS on a single partition, and if anything, it makes far less sense now then you could have argued it would “then”.

    I have a “SBS Disaster Recovery Myths, Mystery and Magic” presentation I’ve given a few times and will be presenting at TechEd 2006 (Boston June 11-16). It includes a slide on this topic of the “One Big C” which I really recommend against all temptations….don’t do it!

    The logic of allocating different partitions for “different purposes” actually makes far more sense now. Why?

    The counter-argument is “with the option to buy 400G hard drives, we can put everything on one drive volume/partition and never run out of disk space, so why bother partitioning it?”. Why indeed.

    My answer is in several parts:

    1. If you have to do a disaster recovery in which you need to fix a damaged partition or repair the OS, do you really want to have to backup or restore a 400G partition without a smaller capacity option instead?

    If you partition your C drive to some reasonable spaces respective to your need for that partition, you are much better off. Your “c:” system partition generally would not grow in space requirements over a 3 yr life cycle of the server, so look at the baseline need and split the partition at what you consider “reasonable” by comparison to the total you have available. I really don’t care how big you make the partition, I care how much stuff you stuff into it! I think nobody needs much more than a 30G partition. I think I’ve been doing 24G system partitions lately. If you have 500G of disk space, I’m fine with 100G, 250G, 250G of allocation. I say that with the expectation that your usage will be along the lines of 15G, 40G, 80G…and don’t look for a percentage relationship there. What I’m saying is a big mostly empty partition is fine, but the 15G of system configuration is probably all that needs to be there if you have to either do a DR prep backup or restore.

    If you server becomes badly mangled by a service pack or something, you have a relatively small amount of “stuff” to backup or restore, and you can do the entire partition with ease.

    Yet, if you clutter up the C with data, log files, user data and the like, you now have to be a lot more astute and careful in making a backup or restore to fix configuration details because you might LOSE data.

    2. Even if you don’t like the first argument, the second argument is a greatly different point of logic. If you stuff everything you can possible create or add or delete into a single partition, you are rapidly creating fragmentation on that partition. That’s going to slow down the System file performance, the data file performance and the Applications at the same time. It’s far better to have isolated partitions for:

    – System operations
    – Application client/server databases
    – User data files

    For the typical word or excel doc, fragmentation isn’t going to really slow the load time from the server, but it will affect the Exchange Server’s database search and retrieval times. Same for SQL. All of that can be offset somewhat with more RAM, but only a little. Faster drives, also help. But why not optimize the configuration? Spread the partitions to allocate a more logical size separation.

    3. Application repairs, you might not have thought about this one.

    You can put your Exchange (new and improved, now ready for 75G of space) on “one big C”, but now you have to allocate that much more diskspace for recovery on that same partition, or you need another drive, or you need another partition. Just in case you don’t realize it, when you repair an Exchange, figure to need minimum 110% of store-size in free disk space, and I could argue for 150%. That’s just to build the repair file. Now, what about that backup copy of the 75G store before you even run the repair against it. Do you realize that to repair a 75G store you probably need:

    – 75G for the store
    – 75G for a backup of the store before you start
    – 90G for repair file free space

    That’s right, you Information Store alone might lead you to want 240G of space that you can’t use for anything else…ever. Still think you have a lot of free space on that 400G drive?

    Now, go back and revisit that fragmentation problem. If you have this massive store file on a System partition, all those little temp files, logs, reads and writes are fragmenting information in the store constantly, not to mention all the transaction logs of the store itself….or did you put those on another partition???? Wow. What an idea. Log files on a different partition!

    4. Remember when everyone circa pre-Y2K said “you should always install Exchange with the databases on a different drive/partition from the log files” because you have better fault tolerance that way. Anyone remember why that was being suggested? Answer was that if you had a disk crash for the databases, having the the logs survive on a different drive would allow you to replay the logs (without a backup having been made, but they survived on a different drive is the theory) against a restore of the store condition from the previous night. Well….now that most people are running fault-tolerant RAID mirror or 5 they don’t think about this nearly as much…less need there. But there’s another point here.

    If you split the Exchange Information Store Priv1.edb, Priv1.stm, pub1.edb, pub1.stm onto a separate partition from the logs, you can dramatically cut down on disk fragmentation because you have just those 4 files on that partition. Better yet, if you read above that you need to have 240G of space to run a 75G store, here’s a great idea: allocate one other partition!

    You could set one partition at 90G (the maximum required for a repair of a 75G database), and then allocate 180G on another parition. This way, instead of having the server grinding to defrag the 4 files by shuffling them about, you could periodically simply move the databases to the other -empty- partition. Immediately it’s defragged. (yes, I know, defraggins is done automatically by the OS these days)…(yes, I know too that database defragging and file defrags are different things, but I’m trying to stay on topic of the partition needs.)

    By periodically shifting the databases to other drive partitions you can easily clean-up fragmentation and you have addressed the need to allocate partition space…and you have isolated the Exchange files from other applications and data.

    Wow…that means I would need a system partition C of like 30G, 90G exchange, 180G alternate exchange, plus whatever I need for my actual user data files?? If the data files need 100G….this is now looking like 400G!

    Yeah, disk space may be cheap, but it’s not free….you have data backup and recovery risks involved here.

    It’s very easy to see that we can benefit from multiple partitions, and I’ve only scratched the surface on “design” issues for the server as a whole.

    Nobody should install SBS one one big C.

    – Jeff Middleton SBS-MVP

  5. Patrick Hulst says:

    One other argument againts the one big C: thing…. ShadowCopies. However, from what I remember you can’t enable SC’s on your principle OS drive, in this case your c: drive. So one of the big benefits from the user’s standpoint has been removed b/c you can’t use it.