Ivanti DSM Autopilot - Remote Grundinstallation

Die Grundinstallation von Windows Computern funktioniert per Ivanti DSM vollautomatisch per PXE, unattended Windows Setup und der nach der Betriebssysteminstallation automatisch laufenden Installationen von Treibern, Applikationen und Patches. Am Ende meldet sich der Benutzer an und - nun ja - benutzt den neu installierten Arbeitsplatz.
Alles ganz einfach, funktioniert so aber nur innerhalb des eigenen Netzwerks.

PXE braucht eine LAN-Verbindung und auch die Erstanmeldung des Benutzers erfordert den Zugriff auf einen Domain Controller.

Kein Problem wenn alle Benutzer mindestens gelegentlich mal an einem Standort sind, da ihr Gerät in Empfang nehmen können und sich auch erstmalig anmelden.

Was aber wenn Benutzer dauerhaft im Home Office oder an kleinen Standorten ohne Anbindung an das Firmennetz arbeiten? Oder wenn der Zugang zu den Standorten nicht möglich ist - siehe Corona Lockdown.
Microsofts Lösung heißt Autopilot.

Per Autopilot funktioniert der komplette Lifecycle bei Bedarf abseits von Firmenstandorten, bis hin zur direkten Lieferung des Geräts ins Home Office des Benutzers durch den Hersteller. Verbunden damit entfallen die initialen Betriebssystem- und Treiberinstallationen. Nur um die Updates dieser Komponenten muss man sich weiterhin kümmern. Für die Wiederherstellung im Fehlerfall (Break Fix) wird der Computer über Betriebssystemmechanismen zurück gesetzt und Autopilot erneut gestartet.

Und Intune funktioniert ja auch ganz ohne Ivanti DSM, oder?
Ja, geht. Wenn man Intune mit DSM vergleicht fällt allerdings auf, dass man da auf ganz schön viel verzichten muss. Ich erspare mir hier einen systematischen Vergleich und behaupte mal, dass man auf DSM nicht verzichten möchte. Vor allem wenn man es schon hat und nicht plötzlich "ohne alles" da stehen möchte.
Also doch lieber weiterhin mit Ivanti DSM:

• Autopilot registriert den Computer in Azure Active Directory und Intune
• Intune installiert den DSM Client
• DSM installiert wie üblich die zugewiesenen Pakete

Eigentlich ganz einfach.

Ein wesentlicher Punkt, der hier wie bei allen Autopilot-Installationen zu klären ist: AAD joined oder Hybrid AAD joined? Also soll das neue Gerät nur im Azure Active Directory registriert werden - AAD joined - keine Mitgliedschaft im eigenen Active Directory? Oder soll es weiterhin primär in das eigene Active Directory aufgenommen werden und parallel dazu zusätzlich ins AAD? Das nennt sich dann Hybrid AAD joined.

Insbesondere wenn man auf die Mitgliedschaft des Geräts im eigenen Active Directory verzichtet, verändert sich das Betriebmodell erheblich.
Das Gerät benötigt keinen Kontakt zum lokalen AD bzw. zu den entsprechenden Netzen mehr, es gibt dann entsprechend aber auch keine AD-Konten und -Gruppen auf dem lokalen Gerät und das Computerkonto kann nicht auf Ressourcen berechtigt werden. Außerdem gibt es keine per AD zugewiesenen Group Policies mehr. Im Gegenzug bekommt man z.B. Multifactor Authentifizierung, Conditional Access, Reporting, Intune Policies und alles, was die Cloud heute und in Zukunft bietet.
Das ist gut so wenn man einen "modern Workplace" anstrebt, d.h. wenn man sich unter anderem auf den Weg macht, Applikationen in der Cloud bzw. per HTTPS bereitzustellen.
Je geringer die Cloud-Affinität ansonsten ist, umso mehr wird man zur Hybridlösung tendieren, die ich hier allerdings nicht näher betrachte. Das heißt nicht, dass sie nicht möglich wäre, sie erfordert aber einen deutlich höheren Aufwand um - per VPN mit Prelogon Authentication bzw. Always-on-VPN - auch außerhalb des LANs zum passenden Zeitpunkt eine zuverlässige Verbindung zu einem Domain Controller herzustellen. Ohne VPN geht der hybrid Join nur im LAN und da macht Autopilot deutlich weniger Spaß.
Wir betrachten also in der Folge das AAD joined-Szenario mit Azure Active Directory, ohne das lokale AD und ohne VPN.

 AAD, Intune, Autopilot müssen lizenziert und konfiguriert werden. Hier gibt es zunächst nichts besonders, daher nur ein paar Stichpunkte und der Verweis auf die Standarddoku

