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 Gert in Empfang nehmen knnen 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 mglich ist - siehe Corona Lockdown. Microsofts Lsung heit Autopilot. // Was geht? Per Autopilot funktioniert der komplette Lifecycle bei Bedarf abseits von Firmenstandorten, bis hin zur direkten Lieferung des Gerts 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 kmmern. Fr die Wiederherstellung im Fehlerfall (Break Fix) wird der Computer ber Betriebssystemmechanismen zurck gesetzt und Autopilot erneut gestartet. Und Intune funktioniert ja auch ganz ohne Ivanti DSM, oder? Ja, geht. Wenn man Intune mit DSM vergleicht fllt allerdings auf, dass man da auf ganz schn viel verzichten muss. Ich erspare mir hier einen systematischen Vergleich und behaupte mal, dass man auf DSM nicht verzichten mchte. Vor allem wenn man es schon hat und nicht pltzlich "ohne alles" da stehen mchte. 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 klren ist: AAD joined oder Hybrid AAD joined? Also soll das neue Gert nur im Azure Active Directory registriert werden - AAD joined - keine Mitgliedschaft im eigenen Active Directory? Oder soll es weiterhin primr in das eigene Active Directory aufgenommen werden und parallel dazu zustzlich ins AAD? Das nennt sich dann Hybrid AAD joined. // AAD joined Insbesondere wenn man auf die Mitgliedschaft des Gerts im eigenen Active Directory verzichtet, verndert sich das Betriebmodell erheblich. Das Gert bentigt 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 Gert und das Computerkonto kann nicht auf Ressourcen berechtigt werden. Auerdem 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-Affinitt ansonsten ist, umso mehr wird man zur Hybridlsung tendieren, die ich hier allerdings nicht nher betrachte. Das heit nicht, dass sie nicht mglich wre, sie erfordert aber einen deutlich hheren Aufwand um - per VPN mit Prelogon Authentication bzw. Always-on-VPN - auch auerhalb des LANs zum passenden Zeitpunkt eine zuverlssige 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 AAD, Intune, Autopilot mssen lizenziert und konfiguriert werden. Hier gibt es zunchst 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 Gerte hinzuzufgen AAD Benutzerkonfiguration vervollstndigen 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 Gertehersteller nicht macht // DSM Webaccess Um ohne VPN den Remote-Zugriff auf DSM ber das Internet zu ermglichen, ist der Zugriff per HTTPS einzurichten. Ich nenne das gerne "DSM WebAccess". Offiziell heit das Feature "DMZ Support". Solange ich dazu keine vernnftige Beschreibung parat habe (kommt womglich demnchst), 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 mssten. Die Installation des Betriebssystems und des DSM Clients funktionieren darber nicht aber das bekommen wir ja per Autopilot und Intune bzw. mit dem Hersteller-Image. // DSM Intune Integration 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 vollstndig noch ausgereift. Es handelt sich um ein Stand heute (Anfang 2023) neues Feature, das noch einiges Entwicklungspotential hat. Vorlufig sind noch einige eigene Bemhungen 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 fr 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 Gerten zugewiesen. Soweit die DSM-Version gleich ist, wird das Intune-Paket ersetzt. Nach DSM Updates wird es parallel zu den bestehenden Intune-Paketen fr ltere DSM Clientversionen angelegt. Die Zuweisung fr das alten Pakete sind jeweils manuell zu entfernen. Alternativ kann hier sicherlich mit etwas Powershell ein eigener, leistungsfhigerer Automatismus etabliert werden. Eine Aktualisierung des DSM Client-Pakets ist nach jedem DSM-Update oder nach greren nderungen in der ICDB fllig. 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 Verschlsselung gendert werden muss. Die automatische Aktualisierung von Client und Konfiguration funktioniert ansonsten im laufenden Betrieb wie blich, insbesondere wenn man bei der Installation die Voraussetzungen fr 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 erwhnt 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 mssen. Das Original des angepassten Batches unbedingt auerhalb des DSM-Depots ablegen - es wird beim Update sonst evtl. berschrieben. Das bedeutet auch, dass das Batch nach jedem DSM-Update erneut geprft / kopiert werden muss. // Das Install-Batch kann dann z.B. so aussehen. Oder man macht es gleich richtig, sprich in Powershell. installIntune.bat // 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. // DSM Infrastrukturkonfiguration Was braucht es zustzlich an Konfiguration in DSM? Der Client befindet sich auerhalb des lokalen AD, das gleiche gilt oftmals fr Server in der DMZ. Das sind gute Grnde, mit Domnenkonten auf dem Client sparsam umzugehen, d.h. wir verwenden den SYSTEM Account fr 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 prfen, ob per Runtime Service Account auf lokale Ressourcen zugegriffen wird und auch alle Pakete mit SYSTEM testen. Fr 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 zunchst ein Problem, das man aktuell nur ber einen von Ivanti nicht supporteten Workaround lsen kann. Wenn man wie blich ein Domnenkonto als Depot Access Account whlt, dann funktioniert das mit einem AAD joined Client nicht! Workaround: lokales Benutzerkonto des Depotservers konfigurieren. Das heit 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 schn aber machbar wenn man eine bersichtliche Zahl an Depots hat und bis der Hersteller das Problem hoffentlich bald lst bzw. AAD joined Clients voll supportet. Am besten gleich den entsprechenden Feature Request auf Uservoice untersttzen! Und weil wir schon bei Problemen sind - das Update des per MSI installierten DSM Clients funktioniert aktuell - mit Version 2022.2.1 - nicht vollstndig. 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 wrde auch ein Intune-Paket funktionieren. Ich gehe davon aus, dass das Problem von Ivanti zeitnah gefixt wird. // DSM Autopilot-Prozess Wenn die Infrastruktur vorbereitet ist, kann der ganze DSM Autopilot-Prozess so aussehen: Computer in DSM registrieren. Die Registrierung funktioniert zwar auch automatisch per Autoinsert, praktischer ist aber in diesem Fall die manuelle Registrierung bzw. der DSM-Import per CSV. Computerobjekt knnen in die passende OU sowie in statische Gruppen aufgenommen werden. Auerdem knnen Properties konfiguriert werden. Das heit, das Computerobjekt ist fertig konfiguriert und kann jederzeit - sobald der Benutzer sein neues Gert in Hnden hat und beschliet es zu starten - von A-Z installiert werden. Am Ende der Installation ist das Gert fertig fr den Benutzereinsatz ohne dass ein Administrator noch etwas tun msste. Notwendig sind fr die Erstellung die MAC-Adresse und oder die SMBios GUID. Um die Zuordnung zur Autopilot-Registrierung zu erleichtern ist auch die Seriennummer ntzlich. Computer in Autopilot registrieren. Das erledigt im einfachsten Fall direkt der Hersteller oder der Microsoft Partner. Fr Bestandsgerte knnen die ntigen Informationen per Script bzw. DSM Paket gesammelt werden. Computer an das Netzwerk anschlieen und starten Im Home Office, an einem Standort oder irgendwo, wo es eine Internetverbindung gibt. Das macht typischerweise der Benutzer selbst. Beim ersten Start erscheint u.a. die per Company Branding angepasste Anmeldemaske. Der Benutzer gibt seinen Benutzernamen, typischerweise seine Mailadresse, und sein Passwort ein. Dann luft die Installation an, d.h. Autopilot installiert den DSM Client - das geht sehr schnell und direkt anschlieend installiert DSM die zugewiesenen Pakete, startet neu usw., alles wie auch im LAN blich. Nach Abschluss der Installation steht der Computer dem Benutzer zur Verfgung, d.h. der Benutzer meldet sich an, startet seine Applikationen und macht was Benutzer eben so machen - er benutzt sein Gert um seinen Job zu erledigen. Der Wechsel zwischen verschiedenen Netzen, insbesondere zwischen Home Office und Firmen-LAN funktioniert in jeder Beziehung transparent. Nur falls fr den Remote-Zugriff auf lokale Ressourcen manuell ein VPN aufzubauen ist, muss der Benutzer zwischen "Remote" und "am Standort" unterscheiden. Das lsst sich bei Bedarf ber ein Always-on-VPN lsen. Am Standort ist der Zugriff auf lokale Server jedenfalls im Regelfall transparent mglich. Hier hat Microsoft Mechanismen implementiert, die den Benutzerzugriff automatisch mit dem lokalen Active Directory Konto des Benutzers authentifizieren. Das ist natrlich, wie alles andere, zu prfen. DSM wechselt automatisch zwischen den verschiedenen DSM Standorten und verwendet automatisch u.a. das passende Depot. Genug fr einen Blogpost. Bei Fragen oder Anmerkungen bitte kommentieren oder direkt Kontakt aufnehmen. Bei Bedarf ergnze ich diesen Blogpost um Unklarheiten zu beseitigen oder einzelne Aspekte detaillierter auszuarbeiten.

