Overview Robert's Rules of Exchange is a series of blog posts in which we take a fictitious company, describe their existing Exchange implementation, and then walk you through the de...
Updated Jul 01, 2019
Version 2.0
Blog Post
@Chrisc.Rachele - Thanks!
@Anand - Without going into much detail, the changes in the database schema that allow Exchange to support up to 100,000 items in a folder (as opposed to 5000/folder in E2k3) also caused us to lose Single Instance Store or SIS. This was certainly a concern of the Exchange team. But, one other thing that was implemented was compression within the database. Things like the headers of messages and the payload of HTML messages are compressed inside of the Exchange 2010 store. Interestingly enough, at Microsoft with real data (my data, for instance), it was seen that the compression almost perfectly cancelled out the loss of SIS.
Another thing to keep in mind: As our customers moved from Exchange 2000 to Exchange 2003 to Exchange 2007 to Exchange 2010, the number of users in a single database continued to reduce, even though the sizes of the databases went up. Because you have less of your users in a single database, you have less statistical chance that any given message would be delivered twice (or more often) to a given store. This means that as you put less and less users in a single database, you gain less from SIS anyway. Sometimes you'll hear the Exchange product group guys talk about how SIS was "broken anyway", and this is what they mean. Our SIS in Exchange 2007 and previous did not work across databases, so our customers got less and less advantage over the years.
So, the bottom line is that while you lost SIS, compression makes the databases roughly the same size for almost all of our customers, so when looking at the size of the databases on disk it is basically a wash. (Which is an American, possibly "Southern", saying meaning that there is no gain or loss from this.) BUT, you gain in a big way when you look at how many messages you can have in a single folder (and some other performance increases not discussed here). Because there was no significant loss, and a huge upside, it was decided that this was a good decision and that is how the Product Group moved forward.
Anything else I can help with around SIS?
@Anand - Without going into much detail, the changes in the database schema that allow Exchange to support up to 100,000 items in a folder (as opposed to 5000/folder in E2k3) also caused us to lose Single Instance Store or SIS. This was certainly a concern of the Exchange team. But, one other thing that was implemented was compression within the database. Things like the headers of messages and the payload of HTML messages are compressed inside of the Exchange 2010 store. Interestingly enough, at Microsoft with real data (my data, for instance), it was seen that the compression almost perfectly cancelled out the loss of SIS.
Another thing to keep in mind: As our customers moved from Exchange 2000 to Exchange 2003 to Exchange 2007 to Exchange 2010, the number of users in a single database continued to reduce, even though the sizes of the databases went up. Because you have less of your users in a single database, you have less statistical chance that any given message would be delivered twice (or more often) to a given store. This means that as you put less and less users in a single database, you gain less from SIS anyway. Sometimes you'll hear the Exchange product group guys talk about how SIS was "broken anyway", and this is what they mean. Our SIS in Exchange 2007 and previous did not work across databases, so our customers got less and less advantage over the years.
So, the bottom line is that while you lost SIS, compression makes the databases roughly the same size for almost all of our customers, so when looking at the size of the databases on disk it is basically a wash. (Which is an American, possibly "Southern", saying meaning that there is no gain or loss from this.) BUT, you gain in a big way when you look at how many messages you can have in a single folder (and some other performance increases not discussed here). Because there was no significant loss, and a huge upside, it was decided that this was a good decision and that is how the Product Group moved forward.
Anything else I can help with around SIS?