Servicing Exchange 2007

» Could Exchange Server 2007 spell the end of the traditional service pack? | All about Microsoft | ZDNet.com

Wed, 23 May 2007 01:39:56 GMT

PingBack from http://blogs.zdnet.com/microsoft/?p=140

Exchange Server 2007 Update 1

TenBrink Tech — Wed, 18 Apr 2007 23:45:42 GMT

In the very cool department, today sees the first Update to Microsoft Exchange Server 2007 posted to

Exchange 2007 Rollup 1 Released

Jeff's Connected Corner — Wed, 18 Apr 2007 22:08:53 GMT

In some 'Better Late Than Never' news, Microsoft finally released Exchange 2007 Rollup 1 to the download

Exchange 2007 Service Pack 1 « Dynamic Computer Corporation’s Blog

Exchange 2007 Service Pack 1 « Dynamic Computer Corporation’s Blog — Tue, 27 Feb 2007 17:12:59 GMT

PingBack from http://dccblog.wordpress.com/2007/02/27/exchange-2007-service-pack-1/

re: Servicing Exchange 2007

Shannon — Tue, 05 Dec 2006 00:51:47 GMT

You had me at "cumulative." :-)

re: Servicing Exchange 2007

Richard Siddaway — Mon, 04 Dec 2006 17:11:18 GMT

Brilliant idea. If only all systems operated this way. Personally I would prefer to see the release cycle synchronise with the normal Micorosoft patching cycle rather than be concerned with tracking 2 seperate cycles

re: Servicing Exchange 2007

Jesper Bernle — Sun, 03 Dec 2006 23:47:31 GMT

This is professionalism to it´s core. I gladly lift my hat to salute you. Well done!

re: Servicing Exchange 2007

gblinckmann — Sun, 03 Dec 2006 03:14:43 GMT

This is one of the best ideas I've heard of in a long time! Knowing what hotfixes to keep up with is a major pain. I really hate running into the problem and then finding that a patch was available for it months ago. Having all these patches regression tested also will make me feel a lot better about the patches. We can just schedule updates ahead of time. Perfect!

re: Servicing Exchange 2007

Tony Woodruff — Sat, 02 Dec 2006 02:07:37 GMT

I do not see a downside to this new approach. If Microsoft were to split out the patches as Josh suggests, it would make for an untested environment - something I do not want for my production servers.

Microsoft certainly cannot be held responsible for third-party functionality - in my mind they are only obligated to adhere to their own published APIs - or give adequate notice that something needs to change. Overall compatibility is part of the calculus when deciding to implement third party software in the first place. Often it is well worth the trade off to get a better price or better features than is available from Microsoft directly.

Keeping the number of released builds to a finite and manageable level makes complete sense. I would offer a "thank you" to Microsoft for continuing to improve processes - not just software.

re: Servicing Exchange 2007

Josh Maher — Sat, 02 Dec 2006 01:33:10 GMT

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.