die „Customizing Scripts“ im SPC haben wir seinerzeit auf Basis verschiedener Kundenwünsche entworfen, um bei Bedarf während der SPC Prozesse eingreifen zu können. Zum Beispiel ist es so schon heute möglich, ein gerade nach Intune importiertes Paket in die gewünschten Verteilungsgruppen aufzunehmen - die Basis der AutoPackageRelease Skripte aus unserer Toolbox für Empirum und Intune.
Sicherlich ein tolles Feature, aber rückblickend liegt die technische Hürde für viele Kunden im Alltag zu hoch und so wird das darin liegende Potenzial nur selten vollständig ausgenutzt.
Mit den Pipelines im APC schaffen wir jetzt die Möglichkeit unterschiedlichste Customizings komplett ohne Skripting umsetzen zu können. Man kann das Pipelinekonzept also als Evolutionsstufe der „Customizing Scripts“ betrachten.
Wie im Youtube Video gezeigt, haben wir bereits eine Reihe von vorgefertigten Tasks für sie bereitgestellt, die unterschiedlichste Aufgaben innerhalb der Pipelines durchführen können - haben aber sicherlich noch Spielraum für weitere Tasks.
Um den Umstieg von „Customizing Scripts“ auf die APC Pipelines möglichst komfortabel zu gestalten deshalb nun die Fragen in die Runde:
Welche Aufgaben automatisieren sie derzeit über „Customzing Scripts“?
Wie hilfreich waren unsere Beispiele auf Github bei der Erstellung von Anpassungen?
Welche Anpassungen an den Abläufen des SPCs hätten sie in der Vergangenheit gerne vorgenommen - sind aber aus Zeitgründen nie dazu gekommen?
Guten Tag,
ich habe eine Frage zu dem zukünftigen Client. Wir setzen derzeit eine individuelle Anpassung aus Ihrem Hause ein, die Herr Geringhausen, vor längerer Zeit für uns realisiert hat und womit wir auch sehr glücklich sind. Das ganze setzt auf PowerShell, Intune und den Neo42 Client auf. Wird dies auch zukünftig vielleicht noch einfacher mit dem neuen Client realisierbar sein?
ZIEL DES CUSTOMIZINGS
Das Ziel des Customizings ist ein automatisierter Ablauf für Softwareupdates aus dem neo42 Service Portal in den Intune Tenant des Kunden.
Die Basis für das Customizing stellen die cmdlets des Service Portal Clients (SPC) sowie die Funktion Customizing Skripts dar. Weitere Interaktionen mit Intune werden über die Microsoft Graph API realisiert.
Das Customizing kann manuell über die GUI des SPCs oder über ein PowerShell Skript ausgeführt werden.
BESCHREIBUNG
ALLOWLIST
Basis für die folgenden Automatisierungen ist eine Allowlist mit Produkten. Nur Produkte, die in der Allowlist vor-kommen werden berücksichtigt. Die folgenden Informationen müssen in der Liste eingetragen werden
• • Produktname laut SPC
• • Optional: Intune Pilotgruppe
• • Intune Zielgruppe
• • Testzeitraum
AUTHENTIFIZIERUNG
• • Implementierung der Authentifizierung per Anwendungs-ID und Anwendungskennwort
• • Schutz des Kennworts per DPAPI / SecureString
• • Kein Cache des Tokens, neue Authentifizierung in jedem Aufruf
CUSTOMIZING SCRIPTS
SPC Trigger: Vor Upload in Intune
• • Es wird ein temporärer Cache mit aktuellen Smart Update Daten erstellt, dieser speichert die Vorgänger der neuen Versionen ab
• • Optional: Paketanpassungen des Kunden, wie z.B. Anpassung der CI, Askkillprocesses
SPC Trigger: Nach Upload in Intune
• • Supersedence auf die Vorgängerversion des Pakets setzen. Damit wird verhindert, dass die Pakete sich im Kreis installieren so lange die alte Version noch zugewiesen ist
• Assignments des Pakets auf die Zielgruppen erstellen. Pro Produkt ist jeweils eine von zwei verschiedenen Parametrisierungen möglich o Sofortige Zuweisung an eine Pilotgruppe und zeitverzögerte Zuweisung an eine definierbare Ziel-gruppe nach X Tagen
o Sofortige Zuweisung an die Zielgruppe
Intune Paket Automatition Beschreibung des Customizings
Scheduled Task: Abschluss Paket Lifecycle
• Anhand der Allowlist wird pro Produkt ermittelt, ob der Testzeitraum abgelaufen ist. Bei abgelaufenem Test-zeitraum: o Assignments und Supersedence der Vorgänger Software entfernen,
es freut mich natürlich zu hören, dass bei euch ein Set an Customizing Scripts im Einsatz ist, die den täglichen Betrieb um manuelle Regelaufgaben erleichtern.
Anhand der Beschreibung und unseren Aufzeichnungen dazu kann ich sagen, dass das grundsätzliche Ziel mit den Pipelines im APC natürlich weiterhin erreicht werden kann. Der Weg dorthin wird sich nur stark verändern.
Manche Schritte sind fest in das APC integriert und können über die Oberfläche konfiguriert werden - für Schritte die es nicht als konfigurierbaren Task gibt wird es die Möglichkeit geben weiterhin eigene PowerShell Skripte laufen zu lassen, die aus der Pipeline als Parameter alle notwendigen Informationen bekommen können.
Das ganze Customizing jetzt durchzuplanen würde den Rahmen sprengen, aber hier mal ein paar Beispiele:
Die Funktion der ALLOWLIST wird eine fest in das APC integrierte Ansicht sein. Man kann also über die Liste der APD Pakete in der Oberfläche definieren welche Produkte man für solche Automatisierungen betrachten möchte
Den automatischen Start des Update Prozesses muss man nicht mehr manuell über den Task Scheduler antriggern, sondern kann einen Scheduler in der APC Oberfläche konfigurieren
Die Assignments des Pakets auf die Zielgruppen sind Tasks die per Drag & Drop einer Pipeline hinzugefügt werden können
Die Supersedence auf die Vorgängerversion des Pakets haben wir noch nicht als Task geplant. Hier müsste ein entsprechender Skripting Task mit einem eigenen PowerShell Skript in der Pipeline hinzugefügt werden. Hier könnte man vermutlich viel der bestehenden Logik überführen.
Wie du siehst wird es an einigen Stellen einfacher werden das Customizing zu erstellen und im Nachgang anzupassen.
Wir verwenden aktuell noch keine Customizing Scripts, aber sobald das neue Depot steht, werde ich mich wahrscheinlich etwas mehr damit befassen. Aktuell besteht unser Update-Prozedere aus den folgenden Schritten:
Alle neuen Paketversionen werden heruntergladen und in Empirum in den Ordner _inbox-Todo importiert
Dann verschiebe ich jedes Paket in seine Gruppe
Dann passe ich das Feld Version im Produktiv- und ggf. Testpaket der Software an. Diese Pakete sind im Empirum ohne Versionsangabe im Namen bzw. der ID gespeichert. Der Pfad des Pakets ändert sich also sofort, wenn ich die Version anpasse. Das hat den Vorteil, dass die Pakete im Service Catalog nach einem Update unverändert aber immer aktuell bleiben.
Alle Clients beginnen automatisch die neuere Version zu installieren, sofern das Produktiv- oder Testpaket der Software zugewiesen ist
wir verwenden Customizing Scripts im Empirum Umfeld in Zusammenhang mit dem AutoPackageRelease um die heruntergeladenen Pakete mit weiteren Dateien (Lizenzdateien, Einstellungsdateien, …) anzureichern, um Anpassungen am Paket direkt in der Datenbank zu machen, da es für diesen Fall leider keine API gibt und um die Pakete auf unsere Umgebung anzupassen.
wir ändern den MachineKeyName und den UserKeyName, damit unsere Pakete in der Registry alle an einer Stelle sind. Leider steht nach dem Deployment in Empirum aber noch der alte Pfad in der Datenbank. Daher konnten wir zuerst das volle Potential vom AutoPackageRelease nicht nutzen, da man im Anschluss immer erst einmal Versionen abgleichen in der Empirum Management Console ausführen musste, damit auch in der Datenbank die richtigen Werte stehen. Deshalb haben wir nun ein Script, dass den Pfad direkt in der Datenbank auf den geänderten Wert umbiegt.
Falls es dafür bessere Methoden gibt immer her damit!
auch wir verwenden Customizing Scripts im Empirum Umfeld in Zusammenhang mit dem AutoPackageRelease um die heruntergeladenen Pakete mit weiteren Dateien (Lizenzdateien, Einstellungsdateien, …) anzureichern und um die Pakete auf unsere Umgebung anzupassen. Wir automatisieren damit ca. 95% unserer Software und rollen die dann auch (nach einer Testphase) Produktiv aus.
Und wir unterscheiden zwischen „Überall-Paketen“ und „Paketen, die viele Rechner haben“ 8also zweimal Autorelease mit White-Listing).