Wer heutzutage eine IT-Infrastruktur in den eigenen Räumlichkeiten (on-premises) betreibt, wird in den meisten Fällen auf die Virtualisierung setzen. Wenn wir hierbei auf das Microsoft-Produktportfolio blicken, lockt die Virtualisierung mit Hyper-V-Technologie. In vielen Fällen werden dann zur Erhöhung von Redundanz und Verwaltbarkeit Windows Failover Cluster mit Hyper-V eingesetzt.

Bei der Konkurrenz ist zum Beispiel VMware vSphere mit ESXi als Virtualisierer weit verbreitet – ebenfalls meist hochverfügbar ausgelegt (High Availability, HA).

Beim Betrieb von virtuellen Maschinen (VMs) besteht in der Betriebspraxis oftmals ein Interesse daran, Kontrolle darüber zu haben, in welcher Reihenfolge VMs starten (oder "failovern"). Weil es eben oft Abhängigkeiten der VMs untereinander gibt: Die Funktion eines SQL-Datenbank-Servers zum Beispiel hängt von einem betriebsbereiten Domain Controller (DC) ab. Ein Applikationsserver mag wiederum von SQL-Servern abhängen.

Unter Hyper-V gibt es in der grafischen Verwaltungsoberfläche (Failover Cluster Manager, FCM bzw. Hyper-V Manager) ein paar Möglichkeiten, Einfluss auf den Start von VMs bzw. im Falle eines Failovers auf einen anderen Knoten (Node) im Cluster zu nehmen.

Diese "Start Priority" bietet aber in der GUI nur recht wenige Optionen zur Ausgestaltung. Entweder stuft man die Start-Prio der VM als High, Medium oder Low ein oder man verzichtet auf den automatischen Start der VM gänzlich. Über die PowerShell kann man zwar hier die Abstufung der Priorität auch granularer wählen – aber welche VMs nun Voraussetzung für den erfolgreichen Betrieb anderer VMs sind, lässt sich auch damit bei mehr als einer Hand voll VMs kaum sinnvoll regeln.

Bei der VMware-Konkurrenz bieten sich in der entsprechenden GUI (vCenter) da mehr Möglichkeiten, um auch Abhängigkeiten von VMs untereinander zu modellieren.

Selbst in den neueren Versionen des Windows Servers bleiben den Administratoren in der GUI solcherlei weitergehende Eingriffsmöglichkeiten verwehrt. Und neidisch schielt man auf die Konkurrenz. Es gibt aber durchaus eine – u. a. durch Nicht-Sichtbarkeit in der GUI wenig beachtete – Möglichkeit, hier präzisere Stellschrauben zu benutzen: Schon seit Windows Server 2016 gibt die PowerShell da ein logisches Konstrukt her, mit dem man dem Hyper-V-Cluster in Bezug auf diese Modellierung auf die Sprünge helfen kann. Das Stichwort heißt hier: ClusterGroupSet.

Die Dokumentation dazu ist dürftig, die Logik etwas sperrig und die Nomenklatur eigenwillig. Wenn man die vor allem zu Beginn so störenden Hürden aber überwindet, hat man durchaus ein nützliches Werkzeug an der Hand.

Wie funktioniert das also nun? Die Idee basiert auf den ClusterGroupSets und der ClusterGroupSetDependency. Im Kommandozeilen-Cluster-Sprech sind VMs (bzw. das, was VMs im Cluster ausmacht) eigentlich ClusterGroups. Da hier der Begriff der Group im Cluster also schon reserviert ist, heißen die Gruppierungen, die wir hier und jetzt betrachten eben ClusterGroupSets. Diese Sets beinhalten die ClusterGroups (die VMs) als Mitglieder. So gesehen steckt man nun also VMs in diese Sets. Mit den zugehörigen Dependencies lassen sich nun die Abhängigkeiten abbilden. Dazu gibt man bei der ClusterGroupSetDependency für ein ClusterGroupSet einen "Provider" an. Mit Provider ist hier konkret dasjenige ClusterGroupSet gemeint, von dem das mittels Provider konfigurierte nun denn abhängen soll. Am besten ein Beispiel: Sieben VMs, nämlich drei DCs (DC01 bis DC03), zwei SQL-Server (SQL01, SQL02), zwei AppServer (AppSrv01 und AppSrv02). Die beiden App-Server hängen von den SQL-Server-VMs ab und diese wiederum von mindestens zwei der drei DC-VMs.

