Slightly off topic, zenworks MSI deployment.
So this is a little off topic but I didn't know where else to ask it.
I am sure you all know my answers to this however I just wanted some reinforcement as I am fighting a little resistance from the latest new role.
We use Zenworks 7.0 to deploy applications here.
We currently deploy all applications in user security space (even though there is a pretty little tickbox to elevate to local system).
The issues I see with this are.
1) all applications reinstall for each user (as by design from zenworks when using user security space).
2) we then hack the availability options in zenworks to stop this from happening effectively making it difficult to repair unless using add / remove programes)
3) when we have immediate CA's writing to the system things fail (go figure)
So to alleviate the last option we do something very clever (well i like it anyway *grin*)
So to fix the latter we wrap all MSI's in a self extracting EXE. Then create an AXT (non MSI object) and elevate the EXE to run as "unsecured system user" (for the non Zen people local system). this involves the following steps.
1) cache the EXE to machine at c:\NALCACHE
2) extract the self extracting EXE to c:\temp
3) install the MSI from C:\temp
4) delete the MSI from C:\temp
5) at no point do we / they enter a [SourceList] (seems this is a relic of old habit)
Now perhaps I am missing something here but the way I see it we have no MSI's anywhere on the network as they are all wrapped in EXE's, and even if we did have one we deleted it anyway.
No this is perhaps my misguided interpretation of how Zenworks works but wouldn't it be easier to tick the box that says run as local system instead of creating the interesting fix that is applied atm ?
Note: I had nothing to do with any of this I am an outside observer looking into a completely alien environment.
Would you all agree this somewhat limits the ability to repair ?
How about upgrades ?
What about the funny little context thingoes that happen during installation ?
Who loves using Installshield and Zenworks in the same role (*sigh*)
What security space do others use with Zen 6.5 or later ?
Who likes the c:\temp idea ?
I think I am getting to old for this, someone tell me I am missing something before my head explodes with frustration. Ian don't get me started on the error checking ;-) im still looking.
Has anybody heard of "out of the box"?
It sounds as though packaging and the resulting ROI if implemented correctly is totally alien to the "Consultant / Expert" who thought this up.
We have recently used Zen to distribute MSI / MSI + MST packages to Vista machines, and have had nothing but problems. Thankfully as far as the MSI's where concered, we did not have to do anything "tricky" like you have had to do.
Points 1 and 2 do not make sense, use a technology (MSI) and then specifically break it. (Dooh!)
3. Worst practice, this is something that I personally harp on about never to do.
As for the other issues, an application that requires self repair, will not work correctly, as soon as it requires anything that is not present in the cached MSI (is that there, or is that also deleted?)
I could understand some of the things there IF the SourceList property were to be set to a repository location, but it is not.
Reading through your post, the only thing that the process you describes achives, is the inital (non user specific) automated installation. After that it is a "ABM" for the help desk. (ABM -> Abeitsbeschafungsmaßname).
Cheers
Phil
This looks too cumbersome to be true
It's a few years since I worked on Zenworks deployment, but AFAIR, they were all deployed as system (machine) apps with the usual self healing or active setup solutions. I don't recall any particular problems once we figured out how to set up the apps in Zenworks. (Only Novell can produce such crippleware)
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
general
I totally agree this is bordering on temporary insanity I guess it's time for me to elevate the risks etc.
The latest item I QA'd was Silverlight here's what took place.
Silverlight comes as a self extracting exe. (msi inside).
What I would of done,
Extract the msi, add properties and deploy with native MSI objects via Zenworks. (1 step)
What took place.
Wrap the self extracting exe in a self extracting exe
1) run install
2) cache to local machine (as exe) using NALCACHE
3) extract exe to temp (content is a self extracting exe)
4) extract the exe from temp to another spot in temp.
5) execute msi
6) delete temp (break msi, job done)
job done.
Coincidentally there is often self repairs in this environment followed by a browse to your msi prompt. Fortunately the MSI's don't exist anywhere on the network as they are mostly wrapped up in self extracting EXE's.
*sigh* it would appear I have a lot of work ahead of me. I almost don't have the energy for this one.
It's the users that are wearing, not the task....
John,
My sincere condolences for your being lumbered with this task. I'm sure it is more wearing trying to knock some sense into your users/clients than it is to do the job the way it should be done.
Why couldn't Novell stick with what they were good at (ie file and print services) and keep their hands off the desktop where they have consistently failed to provide a technically viable and reliable solution.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Ed, it looks to me more like
[deleted]
Interesting...in the text I just deleted, I italicised some text which the forum software daintily changed to bold. Cool testing, guys...
Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using http://www.google.com before posting.
A dump question
So what is the problem for the "customer" not to store the MSI in the C:\temp folder or pointing the sourcelist to a repository?
If they now want to make it more difficult then it should; why not zap the package after the installation (to prevent a repair from occuring the hard way) and install the HKCU & Profile resources by a different (legacy) package within the user security space. Then have a removal package that would install and then uninstall the (MSI) package at once ;)
The whole setup sounds ridiculous!
If I was you I would "force" them to re-consider and to setup the whole thing in the way it should.
forcing their hand
Kim,
To date I elevated this to the central packaging team I don't think they were particularly interested. As you mentioned forcing their hand is on the cards. This site is bordering on the worst setup I have ever encountered.
I have written up a full test plan, highlighted applications which cannot currently be healed or even uninstalled. Created virtual environments demonstrating the multitude of failures of I have found and will be placing it in front of senior management to chew over.
I might just add your post into the equation, I was sort of hoping someone would post something that agreed its ridiculous.
Cheers,
John
Indifference - the final frontier
John,
The biggest batlle we face is with indifference. That's what has got them where they are today, and that's what you need to overcome before you can make ANY progress towards the common standards that are a pre-requisite for a reliable and cost effective operation.
I wish you luck, but if you can't change the mindset, consider walking away, as life is too short to deal with this kind of BS.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Would you like to reply?
Login or Register to post your comment.