Commented Issue: REQUEST: default value for -Action parameter in Execute-MSI [161]

February 18, 2015, 12:12 pm

≫ Next: Closed Unassigned: Typo in Remove-RegistryKey [160]

≪ Previous: Edited Issue: REQUEST: default value for -Action parameter in Execute-MSI [161]

$

0

0

ran in to a small annoyance today where I had forgotten to specify the -Action Install parameter on an Execute-MSI function call.

I would advocate that putting the default value of the $action variable to __"Install"__ instead of __$null__ might be a good idea?
This would prevent the script failing. Now I got this behaviour:

Executing [msiexec.exe "<path to msi>" /L*v ".log"]...

So no /i and no name for the log, which causes the parameters dialog for msiexec.exe to pop up, and the script to hang..

EDIT: I just noticed that the latest version of the toolkit made the -Action parameter mandatory, but I would still like to put my approach forward as an alternative.
Comments: This has been done in the latest source, will be included in 3.6.0

---

Closed Unassigned: Typo in Remove-RegistryKey [160]

February 18, 2015, 12:14 pm

≫ Next: New Post: Using PSAT on Servers, Is PS 2.0 ok?

≪ Previous: Commented Issue: REQUEST: default value for -Action parameter in Execute-MSI [161]

$

0

0

The word __key__ should be removed. Otherwise we have 2 parameters used to specify the affected registry key

Please change:
```
.PARAMETER Name
Name of the registry key value to delete.
```

to:
```
.PARAMETER Name
Name of the registry value to delete.
```



Comments: Fixed in latest source

New Post: Using PSAT on Servers, Is PS 2.0 ok?

February 18, 2015, 12:19 pm

≫ Next: Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

≪ Previous: Closed Unassigned: Typo in Remove-RegistryKey [160]

$

0

0

Can you indicate what the issues might be? 2.0 should be fully supported for the current release. If there's a problem we should investigate.

Thanks, Dan

Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

February 18, 2015, 12:43 pm

≫ Next: Source code checked in, #6e4da2e68ecf765adaa7086e66162b9fcf14ae80

≪ Previous: New Post: Using PSAT on Servers, Is PS 2.0 ok?

$

0

0

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: Unfortunately, it's still not working for me. I'm calling Execute-MSI like so: ``` Execute-MSI -Action Install -Path 'rta.msi' -Parameters 'RTA_SETUP_TYPE=RTAClient RTA_SRVR_NAME=142.192.71.240 /qn' -Patch 'RTA7.5.360.msp' ``` And the log file says: ``` [Installation] :: Executing [C:\Windows\system32\msiexec.exe /i "D:\New RTA\Files\rta.msi" PATCH="RTA7.5.360.msp" RTA_SETUP_TYPE=RTAClient RTA_SRVR_NAME=142.192.71.240 /qn /L*v "C:\Windows\Logs\Software\rta_Install.log"]... [Installation] :: Get message for exit code [1635]. [Installation] :: Execution failed with exit code [1635]: This patch package could not be opened. Verify that the patch package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer patch package. ```

Source code checked in, #6e4da2e68ecf765adaa7086e66162b9fcf14ae80

February 18, 2015, 1:56 pm

≫ Next: Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

≪ Previous: Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

$

0

0

Remove previous modification and add extra logging

Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

February 18, 2015, 2:45 pm

≫ Next: Commented Unassigned: Get-UniversalDate from AppDeployToolkitMain.ps1 fails [165]

≪ Previous: Source code checked in, #6e4da2e68ecf765adaa7086e66162b9fcf14ae80

$

0

0

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: Can you redownload and try this again? Specifically we're looking for anything that specifies the working directory. It's working perfectly in all my testing here which, apart from a different path, is identical to your command line. Thanks, Dan

Commented Unassigned: Get-UniversalDate from AppDeployToolkitMain.ps1 fails [165]

February 19, 2015, 2:28 am

≫ Next: New Post: SCCM 2012 R2 - Run Powershell script

≪ Previous: Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

$

0

0

PSADT Installations fails; it pops up an error stating that AppDeployToolkitMain.ps1 fails in line 4217 char:10

When I execute the function Get-UniversalDate from AppDeployToolkitMain.ps1 I get the error message

