New in version 3.0

The following new features and bug fixes have been implemented in version 3.0 of the Packaging PowerBench:

New features
  • You can publish packages directly from the Packaging PowerBench in Ivanti DSM and Ivanti EPM.
  • In the Registry Editor, the properties "Use 32-Bit Mode", "Restore values during Repair" and "Remove values during Uninstall" can now be inherited by subkeys.
  • The new command line parameter RestartInteractive enables the execution of PPB-packages that can interact with a logged-in user via messages even for systems that do not initially provide for this (e.g. Ivanti EPM and Microsoft Intune). 
  • When publishing packages to Microsoft Configuration Manager or Microsoft Intune, it is now possible to define custom detection methods and to specify, if the installation should be able to interact with the user (see also RestartInteractive command line parameter).
  • The PPB now writes a logfile (by default "PackagingPowerBench_<timestamp>.log" in the directory "%ProgramData%\NWC Services\Logs").
  • When publishing a package to Microsoft Configuration Manager, the return code 60001 is configured as Failed, the returncodes 69000 and 69002 (returned by the Exit-Package command) are configured as Retry and Failed, respectively. Additionally, it is now possible to specify that the generated application can be installed as part of a task sequence without being advertised.
  • Numerous commands can be created by dragging and dropping files into the script window.
  • New commands are classified automatically.
  • Due to the new variable provider concept, more variables are now available out-of-the-box.
  • You can now natively search & replace within a PPB script.
  • When installing packages with user parts, if there is a logged-in user, they are now installed for that user directly after the computer part is installed, eliminating the need for logging out and logging in, and thus running the user part via Active Setup.
  • To avoid accidental deletion of directories, you can now configure how the Packaging PowerBench should behave when selecting package directories.
  • In expert mode, the Packaging PowerBench now offers auto-completion of, among others, cmdlets, parameters, switches, paths, variables, etc. when writing PowerShell code. Also, there is now a column with the script line numbers.
  • When exporting packages to Microsoft Intune, the format of the suggested default package name can now be specified.
  • There are new settings allowing to configure the command set displayed (with Ivanti DSM aliases or not) and choosing the editor's color theme.
  • Package templates are now multilingual, so comments, messages and other arbitrary strings are replaced according to the current language setting when creating a new package.
  • A Dark Mode theme is now supplied for the script editor, which can be selected via a setting in the options.


DSM script commands that have been newly implemented


New script commands for which there is no equivalent in DSM


The following bugs and problems from version 2.1 have been fixed
  • Canceling a condition followed by OK of the If dialog caused the PPB to crash.
  • When importing a DSM package directly from the package directory, no package ID was generated (due to missing _ExpInfo.xml) and inserted in the Package.xml.
  • The first underscore in a package name was interpreted as an indicator for an access key and was therefore not displayed.
  • When importing exported DSM packages with multiple revisions, the name of the first revision (instead of the name of the last revision) was mistakenly adopted.
  • If the PowerShell execution policy was restricted by group policy and the option "Set the PowerShell execution policy to 'Bypass'" was enabled, the Packaging PowerBench could not be started anymore.
  • When importing DSM packages, a parsing error occurred under some circumstances and the package could not be imported successfully. The behavior occurred if the source eScript had an commented out command ending with "EndProc" in the eScript language in an indented block.
  • When pasting content from the clipboard, selected script lines were not replaced.
  • Various conditions (Get-DriveFreeKB, Get-FileDate, Get-FileVersion, Get-ProductVersion) generated an error if the referenced object (drive, file, directory or similar) did not exist. The behavior is now analogous to DSM, and the condition evaluates to false.
  • The Remove-File and Remove-FileList commands may not work (especially if wildcards were used for the file name(s)).
  • The New-Link command failed if a link with the same name already existed.
  • Importing a DSM package that used a variable with "(" or ")" in its name (for example, the environment variable %ProgramFiles(x86)%) caused an error.
  • When deleting a command within a block, the focus jumped back to the beginning of the block after the next mouse click.
  • When setting a variable via the Set-PdVar command, which could be interpreted as a number, it was automatically converted. This caused e.g. leading zeros to be truncated. It is now possible to set the value in quotes, then no attempt is made to interpret the content.
  • Performance and out-of-memory issues when selecting, cutting, and pasting a large number of lines have been fixed.
  • The behavior of the Read-WmiObject command and its DSM counterpart WMISimpleQuery were different if no suitable WMI object could be retrieved.
  • The Add-EnvironmentPath command added content to the path even if it already existed and used semicolons that were not required.
  • When importing a DSM package, the package property "Version" was not set in the package properties file "Package.xml".
  • When a new package revision was created, the value of the version property was not automatically incremented and thus the user part (via Active Setup) was not executed again.
  • When publishing a package exported to Intune format, the name of the .intunewin file was always changed to "IntunePackage.intunewin", making it impossible to tell in the Endpoint Manager Portal which intunewin file had actually been uploaded.
  • The change of the path variable by the Add-EnvironmentPath command were applied for the current user under certain conditions even if the command was classified machine-specific.