• AAD Company Branding anpassen
• AAD Automatic Intune Enrollment aktivieren
• AAD Benutzern erlauben Geräte hinzuzufügen
• AAD Benutzerkonfiguration vervollständigen
• AAD Sync per Azure AD Connect einrichten
• Intune Enrollment Profile anlegen und zuordnen
• Intune Enrollment Status Page (ESP) zuordnen
• Intune Policies zuordnen
  Intune Autopilot-Registrierung - testweise bzw. falls es der Gerätehersteller nicht macht

Um ohne VPN den Remote-Zugriff auf DSM über das Internet zu ermöglichen, ist der Zugriff per HTTPS einzurichten. Ich nenne das gerne "DSM WebAccess". Offiziell heißt das Feature "DMZ Support". Solange ich dazu keine vernünftige Beschreibung parat habe (kommt womöglich demnächst), hier der Link zur offiziellen Doku:  https://help.ivanti.com/iv/help/en_US/DSM/vNow/Booklets/B_DMZ_Einleitung.htm
Man installiert mindestens einen Management Point und ein HTTP-Depot in der DMZ. Damit haben DSM Clients dann transparenten Zugriff auf die DSM Infrastruktur ohne dass sich Benutzer mit einem VPN herumschlagen müssten. Die Installation des Betriebssystems und des DSM Clients funktionieren darüber nicht aber das bekommen wir ja per Autopilot und Intune bzw. mit dem Hersteller-Image.

Die DSM Intune Integration wird genutzt um den DSM Client und die DSM Infrastrukturkonfiguration im Zuge des Autopilot-Prozesses auf die Clients zu bekommen. Die Intune Integration ist allerdings weder vollständig noch ausgereift. Es handelt sich um ein Stand heute (Anfang 2023) neues Feature, das noch einiges Entwicklungspotential hat. Vorläufig sind noch einige eigene Bemühungen und Workarounds erforderlich. Dazu gleich mehr.

Die DSM Intune Integration bietet immerhin einen Mechanismus, um per Knopfdruck automatisch das aktuelle DSM Client MSI zusammen mit der aktuellen Infrastruktur-Konfigurationsdatei (nicfgsrv.ncp) und einem Steuerbatch für Installation und Deinstallation in ein Intune-Win32-Paket gepackt in Intune bereitzustellen. Der Prozess kann aus der DSM-Konsole heraus gestartet werden - allerdings nur wenn die Konsole auf einem BLS gestartet wird.

Das Paket wird automatisch allen Geräten zugewiesen. Soweit die DSM-Version gleich ist, wird das Intune-Paket ersetzt. Nach DSM Updates wird es parallel zu den bestehenden Intune-Paketen für ältere DSM Clientversionen angelegt. Die Zuweisung für das alten Pakete sind jeweils manuell zu entfernen.

Alternativ kann hier sicherlich mit etwas Powershell ein eigener, leistungsfähigerer Automatismus etabliert werden.