[17-02-2015 09:33:24.558] [Initialization] [Get-UniversalDate] :: Convert the date [02/
17/2015 09:33:24] to a universal sortable date time pattern based on the current cultur
e [da-DK]
[17-02-2015 09:33:24.624] [Initialization] [Get-UniversalDate] :: The specified date/ti
me [02/17/2015 09:33:24] is not in a format recognized by the current culture [da-DK].

Get-Culture function returns this:
LCID Name DisplayName
---- ---- -----------
1030 da-DK Danish (Denmark)

Any ideas?

The error message is continued here:
Error Record:
-------------

Message : Cannot bind parameter 'Date'. Cannot convert value "02/17/2015 09:33:
24" to type "System.DateTime". Error: "String was not recognized as a
valid DateTime."
InnerException : System.Management.Automation.PSInvalidCastException: Cannot convert v
alue "02/17/2015 09:33:24" to type "System.DateTime". Error: "String
was not recognized as a valid DateTime." ---> System.FormatException:
String was not recognized as a valid DateTime.
at System.DateTime.Parse(String s, IFormatProvider provider)
--- End of inner exception stack trace ---
at System.Management.Automation.LanguagePrimitives.ConvertViaParse
Method.ConvertWithCulture(Object valueToConvert, Type resultType, Boo
lean recursion, PSObject originalValueToConvert, IFormatProvider form
atProvider, TypeTable backupTable)
at System.Management.Automation.LanguagePrimitives.ConversionData`
1.Invoke(Object valueToConvert, Type resultType, Boolean recurse, PSO
bject originalValueToConvert, IFormatProvider formatProvider, TypeTab
le backupTable)
at System.Management.Automation.LanguagePrimitives.ConvertTo(Objec
t valueToConvert, Type resultType, Boolean recursion, IFormatProvider
formatProvider, TypeTable backupTypeTable)
at System.Management.Automation.ParameterBinderBase.CoerceTypeAsNe
eded(CommandParameterInternal argument, String parameterName, Type to
Type, ParameterCollectionTypeInformation collectionTypeInfo, Object c
urrentValue)

FullyQualifiedErrorId : CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.G
etDateCommand
ScriptStackTrace : at Get-UniversalDate<Process>, C:\Temp\PSADT\AdobeReader 11.0.
10\AppDeployToolkit\AppDeployToolkitMain.ps1: line 4211
at <ScriptBlock>, <No file>: line 1

PositionMessage : At C:\Temp\PSADT\AdobeReader 11.0.10\AppDeployToolkit\AppDeployToolk
itMain.ps1:4211 char:48
+ [string]$universalDateTime = Get-Date -Date $DateTime
-Format ($culture).Date ...
+ ~~~~~~~~~



Error Inner Exception(s):
-------------------------

Message : Cannot convert value "02/17/2015 09:33:24" to type "System.DateTime".
Error: "String was not recognized as a valid DateTime."
InnerException : System.FormatException: String was not recognized as a valid DateTime
.
at System.DateTime.Parse(String s, IFormatProvider provider)



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Message : String was not recognized as a valid DateTime.
InnerException :




The specified date/time [02/17/2015 09:33:24] is not in a format recognized by the cur
rent culture: Cannot bind parameter 'Date'. Cannot convert value "02/17/2015 09:33:24"
to type "System.DateTime". Error: "String was not recognized as a valid DateTime."
At C:\Temp\PSADT\AdobeReader 11.0.10\AppDeployToolkit\AppDeployToolkitMain.ps1:4217 ch
ar:5
+ Throw "The specified date/time [$DateTime] is not in a format recogn
ized by ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~
+ CategoryInfo : OperationStopped: (The specified d...alid DateTime.":St
ring) [], RuntimeException
+ FullyQualifiedErrorId : The specified date/time [02/17/2015 09:33:24] is not in
a format recognized by the current culture: Cannot bind parameter 'Date'. Cannot
convert value "02/17/2015 09:33:24" to type "System.DateTime". Error: "String wa
s not recognized as a valid DateTime."
Comments: I have the same problem, both on Windows 7 SP1 x64 and Windows 8.1 x64. To me, it seems to be a problem related to the object type. In AppDeployToolkitMain.ps1, line 4207 (function Get-UniversalDate) : $dateTime = [DateTime]::Parse($dateTime, $culture) If I manually try to trigger this code and then run $dateTime.getType() it returns System.Object. However, if I change the line to $dateTimeNew = [DateTime]::Parse($dateTime, $culture) and run $dateTimeNew.getType() it returns System.ValueType. I have gotten it to work by changeing the following two lines from ``` 4207: $dateTime = [DateTime]::Parse($dateTime, $culture) 4211: [string]$universalDateTime = Get-Date -Date $DateTime -Format ($culture).DateTimeFormat.UniversalSortableDateTimePattern -ErrorAction 'Stop' ``` to ``` 4207: $dateTimeNew = [DateTime]::Parse($dateTime, $culture) 4211: [string]$universalDateTime = Get-Date -Date $dateTimeNew -Format ($culture).DateTimeFormat.UniversalSortableDateTimePattern -ErrorAction 'Stop' ``` So far tested on one deployment, but will try it some more. Don't know if this is the best solution, but it does at least show that there is a problem with the object type here.

New Post: SCCM 2012 R2 - Run Powershell script

February 19, 2015, 7:22 am

≫ Next: Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

≪ Previous: Commented Unassigned: Get-UniversalDate from AppDeployToolkitMain.ps1 fails [165]

$

0

0

Hello,

With SCCM 2102 R2, it is now possible to run a powershell script in a task sequence.
Is it possible to use Deploy-Application.ps1 with this function?

I'm trying to deploy an application after the OS installation and always get this message in the smsts.log:

Module [C:_SMSTaskSequence\Packages\NBB004EB\AppDeployToolkit\AppDeployToolkitMain.ps1] failed to load:
You cannot call a method on a null-valued expression.
At C:_SMSTaskSequence\Packages\NBB004EB\Deploy-Application.ps1:81 char:3

• . $moduleAppDeployToolkitMain
• ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

Regards,
Gerald

---

Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

February 19, 2015, 8:15 am

≫ Next: New Post: Deferral and Blocked App

≪ Previous: New Post: SCCM 2012 R2 - Run Powershell script

$

0

0

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: Still no go. Redownloaded the latest version, added the Execute-MSI line as above, and I get this in the log: ``` [Installation] :: Working Directory is [D:\New RTA\Files] [Installation] :: Executing [C:\Windows\system32\msiexec.exe /i "D:\New RTA\Files\rta.msi" PATCH="RTA7.5.360.msp" RTA_SETUP_TYPE=RTAClient RTA_SRVR_NAME=142.192.71.240 /qn /L*v "C:\Windows\Logs\Software\rta_Install.log"]... [Installation] :: Get message for exit code [1635]. [Installation] :: Execution failed with exit code [1635]: This patch package could not be opened. Verify that the patch package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer patch package. ```

New Post: Deferral and Blocked App

February 19, 2015, 12:34 pm

≫ Next: Commented Unassigned: Set-ActiveSetup [163]

≪ Previous: Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

$

0

0

Hello,

I have added an application with a defer option of 3 times and also included a blocked application which can not be launched during installation. In testing I have found that if I click defer the application doesn't install (as expected). However, the blocked application still will not load. I checked the registry and under the blocked application I find the Debugger key with the value set to wscript.exe "C:\Users\Public\PSAppDeployToolkit\AppDeployToolkit_BlockAppExecutionmessage.vbs"

When a user clicks defer, shouldn't that registry key be released? I assume the registry key would be released after a successful installation but what about the deferral?

Commented Unassigned: Set-ActiveSetup [163]

February 19, 2015, 7:12 pm

≫ Next: Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

≪ Previous: New Post: Deferral and Blocked App

$

0

0

Hi,

I just notice there is nothing in the documentation about Set-ActiveSetup. I believe it should be add.

Also when you run :
Set-ActiveSetup -StubExePath "$($var_ActiveSetupFolder)\ActiveSetup.ps1" `
-Description "Configuration de $var_PackageLongName" -Key "$var_PackageLongName" -Locale 'Fr' -PurgeActiveSetupKey $true

