with the aim of bringing management of Linux desktops and servers on par with that of Windows desktops and servers

Um, how about a tool that does the reverse? Something that turns the windows registry and software configurations into a bunch of sensible and human readable text files all in a single directory with sane permissions.

Although the imaging is nice. I know way too many imaging programs which do not correctly support certain bootloaders in the mbr.

Newsforge, an OSTG site, had this story [newsforge.com] two days ago. In fact Joe Barr, OSTG's own epic hack, interviewed Novell execs directly.

True to form, it is a terrible artice from Barr but, it was several days earlier than what your posting. Surely the left hand knows what the right is doing at OSTG. Doesn't it?

with the aim of bringing management of Linux desktops and servers on par with that of Windows desktops and servers.

And why would we want to subject ourselves to that kind of difficulty, pain, and anguish? The tools that are already part and parcel of Unix/Linux are complete and useful for that. All it takes is someone that knows what the hell they are doing.

Posting AC because I used to work for one of these (now hated) companies. :)

Long ago, Novell entertained the idea of replacing NetWare with Linux. This was way before the big Linux boom so management obviously just laughed off the idea. So Ransome Love took a bunch of engineers away from Novell and started Caldera.

Novell at the time was developing Zenworks and many in the group felt that there ought to be a Zen for Linux. Again, Novell management flatly rejected that idea as well, so they left novell and started up their own Zen-like product at Caldera, Volution, which I suppose didn't end up doing well.

Right. So instead of listening to their own people years ago and letting them leave for cash-starved startups, Novell is finally getting around to it 5 years later. Better late than never.

Cost of a Linux support person compared to a Winblow -> HIGH

Rightly so, considering that a Linux support/admninstrator can handle, in average, 3 times more users/machines.

The most important question is: what does it really mean for Linux users, administrators and developers?

They are not referring to making Linux like Windows. They are referring to making the management of Linux, through ZenWorks, like the management of Windows, through ZenWorks. This is an important feature for ZenWorks and its users and is a feature that Novell has been missing for some time, despite their previous claims of ZenWorks Linux support.

ZenWorks is a fantastic tool and is extremely powerful. It performs functions such as hardware and software inventory, application installation and removal, remote control, system policy management and more. But, ZenWorks primary area of support has been Windows systems. Novell claimed that it supported Linux and PDA's but, this support was very limited. Now, with ZenWorks 7, the supported features for Linux approach the level of the Windows features that have always been there.

First off, you need to understand what ZenWorks can do. ZenWorks is a system for controlling and managing workstations and servers network-wide from a single location, using policies that are stored in eDirectory, Novell's directory service. With ZenWorks, an administrator can control settings like Windows Policies and KDE kiosk configuration. With ZenWorks an administrator can install and remove applications, patches and configurations remotely from a single location. With ZenWorks, an administrator can install new operating systems or reinstall broken operating systems remotely, from a single location.

Some of these things you can do with Linux already and some of them you can't. Or at least, you can't do them easily. This new ZenWorks is supposed to make it brain dead easy to do these things for 10 systems or 10,000 systems. The key concepts are ease and volume/automation. Sure, you could write a script to ssh into your systems and install some software or what-have-you but, it will be different every time and too often requires some form of manual intervetion. Most importantly, nothing about the script will be useable on Windows workstations. You'll have to use different scripts and scripting languages for those systems so, the overhead is relatively high.

Here are a couple of scenarios. Suppose your working the helpdesk and a user calls to say that their PC isn't working. You open up the management console and quickly locate the PC in question from amongst the thousands in your firm. With two clicks you are connected to the PC and remotely controlling it. Regardless of whether the PC is Windows or Linux, the procedure is the same.

Now you see that the PC isn't actually broken, as the user reported but, it is simply missing an application because the user had moved in from another department and had not yet been configured to use that application. A couple of clicks associates the user with the application and the application is automatically installed and made available to the user. Again, Windows or Linux, the procedure is the same in ZenWorks.

Now, let's suppose that during the install of the application, the user unplugged the PC. I don't know why they did it, they just did it. They're a user, OK? Anyway, for what ever reason the disk is corrupted and the OS is hosed. You instruct the user to restart the machine and choose the appropriate option from the boot menu. The PC is reimaged with a fresh copy of the OS and the appropriate applications are reinstalled. In ten minutes the user is up and running with no user or admninistrator intervention. Again, Windows or Linux, the procedure is the same from within ZenWorks.

Now, let's assume a different scenario. This time, let's assume that your boss has decided that the company will now use the latest Windows 200X on all workstations. This is a massive upgrade that requires not only the installation of a new OS but also the installation or upgrade of numerous applications that were being used before but no longer work under the new Windows version. Even if you use RIS or Ghost

Yes, the "active directory" thing actually is much better in the microsoft side

(of course I'd say that plan9 beats both in this regard, in plan9 unlike happens in windows and linux apps don't really need to be "LDAP aware", you just exports and imports filesystem namespaces)

