Re: SBS 2003 Installation Drives - Folders

Tech-Archive recommends: Speed Up your PC by fixing your registry

"SuperGumby [SBS MVP]" <not@xxxxxxxxxxx> wrote in message
news:%23OrMBxBMGHA.2696@xxxxxxxxxxxxxxxxxxxxxxx
I think your plan is crazy.

Should you move the application installation points you will reduce the
space required on the OS partition significantly. A 20GB partition has
enough space to accept the default program installation points. There is
also reason to practice caution about moving the installation point of the
major SBS applications, SBS is tightly integrated and by moving the
application installation point you may experience a problem when, say, a
service pack comes out.

The system is overpartitioned. Please explain the benefit you perceive by
using these additional partitions.

The plan does not account at all for:
companywide shared data (either sharepoint or the 2000 style 'company
shared folder')
private user shares
roaming profiles or folder redirection (if implemented)
Though you mention CRM is to be installed you seem to have already run out
of space by dedicating it to other tasks.

I would create a single RAID 5 array using 3 HDD's and the fourth as
hotspare. Total usable space 140GB partitioned as 20GB for OS/Program
installation point and a single DATA partition using the rest, all DATA
(exch/sql databases included) would reside on this partition. I _may_ move
the logfiles to this partition as well.

I've been waiting for proponents of the seperate partition for
Exchange/SQL databases to pull me up on a point (I've been involved in
more than a few such discussions), a point I have ignored but thought
about recently. The effect of large database files on Shadow Copy. I
haven't thought this through completely but at 'first level' it would seem
sensible to have such large databases on partitions excluded from Shadow
Copy, relying on the underlying database technology to 'roll back' or
'recover' data rather than allowing them to consume your Shadow Copy
allowance. If this 'pans out' in the manner I'm thinking I may well change
my position to '20GB for OS (turn off shadow copy), xGB for specifically
Shadow Copy excluded files, remaining GB's for Shadow Copy enabled
partition (DATA)'. The partition which holds the files excluded from
shadow copy could also hold the shadow copy data from the standard DATA
partition.

Super,

All data inside CRM goes on the SQL partition. Same goes for your Sharepoint
content. Here is some data for the Sharepoint scenario -
http://www.microsoft.com/technet/prodtechnol/sppt/wss/wssipo2d.mspx
All user data goes on the Data partition
Exchange data goes on the Exchange partition
Neither of these has a chance to overflow the disk capacity. Databases are
rather easy to move should the disk capacity come close to being exceeded.

There is ample expansion space on this server either internally or through
addition of another storage array. Budget is obviously not a problem - CRM
licenses are not cheap. Notice that there is an additional file server on
this network already, which makes this mostly an application server.

The natural progression for this server will likely be to deploy SQL for CRM
on a separate member server once SBS R2 is released.

I would say this is close to an ideal configuration in compliance with most
of best practices.

Microsoft supports deploying its integrated applications in different
locations on the same server, but that's where the big C: partition will
come in handy for supporting system updates. It insists on putting a lot of
common files in %WINDIR%, which is a questionable practice, but we'll see
what happens in the next major release.

In this proposed configuration, this server will be very easy to bring back
online due to compartmentalization. Typically, the users would not notice
the disk failure. I could probably do a functional rebuild in an hour or so.
CRM is a mission-crtical application that is required for sales and customer
support. While it is offline, salespeople will be able to continue to work
in disconnected mode and continue being productive, however they wouldn't be
able to synchronize their changes until the server is back online. More
importantly to the company's image, CRM is a customer support tool. If a
customer calls in, then the customer support team will have a problem
getting the records, which is not good.

In case of RAID5, I would not be able to bring the system back that quickly
if solely due to rebuild requirements. Also, writing transaction logs is a
sequential operation, which carries a performance penalty of up to 80% in a
RAID5 scenario. This alone would slow down the entire array. Lastly, history
suggests that RAID5 arrays are more susceptible to intermittent data
corruption, which makes them a little more challenging to rebuild. There is
not a single best practices document that would support putting both parts
of the equation on the same disk, not to mention same array. That's so for a
good reason. :-)

I am perfectly fine with using RAID5 for heavy-read file servers that can
simply be rebuilt from backups as the risk there is minimal. Performance
degradation in addition to added risk of data corruption make me not
recommend it as a solution for an application or messaging server data
storage confguration.

The first thing we do if we have to recover a dead server for a new client
is rebuild its arrays to the best practices specification. Very frequently
the failed arrays are indeed RAID5 and involve rather tricky data recovery.
:-)

Now to address Shadow Copy... The technology covers shares, and database
files are not shared. Data Protection Manager further extends VSS, but it's
not a factor in this particular situation. Your shadow copies are deltas of
the original files, so if the original volume is corrupt, it does not help
much.
--
Leonid S. Knyshov, CEO
Crashproof Solutions, LLC - http://www.crashproofsolutions.com
MCP Exchange 2003/Small Business Server 2003, CCNA, SCSA 8, NCIE
Microsoft Small Business Specialist Partner


.

Relevant Pages

  • Re: SBS 2003 Installation Drives - Folders
    ... Should you move the application installation points you will reduce the ... space required on the OS partition significantly. ... The effect of large database files on Shadow Copy. ... There is ample expansion space on this server either internally or through ...
    (microsoft.public.windows.server.sbs)
  • Re: Kickstart script with parameters.
    ... In the pre-script, before you partition the disk, do something like ... fetch the application server disk partition file. ... We are using a HTTP based installation server with a CGI that generates ... Now you can generate includes for your kickstart script from this. ...
    (RedHat)
  • Issue with Volume Shadow Copy service (resolved)
    ... Shadow Copy Service was enabled on D: ... A drive died in the server approximately 1+ months ago. ... partition which fixed the Altiris issue. ... System image is also inflated to 58,000KB. ...
    (microsoft.public.windows.server.general)
  • Re: Partitioning an OEM install of SBS 2003
    ... Microsoft Windows Small Business Server 2003, ... you can only specify the boot partition size with the Dell Server ... continues with the installation of the SBS 2003 components. ...
    (microsoft.public.windows.server.sbs)
  • Re: Need Help setting up Mysql on Openserver 6.0
    ... > mysql> status ... > Server characterset: latin1 ... to make the proper selection during installation. ... was installed first in partition 1 and 6.0 was later installed in partition 2) ...
    (comp.unix.sco.misc)