ZW10's MSI deployment technology is flawed at best in a Windows domain

The only deployment that seems to work well is the PUSH deployment of ZW10
Agents through dedicated credentials (supplied by the windows 2003 domain)
Agents are perfectly deployed by using

Now why isn't this possible with MSI application deployment?
Why was a different design chosen?

I will dicuss the MSI deployment options in more detail:
1 deploy from repository
Practical issue: if your MSI is Office2003 or Office 2007 with over 400 MB
in installables, your agents (say workstations 1000, users 2000 example)
will pull 400 MB everytime over the network from the zenworks repository
to ZCagent cache.
The way this works is that the MSI and all associated files .cabs and
directories are pulled to the Zenworks agent cache directory. and executed
from there locally on the machine.
You must have disk space enough to accomodate the download.

Once you upload the files to the repository there is actually no way of
gaining access to the repository to edit (let's say) just a single file.
you have to keep two separate MSI resource locations: repository and
somewhere on disk. (yeah for storage management, application management)

2 Deploy from network location (or local disk)
FLAWED. msiexec not executed properly. This is where ZW10 is not fully
windows 2003 domain aware. you have the option to execute the MSI as the
logged in user. Now if your users are members of just "domain users", you
know they can't install products.
Second option is install as secure system user (don't allow interaction
with the desktop). This hides the MSI deployment from the user, completely
rendering any /qr /qf or whatever option and progress bar native to
MSIEXEC obsolete. And the "show progress" indicator of the ZAC Agent is
very informative as well... "Installing" is all that appears. Yes you can
enable logging, but what would that do for the user. The user must be
informerd that there is a deployment executing and that he'she has to wait
until the progress bar is at 100%..... You can monitor the deployment very
primitive by watching task manager process msiexec and checking the local
disk in windows explorer to see if the application directories are being

You might run into "illegal characters in path" which has nothing to do
with a space in the msi name or directory name or share name or server
name. Even if you run the msiexec with /i "c:\local\someapp.msi you will
still get "illegal characters in path" or "not a valid msi package..
contact application vendor".
Ow yes and verify that you can access the network resource.. (yes?)
Verify that you can execute the MSI and deploy the application with the
"runas" helper app native to microsoft.
Now why is ZW10 not fully Windows Domain aware... you have the option of
also executing the MSI as dynamic administrator. Please keep in mind that
is is a LOCAL administrator and this user is destroyed upon completion.

3 MSI options always revert to /qn
When creating a bundle, either from repository or network share the
default deployment options for MSI's always resets to /qn
ZW10 does not have a feature to set defaults for global MSI options
(always /qr or /qf, or whatever)

If and If Novell changes the "network install MSI" to be more like the
agent deployment, then ZW10 might have a fighting chance. As it now stands
this product gets a big thumbs down on the MSI deployment. Boot the
repository idea.... on Windows 2003 environments rely on DFS domain
syncing. There is no need to reinvent the wheel.

Am curious to know if I am the only one experiencing these problems
related to MSI app delivery? Going to discuss these issues come monday
with the local Novell rep. Can't even believe they'd dare sell this.....

Shaun and Craig... thanks for your effort on the boards!