Im Bild die zugehörigen PowerShell-Befehle:

Wir erstellen zuerst die "Gruppierungen", also die ClusterGroupSets, wie zum Beispiel die DomainControllers. Dann stecken wir die VMs, repräsentiert durch die "Group", in das jeweils passende Set hinein.

Zuletzt geben wir an, dass das Set für die AppServers von dem Set für die SQLServers abhängt und dieses wiederum von den DomainControllers. Die Abhängigkeiten und die logische Verschachtelung sind damit gebaut.

Nun noch ein paar Details: StartupDelayTrigger und StartupCount. Die Option "Delay" beim Trigger bedeutet, dass auf den Heartbeat gewartet wird – und dann erst die Zeit für den Delay (StartupDelay) zum Start abhängiger Sets losläuft. Die Option "online" beim Trigger bedeutet, dass es bereits dann weitergehen darf, wenn die VM-Rollen überhaupt erfolgreich gestartet wurden, aber ebenfalls erst nach Ablauf eines StartupDelay.  Beim ein oder anderen mag das nicht dem ersten Instinkt zur Bedeutung der Optionen entsprechen.
Die Anzahl beim StartupCount gibt für das Set an, wie viele der enthaltenen VMs zur Erfüllung der Regeln laufen müssen.

Hier im Beispiel also sollen zwei der drei DCs laufen, um als ausreichend vollständig laufendes Set zu gelten. Es empfiehlt sich, zumindest für das letzte Set in der Kette der Abhängigkeiten diesen Wert auf die Anzahl der enthaltenen VMs zu setzen, um das recht eigenwillige Verhalten beim Starten der zweiten AppServers-VM zu vermeiden. Die genaue Logik dahinter wird bestimmt wohlbegründbar sein, scheint aber wohl anfangs schwer zu durchschauen.

Für eigene Tests sei empfohlen, auf dem Beispiel aufzubauen.

Nun das Resultat im einfachsten Szenario also im Bild: Wenn alles ausgeschaltet ist und wir schalten über den FCM eine der AppServers-VMs (z. B. AppSrv01) ein, dann startet diese zunächst nicht direkt, sondern wirft zuerst das Set am Ende der Abhängigkeitskette mit den DCs an. Noch laufen ja nicht ausreichend viele.  Da das ganze Set gestartet wird, werden kurz danach im Allgemeinen also drei DCs laufen. Das sind genug zur Erfüllung der Regeln für dieses Set. Dann starten, nach einem (einstellbaren) Verzug von 20 Sekunden (so der Default für den StartupDelay) auch die SQL-Server-VMs. Wenn beide laufen, darf dann auch der AppSrv01 wirklich starten... so soll es sein.

Fazit:

Microsoft sorgt durch Weglassen eines GUI-Zugriffs und bestenfalls mäßige Dokumentation durchaus selbst dafür, dass die ClusterGroupSets weniger bekannt oder in Vergessenheit geraten sind. Ob das Zeichen für technische Schwierigkeiten MS-seitig bei der Umsetzung sind oder man gar überhaupt auf das Feature setzen sollte, mag sicherlich kontrovers diskutiert werden. Wer auf eine genauere Regelung der Startreihenfolge von VMs im Cluster Wert legt, sollte sich aber ruhig einmal mit den Möglichkeiten rund um dieses Feature durch Testing beschäftigen und entscheiden, ob dies zur produktiven Nutzung in der eigenen Hyper-V-Welt in Frage kommt.

Wer das zum Einsatz vorsieht, sollte aber über etwas Frustrationstoleranz verfügen und die Admin-Kollegen mit einbeziehen: Wenn man VMs im Cluster starten möchte, und stattdessen starten andere (nur manchmal genau diejenige nicht, die man wollte), rauft man sich schnell die Haare, wenn man so gar nicht ahnt, wo das Verhalten herkommt.

