Edumacation is good, and as it turns out this little thread has been
*extremely* edumacational on a number of fronts. I'm certainly getting a
whole lot out of it, and I hope some others are as well.
To address what was apparently my biggest mistaken assumption, the sum of
the individual mailbox sizes is 91.8 GB. The EDB + STM total = 120.7GB.
Accounting for 10GB of free space in the database (as determined by mailbox
event 1221) created last month by manually pulling out old messages from the
hyperactive mailboxes, the amount of space actually used is roughly 110GB.
Does this mean that my 'real SIS ratio' = 91.8/110.7 = 0.83?* I always
thought that the perfmon-reported number was so high because of the large
attachments that fly back and forth with multiple internal recipients.
Could it be that since SIS includes message bodies as well as attachments,
each reply that includes copies of previous messages in the body actually
creates one or more pointers which could artificially inflate the perfmon
number?
Regarding 2] below, that's a feature I wasn't aware of and sounds great.
Are the indexing requirements high? I'm just wondering if there is a
notional value you could use to plan. E.g, "X MB of disk space is typically
required to index YGB of an Exchange 2010 database" Should the indexes
should be on separate volumes from the databases?
Lastly, about 1]. Do you mean that it doesn't apply because messages can
always be restored from backup? That makes complete sense if you don't mind
having IT involved in finding and restoring old messages. I didn't state
IT-free discovery of old messages as a requirement for that scenario, but it
sure would be nice. If the updated SIS assumptions are correct, then it
becomes pretty much a non-issue.
Thanks again for the help,
RS
*It doesn't really matter what the 'real' number is. What's important is
that there wouldn't be 10X or more increase in the size of the database if
moved to 2010. In this case it might even be near 1:1, and, if true, it
would be a big relief.
On Mon, Feb 1, 2010 at 4:21 PM, Michael B. Smith <mich...@smithcons.com>wrote:
> 1] that doesn't apply if you continue to take regular backups.
>
> 2] you can do this with delegated discovery search in Exchange 2010.
>
> 3] add up the sizes of all the individual mailboxes ('cuz when reporting
> individual mailbox size, SIS isn't taken into account). Compare that to the
> actual physical size of EDB + STM. THAT is your real SIS ratio. It likely
> isn't as high as you think (regardless of what perfmon says).
>
> Not trying to change your mind - just trying to properly edumacate. ;-)
>
> From: Richard Stovall [mailto:rich...@gmail.com]
> Sent: Monday, February 01, 2010 4:15 PM
> To: MS-Exchange Admin Issues
> Subject: Re: 2003 to 2010 planning
>
> Thanks for the response.
>
> For several very particular reasons, actually. It could be that my
> thinking isn't consistent with what Exchange 2010 brings to the table (or
> that I'm just flat wrong), but here they are:
>
> 1) We have a couple of mailboxes that routinely receive very large amounts
> of data in the form of attachments each month. I don't have exact numbers,
> but growth of 1GB / month or more is not unheard of at times. We are
> expected to maintain all of the messages and correspondence within the
> context of e-mail for long periods of time. Up to years for some customers.
> It just goes against conventional wisdom to store all of this in live
> mailboxes. Perhaps with Exchange 2010's optimization for cheap, giant SATA
> disks this is just old school thinking. (Note: I do remember reading that
> RAID is required for 2 server DAGs instead of JBOD. This does raise the
> cost a bit, but not too much.
> http://www.slideshare.net/harold.wong/exchange-2010-high-availability-and-storage
> slides
> 16 and 20)
>
> 2) Availability of historical messaging information to appropriate persons
> not involved in the original conversation. This is a pure archive function
> as I see it. E.g., a departmental manager needs to easily, and without IT
> intervention, find an e-mail thread between a valued customer and a former
> employee.
>
> 3) My Single Instance Ratio is very high compared to what I understand the
> average to be. I know it's not entirely accurate, but a back of the
> envelope calculation might put my off-the-bat Exchange 2010 storage
> requirements to >1TB without doing something to prune old messages from the
> existing 2003 database.
>
> I certainly didn't mean to imply that archive should be used for anything
> other than archive.
>
> Again, all comments, thoughts, and education are appreciated.
>
> Thanks,
> RS
>
>
> On Mon, Feb 1, 2010 at 2:43 PM, Michael B. Smith <mich...@smithcons.com>
> wrote:
> In addition to Neil's comments, I ask WHY you think that storage is better
> served in an archiving system than in an Exchange mailbox?
>
> From: Richard Stovall [mailto:rich...@gmail.com]
> Sent: Monday, February 01, 2010 1:49 PM
>
> To: MS-Exchange Admin Issues
> Subject: 2003 to 2010 planning
>
> Good afternoon one and all, and please forgive the long post.
>
> I'm thinking about proposing the upgrade from Exchange 2003 to Exchange
> 2010 this year. We're currently running a single monolithic server that has
> (knock on wood) been extremely reliable for going on 5 years. We've got
> ~100 mailboxes now, and I don't see us ever growing past 200. The
> information store is currently 110GB, and the perfmon-reported Single
> Instance Ratio is pretty large at 22. We have ~10 remote users who use
> Outlook Anywhere, ~10 PDA users, ~10 Mac (Entourage) users, and OWA is
> available to most everyone. AD is a single domain forest, is at 2003 Domain
> and Forest Functional Levels, and all DCs are 2003 SP2. We have a single
> physical site, and only one site in AD.
>
> Before rolling out 2010, I intend to deploy an e-mail archiving solution of
> some sort. My hope is that, in addition to the obvious retention and search
> benefits this will provide, it will also take some of the pressure off of
> Exchange 2010's storage requirements by allowing me to finally enforce
> mailbox size restrictions without reducing the availability of older
> messages.
>
> I've been poking around the interweb, looking for information that will
> help me determine how to design and deploy Exchange 2010 in a manner
> appropriate for our environment. The most promising thing I've come up with
> is a simple statement on the Microsoft page that describes Exchange 2010
> Mailbox Resiliency (
> http://www.microsoft.com/exchange/2010/en/us/Mailbox-Resiliency.aspx). It
> says, " For smaller sites, you can deploy a simple two-server configuration
> that provides full redundancy of mailbox data along with Client Access and
> Hub Transport roles. These changes put high availability within the reach of
> organizations that once considered it impractical." That sounds like
> exactly like what I'm after - a simple-to-maintain, two server solution
> where all the inside roles are redundant.
>
> Does this configuration sound appropriate for an organization of the size
> and characteristics described above? Does anyone have any pointers to more
> in-depth discussion of this two server configuration? (Is there a
> particular name for this configuration?)
>
> Lastly, from what I can gather, this can be accomplished with Exchange
> Server 2010 Standard and Standard CALs. For an organization the size of
> ours, I don't think I need the added benefits of the Enterprise CAL at this
> point. Message hygiene is handled by the Barracuda and Sunbelt's VPE
> product, and I believe mailbox resiliency is available in the standard
> server regardless of CAL type.
>
> Any thoughts or comments are most welcome.
>
> Thanks,
> RS
>
>
>
>
