Änderungen zur Vorgängerversion

Ausschluss von Skriptgruppen

Skripte aus dem mypackage-Portal können jetzt nicht nur einzelne Produkte und -versionen, sondern ganze Skriptgruppen ausschließen. Die Information wird in den Eigenschaften des Skripts angezeigt.

Open

Diese Funktion steht ausschließlich für Portal-Skripte und nicht für UDP’s zur Verfügung, da UDP’s nicht unbedingt eine Skriptgruppe haben.

Skriptgruppen für Einmal-Aktionen

Einmal-Aktionen können jetzt wahlweise auch eine Skriptgruppe zugewiesen bekommen.

Open

Nur wenn die Einmal-Aktion einer Skriptgruppe zugeordnet ist, kann die Reihenfolge für die Erstinstallation beeinflusst werden; legen Sie die Einmal-Aktion ohne Skriptgruppe an ist die Option im Kontextmenü nicht verfügbar.

Open

Ausführungs-Historie für Einmal-Aktionen

In der Ansicht des mypDeploy-Admin gibt es nun eine zusätzliche Registerkarte, die alle ausgeführten Einmal-Aktionen für das System anzeigt. Sie sehen nicht nur, ob eine Einmal-Aktion ausgeführt wurde, sondern auch, wann sie zuletzt ausgeführt wurde und wie häufig sie insgesamt ausgeführt wurde.

Open

Aktuelle https-Kommunikationsbibliothek

Alle mypDeploy-Komponenten haben eine aktuelle Kommunikationsbibliothek für http/https erhalten.

Menü-Erweiterungen

Im Kontextmenü eines benutzerdefinierten Skripts/Pakets oder einer benutzerdefinierten Einmal-Aktion kann nun dieses Element direkt bearbeitet werden, ohne vorher in das Register “Eigenschaften” des entsprechenden Skripts/ Pakets zu öffnen.

Open

Die einzelnen Menüpunkte sind je nach Kontext, in dem Sie sich gerade befinden (Skript/Paket) aktiviert bzw. deaktiviert.

Neue Funktionen

Abschluss-Skripte für Pakete

Sie können einem Paket nun eine oder mehrere Abschluss-Aktionen hinzufügen. Diese Abschluss-Aktionen werden immer direkt nach der Installation des Pakets ausgeführt; unabhängig davon, ob sie bereits ausgeführt wurden oder nicht.

Diese Einstellung kann sowohl für Pakete aus dem mypackage-Portal als auch für UDPs vorgenommen werden. Öffnen Sie hierzu das Kontextmenü und wählen “Benutzerdefinierte Abschluss-Aktion”

Open

Es werden alle verfügbaren OTAs angezeigt; wählen Sie eine oder mehrere OTAs aus

Open

Die zugeordneten Abschluss-Aktionen werden anschließend in den Eigenschaften des Skripts angezeigt.

Open

Bei der Zuweisung eines Paket werden die zugeordneten Abschluss-Aktionen automatisch mit an das System geschickt.

Open

Die entsprechende Reihenfolge wird zugewiesen.

Open

Nach erfolgter Ausführung wandern die Abschluss-Aktionen wie alle anderen OTAs in die Übersicht der ausgeführten Aktionen.

Open

Gruppen-Skripte: Eintritts- und Austrittsaktionen

Sie können einer Gruppen nun Ein- und Austrittsaktionen zuweisen. Diese Funktion können Sie benutzen, um spezifische OTAs entweder in dem Moment auszulösen, indem ein Rechner Mitglied einer Gruppe wird oder wenn er die Gruppe wieder verlässt. Hierbei kann es sich sowohl um automatisch zugeordnete Gruppen handeln als auch um Gruppen, in die manuell Rechner aufgenommen bzw. entfernt werden. Diese Funktion kann für regelbasiertes proaktives Management von Rechnern (“Hast du weniger als x% Plattenkapazität wirst du Mitglied der Gruppe und führst ein Skript zur Festplattenbereinigung aus”) oder auch für spezielle Aktionen für bestimmte Standorte zur automatischen Ausführung (bei Bedarf auch mehrfach) genutzt werden.

Die Bearbeitung von Gruppen hat hierzu ein neues Register erhalten.

Open