Eine Aktualisierung des DSM Client-Pakets ist nach jedem DSM-Update oder nach größeren Änderungen in der ICDB fällig. Zumindest dann, wenn die alte Clientversion mit der alten Konfiguration im Intune-Paket keine Verbindung mehr zur DSM-Infrastruktur bekommt um sich automatisch zu aktualisieren, z.B. weil der Client einfach zu alt ist oder die Konfiguration der Verschlüsselung geändert werden muss. Die automatische Aktualisierung von Client und Konfiguration funktioniert ansonsten im laufenden Betrieb wie üblich, insbesondere wenn man bei der Installation die Voraussetzungen für das Autoupdate schafft (siehe unten).

Vor der Erstellung des Intune DSM Client-Pakets kann und sollte das Installationsbatch angepasst werden. Sinnvoll ist z.B. wie erwähnt das Setzen des Registry Keys, der das Update des MSI Clients durch den normalen DSM Client-Updatemechanismus erlaubt (EnforceClassicUpdate) und von OperatingSystemInstalled um DSM zu signalisieren, dass alle Policyinstanzen auf install gesetzt werden sollen. Beides macht das Handling angenehmer weil 1. die DSM Clientupdates genauso funktioneeren wie üblich und 2. weil die Reinstallation per Autopilot funktioniert, ohne in DSM extra Vorbereitungen treffen zu müssen.

Das Original des angepassten Batches unbedingt außerhalb des DSM-Depots ablegen - es wird beim Update sonst evtl. überschrieben. Das bedeutet auch, dass das Batch nach jedem DSM-Update erneut geprüft / kopiert werden muss.

Paketierung und Upload der DSM-Clientkomponenten erfolgen nach Auswahl von "DSM-Client auf Intune hochladen".

Allerdings nur wenn die DSM-Konsole auf einem BLS gestartet wird.

Was braucht es zusätzlich an Konfiguration in DSM?
Der Client befindet sich außerhalb des lokalen AD, das gleiche gilt oftmals für Server in der DMZ. Das sind gute Gründe, mit Domänenkonten auf dem Client sparsam umzugehen, d.h. wir verwenden den SYSTEM Account für den DSM Runtime Service. Das ist ohnehin die empfohlene weil sicherere Konfiguration. Wer das so noch nicht hat, kann auf SYSTEM umstellen. Vorher alle Pakete daraufhin prüfen, ob per Runtime Service Account auf lokale Ressourcen zugegriffen wird und auch alle Pakete mit SYSTEM testen.

Für den Zugriff auf das Depot verwendet man dann in allen Sites einen Depot Access Account. Vorsicht, hier gibt es 2 Stellen, an denen ein solches Konto konfiguriert wird: 1. Site, 2. Client Proxy.

An der Stelle bekommen wir zunächst ein Problem, das man aktuell nur über einen von Ivanti nicht supporteten Workaround lösen kann. Wenn man wie üblich ein Domänenkonto als Depot Access Account wählt, dann funktioniert das mit einem AAD joined Client nicht! Workaround: lokales Benutzerkonto des Depotservers konfigurieren. Das heißt man erstellt auf jedem Depotserver ein lokales Benutzerkonto, berechtigt es zum Lesen im Depotverzeichnis und auf der Freigabe und konfiguriert dieses lokale Konte dann jeweils in der DSM Site- bzw. Depotkonfiguration.
Nicht schön aber machbar wenn man eine übersichtliche Zahl an Depots hat und bis der Hersteller das Problem hoffentlich bald löst bzw. AAD joined Clients voll supportet. Am besten gleich den entsprechenden Feature Request auf Uservoice unterstützen!

Und weil wir schon bei Problemen sind - das Update des per MSI installierten DSM Clients funktioniert aktuell - mit Version 2022.2.1 - nicht vollständig. Hier hilft es die VC++ Runtime 2015 x86 zu installieren. Das funktioniert immerhin auch komfortabel per DSM-Paket, d.h. der DSM Client ist trotz Problem noch in der Lage Pakete zu installieren. Alternativ würde auch ein Intune-Paket funktionieren. Ich gehe davon aus, dass das Problem von Ivanti zeitnah gefixt wird.