Why To Sell NOVL, Part 2 - OES Patching Issues

In January, I posted an entry out of raw frustration resulting from a series of experiences and announcements with and from Novell. The straw that broke the camel's back was related to their misguided BorderManager / Novell Security Manager statement (So long, linux - hello, NetWare). However, a huge heap of the load was due to the unbelievably poor method Novell chose for applying patches to OES on SLES.

In October of 2006, during an executive briefing I attended, I had raised this issue to a Novell OES product manager. I'm no longer certain what this title entails, since there's an awful lot of product managers at Novell, and they don't seem to talk to one another.

The product manager's expression was one of simple acquiesence - he understood that our request to split patches into several channels (rather than one, as it is today), was one that made sense and would be very simple to implement.

Fast forward 4 months, and we're in January - still no separate "stable" or "critical" OES patch channel...everything's still coming down in one big clump.

Fast forward another 4 months, and we're in May - where we've just completed another conference call with another OES Product Manager who agrees that ZLM is a poor method for applying patches to production servers, and who thinks the concept of splitting OES patches into multiple channels is a valid, actionable idea.

Novell have committed to us that they'd let us know by this week if/when they can make this happen, and if not, why. The alternative is to wait for OES 2, since that's when they intend to make this 'better', but in a way that leaves OES SP2 adopters in the cold.

It seems that there really are very few people who have made the leap from NetWare to OES on SLES as we have. Our move was one of necessity - NetWare wasn't stable enough to run the mix of services we needed on a single platform any longer. In speaking to a Collaboration SE last week, we agreed that Novell could do a better job of reducing barriers to adoption - like putting placeholder scripts on OES systems that mimic the look & feel of the old C-Worthy interfaces we enjoyed (like DSREPAIR, MONITOR, etc). Even if it doesn't look the same, it can at least tell you what options to put on the command line or present a menu of common tasks.

CoolSolutions has such a script for DSREPAIR specifically - originally written for eDirectory on Solaris, by an enthusiastic user. It's a brilliant idea, and eliminates one big reason that people have for not going to OES on SLES.

If you had to get training to learn a new server OS, would you pursue a niche product like OES, or would you just sell out and run Windows like everyone else in the world?

There's lots that Novell still doesn't understand about the market and their customers, unfortunately.

That said, we were treated to an overview of new features in OES 2, and from the sounds of it, we could really make use of those enhancements. Still waiting on more details, but our fingers are crossed.