[wpkg-users] WPKG client service script error on clean

[Vasaris]

> Vasaris wrote:
> 
> >>> I would rather stick to MSI packages, as they allow seemless upgrade, when new version is out. If it is not possible, I think, that server-mode deployment is better then.
> >> If you have "wpkg" package defined (including WPKG Client), it will install WPK Client.
> > 
> > OK. I understood. wpkg.js is capable to deploy WPKG client itself. But doesn't this implies, that in such configuration, one must have two different WPKG-server side folder trees with .xml config files, sub-folders and packages? This is because WPKG client must have different tree to pull deployment information. If only one tree will be used, both AD-executed wpkg.js and the WPKG client will deploy packages twice. Or if wpkg.xml local datastore escapes this situation, then only wpkg.js will do actual deployment, and when WPKG client is run, it will have no actual jobs to do. Is this right or not?
> 
> No, one folder is enough.
> If WPKG Client is already installed, wpkg.js will just skip its 
> installation.

I think you did not understood the issue. If I understand correctly:

1. wpkg.js deployes WPKG client by de-fault to all computers, which are assigned wpkg.js script.
2. WPKG client must have to be directed to some wpkg.js file, to get other packages, it will be deploying.
3. If it is directed to the same share, as it was deployed from, and there are other packages, then wpkg.js will have already finished their installation, alogn WPKG client on the 1st run. Then there is no reason for this config.
4. If there is another share, separate from the 1st, which deployes only WPKG client, then WPKG client can use it, and all other packages except WPKG client, must be staged there.

I think this is the case, or I do not get inner workings of the WPKG client/Windows startuo sequence. If WPKG client runs BEFORE the AD Scrips (with wpkg.js) are run, then maybe WPKG client will read packages info and will deploy them OK. If wpkg.js runs BEFORE WPKG client, then I think there is no reason for such config.

> > Yes, it does not handle. On the other side, MSI often can be edited directly, or MST transform created to add those command line parameters. Not an intuitive way, but possible.
> 
> Perhaps we should make the installer so that it looks for settings.xml 
> in the same directory where the msi package is located - if no arguments 
> are given.
> This should essentially solve the problem.

Yes, this is the perfect solution. If you would implement it as default, and then edit FAQ/installation for this, leaving the option for other settings.xml path via .MST transform, this would be complete solution.

Yet, you should fix WPKG client .MSI, to fail gracefully, if it does not find settings.xml, or there is no Property in MSI database for settings.xml path.

Because for now, if there is no that property, then WPKG client, when deployed with .MSI in computer-assigned mode, hangs the computer indefinetly with the information "WPKG is installing ..." in Windows startup screen. This is embarrasing for newbie (at least it was for me ;-), as he does not know, what is the problem. It would be better, if the .MSI package would fail, outputing detailed error to the Windows application log, if it does not find that property, or if the property is present, but settings.xml is not found in the path, assigned to that property value.

> Yep, and this is when you'll like mix something up - especially if there 
> are more admins in your environment.

Yes, you are right from this POV. In our case, there is strict responsibility - only 1 administrator is responsible for software and its deployment in the domain at any given time. If WPKG is used in multi-admin environment, in any case, there should be some protection or atleast spoken agreement to save .xml files and packages from multiple-edit problem.

Regards,

Andrew.