Viel Erfolg bei eigenen Experimenten!

In vielen Unternehmen haben sich über die letzten 30 Jahre große Datenmengen (Dateien) auf File-Servern angesammelt. Solche File-Server wurden klassischerweise hoch bewertet, da hier zentral gemeinsame Unternehmensinformationen abgelegt und von vielen Mitarbeitern genutzt wurden. Nach mehreren Jahren Nutzung präsentieren sich File-Server aber wegen gewachsener Freigabe- und Berechtigungsstrukturen und eingeschränkter Mobilität oft eher als Datengräber denn als Informationsquellen. Die Auffindbarkeit von Informationen mit der konventionellen Suche im File-Explorer wirkt stark eingeschränkt oder so langsam, dass sie irgendwann nicht mehr genutzt wird.

Für eine Modernisierung fehlt oft die Idee. Wie sollen große File-Server auf moderne Cloud-Dienste abgebildet werden? Besondere Hemmschuhe sind:

• Inklusiv-Angebote von SharePoint Online reichen meist nicht für alle Dateien aus.
• Im MS365-Umfeld werden heute gänzlich neue Authentifizierungs- und Transportprotokolle genutzt und es ist unklar, wie diese mit klassischen Nutzungsformen in Einklang zu bringen sind.
• Die Menge der Daten steht im Missverhältnis zu den vorhandenen Internet-Bandbreiten.
• Die Kosten für Cloud-Speicher liegen vermeintlich deutlich höher als für lokalen Speicher.

Unternehmen, die ihre File-Server nicht auf Cloud-Techniken hin adaptieren, sind in der Regel in einer endlosen Hybrid-Situation gefangen. Sie müssen zwei Welten parallel betreiben und absichern. Die Effizienzgewinne der SAAS-Strategie in MS365 können so niemals vollständig realisiert werden.

SharePoint Online oder Azure Files?

Im MS365-Kosmos steht nun neben SharePoint Online als modernem Dokumenten- und Informationsspeicher auch Azure Files als Cloud-basierter File-Service zur Verfügung. Die beiden Lösungen kommen, wenn sie als File-Services genutzt werden, jedoch mit recht unterschiedlichen Vor- und Nachteilen daher:

Im Vergleich der beiden Varianten kann erkannt werden, dass mit SharePoint Online das modernere Werkzeug für die Dateiverwaltung bereitgestellt wird. Insbesondere die Informationssuche und die Mobilität sind wichtige Pluspunkte. Aktiv genutzte Office-Daten sind hier sicherlich optimal aufgehoben.

Aber SharePoint Online ist leider nicht die Antwort auf alle Fragen zur Ablösung von File-Services durch Cloud-Angebote. Azure Files stellt hier eine zusätzliche Microsoft-Option für den Übergang in die Cloud dar, mit der viele Sondernutzungsformen abgedeckt werden können:

Fazit

Viele Unternehmen besitzen „riesige“ File-Server, die einen Übergang von „alt“ (Active Directory) auf „neu“ (Azure AD) maßgeblich behindern. Für große File-Server fehlt eine Idee für deren Umsetzung auf Cloud-Lösungen. Mit SharePoint Online und Azure Files stehen zwei recht komplementäre Lösungsoptionen für File-Services in der Microsoft-Cloud zur Verfügung. Es wird erwartet, dass durch diese komplementären Ansätze für einen Großteil der Nutzer und Nutzungsformen eine Umstellung auf Cloud-Lösungen machbar ist. Daten sollten entsprechend SharePoint Online und Azure Files aufgeteilt und den Nutzern damit effizient online zur Verfügung gestellt werden.

Also: Ran ans Werk und raus aus der Hybrid-Schleife! Internet-Bandbreite wird immer günstiger und Lösungsoptionen sind vorhanden. Unternehmen, die MS365-Services nutzen, sollten versuchen, ihre File-Server mittelfristig und sukzessiv auf MS365-Dienste abzubilden.

Arbeiten von überall mit Azure Virtual Desktop

