Further fixes to transform and patches in execute-msi
↧
Source code checked in, #14f67e74278d017158e09712741b22736835cfd4
↧
Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]
When using the -Patch parameter of Execute-MSI, the full path to the patch is not listed (e.g. the path is passed to msiexec as simply "patch.msp" instead of "d:\app\files\patch.msp"). msiexec does not like that, saying it cannot find the patch file. I notice that in the code, the full path is prepended to $path to make the $msiFile variable which is given to msiexec, but $mspFile is simply set to $patch with no path modification done. If I add similar code to prepend the full path to $mspFile, the install works.
Comments: Apologies, seems I'm having a bad day! :) I've made a number of changes and have tested this every way I can possibly come up with. It works for me every single time using multiple transforms and patches. Can you recheck? Thanks, Dan
Comments: Apologies, seems I'm having a bad day! :) I've made a number of changes and have tested this every way I can possibly come up with. It works for me every single time using multiple transforms and patches. Can you recheck? Thanks, Dan
↧
↧
New Post: Deferral and Blocked App
Found the issue with this - just in case someone runs across the same issue. Workstation was only on PowerShell 2.0. Upgraded and all was well.
↧
Created Unassigned: Function Execute-Process - $private:ErrorActionPreference [168]
I'm running Windows Powershell ISE 4.0 as an Administrator. When I run the script in debug mode (by setting a breakpoint in Deploy-Application.ps1) I get the exception below in Function Execute-Process.
__AppDeployToolkitMain.ps1__
```PowerShell
Function Execute-Process
...
## Using this variable allows capture of exceptions from .NET methods. Private scope only changes value for current function.
$private:ErrorActionPreference = 'Stop'
```
__PowerShell ISE Console__
> PS C:\Windows\system32> $Error
System error.
Cannot set options on the local variable ErrorActionPreference. Use New-Variable to create a variable that allows options to be set.
At C:\PSAppDeployToolkit\PSAppDeployToolkit_v3.5.0\Toolkit\AppDeployToolkit\AppDeployToolkitMain.ps1:2229 char:5
>+ $private:ErrorActionPreference = 'Stop'
>+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + CategoryInfo : WriteError: (ErrorActionPreference:String) [], >SessionStateUnauthorizedAccessException
> + FullyQualifiedErrorId : VariableOptionsNotSettable
__Work Around__
```PowerShell
Function Execute-Process
...
## Using this variable allows capture of exceptions from .NET methods. Private scope only changes value for current function.
$ErrorActionPreference = 'Stop'
...
#REPLACE AT END OF FUNCTION
Finally {
If ($private:previousErrorActionPreference) {
$ErrorActionPreference = $private:previousErrorActionPreference
}
}
}
End {
Write-FunctionHeaderOrFooter -CmdletName ${CmdletName} -Footer
}
}
#endregion
```
Similar to https://psappdeploytoolkit.codeplex.com/workitem/120 which has been closed.
__AppDeployToolkitMain.ps1__
```PowerShell
Function Execute-Process
...
## Using this variable allows capture of exceptions from .NET methods. Private scope only changes value for current function.
$private:ErrorActionPreference = 'Stop'
```
__PowerShell ISE Console__
> PS C:\Windows\system32> $Error
System error.
Cannot set options on the local variable ErrorActionPreference. Use New-Variable to create a variable that allows options to be set.
At C:\PSAppDeployToolkit\PSAppDeployToolkit_v3.5.0\Toolkit\AppDeployToolkit\AppDeployToolkitMain.ps1:2229 char:5
>+ $private:ErrorActionPreference = 'Stop'
>+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + CategoryInfo : WriteError: (ErrorActionPreference:String) [], >SessionStateUnauthorizedAccessException
> + FullyQualifiedErrorId : VariableOptionsNotSettable
__Work Around__
```PowerShell
Function Execute-Process
...
## Using this variable allows capture of exceptions from .NET methods. Private scope only changes value for current function.
$ErrorActionPreference = 'Stop'
...
#REPLACE AT END OF FUNCTION
Finally {
If ($private:previousErrorActionPreference) {
$ErrorActionPreference = $private:previousErrorActionPreference
}
}
}
End {
Write-FunctionHeaderOrFooter -CmdletName ${CmdletName} -Footer
}
}
#endregion
```
Similar to https://psappdeploytoolkit.codeplex.com/workitem/120 which has been closed.
↧
Edited Unassigned: Function Execute-Process - $private:ErrorActionPreference [168]
I'm running Windows Powershell ISE 4.0 as an Administrator. When I run the script in debug mode (by setting a breakpoint in Deploy-Application.ps1) I get the exception below in Function Execute-Process.
__AppDeployToolkitMain.ps1__
```PowerShell
Function Execute-Process
...
## Using this variable allows capture of exceptions from .NET methods. Private scope only changes value for current function.
$private:ErrorActionPreference = 'Stop'
```
__PowerShell ISE Console__
> PS C:\Windows\system32> $Error
System error.
Cannot set options on the local variable ErrorActionPreference. Use New-Variable to create a variable that allows options to be set.
At C:\PSAppDeployToolkit\PSAppDeployToolkit_v3.5.0\Toolkit\AppDeployToolkit\AppDeployToolkitMain.ps1:2229 char:5
>+ $private:ErrorActionPreference = 'Stop'
>+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + CategoryInfo : WriteError: (ErrorActionPreference:String) [], >SessionStateUnauthorizedAccessException
> + FullyQualifiedErrorId : VariableOptionsNotSettable
__Suggested Work Around__
```PowerShell
Function Execute-Process
...
## Using this variable allows capture of exceptions from .NET methods. Private scope only changes value for current function.
$ErrorActionPreference = 'Stop'
...
#REPLACE AT END OF FUNCTION
Finally {
If ($private:previousErrorActionPreference) {
$ErrorActionPreference = $private:previousErrorActionPreference
}
}
}
End {
Write-FunctionHeaderOrFooter -CmdletName ${CmdletName} -Footer
}
}
#endregion
```
Similar to https://psappdeploytoolkit.codeplex.com/workitem/120 which has been closed.
__AppDeployToolkitMain.ps1__
```PowerShell
Function Execute-Process
...
## Using this variable allows capture of exceptions from .NET methods. Private scope only changes value for current function.
$private:ErrorActionPreference = 'Stop'
```
__PowerShell ISE Console__
> PS C:\Windows\system32> $Error
System error.
Cannot set options on the local variable ErrorActionPreference. Use New-Variable to create a variable that allows options to be set.
At C:\PSAppDeployToolkit\PSAppDeployToolkit_v3.5.0\Toolkit\AppDeployToolkit\AppDeployToolkitMain.ps1:2229 char:5
>+ $private:ErrorActionPreference = 'Stop'
>+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + CategoryInfo : WriteError: (ErrorActionPreference:String) [], >SessionStateUnauthorizedAccessException
> + FullyQualifiedErrorId : VariableOptionsNotSettable
__Suggested Work Around__
```PowerShell
Function Execute-Process
...
## Using this variable allows capture of exceptions from .NET methods. Private scope only changes value for current function.
$ErrorActionPreference = 'Stop'
...
#REPLACE AT END OF FUNCTION
Finally {
If ($private:previousErrorActionPreference) {
$ErrorActionPreference = $private:previousErrorActionPreference
}
}
}
End {
Write-FunctionHeaderOrFooter -CmdletName ${CmdletName} -Footer
}
}
#endregion
```
Similar to https://psappdeploytoolkit.codeplex.com/workitem/120 which has been closed.
↧
↧
Commented Unassigned: sccm "available" vs "required" deployment [143]
Hi,
I'm running a flash player upgrade using the v3.5.0 kit which worked great during my tests.
more specifically the welcome screen:
```
Show-InstallationWelcome -CloseApps "iexplore,firefox" -forceCloseAppsCountdown 900 -BlockExecution -PersistPrompt
```
That works fine when deploying to a machine when the advertisement is "Available". This is good for testing.
```
[Initialization] :: The following user is the console user [[EMEA\mp2827]] (user with control of physical monitor, keyboard, and mouse). PSAppDeployToolkit 1/16/2015 12:43:01 1 (0x0001)
[Initialization] :: Unable to load COM Object [Microsoft.SMS.TSEnvironment]. Therefore, script is not currently running from a SCCM Task Sequence. PSAppDeployToolkit 1/16/2015 12:43:01 1 (0x0001)
[Initialization] :: Session 0 detected, process running in user interactive mode, user(s) logged in. PSAppDeployToolkit 1/16/2015 12:43:01 1 (0x0001)
[Initialization] :: Installation is running in [Interactive] mode. PSAppDeployToolkit 1/16/2015 12:43:01 1 (0x0001)
```
But when starting the actual deployment I want to set it as 'required' so the user gets it installed in any case.
```
[Initialization] :: The following users are logged on to the system: EMEA\mp2827 PSAppDeployToolkit 1/16/2015 13:52:14 1 (0x0001)
[Initialization] :: Current process is running under a system account [NT AUTHORITY\SYSTEM] PSAppDeployToolkit 1/16/2015 13:52:14 1 (0x0001)
[Initialization] :: The following user is the console user [[EMEA\mp2827]] (user with control of physical monitor, keyboard, and mouse). PSAppDeployToolkit 1/16/2015 13:52:14 1 (0x0001)
[Initialization] :: Unable to load COM Object [Microsoft.SMS.TSEnvironment]. Therefore, script is not currently running from a SCCM Task Sequence. PSAppDeployToolkit 1/16/2015 13:52:14 1 (0x0001)
[Initialization] :: Session 0 detected, process not running in user interactive mode: deployment mode set to [NonInteractive]. PSAppDeployToolkit 1/16/2015 13:52:14 1 (0x0001)
[Initialization] :: Installation is running in [NonInteractive] mode. PSAppDeployToolkit 1/16/2015 13:52:14 1 (0x0001)
```
Now the interactive mode is disabled and my users do not get the option any longer to stop their work and properly close IE or FF.
Can anyone confirm if this is by design, or because otherwise is not possible or you have this fixed in 3.6? Because if we can't push out required applications without giving the end-user the option to close off some work before closing the application we need to update then that makes it not possible to user the required option in my eyes.
How do you suggest we work around this?
ps: complaints, I know. But I remain a big fan of this deployment kit, no doubt. It is the best thing around for the job! thanks again for the hard work
Maarten
Comments: I had to downgrade back to 3.2 because of this. It is not a problem to make an interactive mandatory assignment to devices there. Hope you can fix this in 3.6 Maarten
I'm running a flash player upgrade using the v3.5.0 kit which worked great during my tests.
more specifically the welcome screen:
```
Show-InstallationWelcome -CloseApps "iexplore,firefox" -forceCloseAppsCountdown 900 -BlockExecution -PersistPrompt
```
That works fine when deploying to a machine when the advertisement is "Available". This is good for testing.
```
[Initialization] :: The following user is the console user [[EMEA\mp2827]] (user with control of physical monitor, keyboard, and mouse). PSAppDeployToolkit 1/16/2015 12:43:01 1 (0x0001)
[Initialization] :: Unable to load COM Object [Microsoft.SMS.TSEnvironment]. Therefore, script is not currently running from a SCCM Task Sequence. PSAppDeployToolkit 1/16/2015 12:43:01 1 (0x0001)
[Initialization] :: Session 0 detected, process running in user interactive mode, user(s) logged in. PSAppDeployToolkit 1/16/2015 12:43:01 1 (0x0001)
[Initialization] :: Installation is running in [Interactive] mode. PSAppDeployToolkit 1/16/2015 12:43:01 1 (0x0001)
```
But when starting the actual deployment I want to set it as 'required' so the user gets it installed in any case.
```
[Initialization] :: The following users are logged on to the system: EMEA\mp2827 PSAppDeployToolkit 1/16/2015 13:52:14 1 (0x0001)
[Initialization] :: Current process is running under a system account [NT AUTHORITY\SYSTEM] PSAppDeployToolkit 1/16/2015 13:52:14 1 (0x0001)
[Initialization] :: The following user is the console user [[EMEA\mp2827]] (user with control of physical monitor, keyboard, and mouse). PSAppDeployToolkit 1/16/2015 13:52:14 1 (0x0001)
[Initialization] :: Unable to load COM Object [Microsoft.SMS.TSEnvironment]. Therefore, script is not currently running from a SCCM Task Sequence. PSAppDeployToolkit 1/16/2015 13:52:14 1 (0x0001)
[Initialization] :: Session 0 detected, process not running in user interactive mode: deployment mode set to [NonInteractive]. PSAppDeployToolkit 1/16/2015 13:52:14 1 (0x0001)
[Initialization] :: Installation is running in [NonInteractive] mode. PSAppDeployToolkit 1/16/2015 13:52:14 1 (0x0001)
```
Now the interactive mode is disabled and my users do not get the option any longer to stop their work and properly close IE or FF.
Can anyone confirm if this is by design, or because otherwise is not possible or you have this fixed in 3.6? Because if we can't push out required applications without giving the end-user the option to close off some work before closing the application we need to update then that makes it not possible to user the required option in my eyes.
How do you suggest we work around this?
ps: complaints, I know. But I remain a big fan of this deployment kit, no doubt. It is the best thing around for the job! thanks again for the hard work
Maarten
Comments: I had to downgrade back to 3.2 because of this. It is not a problem to make an interactive mandatory assignment to devices there. Hope you can fix this in 3.6 Maarten
↧
New Post: BlockExecution still enabled after the installation
Hello. I'm experiencing the same situation. The DebuggerValue registry value isn't being deleted after the application install. Any thoughts why?
Thank you in advance.
Thank you in advance.
↧
New Post: BlockExecution still enabled after the installation
sstanfie wrote:
Hello. I'm experiencing the same situation. The DebuggerValue registry value isn't being deleted after the application install. Any thoughts why?And this happens with version 3.6.0 of the script also.
Thank you in advance.
↧
Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]
When using the -Patch parameter of Execute-MSI, the full path to the patch is not listed (e.g. the path is passed to msiexec as simply "patch.msp" instead of "d:\app\files\patch.msp"). msiexec does not like that, saying it cannot find the patch file. I notice that in the code, the full path is prepended to $path to make the $msiFile variable which is given to msiexec, but $mspFile is simply set to $patch with no path modification done. If I add similar code to prepend the full path to $mspFile, the install works.
Comments: Hi Dan I can confirm that the path for both patch and transforms are resolved correctly and now correctly parses a commaseperated list. This is really great fix. But now I have a new problem. It looks like the added path validation feature of execute-msi tries to validate the path of a GUID when executing Execute-MSI -Action Uninstall -Path "{95150000-0052-0409-1000-0000000FF1CE}" or as in this example where I'm using "Remove-MSIApplications -Name "Microsoft Visio Viewer 2013" -Exact". Can anyone confirm this behavior? Logfile: > [Uninstallation] :: Get information for installed Application Name(s) [Microsoft Visio Viewer 2013]... Get-InstalledApplication 21-02-2015 20:30:44 3 (0x0003) [Uninstallation] :: Found installed application [Microsoft Visio Viewer 2013] version [15.0.4569.1506] exactly matching application name [Microsoft Visio Viewer 2013] Get-InstalledApplication 21-02-2015 20:30:44 3 (0x0003) [Uninstallation] :: Remove application [Microsoft Visio Viewer 2013 ]. Remove-MSIApplications 21-02-2015 20:30:45 3 (0x0003) [Uninstallation] :: Resolve product code to a publisher, application name, and version. Execute-MSI 21-02-2015 20:30:45 3 (0x0003) [Uninstallation] :: Get information for installed Product Code [{95150000-0052-0409-1000-0000000FF1CE}]... Get-InstalledApplication 21-02-2015 20:30:45 3 (0x0003) [Uninstallation] :: Found installed application [Microsoft Visio Viewer 2013] version [15.0.4569.1506] matching product code [{95150000-0052-0409-1000-0000000FF1CE}] Get-InstalledApplication 21-02-2015 20:30:45 3 (0x0003) [Uninstallation] :: Failed to find MSI file [{95150000-0052-0409-1000-0000000FF1CE}]. Execute-MSI 21-02-2015 20:30:46 3 (0x0003)
Comments: Hi Dan I can confirm that the path for both patch and transforms are resolved correctly and now correctly parses a commaseperated list. This is really great fix. But now I have a new problem. It looks like the added path validation feature of execute-msi tries to validate the path of a GUID when executing Execute-MSI -Action Uninstall -Path "{95150000-0052-0409-1000-0000000FF1CE}" or as in this example where I'm using "Remove-MSIApplications -Name "Microsoft Visio Viewer 2013" -Exact". Can anyone confirm this behavior? Logfile: > [Uninstallation] :: Get information for installed Application Name(s) [Microsoft Visio Viewer 2013]... Get-InstalledApplication 21-02-2015 20:30:44 3 (0x0003) [Uninstallation] :: Found installed application [Microsoft Visio Viewer 2013] version [15.0.4569.1506] exactly matching application name [Microsoft Visio Viewer 2013] Get-InstalledApplication 21-02-2015 20:30:44 3 (0x0003) [Uninstallation] :: Remove application [Microsoft Visio Viewer 2013 ]. Remove-MSIApplications 21-02-2015 20:30:45 3 (0x0003) [Uninstallation] :: Resolve product code to a publisher, application name, and version. Execute-MSI 21-02-2015 20:30:45 3 (0x0003) [Uninstallation] :: Get information for installed Product Code [{95150000-0052-0409-1000-0000000FF1CE}]... Get-InstalledApplication 21-02-2015 20:30:45 3 (0x0003) [Uninstallation] :: Found installed application [Microsoft Visio Viewer 2013] version [15.0.4569.1506] matching product code [{95150000-0052-0409-1000-0000000FF1CE}] Get-InstalledApplication 21-02-2015 20:30:45 3 (0x0003) [Uninstallation] :: Failed to find MSI file [{95150000-0052-0409-1000-0000000FF1CE}]. Execute-MSI 21-02-2015 20:30:46 3 (0x0003)
↧
↧
Source code checked in, #b6373552484da21c62c83443c5f2dcf064591540
Fixed Execute-MSI failing if run using Remove-MSIApplication
↧
Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]
When using the -Patch parameter of Execute-MSI, the full path to the patch is not listed (e.g. the path is passed to msiexec as simply "patch.msp" instead of "d:\app\files\patch.msp"). msiexec does not like that, saying it cannot find the patch file. I notice that in the code, the full path is prepended to $path to make the $msiFile variable which is given to msiexec, but $mspFile is simply set to $patch with no path modification done. If I add similar code to prepend the full path to $mspFile, the install works.
Comments: Doh! Sorry about that. It's now fixed. Dan
Comments: Doh! Sorry about that. It's now fixed. Dan
↧
Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]
When using the -Patch parameter of Execute-MSI, the full path to the patch is not listed (e.g. the path is passed to msiexec as simply "patch.msp" instead of "d:\app\files\patch.msp"). msiexec does not like that, saying it cannot find the patch file. I notice that in the code, the full path is prepended to $path to make the $msiFile variable which is given to msiexec, but $mspFile is simply set to $patch with no path modification done. If I add similar code to prepend the full path to $mspFile, the install works.
Comments: Sorry, but no dice. Still no uninstall, the GUID is not in the commandline. > [Uninstallation] :: Get information for installed Application Name(s) [Microsoft Visio Viewer 2013]... Get-InstalledApplication 22-02-2015 20:35:27 3 (0x0003) [Uninstallation] :: Found installed application [Microsoft Visio Viewer 2013] version [15.0.4569.1506] exactly matching application name [Microsoft Visio Viewer 2013] Get-InstalledApplication 22-02-2015 20:35:28 3 (0x0003) [Uninstallation] :: Remove application [Microsoft Visio Viewer 2013 ]. Remove-MSIApplications 22-02-2015 20:35:28 3 (0x0003) [Uninstallation] :: Resolve product code to a publisher, application name, and version. Execute-MSI 22-02-2015 20:35:28 3 (0x0003) [Uninstallation] :: Get information for installed Product Code [{95150000-0052-0409-1000-0000000FF1CE}]... Get-InstalledApplication 22-02-2015 20:35:28 3 (0x0003) [Uninstallation] :: Found installed application [Microsoft Visio Viewer 2013] version [15.0.4569.1506] matching product code [{95150000-0052-0409-1000-0000000FF1CE}] Get-InstalledApplication 22-02-2015 20:35:28 3 (0x0003) [Uninstallation] :: Get information for installed Product Code [{95150000-0052-0409-1000-0000000FF1CE}]... Get-InstalledApplication 22-02-2015 20:35:29 3 (0x0003) [Uninstallation] :: Found installed application [Microsoft Visio Viewer 2013] version [15.0.4569.1506] matching product code [{95150000-0052-0409-1000-0000000FF1CE}] Get-InstalledApplication 22-02-2015 20:35:29 3 (0x0003) [Uninstallation] :: Executing MSI action [Uninstall]... Execute-MSI 22-02-2015 20:35:29 3 (0x0003) [Uninstallation] :: [msiexec.exe] successfully resolved to fully qualified path [C:\Windows\system32\msiexec.exe]. Execute-Process 22-02-2015 20:35:29 3 (0x0003) [Uninstallation] :: Check to see if mutex [Global\\_MSIExecute] is available. Wait up to [10 minutes] for the mutex to become available. Test-MsiExecMutex 22-02-2015 20:35:29 3 (0x0003) [Uninstallation] :: Mutex [Global\\_MSIExecute] is available. Test-MsiExecMutex 22-02-2015 20:35:29 3 (0x0003) [Uninstallation] :: Working Directory is [C:\Windows\system32] Execute-Process 22-02-2015 20:35:30 3 (0x0003) __[Uninstallation] :: Executing [C:\Windows\system32\msiexec.exe /x "" REBOOT=ReallySuppress /QN /L*v "C:\Windows\Logs\Software\MicrosoftCorporation_MicrosoftVisioViewer2013_15.0.4569.1506_Uninstall.log"]... Execute-Process 22-02-2015 20:35:30 3 (0x0003)__ [Uninstallation] :: Execution complete and the exit code [1619] is being ignored Execute-Process 22-02-2015 20:35:31 3 (0x0003)
Comments: Sorry, but no dice. Still no uninstall, the GUID is not in the commandline. > [Uninstallation] :: Get information for installed Application Name(s) [Microsoft Visio Viewer 2013]... Get-InstalledApplication 22-02-2015 20:35:27 3 (0x0003) [Uninstallation] :: Found installed application [Microsoft Visio Viewer 2013] version [15.0.4569.1506] exactly matching application name [Microsoft Visio Viewer 2013] Get-InstalledApplication 22-02-2015 20:35:28 3 (0x0003) [Uninstallation] :: Remove application [Microsoft Visio Viewer 2013 ]. Remove-MSIApplications 22-02-2015 20:35:28 3 (0x0003) [Uninstallation] :: Resolve product code to a publisher, application name, and version. Execute-MSI 22-02-2015 20:35:28 3 (0x0003) [Uninstallation] :: Get information for installed Product Code [{95150000-0052-0409-1000-0000000FF1CE}]... Get-InstalledApplication 22-02-2015 20:35:28 3 (0x0003) [Uninstallation] :: Found installed application [Microsoft Visio Viewer 2013] version [15.0.4569.1506] matching product code [{95150000-0052-0409-1000-0000000FF1CE}] Get-InstalledApplication 22-02-2015 20:35:28 3 (0x0003) [Uninstallation] :: Get information for installed Product Code [{95150000-0052-0409-1000-0000000FF1CE}]... Get-InstalledApplication 22-02-2015 20:35:29 3 (0x0003) [Uninstallation] :: Found installed application [Microsoft Visio Viewer 2013] version [15.0.4569.1506] matching product code [{95150000-0052-0409-1000-0000000FF1CE}] Get-InstalledApplication 22-02-2015 20:35:29 3 (0x0003) [Uninstallation] :: Executing MSI action [Uninstall]... Execute-MSI 22-02-2015 20:35:29 3 (0x0003) [Uninstallation] :: [msiexec.exe] successfully resolved to fully qualified path [C:\Windows\system32\msiexec.exe]. Execute-Process 22-02-2015 20:35:29 3 (0x0003) [Uninstallation] :: Check to see if mutex [Global\\_MSIExecute] is available. Wait up to [10 minutes] for the mutex to become available. Test-MsiExecMutex 22-02-2015 20:35:29 3 (0x0003) [Uninstallation] :: Mutex [Global\\_MSIExecute] is available. Test-MsiExecMutex 22-02-2015 20:35:29 3 (0x0003) [Uninstallation] :: Working Directory is [C:\Windows\system32] Execute-Process 22-02-2015 20:35:30 3 (0x0003) __[Uninstallation] :: Executing [C:\Windows\system32\msiexec.exe /x "" REBOOT=ReallySuppress /QN /L*v "C:\Windows\Logs\Software\MicrosoftCorporation_MicrosoftVisioViewer2013_15.0.4569.1506_Uninstall.log"]... Execute-Process 22-02-2015 20:35:30 3 (0x0003)__ [Uninstallation] :: Execution complete and the exit code [1619] is being ignored Execute-Process 22-02-2015 20:35:31 3 (0x0003)
↧
Source code checked in, #99a1f4d5d25d1bc07861917d81a4cb6461d2cb8e
Final attempt to fix Execute-MSI before I pull my hair out :(
↧
↧
Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]
When using the -Patch parameter of Execute-MSI, the full path to the patch is not listed (e.g. the path is passed to msiexec as simply "patch.msp" instead of "d:\app\files\patch.msp"). msiexec does not like that, saying it cannot find the patch file. I notice that in the code, the full path is prepended to $path to make the $msiFile variable which is given to msiexec, but $mspFile is simply set to $patch with no path modification done. If I add similar code to prepend the full path to $mspFile, the install works.
Comments: Okay this has gotten embarrassing. No more code changes when I'm not entirely paying attention. Definitely resolved: ``` <![LOG[[Initialization] :: Executing [C:\WINDOWS\system32\msiexec.exe /x "{A95EA7C4-90C2-4462-8C5E-827A2FB20FA1}" REBOOT=ReallySuppress /QN /L*v "C:\WINDOWS\Logs\Software\PSAppDeployToolkit_TestInstallation(Testing)[Testing]_1.0.0_Uninstall.log"]...]LOG]!><time="15:07:43.601-300" date="02-22-2015" component="Execute-Process" ``` Can you verify I haven't broken anything else in Execute-MSI? I fully expect to be given out to by the other devs for making silly mistakes :( Thanks, Dan
Comments: Okay this has gotten embarrassing. No more code changes when I'm not entirely paying attention. Definitely resolved: ``` <![LOG[[Initialization] :: Executing [C:\WINDOWS\system32\msiexec.exe /x "{A95EA7C4-90C2-4462-8C5E-827A2FB20FA1}" REBOOT=ReallySuppress /QN /L*v "C:\WINDOWS\Logs\Software\PSAppDeployToolkit_TestInstallation(Testing)[Testing]_1.0.0_Uninstall.log"]...]LOG]!><time="15:07:43.601-300" date="02-22-2015" component="Execute-Process" ``` Can you verify I haven't broken anything else in Execute-MSI? I fully expect to be given out to by the other devs for making silly mistakes :( Thanks, Dan
↧
New Post: invoke a reboot after installation
I am also attempting to do this... I have added this to my Deploy-Application.ps1
##*===============================================
##* POST-INSTALLATION
##*===============================================
[string]$installPhase = 'Post-Installation'
## <Perform Post-Installation tasks here>
__Show-InstallationRestartPrompt -NoCountdown
↧
New Post: -ShowInstallationRestartPrompt -NoCountdown not visiable Version 3.5
Instead of changing it this way you only need to change this line (Change File to Command)
Line 5458 Version 3.5.0
Line 5458 Version 3.5.0
Start-Process -FilePath "$PSHOME\powershell.exe" -ArgumentList "-ExecutionPolicy Bypass -NoProfile -NoLogo -WindowStyle Hidden -File `"$scriptPath`" -ReferringApplication `"$installName`" -ShowInstallationRestartPrompt $installRestartPromptParameters" -WindowStyle Hidden -ErrorAction 'SilentlyContinue'
Start-Process -FilePath "$PSHOME\powershell.exe" -ArgumentList "-ExecutionPolicy Bypass -NoProfile -NoLogo -WindowStyle Hidden -Command `"$scriptPath`" -ReferringApplication `"$installName`" -ShowInstallationRestartPrompt $installRestartPromptParameters" -WindowStyle Hidden -ErrorAction 'SilentlyContinue'↧
New Post: Invoking Show-InstallationRestartPrompt
↧
↧
New Post: Show-InstallationProgress Delayed on PowerShell 3.0 and 4.0
I've got the same issue. I get overlapping Show-InstallationProgress windows. Power shell 2 is fine.
↧
New Post: BlockExecution still enabled after the installation
As I wrote in a previous post - try to use the full process name WITH the file extension. I.e. "chrome.exe" or "iexplore.exe".
↧
Commented Unassigned: FEATURE REQUEST: Execute-MSI -LoggingOptions parameter [167]
I noticed today that it's not possible to change the logging options for singular executions of Execute-MSI
the -LogName parameter allows for specifying a differently named logfile. Could a -LoggingOptions parameter allow for overriding the value of MSI_LoggingOptions from AppDeployToolkitConfig.xml?
Example function call would then be
```
Execute-MSI -Action "Install" -Path "my.msi" -LogName "mylog.log" -LoggingOptions "\Leai+"
```
or perhaps
```
Execute-MSI -Action "Uninstall" -Path "my.msi" -LogName "mylog.log" -LoggingOptions "eai+"
```
Haven't written implementation code yet for this in the framework, but it should be similar to the code for the -LogName parameter.
Comments: It's been added in the latest source code. Dan
the -LogName parameter allows for specifying a differently named logfile. Could a -LoggingOptions parameter allow for overriding the value of MSI_LoggingOptions from AppDeployToolkitConfig.xml?
Example function call would then be
```
Execute-MSI -Action "Install" -Path "my.msi" -LogName "mylog.log" -LoggingOptions "\Leai+"
```
or perhaps
```
Execute-MSI -Action "Uninstall" -Path "my.msi" -LogName "mylog.log" -LoggingOptions "eai+"
```
Haven't written implementation code yet for this in the framework, but it should be similar to the code for the -LogName parameter.
Comments: It's been added in the latest source code. Dan
↧