Windows Service Msix Automatic Update - in SYSTEM ACCOUNT

[jocs]

Hi,

We have a service that we deploy using msix, all is working, however we now need to have the service automatic updated wihtout user interaction. We deploy the service outside microsoft store and want it to be like that for now... Ive implemented a small command line utility that i run that will run 

[E:\WinUiPackage\TeklaTBone\TeklaTBoneMsix_1.2.43.0_Test] cmd /c powershell -command "Add-AppxPackage -ForceApplicationShutdown -Path E:\WinUiPackage\TeklaTBone\TeklaTBoneMsix_1.2.43.0_Test\TeklaTBoneMsix_1.2.43.0_AnyCPU.msixbundle"

when running this outside the service the utility works fine. However when i run under the service, and under SYSTEM account i get:

Install Msix E:\WinUiPackage\TeklaTBone\TeklaTBoneMsix_1.2.44.0_Test\TeklaTBoneMsix_1.2.44.0_AnyCPU.msixbundle
[C:\WINDOWS\system32] cmd /c powershell -command "Add-AppxPackage -ForceApplicationShutdown -Path E:\WinUiPackage\TeklaTBone\TeklaTBoneMsix_1.2.44.0_Test\TeklaTBoneMsix_1.2.44.0_AnyCPU.msixbundle"
Result: Add-AppxPackage : Deployment failed with HRESULT: 0x80073CF9, Install failed. Please contact your software vendor.
(Exception from HRESULT: 0x80073CF9)
Deployment Add operation rejected on package 66daac85-c649-42b7-b4ee-0deca2697f95_1.2.44.0_neutral_~_63fv57jsaj22j
from: TeklaTBoneMsix_1.2.44.0_AnyCPU.msixbundle install request because the Local System account is not allowed to
perform this operation.
NOTE: For additional information, look for [ActivityId] 2a54b8ab-74ad-000d-8580-552aad74d801 in the Event Log or use
the command line Get-AppPackageLog -ActivityID 2a54b8ab-74ad-000d-8580-552aad74d801
At line:1 char:1
+ Add-AppxPackage -ForceApplicationShutdown -Path E:\WinUiPackage\Tekla ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : WriteError: (E:\WinUiPackage...yCPU.msixbundle:String) [Add-AppxPackage], IOException
+ FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand

Its clear that the security for this account doesnt allow us to install the app. What are the alternatives here?

Ive tryed both runas, and elevate utilities... they both lock the process because they are requisting user interaction. either pass or uac bypass... Since we dont have the admin password so we can run it as admin account what are our alternatives there?

thanks in advance

jorge costa

[#2]

Hi

Can you run the below commands and re-try?

1. cmd-device powershell Set-ExecutionPolicy -scope 'CurrentUser' -executionPolicy 'ByPass'
2. cmd-device powershell Add-AppxProvisionedPackage -Online -PackagePath ".\Test.msix" -SkipLicense

[#3]

Hi @jocs Can you please confirm if this worked for you? This will really help us debug the issue. Thanks

[#4]

@jocs 

Based on the docs here..

MSIX doesn't support windows services that need to run under system accounts. I think you need to fall back to MSI if you need to install a service under a system account. Or run some sort of custom script post install to configure it.. 

• Your application requires a kernel-mode driver or a Windows service. MSIX does not support a kernel-mode driver or a Windows service that needs to run under a system account. Instead of a Windows service, use a background task.
  
  
  

[#5]

@jocs  I am assuming that you didn't really mean the System account, but that you were elevating from a user account, which is different...

The intended way to automate update MSIX apps (even those with services) is one of the following:

• Distribute through the Microsoft Store.
• Intune, Config Manager, or other management platform that uses a local agent that will already have the extra permissions needed.
• Install the original package using an AppInstaller File.  This one became dicey when Microsoft disabled the feature in the Desktop.Appinstaller program that is used to perform the installation due to a security issue.  But there is a policy that can be enabled to allow use of the AppInstaller file for the installation.  This should probably only be used when the AppInstaller file and package source are stored in a secure location within the company's premises to avoid the security issue.  This was discussed in a post by Dian (a Microsoft employee) Disabling the MSIX ms-appinstaller protocol handler - Microsoft Community Hub

Trying to start that install from within the package directly is something that I don't think is going to work.