Immer mehr Unternehmen nutzen Remote Desktop-Umgebungen, um ihren Mitarbeitern standortunabhängiges, komfortables und performantes Arbeiten zu ermöglichen. Solche Lösungen bieten vor allem den Vorteil, dass die Geräte der Mitarbeiter günstig und leicht auszutauschen sind. Diese Thin-Clients minimieren den Verwaltungsaufwand, da alle wichtigen Daten und Anwendungen auf den zentral Session-Hosts verwaltet werden. Diese Architektur schützt vor Datenverlust, weil die Dokumente, die in der Cloud liegen, von dort automatisch und redundant gesichert werden können.

Eine cloud-basierte Variante dieser Remote Desktop-Umgebungen ist Azure Virtual Desktop (AVD) von Microsoft. Durch den großen Funktionsumfang und die Einstellungsmöglichkeiten ist die Konfiguration einer AVD-Umgebung nicht trivial. Deshalb wollen wir im Folgenden zeigen, worauf Sie bei der Erstellung und Verwendung einer AVD-Umgebung achten sollten.

Warum Azure Virtual Desktop?

Mit AVD bietet Microsoft eine weitaus flexiblere Remote-Desktop-Lösung als Windows 365, Citrix oder VMware. Die Flexibilität besteht insbesondere in einer genauen Anpassbarkeit der Server, den sogenannten Session Hosts, an die Bedürfnisse der Nutzer. Im Gegensatz zu Microsofts zweiter virtual Desktop Lösung, Windows 365, bei der nur eine eingeschränkte Auswahl an VM-Konfigurationen zur Verfügung steht, kann bei AVD fast jede Azure VM-Konfiguration ausgewählt werden. So können, laut Microsoft, Rechner mit besonders hohem Arbeitsspeicher oder einer leistungsfähigen Grafikkarte für CAD- und Videoschnitt bereitgestellt werden. Es können auch die Hardwarekosten von Thin-Clients reduziert werden, da alle rechenintensiven Prozesse von den Session-Hosts übernommen werden.

AVD bietet die Möglichkeit, entweder einen kompletten virtuellen Desktop oder nur einzelne Applikationen bereit zu stellen. Das Verbindungs-, Lasten- und Speicherverwaltung wird komplett von AVD übernommen. Des Weiteren gibt es beispielsweise die Option, zwischen verschiedenen Algorithmen zum Lastenausgleich zu wählen.

Folgendes Schaubild erläutert den kompletten Aufbau und Verwaltungsbereiche einer AVD-Umgebung.

Eine weitere Stärke von AVD ist die optionale Multisessionskalierung. Mehrere Nutzer können sich einen Host teilen, sodass bereits wenige leistungsstarke Hosts ausreichen, um vielen Benutzern die Arbeit von überall zu ermöglichen. Zur Optimierung der Kosten können weitere Hosts, je nach Bedarf und Auslastung, automatisiert ein- und ausgeschaltet werden.

Ein solcher AVD-Skalierungsplan ist in vier Phasen unterteilt: Ramp-up, Peak hours, Ramp-down und Off-Peak hours. Diese Phasen werden der obigen Reihenfolge nach durchlaufen und es kann eingestellt werden, zu welchen Uhrzeiten in die nächste Phase gewechselt werden soll. Die Ramp-up Phase dient dazu, zusätzliche Hosts hochzufahren, um direkt ausreichend viele Sessions, ohne Wartezeit für die User, während der Peak hours bereitstehen. Während des Ramp-downs wird die Anzahl der aktiven Session-Hosts sukzessive reduziert. Hierbei kann ausgewählt werden, ob die User zwangsweise ausgeloggt werden oder nur Hosts ohne aktive Sessions heruntergefahren werden. Während der Off-Peak Hours stehen keine oder nur ein Mindestmaß an Hosts zur Verfügung, sodass Kosten eingespart werden können. Die Skalierung erfolgt in allen vier Phasen immer anhand der prozentualen CPU-Auslastung der Session-Hosts. Die Schwelle lässt sich dabei individuell festlegen, allerdings ist die Schwelle bei Ram-up und Peak hours bzw. bei Ramp-down und Off-Peak hours immer gleich.

