Neu in Version 5.0

Folgende neuen Features und Fehlerbehebungen wurden in der Version 5.0 der CANCOM Packaging PowerBench implementiert:

Neue Features

Hinweis: wenn Sie bereits die Intune-Integration in einer Vorgängerversion der PPB konfiguriert haben, müssen für das Zuweisen von Paketen weitere API-Berechtigungen vergeben werden. Details finden Sie im entsprechenden Abschnitt.
  • Wird eine verfügbare Zuweisung definiert und das zugewiesene Paket löst ein anderes Paket ab, so wird die automatische Aktualisierung angeboten.
  • Der Package Subscription Service kann nun auch erstellte Pakete direkt in Intune-Mandaten registrieren und über Zuweisungsregeln gestaffelt verschiedenen Zielen zuweisen.
  • Die Sofort-Ausführung von Paketen innerhalb der PPB ist nun auch im Kontext des System-Kontos möglich.
  • Über den Tastatur-Shortcut STRG + A lässt sich nun schnell das ganze Script markieren.
  • Die Integration in DSM unterstützt nun auch andere Repositories als "Master" und Repositories, die nur eine Kopie des Paketverzeichnisses verwenden, sowohl für Paketimport als auch für Paket-Registrierung.
  • Bei der Registrierung von Paketen mit benutzerdefinierten Erkennungsregeln, werden diese zusammen mit dem Paket gespeichert und beim Aktualisieren des Pakets automatisch voreingetragen.
  • Bei der Aktualisierung von Paketen werden die bei der ursprünglichen Registrierung gesetzten Eigenschaften ausgelesen und automatisch voreingetragen.
  • Die Import Templates für Winget-Pakete wurden vollständig überarbeitet, um den erweiterten Möglichkeiten aktueller Winget-Versionen Rechnung zu tragen. Außerdem wurden die normalen Paket-Templates ebenfalls überarbeitet.
  • Ist die Signierung von Paketen aktiviert, dann werden exportierte, selbstextrahierende Paket-Executables ebenfalls automatisch mit dem konfigurierten Zertifikat signiert.


Änderungen / Erweiterungen bestehender Befehle
  • Die Auswertung der Bedingungen in If-Befehlen wird jetzt standardmäßig im Logfile protokolliert und ist daher deutlich besser nachvollziehbar.
  • Der Start-Program-Befehl erhält eine neue Option, um nicht auf die Ausführung der Befehlszeile zu warten.
  • Der Set-PdVar-Befehl hat eine neue Option, um den Variablenwert in der Anzeige zu verbergen und den Wert verschleiert im Script zu abzuspeichern.
  • Der Show-PdToastMessage-Befehl funktioniert nun auch in Paketen, die im Kontext des Systemkontos ausgeführt werden.
  • Für das Suchmuster des Search-RegistryKey Befehls können nun auch die Wildcards * und ? verwendet werden.
  • Der Exit-Package Befehl kann nun auch individuelle Exitcodes zurückgeben. Außerdem wurde der Standard-Exitcode für die Option "Als nicht ausgeführtes Paket" von 69000 auf 1602 geändert, den Standard-Returncode des PSAppDeployToolkits für das Zurückstellen eines Pakets.
  • Der Standard-Exitcode für die Option "Verschieben" des Show-ADTInstallationWelcome Befehls wurde (durch das zugrundeliegende PSAppDeployToolkit) von 60012 auf 1602 geändert. Dies wird beim Publishing nach Intune und Configuration Manager und im DSM Wrapper entsprechend berücksichtigt.


