In Exchange Server 2010, there is no more single instance storage (SIS). To help understand why SIS is gone, let's review a brief history of Exchange.
During the development of Exchange 4.0, we had...
Updated May 12, 2020
Version 4.0
Blog Post
I've been supporting Exchange since 5.5 and have worked at MS for a year during the Exchange 2000 - 2003 transition. MS was touting SIS as the greatest thing since sliced bread when it was introduced with Exchange 4.0, but now claim that it's no longer viable because of cheap storage. To me, it seems that the MS programmers who wrote E2k10 took the easy way out by trading in SIS for performance. The E2k10 software isn't written any better, it just removed SIS to give it better performance.
The E2k10 code should have been written better to accomodate both SIS and performance. MS recommended that logs and DB's be on separate disks due to random and sequential R/W operations. Now that most E2k10 operations are sequential, there is no longer a need to separate the logs from DB's.
Instead of working hard to rewrite E2k10 and innovate new ideas, the MS programmers just rearranged the E2k10 code to increase per server capacity at the expense of SIS.
I was not a fan of E2k7 and resisted E2k7, but I am more resistant to E2k10. What I would have liked to see was a 64-bit version of E2k3. Since E2k3 64-bit won't happen, I can virtualize E2k3 on any virtualization platform and support as many users as E2k7 or E2k10 using far less money and without training my staff on E2k7 and E2k10.
No need for PowerShell scripting. Yeah!!!
The E2k10 code should have been written better to accomodate both SIS and performance. MS recommended that logs and DB's be on separate disks due to random and sequential R/W operations. Now that most E2k10 operations are sequential, there is no longer a need to separate the logs from DB's.
Instead of working hard to rewrite E2k10 and innovate new ideas, the MS programmers just rearranged the E2k10 code to increase per server capacity at the expense of SIS.
I was not a fan of E2k7 and resisted E2k7, but I am more resistant to E2k10. What I would have liked to see was a 64-bit version of E2k3. Since E2k3 64-bit won't happen, I can virtualize E2k3 on any virtualization platform and support as many users as E2k7 or E2k10 using far less money and without training my staff on E2k7 and E2k10.
No need for PowerShell scripting. Yeah!!!