zum Artikel gehen

ClickShare Videobar: Effiziente Meetings in 7 Sekunden starten

ClickShare ist eine fortschrittliche drahtlose Konferenztechnologie, die den Austausch zwischen Menschen erleichtern und eine intuitive Zusammenarbeit ermöglichen will. Mit der neuen All-in-one-ClickShare-Bar sollen unkomplizierte Drahtloskonferenzen auf

zum Artikel gehen

Troubleshooting: the Case of the missing Link

Mark Russinovich erklrt in seinen "the case of the..."-Blogposts unter anderem die IT-Probleme seiner Mutter, ich erklre meine bzw. die Probleme meiner Kunden rund um Windows und Ivanti DSM (ehemals HEAT DSM, Frontrange DSM, enteo, NetInstall).

zum Artikel gehen

Vor und nach dem Windows 10 Inplace Upgrade

Steuerung per Ivanti DSM 7 Vor dem Windows 10 Feature Update sind ein paar Vorbereitungen zu erledigen und auch danach sollte geprft und nachgearbeitet werden. Aktivierung / Deaktivierung der Verschlsselung? Deinstallation un

zum Artikel gehen

Nachhaltigkeit im Unternehmen

Warum Nachhaltigkeit für Unternehmen wichtig ist Neben einem möglichen inneren Antrieb, das Unternehmen nachhaltiger zu gestalten und der gesellschaftlichen Verantwortung nachzukommen, sprechen auch gesetzliche und wirtschaftliche Gründe für mehr Nachhalt

zum Artikel gehen

Yukatel auf der IFA 2022 in Berlin

Die IFA (internationale Funkausstellung) fand das erste mal im Jahr 1924 statt. Nun ist es endlich wieder soweit nach einem Jahr Zwangspause, welche der Corona-Pandemie geschuldet war, öffnet die Messe dieses Jahr wieder Ihre Pforten. 

zum Artikel gehen