The PrinterLogic Printer Installer Client app uses the same ProductCode GUID for all versions of their installers, but they do use different ProductVersion for each version. The PSADT works great when run by itself as admin. It stops processes, stops the spooler service, uninstalls any older version with Remove-MSIApplications, removes registry keys and files, starts the spooler service; and installs the new version.
However, when I wrap it as .intunewin file, and run the install from Intune the PSADT log file say:
[Installation] :: The MSI is already installed on this system. Skipping action [Install]ā¦ Execute-MSI 9/12/2022 11:00:41 AM 30412 (0x76CC)
--------------------------------- my code ------------------------------------
Thank you for the suggestion. I need to use Remove-MSIApplications to remove different version, and some that I donāt know about. Also, when running in Intune it quits before getting to Remove-MSIApplions. But when I run it independently of Intune it works.
Stop-ServiceAndDependencies is a PSADT function so it should have logged what happened when it tried to stop the Spooler service. Maybe it canāt or needs more time. Check PSADTās log file.
Also, is Printer Installer Client installed in the user profile or in Program Files?
Unfortunately, Stop-ServiceAndDependencies is not in the PSADT Log file.
I will compare the log when it works by itself, and when it fails within Intune. I can add more logging with Write-Log.
It is Installed in āC:\Program Files (x86)\Printer Properties Pro\Printer Installer Clientā
Thank you @That-Annoying-Guy for giving me the clue to uncover a Bug (in either Intune or the PSADT) and get it working in Intune. Intune was never evaluating the IF statement because there is a bug where it fails to detect the existence of a Registry Key when ran from Intune as a Win32app (but works when run by itself), and never uninstalled the old version.
I modified the IF statement and discovered that testing for the existence of a Registry Key in Intune doesnāt work. However, testing for testing the existence of the File Path in Intune does work.
For example, this works: IF (Test-Path -Path "C:\Program Files (x86)\Printer Properties Pro") {
While this fails which I believe is a bug in either Intune or the PSADT: IF (Test-Path -Path "HKLM:\SOFTWARE\PrinterLogic") {
The following will tell you āhowā Microsoft is executing/bootstrapping the script on the endpoint.
Add it to your script somewhere and review your PSADT installation script log.
I somehow suspect you could be running into 32-bit process on 64-bit operating system which adds some complexity when dealing with paths and variables because of Windows File System Redirection. That is only if Win32Intune is in fact running as a 32-Bit process. The execution context will also be āSYSTEMā and not a local administrator which is an entirely different can of worms.
"$Env:ProgramFiles (x86)\Printer Properties Pro" should be "$(${env:ProgramFiles(x86)})\Printer Properties Pro"
I wrote a little code block so that you can remove folders in a loop only if they exist! Keeps the editing down.
$FolderList = New-Object -TypeName 'System.Collections.Generic.List[System.IO.DirectoryInfo]'
$FolderList.Add("$(${env:ProgramFiles(x86)})\Printer Properties Pro")
#$FolderList.Add("Add Another Folder Here")
ForEach ($Folder In $FolderList)
{
Switch ([System.IO.Directory]::Exists($Folder.FullName))
{
{($_ -eq $True)}
{
Remove-Folder -Path ($Folder.FullName) -ContinueOnError:$True
}
Default
{
###Folder does not exist and does not require removal
}
}
}
Also, Get-InstalledApplication is useful to check to see if the application is there before you attempt to remove it.
[Regex]$SoftwareDetectionExpression = '(.*YourFirstApp.*)|(.*YourSecondApp.*)'
$SoftwareDetectionList = Get-InstalledApplication -Name ($SoftwareDetectionExpression) -RegEx
ForEach ($SoftwareDetection In $SoftwareDetectionList)
{
$SoftwareDetection
<#
Do stuff with the uninstall string or product code of your software
Test Conditions
Execute-MSI
Execute-Process
Welcome to dynamic software removal, no need to know every product code in advance!
#>
}
Hope this helps!
PS - Sorry about the code formatting, I could not get it correct when pasting into the post.
Hi @alphaeus, I think you are on to something with the 32-bit process on 64-bit operating system. When wrapped as a *.intunewin file and ran from Intune, Iām not able to access this registry key to delete it or use it in Test-Path: HKLM:\SOFTWARE\PrinterLogic
I have tried both: Remove-RegistryKey -Key "HKLM:\SOFTWARE\PrinterLogic" -Recurse
and Remove-Item -Path "HKLM:\SOFTWARE\PrinterLogic" -Recurse -Force -ErrorAction 'SilentlyContinue'
I shall add your code to the Deploy-Application.ps1 at the beginning of the ##_ <Perform Pre-Installation tasks here>
section and review the PSADT logfile.
Yup, looks like Microsoft is doing some under the hood magic to jam everything inā¦get used to it. I pasted the function you needed to get the process elevation status. Sorry, I forgot it the first time.
#region Function Get-AdministrativePrivilege
Function Get-AdministrativePrivilege
{
$Identity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$Principal = New-Object System.Security.Principal.WindowsPrincipal($Identity)
Write-Output -InputObject ($Principal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator))
} #endregion
Thank you @alphaeus, I added the function, wrapped it as .intunewin file, and here is what the log said: [Pre-Installation] :: Unable to delete registry key [Registry::HKEY_LOCAL_MACHINE\SOFTWARE\PrinterLogic] because it does not exist.
But the key does exist and its spelled correctly, very stranageā¦
Other lines highlighed in yellow say:
[Pre-Installation] :: Process ID: 624
[Pre-Installation] :: Is 64-Bit Process: False
[Pre-Installation] :: Process Command Line: PowerShell.exe -ExecutionPolicy Bypass -File ".\Deploy-Application.ps1" -DeploymentType "Install" -DeployMode "Silent"
[Pre-Installation] :: Process Execution Context: NT AUTHORITY\SYSTEM
Just fyi, I used 3 back ticks ``` one line above, and one line below to help format the code
That is 64 bit process being false is the culprit!
Microsoft is launching powershell as a 32bit process on a 64 bit operating system, that completely changes the execution environment and explains why the process cannot āseeā that registry path.
Does intune allow you to specify the command line?
If so, try explicity pointing to the native 64 bit powershell.
[Pre-Installation] :: Is 64-Bit Process: False
[Pre-Installation] :: Process Command Line: C:\WINDOWS\System32\WindowsPowershell\v1.0\powershell.exe -ExecutionPolicy Bypass -File ".\Deploy-Application.ps1" -DeploymentType "Install" -DeployMode "Silent"
[Pre-Installation] :: Process Execution Context: NT AUTHORITY\SYSTEM GetCurrentProcessInfo 9/24/2022 12:16:00 AM 23000 (0x59D8)
[Pre-Installation] :: Unable to delete registry key [Registry::HKEY_LOCAL_MACHINE\SOFTWARE\PrinterLogic] because it does not exist.
Alphaeus, That Worked!!!
Thank you for your Outstanding Assistance with this little known feature sysnative to solve the WoW64 (Windows 32-bit on Windows 64-bit) system redirection challenges for the registry.
I swapped out System32 with sysnative in the command line at:
