I can't tell you how helpful this discussion has been. Thanks to all who contributed for weighing in, and for weighing through my longish posts.
I may be back at some point with specific design questions, but for now I'm on the right track. Very much obliged, RS On Mon, Feb 1, 2010 at 5:53 PM, Michael B. Smith <mich...@smithcons.com>wrote: > Yeah, your SIS is 1 - .83 = 17%. That’s pretty typical. You’ll gain that > back (or more) by the fact that Exchange 2010 compresses items that aren’t > already compressed. 25% is a “typical” (although not guaranteed) number. I > don’t know how perfmon calculates its number – I can simply tell you that, > whatever it is, it doesn’t reflect reality and that it never has (at least > as far back as Exchange 5.0). > > Exchange 2007 and above (including Exchange 2010) index. Period. It costs > 4-7%. You can’t turn it off, so live with it. ☺ You can move the indexes, > but it isn’t necessary or recommended. All the typical system requirements > include having the indexes on the same volumes as the databases. > > In re: [1], yes, because messages can always be restored from backup. > Compared to exchange 2007 with CCR, if you have two servers in DAG, then > you’ve already matched THAT recoverability. If BOTH servers in the DAG fail, > then you are driven to backup, just as you would be if both servers in a CCR > had failed. That’s why the “third server” can “eliminate backup”. Now, I’m > an anal SOB, I personally would NEVER eliminate backups. But I’m old-school. > > > From: Richard Stovall [mailto:rich...@gmail.com] > Sent: Monday, February 01, 2010 5:34 PM > To: MS-Exchange Admin Issues > Subject: Re: 2003 to 2010 planning > > 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 > > > >