Sie wählen aus, ob Sie eine Ein- oder Austrittsaktion hinzufügen möchten

Open

und wählen dann eine vorhandene OTA aus.

Open

Diesen Schritt können Sie mehrmals ausführen. Schließen Sie den Dialog werden die zugeordneten Ein- und Austrittsaktionen in den Eigenschaften der Gruppe angezeigt.

Open

Sobald nun ein Computer manuell oder aufgrund automatischer Zuordnung Mitglied der Gruppe wird werden ihm die Eintrittsaktionen zur sofortigen Ausführung zugewiesen

Open

und nach erfolgter Ausführung in die Übersicht der ausgeführten Aktionen übernommen.

Open

Entfernen Sie einen Computer manuell aus der Gruppe oder erfüllt er die Kriterien für die automatische Zuordnung zu dieser Gruppe nicht mehr werden ihm die Austrittsaktionen zur sofortigen Ausführung zugewiesen

Open

und nach erfolgter Ausführung in die Übersicht der ausgeführten Aktionen übernommen.

Open

Das Betreten und Verlassen der Gruppe und die hieraus erfolgenden automatischen Zuweisungen werden im Protokoll des Rechners eingetragen.

Vererbung

Ein- und Austrittsaktionen werden analog zu Skripten und OTAs vererbt.

In diesem Fall

Open

wird also der markierte Rechner alle Ein- und Austrittsaktionen der Parent- und der Child-Gruppe durchlaufen.

Portal-Pakete in Einmal-Aktionen umwandeln

Pakete aus dem mypackage-Portal können bei Bedarf in eine Einmal-Aktion konvertiert werden.

Das ist erforderlich, wenn Sie

• ein Portal-Paket als Abschluss-Aktion verwenden möchten.

• ein Portal-Paket als Ein- oder Austrittsaktion verwenden möchten.

• ein Portal-Paket mehrfach ausführen wollen.

• ein Portal-Paket ausführen möchten, ohne dass es in der Paket-Historie protokolliert wird.

Beispiel: Sie konvertieren das Portal-Paket “Windows-Apps entfernen” in eine Einmal-Aktion, weil Sie es als Austrittsaktion für ein Windows-Upgradepaket ausführen möchten, um ggf. bei einem Upgrade erneut automatisch installierte Apps zu entfernen, ohne hierbei eine weitere Aktion anstoßen zu müssen.

Im Kontextmenü des Skripts können Sie die Konvertierung auswählen

Open

und festlegen, ob Sie ein mypackage-Paket in eine Einmal-Aktion konvertieren wollen oder (bei bereits erfolgter Umschaltung) die Einmal-Aktion wieder in ein reguläres Paket umwandeln wollen.

Open

In der Anzeige des Pakets sehen Sie dann ein geändertes Icon, das Sie darauf hinweist, dass es sich hierbei um ein umgewandeltes Paket handelt.

Open

Dieses Paket kann nun wie jede andere Einmal-Aktion verwendet werden.

Wenn Pakete zum Zeitpunkt der Änderung auf einzelnen Computern als installiert markiert sind, werden sie im Computer aus der Pakete-Liste entfernt und in die Einmal-Aktionen übertragen. Bei der Rück-Konvertierung wird die Einmal-Aktionsliste gelöscht. Es werden aber keine Einträge in die Paket-Liste erzeugt (da die dazu notwendigen Daten bei Einmal-Aktionen nicht vorliegen). In beiden Fällen wird dabei auf allen betroffenen Computern eine Meldung in das Log eingetragen.

BugFixes

• Es wurde ein Problem behoben, dass bestimmte Rückgabewerte aufgrund unterschiedlicher Handhabung des Vorzeichen-Bits in benutzerdefinierten Paketen nicht angelegt bzw. falsch ausgewertet werden.

• In den Eigenschaften von Paketen fehlte die Ausgabe des Headers, der eine kurze Erklärung zu dem angezeigten Objekt enthält. Der Fehler wurde behoben.

• Durch einen Fehler in der 2FA-Verwaltung ging die Registrierung eines Kontos in verschiedenen Szenarien verloren. Der Fehler wurde behoben.

• Es wurde ein Fehler behoben, bei dem unter bestimmten Umständen leere Exclude-Schlüssel für das Click-To-Run-Repository erzeugt wurde.