If the active setup was not run Under a specific profile, the set-active-setup will return an error.

```
[02-14-2015 22:03:34.218] [Pre-Installation] [Remove-RegistryKey] :: Delete registry key [Registry::HKEY_USERS\S-1-5-21-784494402-3717492740-3355713634-1001\Software\Microsoft\Active Setup\Installed Components\Vcredist2005_Frv1]
[02-14-2015 22:03:34.343] [Pre-Installation] [Remove-RegistryKey] :: Failed to delete registry key [Registry::HKEY_USERS\S-1-5-21-784494402-3717492740-3355713634-1001\Software\Microsoft\Active Setup\Installed Components\Vcredist2005_Frv1].
Error Record:
-------------

Message : Impossible de trouver le chemin d'accès «HKEY_USERS\S-1-5-21-784494402-3717492740-3355713634-1001\Software\Microsoft\Active Setup\Installed Components\Vcredist2005_Frv1», car il n'existe
pas.
InnerException :

FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand
ScriptStackTrace : à Remove-RegistryKey<Process>, C:\Temp\Vcredist2005_Frv1\_Include\AppDeployToolkit\AppDeployToolkitMain.ps1 : ligne 3173
à <ScriptBlock>, C:\Temp\Vcredist2005_Frv1\_Include\AppDeployToolkit\AppDeployToolkitMain.ps1 : ligne 7675
à Invoke-HKCURegistrySettingsForAllUsers<Process>, C:\Temp\Vcredist2005_Frv1\_Include\AppDeployToolkit\AppDeployToolkitMain.ps1 : ligne 3278
à Set-ActiveSetup<Process>, C:\Temp\Vcredist2005_Frv1\_Include\AppDeployToolkit\AppDeployToolkitMain.ps1 : ligne 7676
à <ScriptBlock>, <Aucun fichier> : ligne 2

PositionMessage : Au caractère C:\Temp\Vcredist2005_Frv1\_Include\AppDeployToolkit\AppDeployToolkitMain.ps1:3173 : 6
+ Remove-Item -Path $Key -ErrorAction 'Stop' -Force | Out-Null
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

```