No offence but the registry is not that hard to figure out, hell it is easier to figure out than setting up Modelines for a wierd monitor in Xorg.
HKLM = Machine specific Settings
HKCU = Link to HK_Users\ = User specific settings
HK_Classes_Root = Link to HKLM\Classes\Software Classes

In both HKCU and HKLM there are Software subkeys which is where apps are supposed to write and user or machine specific settings

Machine specific System Settings (i.e Services, etc) are located in HKLM\System.
In there are CurrentControlSet (curren System Settings) as well as ControlSetx which (I think) are previous settings as well as LastKnownGoodRecovery

Probably the most convoluted section is the Classes but rarely does anyone need to go in there.

It's a little of a different mindset but not that big. The nice thing about Linux is that since they are human readable files there is no singular point of failure (i.e if registry corrupts) but the Registry is still not that daunting and it can be backed up easily by backing up the System state.

Apparently you haven't used windows a lot. Use XP, go to the even viewer, look at any error. It'll say you "even number foo, check http://www.microsoft.com/foobar for more details". Great help, what if the event happens to be a network card error and I can't visit the site??

Call me when Microsoft starts including the documentation in the OS instead of giving me meaningless numbers.

Oh, and I don't think that a support site for servers that says you "click in start -> run and type regedt32.exe" instead of "modifiy registry key HKLM/blah" is a good support site. In that microsoft support article you'll see lot of text, but having a lot of text doesn't means the article is good.

The one thing I've clear is that Microsoft OLE DB provider gave me a error, and instead of saying me "I couldn't access $THIS registry key, not enought permissions", which would have gave me a clue and I could have figured out the fix myself, it gave me a meaningless error number and I had to go trought the web to see what was happening (of course OSS documentation is usually inexistent, so even that is good i suposse...)

It continues to amaze me how Windows and Linux admins present their problems from eachothers' perspectives, neither fully realizing what the other is capable of. Being a system administrator that deals with both (and soon MacOS X as well), I see the value of knowing as much as possible about everything I can about both.

The Second Horseman (121958):
Actually, deploying and managing hundreds or thousands of workstations in a policy-driven fashion is critical in a large buisiness network. It's the policy-driven part that's important -- it can really cut down on the number of people you have running around changing workstation configs.

No argument from me here. Homogeneity is a profoundly important goal for any large organization, unless your employer likes paying unnecessary payroll tax, benefits and workman's comp. However, Microsoft's choice of a consolidated, binary configuration file(s) creates the need for Windows policy management, and all its associated helper utilities. Basic policy enforcement is a free lunch, but more flexible solutions require the purchase of other software, or third-party tools.

Ed Avis (5917):
I must be missing the point here - what is involved in managing desktops in a 'policy-driven fashion'? Perhaps it is more difficult if you can't assume that 99% of the desktop machines have almost identical settings.

It involves creating a 'template' of the configuration you want, and configuring the domain controller to enforce those settings whenever a workstation logs on. Configuration is done through the MS Management Console utility. It's great for Windows settings and MS applications, but nearly worthless for anything else.

The Second Horseman (121958):
The non-corporate elements around here tend to discount these sort of things, but if you're short-staffed and faced with 1,500 workstations, managment and deployment are huge issues. And up until recently, those tools for Linux werent there.

Here's an example of exactly what I mentioned in the first paragraph. Just because it doesn't work exactly like Windows, it "[isn't] there", and to contrast, I've quoted the above, where the poster asks what is the "policy-driven fashion" of configuration management. The tools are there, and not knowing how to make use of them is no excuse for ignoring them during a discussion of management. Since Linux configuration is essentially just a bunch of text files, enforcing the desired configuration is simply a matter of overwriting those that need to be changed. It's conceptually no different from merging forced registry changes, except one can be more selective with separate text config files, and therefore more bandwidth-efficient.

Cron jobs, remote shell, encrypted remote shell, through ftp, http, file shares or secure file transfer, take your pick. Need your policy to follow the user? Stick his home directory on a share and let it be mapped on log-on. Need applications to follow him around, too? Use X sessions on a central host.

The Second Horseman (121958):
If you want to beat Windows, you have to not only match what the OS does for managment, you have to have 3rd-party tools as good as the ones available for Windows. And a lot of those 3rd party tools are quite good.

Those wonderful third-party tools are often quite expensive, and many are per-seat licensing. From my perspective, managing both operating systems as server and client, those third-party tools exist because Microsoft's operating systems lack the flexibility of Linux's tiny, modular components. Don't misconstrue this as my dismissal of said tools; They are quite good and incredibly useful on Windows, and I don't see the problem with them existing for Linux (other than the fact that I don't need them).

There are a whole class of tools that just don't yet exist for Linux b

Not only that, the skillset required is much more extensive. A Linux admin has to be able to program for instance. Every component in a linux system requires far more pre-requisite knowledge and has a much steeper learning curve than it's windows counterpart.

It takes a linux admin 5yrs to get a firm handle on linux. It takes a windows admin about 3 months tops.

Like most things in life, you get what you pay for. Whether you go with the cheap admin or the system that requires cheap admins, you get lower quality either way.