• Wenn ein Paket als Testpaket angelegt wurde, es aber schon eine Vorgängerversion des Paketes gab, die nicht als Testpaket markiert war, wurde die Festlegung im Dialog ignoriert und das Paket sofort auf alle betroffenen Rechner verteilt. Der Fehler wurde behoben.

• Durch einen Fehler in der Schnittstelle zur Aktualisierung von Skript-Daten konnte diese in bestimmten Versionen nicht mehr aufgerufen werden; der Fehler wurde behoben.

• Es wurden einige kleinere Probleme beim Skalieren von Fenstern im mypDeployAdmin behoben.

• Die vom Server verwaltete Gruppe Alle Computer (noch nicht registriert) enthält nur Computer ohne Client-Runtime. Das Setzen von Befehlen, Aktionen etc. in dieser Gruppe ist daher überflüssig, weil diese von Computern ohne Runtime ohnehin nicht ausgeführt werden. Der Fehler ist behoben, der Dialog Gruppe bearbeiten erlaubt für diese Gruppe nur noch die Anpassung von Name und Beschreibung.

• Einmal-Aktionen können keine benutzerdefinierten Voraussetzungen haben (da die Installation einer vorausgesetzten Software der Idee einer Einmal-Aktion widerspricht, die nur ausgeführt, aber nicht installiert wird). Die entsprechenden Einträge in den Menüs sind bei OTAs nun deaktiviert.

• Paket-Einstellungen, die für Einmal-Aktionen keinen Sinn machen, werden jetzt in den Dialogen für Einmal-Aktionen nicht mehr angeboten und in den Eigenschaften des Skriptes nicht mehr angezeigt.

Anhang: wichtige Hinweise zur Verteilung des mypDeploy-Clients über Group Policy

Sofern Sie den mypDeploy-Client über eine Group-Policy verteilen, kann es bei einzelnen Systemen unter Umständen zu Problemen beim Update kommen.

Szenario

• Die GPO installiert einen mypDeploy-Client < 3.40.88.0.

• Auf dem Rechner wird ein mypDeploy-Client in einer Version größer der aktuell per GPO bereitgestellten installiert.

• Die Group-Policy wirkt auf den Rechner erst, nachdem er einen aktuelleren mypDeploy-Client erfolgreich installiert hatte.

• Ein automatisches Self-Update für den mypDeploy-Client wird ausgeführt, nachdem der mypDeploy-Server aktualisiert wurde.

Problem

In dieser seltenen Konstellation kommt es dazu, dass die Deinstallation des mypDeploy-Clients ausgeführt wird, das Update aber mit einem Fehler scheitert (und der Rechner in mypDeploy gesperrt wird) und der Installer irrtümlicherweise glaubt, mehr als eine Version auf dem Rechner zu finden. Auch eine Reparatur oder manuelle Installation eines aktuellen mypDeploy-Clients ist nicht möglich; der Windows Installer meldet Fehlercode 1603 (Schwerwiegender Fehler bei der Installation)

Lösung

Das Installationspaket für den mypDeploy-Client hat ab Version 3.40.88.0 eine erweiterte Sperre, die die Installation/Deinstallation sofort abweist, wenn die aktuell installierte Version >= der Version des Installationspakets ist. Das ist aber leider nicht für bereits ausgerollte ältere Versionen möglich.

Bei Rechner, die Sie im mypDeploy-Admin als “gesperrt” sehen und die den entsprechenden Fehler beim Client-Update in ihr Protokoll eingetragen haben gehen Sie bitte wie folgt vor:

• Deaktivieren Sie die Group Policy zur Verteilung des mypDeploy-Clients

• Verbinden Sie sich mit dem/den Rechner(n), die keinen mypDeploy-Client mehr haben.

• Installieren Sie dort manuell den mypDeploy-Client in der Version, die Sie per Group Policy erzwungen haben.

• Entsperren Sie die Rechner in mypDeploy

• Aktualisieren Sie die MSI-Datei in der Group-Policy, bevor Sie diese wieder aktivieren.

Die Rechner werden sich dann zunächst vom mypDeploy-Server wieder den aktuellen Client installieren, sind danach aber wieder voll updatefähig. Sollte es dennoch zu Problemen kommen wenden Sie sich bitte an unseren Support.