This error is saying "HKEY_USERS\S-1-5-21-784494402-3717492740-3355713634-1001\Software\Microsoft\Active Setup\Installed Components\Vcredist2005_Frv1», car il n'existe
pas." is not found.

I believe no error should be made if a key is not found in any profile. This is a big "mistake"

Thanks,

François
Comments: I did more test. ``` Set-ActiveSetup -StubExePath "$var_ActiveSetup83" ` -Description "Configuration de $var_PackageLongName" -Key "$var_PackageLongName" -Locale 'Fr' ``` This line will create a key Under hklm. ``` [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\Vcredist2005_Frv1] @="Configuration de Vcredist2005_Frv1" "StubPath"=hex(2):43,00,3a,00,5c,00,57,00,69,00,6e,00,64,00,6f,00,77,00,73,00,\ 5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,57,00,69,00,6e,\ 00,64,00,6f,00,77,00,73,00,50,00,6f,00,77,00,65,00,72,00,53,00,68,00,65,00,\ 6c,00,6c,00,5c,00,76,00,31,00,2e,00,30,00,5c,00,70,00,6f,00,77,00,65,00,72,\ 00,73,00,68,00,65,00,6c,00,6c,00,2e,00,65,00,78,00,65,00,20,00,2d,00,45,00,\ 78,00,65,00,63,00,75,00,74,00,69,00,6f,00,6e,00,50,00,6f,00,6c,00,69,00,63,\ 00,79,00,20,00,42,00,79,00,70,00,61,00,73,00,73,00,20,00,2d,00,4e,00,6f,00,\ 50,00,72,00,6f,00,66,00,69,00,6c,00,65,00,20,00,2d,00,4e,00,6f,00,4c,00,6f,\ 00,67,00,6f,00,20,00,2d,00,57,00,69,00,6e,00,64,00,6f,00,77,00,53,00,74,00,\ 79,00,6c,00,65,00,20,00,48,00,69,00,64,00,64,00,65,00,6e,00,20,00,2d,00,43,\ 00,6f,00,6d,00,6d,00,61,00,6e,00,64,00,20,00,22,00,43,00,3a,00,5c,00,50,00,\ 52,00,4f,00,47,00,52,00,41,00,7e,00,31,00,5c,00,50,00,4e,00,47,00,5c,00,49,\ 00,4e,00,53,00,54,00,54,00,52,00,7e,00,31,00,5c,00,54,00,72,00,6f,00,75,00,\ 73,00,73,00,65,00,73,00,5c,00,56,00,43,00,52,00,45,00,44,00,49,00,7e,00,31,\ 00,5c,00,41,00,43,00,54,00,49,00,56,00,45,00,7e,00,31,00,5c,00,41,00,43,00,\ 54,00,49,00,56,00,45,00,7e,00,31,00,2e,00,50,00,53,00,31,00,22,00,00,00 "Version"="1502,1922,0326" "Locale"="Fr" "IsInstalled"=dword:00000001 ``` But nothing Under HKEY_USer This command ``` Set-ActiveSetup -StubExePath "$var_ActiveSetup83" ` -Description "Configuration de $var_PackageLongName" -Key "$var_PackageLongName" -Locale 'Fr' -PurgeActiveSetupKey $true ``` The command will remove entry Under HKLM but will fail Under HKEY_USer as the key is not existing. This is wrong. ``` [02-19-2015 22:08:21.990] [Initialization] [Remove-RegistryKey] :: Failed to delete registry key [Registry::HKEY_USERS\S-1-5-21-784494402-3717492740-3355713634-1001\Software\Microsoft\Active Setup\Installed Components\Vcredist2005_Frv1]. Error Record: ------------- Message : Impossible de trouver le chemin d'accès «HKEY_USERS\S-1-5-21-784494402-3717492740-3355713634-1001\Software\Microsoft\Active Setup\Installed Components\Vcredist2005_Frv1 », car il n'existe pas. InnerException : FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand ScriptStackTrace : à Remove-RegistryKey<Process>, C:\Temp\Vcredist2005_Frv1\_Include\AppDeployToolkit\AppDeployToolkitMain.ps1 : ligne 3173 à <ScriptBlock>, C:\Temp\Vcredist2005_Frv1\_Include\AppDeployToolkit\AppDeployToolkitMain.ps1 : ligne 7675 à Invoke-HKCURegistrySettingsForAllUsers<Process>, C:\Temp\Vcredist2005_Frv1\_Include\AppDeployToolkit\AppDeployToolkitMain.ps1 : ligne 3278 à Set-ActiveSetup<Process>, C:\Temp\Vcredist2005_Frv1\_Include\AppDeployToolkit\AppDeployToolkitMain.ps1 : ligne 7676 à <ScriptBlock>, <Aucun fichier> : ligne 2 PositionMessage : Au caractère C:\Temp\Vcredist2005_Frv1\_Include\AppDeployToolkit\AppDeployToolkitMain.ps1:3173 : 6 + Remove-Item -Path $Key -ErrorAction 'Stop' -Force | Out-Null + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ``` Any workaround will be appreciate :)

Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

