If so, that's not what we've been told... ________________________________________ From: Ken Schaefer [...@adopenstatic.com] Sent: Monday, June 01, 2009 9:00 AM To: NT System Admin Issues Subject: RE: Amusing
So this doesn't have anything to do with a tricky bit of code that requires constant regression testing, and which bean counters wanted culled? I'm shocked... :-) Cheers Ken ________________________________________ From: Michael B. Smith [mich...@owa.smithcons.com] Sent: Monday, 1 June 2009 1:10 PM To: NT System Admin Issues Subject: RE: Amusing The general plan here is to improve performance when you have large mailboxes. "Most", but not all (granted) folks would say that it's OK to use more disk space if that effectively removes a key performance blocker. SIS was designed and implemented when Exchange supported a SINGLE database and most companies were using 9 GB disks and processor power was tiny (think 50-75 Mhz Pentiums). To implement SIS required that certain tables in that database be shared among all mailboxes in that database. This was an acceptable trade-off, then, as it allowed companies to eke out every possible byte from those small disks with their slow I/O. However, that sharing made it impractical to support VLMs (very large mailboxes) due to the size of the index trees that resulted. In Exchange 2007, one of those tables was moved to a per-mailbox table instead of a per-database table (the message body table), the size of database pages was increased, and these improved supported for large mailboxes. This had the impact of removing SIS for message bodies. However, contention and overall table size and total I/O requirements continued to limit the overall performance for VLMs. In Exchange 2010, a couple of other tables are also moved to per-mailbox, notably the attachment table. The size of database pages is increased. These changes effectively make it possible to support VLMs for many mailboxes in a single exchange database; and to do so performantly. And cheaply - using much cheaper disk; since these changes significantly change the overall I/O profile for Exchange databases. However, this change eliminates SIS. For uncompressed attachments, these are now compressed. In Microsoft's tests, significantly more disk space was regained using attachment compression than was saved by SIS. Of course, that may not be true for all companies or stores. Since AT LEAST Exchange 2003, Microsoft has been recommending (warning, if you read it another way) that companies do not use SIS in planning for their disk space requirements. So, in summary: most of Microsoft's customers want very performant very large mailboxes. Microsoft is making the necessary changes to meet that desire. ________________________________________ From: Ben Scott [mailvor...@gmail.com] Sent: Saturday, May 30, 2009 8:06 PM To: NT System Admin Issues Subject: Re: Amusing On Fri, May 29, 2009 at 11:01 PM, Steven M. Caesare <scaes...@caesare.com> wrote: > Companies are seldom democracies, and as I think both scenarios > illustrate, there indeed can be a "wrong". The thing is, in this case, It's not an internal policy decision. It's Microsoft that's the dictator, and all their customers that are the ones who aren't getting a vote. That's generally considered a poor way to do business. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