Bei dieser Skalierungsmethode muss vorher abgeschätzt werden, wie viele Hosts vorhanden sein müssen, da durch den automatisierten Skalierungsplan keine neuen Session-Hosts erstellt werden können. Sind also alle vorher erstellten Maschinen voll ausgelastet, werden keine neuen Verbindungen mehr zugelassen. Allerdings können nachträglich manuell weitere Session-Hosts hinzugefügt werden.

Erstellen eines AVD-Hostpools

Zum Bereitstellen einer AVD-Umgebung muss zuerst ein Host-Pool und ein Workspace erstellt werden. Beide können mit demselben Einrichtungsassistenten im Azure Portal konfiguriert werden. Bevor der Assistent gestartet wird, müssen, falls nicht vorhanden, eine Ressourcengruppe und ein virtuelles Netzwerk erstellt werden, da dies im Assistenten nicht möglich ist. Um den Host-Pool und einen Workspace zu erstellen, wird einfach „Create Hostpool“ im AVD-Bereich ausgewählt. Neben den üblichen Einstellungen wie Azure Region Name und Resource Group muss entschieden werden, ob die Session-Hosts von mehreren Usern (Multisession) oder nur von einem Nutzer verwendet werden sollen. Bei der multisession Nutzung kann des Weiteren der Loadbalancing-Algorithmus und die maximale Anzahl an Sessions eingestellt werden.

Als Nächstes werden die Session-Hosts erstellt. Dies läuft fast genauso ab, wie bei normalen Azure VMs. Allerdings wird hier zusätzlich die Anzahl und ein Namenspräfix angegeben, sodass mehrere gleiche VMs mit durchnummerierten Namen erstellt werden können. Die Session-Hosts können direkt ins (Azure) Active Directory eingebucht werden und im Falle des Azure Active Directory optional auch direkt in Intune eingebucht werden. Damit ist eine nachträgliche zentralisierte Verwaltung der Session-Hosts möglich.

Zuletzt kann noch eine standard Desktop App Group zu einem Workspace hinzugefügt werden und, wenn noch keiner existiert, dieser auch erstellt werden. In App Groups werden User und Gruppen zusammengefasst, die Zugriff auf bestimmte AVD-Applications wie z.B. den AVD-Desktop haben. (Diese User müssen zusätzlich die Virtual Machine User Login Rolle auf den jeweiligen Session Hosts zugewiesen bekommen, da sonst der Zugriff verweigert wird).

Wenn alles konfiguriert ist, kann der Hostpool erstellt werden. Dies dauert in der Regel ca. 20 Minuten.
In dieser Standardkonfiguration können nur Clients eine Verbindung über die Remote-Desktop-App aufbauen, die in derselben Azure AD-Domain wie der Host-Pool sind. Ist dies nicht der Fall oder soll die Web-App benutzt werden, muss in der RDP-Konfiguration des Hostpools „targetisaadjoined:i:1“ als „Ausschalter“ angegeben werden. Dieser Zusatz ermöglicht Verbindungen von beliebigen Geräten und stellt daher ein besonderes Sicherheitsrisiko dar. Deshalb sollte, wenn diese Variante genutzt wird, zusätzlich die MFA-Authentifizierung für die jeweiligen Benutzer eingeschaltet werden.

Fazit

AVD ist vor allem für maßgeschneiderte Szenarien eine gute Lösung. Zusätzlich können selbst kleine Remote Desktop-Umgebungen schnell und ohne teure Hardwareanschaffungen erstellt werden. So können auch zeitlich begrenzte Bereitstellungen effizient und vergleichsweise günstig ermöglicht werden. Allerdings kann die Einrichtung, durch die vielen Optionen, leicht komplex werden. An dieser Stelle unterstützen wir Seitens ITERACON gerne.

Früher waren Mandatory Profiles ziemlich beliebt. Sie wurden häufig in Bildungseinrichtungen oder Kioskumgebungen verwendet oder überall dort, wo die Kopie des Benutzerprofils bei der Abmeldung verworfen werden musste. Auf diese Weise wurde sichergestellt, dass alle Benutzer den gleichen Desktop vorfinden, unabhängig davon, was sie während der Sitzung mit ihrem Profil gemacht haben.