February 19, 2015, 11:57 pm

≫ Next: Created Unassigned: FEATURE REQUEST: Execute-MSI -LoggingOptions parameter [167]

≪ Previous: Commented Unassigned: Set-ActiveSetup [163]

$

0

0

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: I can confirm this behavior with the latest release. Commandline: Execute-MSI -Action Install -Path "vviewer.msi" -Transform "vviewer.mst" -Patch "vviewersp-en-us.msp" Logfile: [Installation] :: Executing [C:\Windows\system32\msiexec.exe /i "C:\Users\USER\Desktop\Microsoft Corporation Microsoft Visio Viewer 2013 v15.0.4569.1506 x64 en-US\Files\vviewer.msi" __TRANSFORMS="vviewer.mst"__ TRANSFORMSSECURE=1 __PATCH="vviewersp-en-us.msp"__ REBOOT=ReallySuppress /QB-! /L*v "C:\Windows\Logs\Software\vviewer_Install.log"]... Execute-Process 20-02-2015 08:52:51 11 (0x000B) [Installation] :: Get message for exit code [1635]. Get-MsiExitCodeMessage 20-02-2015 08:52:52 11 (0x000B) [Installation] :: Execution failed with exit code [1635]: Denne rettelsespakke kunne ikke åbnes. Kontroller, at rettelsespakken findes, og at du har adgang til den, eller kontakt programforhandleren for at kontrollere, at det er en gyldig rettelsespakke til Windows Installer. Execute-Process 20-02-2015 08:52:52 11 (0x000B)

Created Unassigned: FEATURE REQUEST: Execute-MSI -LoggingOptions parameter [167]

February 20, 2015, 4:14 am

≫ Next: Edited Unassigned: FEATURE REQUEST: Execute-MSI -LoggingOptions parameter [167]

≪ Previous: Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

$

0

0

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 for singular function calls?

Example function call would then be

```
Execute-MSI -Action "Uninstall" -LogName "mylog.log" -LoggingOptions "\Leai+"
```