Sonstiges
  • Das Helper-Tool PAEXEC (https://www.poweradmin.com/paexec) wurde auf Version 1.31 aktualisiert.
  • Die integrierten 7-Zip Komponenten wurden auf Version 25.01 aktualisiert.
  • Das in den Runtime-Dateien enthaltene PSAppDeployToolkit wurde auf Version 4.1.8 aktualisiert.
  • Die Teams-Benachrichtigungen des Package Subscription Service wurden von Office 365 Connectors auf das Workflows App Modell umgestellt.

Hinweis: wenn Sie bereits in einer Vorversion die Benachrichtigungen über Teams konfiguriert hatten, so müssen Sie diese aktualisieren. 
  • Der DSM-Wrapper wurde überarbeitet und neue Returncodes werden korrekt verarbeitet.


Folgende Fehler und Probleme aus der Version 4.5 wurden behoben
  • Die Registrierung eines Intune-Pakets schlug fehl, falls das angegebene Package-Icon nicht im PNG-Format vorlag oder zu groß dimensioniert war.
  • Beim Löschen von Integrations-Konfigurationen konnte es vorkommen, dass die falsche Integration gelöscht wurde, falls mehrere Konfigurationen dieses Typs existierten.
  • Wurde der Dialog des Start-ProgramAs-Befehls mehrfach geöffnet, so wurde ein hinterlegtes Kennwort eines angegebenen Benutzers korrupt.
  • Unter bestimmten Umständen, z.B. wenn ein Client zwar Domänenmitglied war, die Domäne aber nicht erreicht werden konnte, wurden nicht alle Variablen aus der Datei Misc.Variables.ps1 gesetzt.
  • Wenn ein versiegeltes Paket geändert wurde und dieses dann registriert werden sollte, wurde gefragt, ob die Änderungen zuerst gespeichert werden sollten. Wenn diese Änderungen verworfen wurden, wurde das Paket geschlossen, die Package.lock Datei blieb aber erhalten und das Paket war daher gesperrt.
  • Der Package Subscription Service wurde immer als 32-Bit Prozess gestartet und musste daher mit weniger Ressourcen auskommen.
  • Wurden PPB-Pakete über den DSM-Wrapper mit DSM ausgeführt, so konnte auch ein Returncode ungleich 0 (also in der Regel ein fehlgeschlagenes Paket) dazu führen, dass die Policy-Instanz in DSM auf grün ging.
  • Wurde bei den Bedingungen Test-RegistryKey und Test-RegistryValue (über eine Variable) ein leerer Registry-Pfad angegeben, so beendete sich das Paket mit einem Fehler. Nun liefern die Bedingungen in diesem Fall einfach false.
  • Die Aktualisierung von Intune-Paketen, die als Installationsverhalten "Benutzer" eingestellt hatten, schlug mit Fehler 400 fehl.
  • Die Bedingung IsInstalledEx/IsSwPackageRevInstalled konvertierte die Prüfung auf den Computerteil mit der Prüfung auf den Benutzerteil.
  • Wenn in einem Abonnement des Package Subscription Service die Option "Neue Paketrevision anlegen, statt neues Paketverzeichnis anlegen" aktiviert war, wurden keine gültigen Paket-Revisionen angelegt.
  • Der Dateisystem-Watcher, der den Paketbaum der Packaging PowerBench aktuell hält, öffnete die vorhandenen Package.xml-Dateien exklusiv und sorgte so für Probleme, wenn mehrere Benutzer gleichzeitig mit der PPB mit einem zentralen Paketablagepfad arbeiteten.
  • Wurde ein Paket so registriert und ausgeführt, dass der Anwender die Installation sehen und mit ihr interagieren konnte, so war unter Umständen bei der Ausführung auf dem User-Desktop kurz das Aufblitzen eines Shell-Fensters.
  • Wurde in einer DSM-Integration die Option "HTTPS für Webservices verwenden" aktiviert, so wurde sich diese Einstellung nicht gemerkt.
  • Wurde bei der DSM-Registrierung eines Pakets ein bestehendes Paket in einer neuen Revision aktualisiert, so konnte diese neue Revision nicht installiert werden, weil der Datensatz noch auf das Fileset der alten Paketrevision verwies. Außerdem wurde die im Paket befindliche Deploy-Application.ps1, die aus dem verwendeten Template stammt, von der Version innerhalb des PPB-Pakets überschrieben, sodass mit der neuen Revision keine Pilot-Installationen in DSM mehr möglich waren. 
  • Die Bedingung Test-FileExists erzeugte einen Fehler, wenn nur auf das Vorhandensein eines Laufwerks geprüft wurde.
  • Die Erzeugung einer neuen Paket-Revision bei geöffneten Paketeigenschaften führte zur Korruption des Revisionszählers.
  • Die Deinstallation von Schriftarten über Uninstall-TTF beziehungsweise die Umkehrung des Install-TTF Befehls funktionierten nicht wie erwartet.
  • Registry-Befehle, die sich direkt auf HKEY_CURRENT_USER bezogen, wurden fälschlicherweise maschinenbezogen klassifiziert.
  • Die Einstellung "Die PowerShell Ausführungsrichtlinie setzen" befand sich fälschlicherweise im Abschnitt "Paket-Einstellungen" und wurde nun in den korrekten Abschnitt "Allgemeine Einstellungen" umgezogen.
  • Beim Invoke-PowerShellCode-Befehl wurden PPB-Befehle, die im Uninstall-Teil verwendet wurden, nicht ausgeführt wie erwartet.
  • Bei der Test-UserGroupMembership-Bedingung wurde ein Problem bei der manuellen Eingabe des Gruppennamens behoben.
  • Beim Aktualisieren eines DSM-Pakets als neue Revision wurden die Bedingungen für die vorhandene Installation nicht aktualisiert.
  • Die Option "Immer überschreiben" wurde bei der Konvertierung von DSM-Paketen in verschiedenen, Dateien-referenzierenden Befehlen (z.B. InstallFileList) nicht übernommen.
  • Wurde der Show-ADTInstallationWelcome-Befehl verwendet und der Benutzer schob die Ausführung des Pakets auf, so wurden trotzdem die IsInstalled-Registrywerte geschrieben und das Paket galt als installiert.
  • Wurde ein Paket exportiert, so wurde versucht, den Inhalt des Eintrags TemplateIncludePath aus der Package.xml zu integrieren, auch wenn dieser Pfad mittlerweile gar nicht mehr verfügbar war. Jetzt werden die aktuellen Common Runtime Files verwendet.
  • Die Authentifizierung gegenüber Intune mit einem Zertifikat funktionierte nicht wie erwartet.
  • Wurde der Dialog des Import-Registry Befehls nur mit einem Dateinamen (ohne Pfad) ausgefüllt, führte dies zu einer Fehlermeldung. Wurde ein Dateiname ohne Endung angegeben, ließ sich die Datei nicht öffnen.
  • Beim Import eines DSM-Pakets mit dem Befehl ChangeRegSecurity wurde der Parameter Replace nicht korrekt gesetzt.