Hello Experts,
greetings! need your help again, thank you very much in advance.
there is a very strange thing that
- run powershell with System account locally, Start-ADTMsiProcessAsUser -Action 'Install' -FilePath 'octoplantClient.msi' is working fine.
- deploy it on the Intune, the installation is failed.
whole code is as below:
##================================================
## MARK: Variables
##================================================
# Zero-Config MSI support is provided when "AppName" is null or empty.
# By setting the "AppName" property, Zero-Config MSI will be disabled.
$adtSession = @{
# App variables.
AppVendor = ''
AppName = 'octoplantClient'
AppVersion = ''
AppArch = ''
AppLang = 'EN'
AppRevision = '107'
AppSuccessExitCodes = @(0)
AppRebootExitCodes = @(1641, 3010)
AppProcessesToClose = @() # Example: @('excel', @{ Name = 'winword'; Description = 'Microsoft Word' })
AppScriptVersion = '1.0.0'
AppScriptDate = '2026-05-05'
AppScriptAuthor = '<author name>'
RequireAdmin = $true
# Install Titles (Only set here to override defaults set by the toolkit).
InstallName = ''
InstallTitle = ''
# Script variables.
DeployAppScriptFriendlyName = $MyInvocation.MyCommand.Name
DeployAppScriptParameters = $PSBoundParameters
DeployAppScriptVersion = '4.1.8'
}
function Install-ADTDeployment
{
[CmdletBinding()]
param
(
)
##================================================
## MARK: Pre-Install
##================================================
$adtSession.InstallPhase = "Pre-$($adtSession.DeploymentType)"
## Show Welcome Message, close processes if specified, allow up to 3 deferrals, verify there is enough disk space to complete the install, and persist the prompt.
if ($adtSession.AppProcessesToClose.Count -gt 0)
{
$saiwParams.Add('CloseProcesses', $adtSession.AppProcessesToClose)
}
## Show Progress Message (with the default message).
## <Perform Pre-Installation tasks here>
##================================================
## MARK: Install
##================================================
$adtSession.InstallPhase = $adtSession.DeploymentType
## Handle Zero-Config MSI installations.
if ($adtSession.UseDefaultMsi)
{
$ExecuteDefaultMSISplat = @{ Action = $adtSession.DeploymentType; FilePath = $adtSession.DefaultMsiFile }
if ($adtSession.DefaultMstFile)
{
$ExecuteDefaultMSISplat.Add('Transforms', $adtSession.DefaultMstFile)
}
Start-ADTMsiProcess @ExecuteDefaultMSISplat
if ($adtSession.DefaultMspFiles)
{
$adtSession.DefaultMspFiles | Start-ADTMsiProcess -Action Patch
}
}
## <Perform Installation tasks here>
Start-ADTMsiProcessAsUser -Action 'Install' -FilePath 'octoplantClient.msi'
MSI Return Code 1619 (ERROR_INSTALL_PACKAGE_OPEN_FAILED) means the Windows Installer cannot open the installation package (.msi file). This is usually caused by a corrupt installer, incorrect file path, missing source files, or inadequate permissions.
I suspect this is because the script doesn't know where the file is located, as your line doesn't specify the path:
Start-ADTMsiProcessAsUser -Action 'Install' -FilePath 'octoplantClient.msi'
I'd recommend you try this and confirm:
Start-ADTMsiProcessAsUser -Action 'Install' -FilePath "$($adtSession.DirFiles)\octoplantClient.msi"
Hello Adrian, unlucky, same....
Just a sanity check here...
Is the file in the .\Files folder and is it spelled exactly as you are calling it? " octoplantClient.msi
is a regular user able to read that MSI in that folder?
Yes, testing locally is no problem - powershell run as System account. APP can be installed on the current user.
Hello Adrian,
finally it works for me 
I added this sentence...
now the log says:
Well, that's good...
I wonder if when the deployment is run as SYSTEM the source file ( $($adtSession.DirFiles)\octoplantClient.msi) doesn't have the correct NTFS permissions to allow the User to access or run the .msi file, but by pre-copying it to the Temp folder, the file has inherited the permissions already set on the C:\Temp folder - Which a normal user has access to?
But I don't think that can be the case, especially as
Definitely a permissions issue on the DirFiles folder. However the real question is "why"? Just scope the entire deployment a user-scoped in Intune and go from there. Scoping apps as system, only to have PSADT deploy it to the logged on user is abusive of why Start-ADTProcessAsUser exists. Don't do it.
Hello gent,
I disagree with your opinion. This has specific usage scenarios, which is exactly why Start-ADTProcessAsUser exists.
the whole story:
I didn't use PSADT to deploy the MSI at the beginning. Instead, I ran the installation as the current user in Intune, so that the software could automatically update itself in the future — which is necessary when running under an account without administrator privileges.
Then we realized that many old versions needed to be uninstalled, and that requires administrator privileges. So the actual complete code also includes uninstall logic. Therefore, what I did is actually a reasonable use case."
Hello gent, c:\temp? - yes
Considering I wrote Start-ADTProcessAsUser and all the Start-ADT*ProcessAsUser code, I know why it exists and what it's for 
Even with your requirements, I'd recommend favouring Intune's supersedence over deploying from SYSTEM to the logged on user. You can have a user-scoped Win32 app supersede one or more system-scoped Win32 apps.
The Start-ADTMsiProcessAsUser function is mostly there for the opposite of what you're doing; that is cleaning up user-based MSI installations prior to rolling out a system-based MSI installation in its place.
Hello Sir,
Glad to talk with you - Coder directly!
Please consider my scenario 
to improve the function in the future - if it's possible.
@mjr4077au does not have to improve the function.
You (@RyanGu) need to give Authenticated Users read permissions to the local installation cache folder.
If you are not comfortable with that, keep copying the files you which to run AsUser in a location where the user CAN read them.
I have been considering ensuring the user can read the executable (or the directory the executable is in) prior to attempting to run something.
Feel free to place a feature request up on our GitHub page so we can track it, we'll see what happens there. We're close to the end of our 4.2.0 development cycle so no promises.
EDIT: For the permissions, you'd just use our Set-ADTItemPermission function to achieve this.
Hello Gent,
Thanks! However, I've discovered a new issue. Although switching to the current user to install the software works, Intune's detection mechanism suddenly fails and cannot detect it, showing that the software cannot be found. I will try another way...
You should just be using %LocalAppData%.
