Exchange Server 2007 is going to be serviced by Microsoft in a unique, new way that will be a substantial improvement for customers in terms of system reliability, release predictability and overal...
Updated Jul 01, 2019
Version 2.0
Blog Post
This is an interesting approach that should help to solve a lot of problems. I like the idea of having each fix tested to the same standards as the RTM builds.
The only thing that is troubling is that each individual patch can not be installed/uninstalled separately. Historically, this individualization has been critical to fix integration problems in Windows and in Exchange.
As an example….
I have an Exchange server running RTM+RU1 and a 3rd party product that MS does not use internally. When RU2 is released it is stated that it has 1 critical database patch and 9 non-critical patches. I am concerned about my mailbox databases, so I install RU2. Unfortunately there was an incompatibility with my 3rd party product and one of the 9 non-critical patches that MS was unable to verify (as they do not run this 3rd party product). In this case I have three options:
1. un-install RU2 and leave the databases exposed
2. un-install the 3rd party product (which could be difficult if it were the only anti-virus product in the environment)
3. Spend several days getting the 3rd party vendor or MS to provide a private patch
The option I no longer have is to un-install the single offending patch and continue operations. This is unfortunate as there are a lot of 3rd party applications that a lot of businesses depend on. Without an enhanced level of early integration, there is no guarantee this new approach will truly provide stability and flexibility.
So again, I really like the approach; however, it would be beneficial to add the individualization that was there previously.
The only thing that is troubling is that each individual patch can not be installed/uninstalled separately. Historically, this individualization has been critical to fix integration problems in Windows and in Exchange.
As an example….
I have an Exchange server running RTM+RU1 and a 3rd party product that MS does not use internally. When RU2 is released it is stated that it has 1 critical database patch and 9 non-critical patches. I am concerned about my mailbox databases, so I install RU2. Unfortunately there was an incompatibility with my 3rd party product and one of the 9 non-critical patches that MS was unable to verify (as they do not run this 3rd party product). In this case I have three options:
1. un-install RU2 and leave the databases exposed
2. un-install the 3rd party product (which could be difficult if it were the only anti-virus product in the environment)
3. Spend several days getting the 3rd party vendor or MS to provide a private patch
The option I no longer have is to un-install the single offending patch and continue operations. This is unfortunate as there are a lot of 3rd party applications that a lot of businesses depend on. Without an enhanced level of early integration, there is no guarantee this new approach will truly provide stability and flexibility.
So again, I really like the approach; however, it would be beneficial to add the individualization that was there previously.