I have found an interesting bug with the above environment. We are rolling
out Microsoft's MSN Messenger (v8.x) and naturally we test the deployment
in a VM first - makes life much easier, until this bug showed up :-(.

Okay, the bug is : the app fails to cleanly install, some unknown error
occurs right at the end and it actually causes the NAL NT Service to die.
Worse is that after rebooting the VM the NAL NT Service (ZenLite) is
permanently hosed and generates several Dr. Watson's and no other NAL apps
can be distributed. To fix this condition you have to remove the app that
failed to install to begin with. BUT...when you run the exact same NAL app
on real hardware there is NO problem! Sweet eh?

The second interesting thing about this is that if you run the MSI from
outside of ZEN, ie from the command-line, and if the msi is on mapped
network volume then the app also fails to install - but it rolls itself
back so it does not cause any permanent damamge. Again this is within the

Yet if you copy the files to the local hard drive of the VM and run the
app it installs just fine. Of course this is one of those nasty apps that
sets some elevated privs in the .msi file - which of course is well know
to cause issues with running msi's from a network volume - whether it is
run natively outside of ZEN or withing ZEN.

We are able to workaround this issue with elevated privs/system
space/network file storage by using the "Unsecure system user" option and
"Run in Workstation Space" options and setting the path to the network
location using UNC rather than mapped drive letter. So it works as such on
real hardware. But fails miserably on VMWare Workstation 6.0.1, whether
the VM guest is hosted on Linux (openSuse 10.2) or Windows XP.

Sigh... :-(

Please note that I am not Ranting. Nor am I begging for help as expect
that this is something that would have to be worked out between at least
two independent parties: Novell and VMWare, if not also Microsoft. Good
luck on that, eh?

So really just consider this a heads up for those of you with a
VMWare-based Zenworks testing environment.

I can think of two possible workarounds though:
1. Use the NAL app object to copy the msi files to the local workstation
hard drive and execute from local storage. Then clean up afterwards. I'll
test this, once I figure out how to do it - I am a ZEN neophyte.

2. Use the free ORCA database editor
(http://support.microsoft.com/kb/255905) to change the elevated priv
problem that started this whole mess off. Again the real source of the
problem is a company that has its roots in single-user, fully-privileged,
non-networked OS's and apps and is fully infected by that model to this
day. (Okay that last bit was a rant - sorry ;-) )


Ron Neilly
Network and Systems Coordinator
UBC Okanagan