Die Anforderung

Das Ziel ist es, ein Profil für Schulungszwecke zu erstellen, welches administrative Berechtigungen hat und vorgenommene Einstellungen nach der Abmeldung verwirft. Zusätzlich sollen die Computer das Profil über Intune erhalten und dieses dort verwaltbar sein.

Vorbereitung des Windows Standardprofil

Ausgangspunkt für ein Mandatory Profile ist ein Standardprofil. Das Standardprofil wird in zwei unabhängig voneinander stattfindenden Prozessen vorbereitet, der Audit Modus zum Vorbereiten des Profils und Windows Assessment and Deployment Kit zum Erstellen einer Antwortdatei (unattend.xml). Um ein Mandatory Profile zu erstellen ist eine VM oder ein PC notwendig mit einem Windows 10/11 Image. Dieser Beitrag basiert auf einer Hyper-V VM mit Windows 10 Pro 21H2.

Audit Modus

Im ersten Fenster der Out-of-Box Experience kann der Audit Modus gestartet werden mit der Tastenkombination Strg + Shift + F3. Die VM startet im Anschluss mit dem vordefinierten Administrator in den Windows Desktop mit offenem System Preparation Tool Fenster. Dieses Fenster kann vorerst geschlossen werden.

Jetzt beginnt die Anpassung des zukünftigen Mandator Profile z.B. mit dem Ändern des Desktophintergrunds, Startmenüs oder der Installation von Programmen oder Treibern.

Windows Assessment and Deployment Kit

Parallel zum Erstellen des Windows Profils muss eine Antwortdatei (unattend.xml) erstellt werden. Dies geschieht mit dem Windows Assessment and Deployment Kit.

Um eine unattend.xml Datei für Windows 10 zu erstellen ist eine install.wim Datei notwendig. Diese ist auf dem Installationsmedium unter \sources zu finden und wird in das Windows Assessment and Deployment Kit eingebunden.

Nun kann die Komponente amd64_Microsoft-Windows_Shell-Setup ausgewählt werden, womit das Standardprofil erstellt wird.

Im Beispiel des Beitrags muss nur CopyProfile auf true gesetzt werden, um die vorgenommenen Einstellungen aus Schritt 2.1 in das Standardprofil zu übernehmen.

Die fertige unattend.xml Datei ist im folgenden Screenshot zu sehen:

Sysprep

Nun werden die beiden Schritte auf der VM zusammengeführt. Die unattend.xml wurde dazu unter C:\ abgelegt und mit folgendem PowerShell Command ausgeführt:

c:\windows\system32\sysprep\sysprep.exe /oobe /generalize /reboot /unattend:c:\unattend.xml

Extrahieren des Profils

Nach einem Neustart der VM befindet man sich erneut in der OOBE, die diesmal durchgeklickt werden muss. Auf dem Desktop angekommen kann mit dem Extrahieren des Profils begonnen werden. In den erweiterten Systemeinstellungen ist die Exportfunktion zu finden.

Das Profil wird als profile.v6 nach C:\tmp kopiert. Wichtig ist, dass die Berechtigungen für „Jeder“ gesetzt werden sowie „Verbindliches Profil“ angeklickt wird.

Im angegebenen Pfad ist eine versteckte Datei ntuser.dat zu finden. Hier muss die Endung in .man angepasst werden um das Profil als Mandatory zu definieren.

Dieses Profil kann nun genutzt werden, um es mit Intune zu verteilen.

Vorbereitung Intune Softwarepaket

Das Intune Paket wurde mit dem PowerShell App Deployment Toolkit erstellt, welches in einem früheren Beitrag ausführlich beschrieben wurde. https://blog.iteracon.de/softwarepaketierung-mit-dem-powershell-app-deployment-toolkit/

Im Pre-Installation Bereich wird der Profilordner des Mandatory Profile unter C:\tmp angelegt. Dazu wurden folgende Befehle hinterlegt:

Im zweiten Schritt muss ein lokaler Benutzer angelegt werden, der dieses Mandatory Profile nutzt. Mit den folgenden Befehlen wird das Anlegen des Benutzers initiiert:

Im Beispiel wurde der MandatoryAdmin als lokaler Administrator mit Passwort123! angelegt und diesem das Profil von C:\tmp zugewiesen.

Das Ergebnis

Das Profil kann als erforderliche oder optionale Installation zugewiesen werden. Das fertige Softwarepaket in Intune sieht nun wie folgt aus:

Der zeitliche Aufwand zum Erstellen des Mandatory Profile beläuft sich auf ungefähr einen Arbeitstag.

Die Verwaltung von Endgeräten ist für viele Firmen ein zentraler Bestandteil der Tätigkeiten in der IT. Dafür existieren verschiedene Lösungen von Gruppenrichtlinienobjekte (Group Policy Object, GPO) über SCCM hin zu Tools von Drittanbietern. In der klassischen Arbeitswelt, in dem der Benutzer primär in einem Standort der Firma arbeitet, hat sich stark gewandelt und stellt die etablierten Lösungen vor neue Herausforderungen, da die Verwaltung oft eine Verbindung zu lokalen Servern und Netzwerken voraussetzt.

Microsoft Intune

Mit Intune hat Microsoft eine cloudbasierte Geräteverwaltung entwickelt, die zu den Herausforderungen des mobilen Arbeitens passt. Microsoft Intune stellt standortunabhängig Profile, Konfigurationen und Applikationen bereit, um eine komfortable, flexible und sichere Verwaltung zu gewährleisten. Dies erfordert grundsätzlich keine lokale Infrastruktur. Intune unterstützt dabei sowohl die klassische Geräteverwaltung (MDM), als auch die Verwaltung einzelner Applikationen (MAM). Weiterhin werden alle gängigen Betriebssysteme (Windows, iOS, Android, macOS) abgedeckt.

Lizenzen

Für die Nutzung von Microsoft Intune werden Benutzerkonten im Azure AD benötigt, die entweder direkt im Azure AD erstellt oder über Azure AD aus einem Windows Server AD (über Azure AD Connect) synchronisiert wurden. Intune ist ein Dienst rund um Microsoft 365 und wird pro Benutzer lizensiert. Die Microsoft Intune Lizenz wird optimal durch Azure AD Premium P1 ergänzt, sodass die automatischen Registrierungsfunktionen, sowie die fortgeschrittene Gruppenverwaltung, zur Verfügung stehen. Intune ist ebenfalls Bestandteil von Microsoft 365 Lizenzpaketen und ist möglicherweise bereits in Ihrem Unternehmen lizensiert.  Intune ist in folgenden Lizenzpaketen enthalten:

• Intune
• Microsoft 365 E3/E5
• Enterprise Mobility +Security E3/E5
• Microsoft 365 F1/F3
• Microsoft 365 Business Premium

Wege, Geräte in Intune zu registrieren

1. Bring your own device (BYOD)

Bring your own device steht stellvertretend für die Registrierung von Geräten, die bisher nicht von der Organisation verwaltet werden. Die Registrierung findet manuell durch den Benutzer am Gerät statt. Anschließend werden alle zugewiesenen Richtlinien und Applikationen angewandt. Die Geräte führen dabei einen „Azure AD Join“ durch. Für diese Art der Verwaltung ist keine lokale Infrastruktur erforderlich. Die bestehenden Konten und deren Berechtigungen bleiben bestehen, sodass der Benutzer in der Regel lokaler Administrator ist. Der Benutzer, sowie der Intune-Administrator kann die Verbindung zu Intune und damit die Anwendung von Richtlinien jederzeit entfernen. Dieser Weg funktioniert auch für Geräte, die mit der Domäne verbunden sind, ist allerdings nicht empfohlen.

2. Azure AD Hybrid Join für existierende AD joinend devices

