MSI Installer

[Romanitho]

Hi guys,

I'm thinking for few days/weeks now to package WAU into a MSI package. This would involve breaking changes I guess. My ideas so far:

• Install WAU to ProgramFiles
• WAU data (like logs mainly) to ProgramData
• MSI would take care of registry (with config in it)
• MSI would manage update smoother and better (no Invoke-PostUpdateActions.ps1 anymore)
• No WAU shortcut or bat anymore to install it
• Select only few parameters from the GUI installer (as all settings are customisable via GPO or via install switch in cli) - mainly for home users
• and much more...

For that, I think about WIX and Github Actions to continue to have all things full automated to be as transparent as possible in the build.

@KnifMelti @AndrewDemski-ad-gmail-com

[Romanitho]

This will involve also new versioning system probably.
Today we have something like 1.19.1 for stable version
and 1.19.2-9 for nightly builds (that will pop to 1.19.2 when becoming stable)

We could change this for something like:
1.19.2.9 for Nightly builds
and by convention x.x.x.100 for stable, so 1.19.2.100 would be the new stable release in this example. Next stable one would be 1.19.3.100 for minor changes or 1.20.0.100 for major changes.

Don't really like the ".100" but I didn't find something better yet 😅

[Romanitho]

Yes, I was thinking about WIX. I'm trying to learn a bit about how it works 😅

Regarding the versionning, maybe we need to think about something else then.

[AndrewDemski-ad-gmail-com]

Why no change it to something similar to what Citrix has done some time ago?
major.minor[.build[.revision]] where each part of identifier was capped at 255.
Modern standard expanded those sections a bit to 16bits, but IMHO that would be an overkill.

Idea for versioning:

octet	definition	max value	sample value
major	Year od current release	255	23
minor	month of current release	255	3
build	day of current release	255	12
revision	any hotfix if necessary	255	0

That would produce WAU release with VersionInfo identified as 23.3.12.0 (simple date formatting would be enough).

It is still consistent with winget schema for packages
https://github.com/microsoft/winget-pkgs/blob/01e23bc050d119377b166bc2e312890c6f11ff1c/schemas/JSON/validation/ValidationSchema.1.0.0.json#L13-L16

    "ValidationVersion": {
      "description": "Version of validation file. Used to handle breaking changes, should the need arise.",
      "type": "string",
      "pattern": "^[0-9]+\\.[0-9]+\\.[0-9]+$"

[Romanitho]

The "date" version could be something easy to implement for sure...
But we need to be sure that we do not run the same day a nightly build with a potential stable one.

[Romanitho]

this powershell cmd could generate our new semver:
Get-Date -Format %y.%M.%d.%H%m
24.3.13.1740

[AndrewDemski-ad-gmail-com]

@KnifMelti you may like this introduction to WIX
https://www.codeproject.com/Tips/105638/A-quick-introduction-Create-an-MSI-installer-with

[AndrewDemski-ad-gmail-com]

Hi guys,

I'm thinking for few days/weeks now to package WAU into a MSI package. This would involve breaking changes I guess. My ideas so far:

• Install WAU to ProgramFiles

achievable already using existing scripted logic by changing the target folder

• WAU data (like logs mainly) to ProgramData

That one is easy, either using that recent settings.JSON file approach from one of PRs or something similar

• MSI would take care of registry (with config in it)

Using Installer to provide automated resolve of WAU variables would give only the ARPINSTALLLOCATION, major settings should land:

• in defaults config file
• Policies Regkey
• in separate HKLM/Software/WAU location (with option for overrides in HKCU)

• MSI would manage update smoother and better (no Invoke-PostUpdateActions.ps1 anymore)

scripting languages natively interpreted during installation include

• vbscript
• jscript
  more details here:
  https://learn.microsoft.com/en-us/windows/win32/msi/summary-list-of-all-custom-action-types
  https://learn.microsoft.com/en-us/windows/win32/msi/scripts

guys from Advanced Installer had some idea but that would require creating an obfuscated DLL which would run the inline script in the background (risking an another false positive for sophisticated inline script).

• No WAU shortcut or bat anymore to install it

so.. winget initiated by WAU would update.. WAU?
What about that brain-dead executable launcher which could solve the problem with false positives returned by AVs?

• Select only few parameters from the GUI installer (as all settings are customisable via GPO or via install switch in cli) - mainly for home users
• and much more...

For that, I think about WIX and Github Actions to continue to have all things full automated to be as transparent as possible in the build.

That would mean adding WAU to winget repo on github.
Yet the idea of calling winget install --id WAU.WAU using package definition with InstallMode : Interactive would be nice.

[KnifMelti]

scripting languages natively interpreted during installation include

vbscript
jscript

It can also be in Powershell

[AndrewDemski-ad-gmail-com]

Assuming that WAU lands in winget repo, those could be treated as separate products.

…

________________________________ From: Romain ***@***.***> Sent: 12 March 2024 22:54 To: Romanitho/Winget-AutoUpdate ***@***.***> Cc: Andrzej Demski ***@***.***>; Mention ***@***.***> Subject: Re: [Romanitho/Winget-AutoUpdate] MSI Installer (Discussion #582) The "date" version could be something easy to implement for sure... But we need to be sure that we do not run the same day a nightly build with a potential stable one. — Reply to this email directly, view it on GitHub<#582 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ASAJCPUAU662N7SW55Y54CDYX52Q5AVCNFSM6AAAAABER4U5VWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DONRVGQYTM>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Romanitho]

could be. i'm not skilled enough for MSI building, but we might (I guess) ensure that we cannot have both version (stable and preview) installed at the mean time on a device.

[AndrewDemski-ad-gmail-com]

Why not?
two distinct INSTALLDIRs and two sets of tasks in the scheduler.
Let the fun begin:)

[Romanitho]

First tests:
https://github.com/Romanitho/WAU-MSI/releases/tag/v1.20.0

New substructure:
https://github.com/Romanitho/WAU-MSI/tree/main/Sources/Wix

Updated GitHub actions:
https://github.com/Romanitho/WAU-MSI/actions/workflows/WAU-CreateNewVersion.yml

So far, WAU installs files to program files. Still have to work on registry entries and scheduled task, but at least, MSI are created successfully

[Romanitho]

I also removed the preversion that used to be created by the nightly builder. This way, even pre version nightly builds are like this 1.19.3 -> 1.19.4

Also, I disabled the automerge of dependabot that creates nightly for nothing. I'll merge manually when other PR are pushed.

[Romanitho]

All seems to work now. Msi simplifies things now:
https://github.com/Romanitho/WAU-MSI/releases/tag/v1.21.3

[KnifMelti]

Quick test; property DONOTRUNONMETERED becomes a REG_SZ if set to 0 at installation instead of the REG_DWORD it should be (as it becomes when not set at all).
Cant find any shortcuts settings at all, but this is a work in progress!

[Romanitho]

I'll have a look for the reg.
Regarding the shortcut, i'm on it as well.

[Romanitho]

And I also need to get the notification back when WAU MSI successfully self update. A small detail.

[Romanitho]

regkeys should be fixed now:
https://github.com/Romanitho/WAU-MSI/releases/tag/v1.21.5
if you can confirm, it would be perfect :)