or perhaps

```
Execute-MSI -Action "Uninstall" -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.

Edited Unassigned: FEATURE REQUEST: Execute-MSI -LoggingOptions parameter [167]

February 20, 2015, 4:15 am

≫ Next: Edited Unassigned: FEATURE REQUEST: Execute-MSI -LoggingOptions parameter [167]

≪ Previous: Created Unassigned: FEATURE REQUEST: Execute-MSI -LoggingOptions parameter [167]

$

0

0

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 "Uninstall" -LogName "mylog.log" -LoggingOptions "\Leai+"
```

or perhaps

```
Execute-MSI -Action "Uninstall" -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.

Edited Unassigned: FEATURE REQUEST: Execute-MSI -LoggingOptions parameter [167]

February 20, 2015, 4:19 am

≫ Next: Source code checked in, #606881782d59145ed0178865d054bcf0c301d8ea

≪ Previous: Edited Unassigned: FEATURE REQUEST: Execute-MSI -LoggingOptions parameter [167]

$

0

0

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.

---

Source code checked in, #606881782d59145ed0178865d054bcf0c301d8ea

February 20, 2015, 5:43 am

≫ Next: Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

≪ Previous: Edited Unassigned: FEATURE REQUEST: Execute-MSI -LoggingOptions parameter [167]

$

0

0

Added ability to specify multiple transforms and patches in Execute-MSI using a comma separated list

Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

February 20, 2015, 5:50 am

≫ Next: Commented Unassigned: FEATURE REQUEST: Execute-MSI -LoggingOptions parameter [167]

≪ Previous: Source code checked in, #606881782d59145ed0178865d054bcf0c301d8ea

$

0

0

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: Hey guys, I've taken a fresh stab at this and tested but would be great if you could verify. Both Transforms and patches now accept comma-separated lists, and the full path to where the MSI file resides will be added if it's not already there and it's a valid path Can you please test the latest source and let me know how it goes? Thanks, Dan

Commented Unassigned: FEATURE REQUEST: Execute-MSI -LoggingOptions parameter [167]

February 20, 2015, 6:59 am

≫ Next: Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

≪ Previous: Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

$

0

0

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: Why not just change the XML file to suit your situation? BTW: In 15 years, I've never needed to specify different logging options to MSI packages. Never mind inside the same package.

Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

February 20, 2015, 8:03 am

≫ Next: Commented Unassigned: FEATURE REQUEST: Execute-MSI -LoggingOptions parameter [167]

≪ Previous: Commented Unassigned: FEATURE REQUEST: Execute-MSI -LoggingOptions parameter [167]

$

0

0

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: With the latest version it doesn't even get to the point of launching msiexec. ``` [Installation] :: Get properties from MSI file [D:\New RTA\Files\rta.msi] in table [Property] [Installation] :: Error Record: ------------- Message : Cannot bind argument to parameter 'Path' because it is null. InnerException : FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsof t.PowerShell.Commands.TestPathCommand ScriptStackTrace : at <ScriptBlock>, D:\New RTA\AppDeployToolkit\AppDeployToolkitMain.ps1: line 1946 at Execute-MSI<Process>, D:\New RTA\AppDeployToolkit\AppDeployToolkitMain.ps1: line 1945 at <ScriptBlock>, D:\New RTA\Deploy-Application.ps1: line 119 at <ScriptBlock>, <No file>: line 1 at <ScriptBlock>, <No file>: line 1 PositionMessage : At D:\New RTA\AppDeployToolkit\AppDeployToolkitMain.ps1:1946 char:18 + If (Test-Path (Join-Path (Split-Path -Path $msiFile -Parent) $transforms[$_]) ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ```

Commented Unassigned: FEATURE REQUEST: Execute-MSI -LoggingOptions parameter [167]

February 20, 2015, 8:47 am

≫ Next: Source code checked in, #14f67e74278d017158e09712741b22736835cfd4

≪ Previous: Commented Issue: Execute-MSI: -Patch parameter does not add patch path correctly [166]

$

0

0

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: > Why not just change the XML file to suit your situation? because that would change the /L option for ALL msi installs, I just want to customise one or two commands so some commands have a less verbose log. > I've never needed to specify different logging options like I showed in my example this case was about appending multiple uninstall logs to one file using /Leai__+__ In the end it would just be an extra available parameter. No harm in that I'd say.