Eine Registrierung für Geräte, die Mitglied der Domäne der Organisation sind, bietet sich der Weg über Azure AD Connect inklusive Hybrid Azure AD Join an. Dabei werden die Computer Objekte in das Azure AD synchronisiert. Die Benutzer müssen ebenfalls synchronisiert werden. Die Registrierung in Intune wird durch eine Gruppenrichtlinie auf die Hybrid Azure AD Joined Geräte ausgelöst. In diesem Fall gelten die Geräte als unternehmenseigen und die Entfernung der Verwaltung durch den Benutzer kann unterbunden werden. Außerdem werden sowohl Gruppenrichtlinien als auch Richtlinien aus Intune angewandt. Konflikte gilt es dabei zu vermeiden. Dieser Weg ist empfohlen für die Migration von bestehenden Domänen-Geräten in Intune. Der Prozess ist automatisiert und der Benutzer bekommt in der Regel nichts von dem Prozess mit. Eine Anmeldung funktioniert mit dem UPN und mit dem SAM-Account Name, wie es die Nutzer gewohnt sind.

3. Windows AutoPilot (Azure AD join)

Geräte, die sich im Auslieferungszustand befinden (neu, neu installiert, zurückgesetzt) können über Windows AutoPilot direkt im Azure AD und in Intune registriert werden. AutoPilot ist ein Bereitstellungsprozess, der in Windows 10/11 integriert ist und in Intune über Bereitstellungsprofile konfiguriert wird. Dabei werden Geräte vor der Provisionierung in Azure vorregistriert. In dem AutoPilot-Prozess wird das Gerät in Intune durch die Benutzeranmeldung registriert und alle zugewiesenen Richtlinien und erforderlichen Applikationen werden angewandt, bevor der Benutzer das Gerät verwenden kann. Dadurch wird ein konformer Einsatz des Geräts von Beginn an sichergestellt. Dieser Prozess kann von dem Benutzer eigenständig und unabhängig vom Standort durchgeführt werden. Es ist nur eine Internetverbindung erforderlich. Dadurch kann ein neues Gerät zum Beispiel direkt zum Anwender geschickt werden und die IT entsprechend so entlasten. In dem AutoPilot Profil kann eingestellt werden, ob der Benutzer lokaler Administrator ist oder Standardbenutzer sein soll. Dieser Weg eignet sich besonders für Geräte, die vollständig in Intune verwaltet werden und keine Domänenmitgliedschaft erfordern.

4. Windows AutoPilot (Hybrid Azure AD Join)

Falls eine Domänenmitgliedschaft der Geräte zwingend erforderlich ist (Gerätegruppen-basierte Authentifizierung, Co-Management, erforderliche GPO, etc.) unterstützt AutoPilot einen Hybrid Azure AD Join. Dafür wird ein Connector lokal installiert, über welchen Intune das Gerät, zusätzlich zum Azure AD Join, in eine Organisation Unit (OU) schreibt. Azure AD Connect synchronisiert das Gerät dann und schließt den Hybrid Azure AD Join ab. Für die Einrichtung ist zusätzlich die Erreichbarkeit des Domänencontrollers nötig. Eine Registrierung ist damit nicht mehr ohne weiteres vom Standort unabhängig möglich. Ansonsten gelten die allgemeinen Vor- und Nachteile des Azure AD Hybrid Join, wie oben beschrieben.

5. Co-Management (SCCM & Intune)

Für Organisationen, die bereits System Center Configuration Manager einsetzen und nicht direkt zu Intune migrieren möchten, hat Microsoft Co-Management implementiert. Dabei werden die Geräte sowohl in SCCM, als auch in Intune verwaltet. Dafür müssen die Geräte Azure AD Hybrid Joined sein. Entweder über Azure AD Connect für Domänengeräte oder mittels AutoPilot Hybrid Join und Installation des SCCM Client über Intune. Im Co-Management kann pro Workload entschieden werden, ob dieser von SCCM oder von Intune verwaltet werden soll.

• Compliance policies
• Windows Updates
• Endpoint Protection
• Device Configuration
• Office Click-to-Run apps
• Client Apps

Fazit

Es gibt verschiedene Möglichkeiten bestehende und neue Geräte in die Verwaltung mit Microsoft Intune zu bringen, um die cloud-native zukunftssichere Geräteverwaltungsfunktionen zu nutzen. Sie benötigen Hilfe bei Entwicklung einer passenden Strategie oder bei der Einrichtung von Microsoft Intune?

Wir unterstützen Sie und finden gemeinsam die passende Lösung. Sprechen Sie uns gerne an!