[KnifMelti]

Now it's fixed, confirmed true!

[KnifMelti]

NB. for documentation!
If the external Path is a Private Azure Container protected by a SAS token the Property LISTPATH must be enclosed by " and the % escaped by an extra %.
Example: https://storagesample.blob.core.windows.net/sample-container?v=2023-11-31&sr=b&sig=39Up9jzHkxhUIhFEjEh9594DIxe6cIRCgOVOICGSP%3A377&sp=rcw must be LISTPATH="https://storagesample.blob.core.windows.net/sample-container?v=2023-11-31&sr=b&sig=39Up9jzHkxhUIhFEjEh9594DIxe6cIRCgOVOICGSP%%3A377&sp=rcw"

[Romanitho]

ok, thanks for report ;)
But maybe this kind of configuration is mainly set in corp environment, so managed by GPO/Intune I guess.

[Romanitho]

https://github.com/Romanitho/Winget-AutoUpdate/tree/v2-MSI

[Romanitho]

#697

[gunthest]

Hello, Can you please show an example of passing the Parameters to the msi file? I am trying to deploy this remotely using the WAU.msi. Your Documentation here (https://github.com/Romanitho/Winget-AutoUpdate under "Advanced Installation") Says you can use the WAU.MSI script with the following parameters. However when i try to run msiexec it brings up the msiexec menu. So is there a specific way to pass the NOTIFICATIONLEVEL, UPDATESINTERVAL, UPDATESATTIME parameters? I have been trying WAU.msi /qn NOTIFICATIONLEVEL none, WAU.msi /qn -NOTIFICATIONLEVEL none, and WAU.msi /qn /NOTIFICATIONLEVEL None. None of them seem to be working.

[Romanitho]

try msiexec.exe /i WAU.msi /qn NOTIFICATIONLEVEL=None

[gunthest]

Worked beautifully. Thank you for everything you do!

[Romanitho]

No worries.
Keep in mind that the current MSI version is still in beta and may be buggy.

[dbennett2843]

Where are the logs? I can't find an install log or an update log

Install command line is WAU.msi /quiet /qn USERCONTEXT=1 NOTIFICATIONLEVEL=NONE UPDATESATLOGON=1 UPDATESINTERVAL=DAILY

[Romanitho]

WAU automatically creates the log folder and log files. The problem seems to be elsewhere.

[whitephnx1]

ok I installed the v2.0 msi on 10 computers and all of them didn't have the folder. I had to force the folder to be created after the install took place so the log would show up. Just figured i mention the behavior on my side. I was installing it with these commands on end
/qn DISABLEWAUAUTOUPDATE=1 RUN_WAU=NO USERCONTEXT=1 BYPASSLISTFORUSERS=1 NOTIFICATIONLEVEL=Full UPDATESINTERVAL=BiDaily

[Romanitho]

It is created on the first run.

[whitephnx1]

Ill test it some more, but wouldn't it be easier to just create the folder on install?

[KnifMelti]

Ill test it some more, but wouldn't it be easier to just create the folder on install?

No. For all of us using a domain and SCCM with a locked down deployment net this way it can be installed during OSD without a problem, then when the client is on the correct net and WAU is run the dependencies are installed (pulling them over internet) and the logs folder is created on first WAU run - no use of it before.

[dbennett2843]

Got it! Thanks.

I ran the Winget-AutoUpdate-Policies instead of the Winget-AutoUpdate so no log was created. Once I ran Winget-AutoUpdate I found the log where I expected it