Mandatory Profile unter Microsoft Intune

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!

SharePoint ist ein integraler Bestandteil von Office 365 und dient als Datengrundlage für weitere Dienste wie Teams oder OneDrive, aber dennoch wird diese Lösung in den meisten Fällen weit unter dem möglichen (und bereits bezahlten) Potential verwendet.            

Die Aussage, die hierzu meist als Grund angegeben wird ist immer die gleiche:              

„SharePoint ist zu unsicher, ich habe keine Kontrolle darüber wer Daten wohin teilt“         

Aus diesen Gründen werden SharePoint Umgebungen oftmals sehr eingeschränkt verwendet und viele vorhandene Features, die nützlich für das eigene Unternehmen sein könnten, werden von Beginn an in den globalen Einstellungen blockiert.

Dieser Beitrag soll Ihnen im Folgenden zeigen, wie Ihre Bedenken mit der richtigen Planung und dem Einsatz von verschiedenen Office 365 Features zerstreut werden. Hierbei werden wir auf spezielle Features zurückgreifen, welche einfach zu implementieren sind (keine Sorge, es werden keine Daten klassifiziert). Die Features sind meist standardmäßig oder mit einer „kleinen“ Lizenz im Tenant enthalten.

Sicherheit und Inhalte teilen

Das größte Bedenken und oftmals auch das K.O. Kriterium von SharePoint ist die Sicherheit und fehlende Übersichtlichkeit der Berechtigungen, da oftmals auch der Unterschied zwischen den Berechtigungsarten nicht ganz klar ist.

SharePoint besitzt zum einen implizite Berechtigungen, die ähnlich wie beim Fileserver administrativ oder durch Seitenbesitzer verwaltet werden können. Zum anderen bietet SharePoint aber auch die Funktion „Teilen“ (Sharing), mit dieser können Benutzer Dateien direkt per Rechtsklick freigeben.  Hierbei sind die Freiheiten des Teilens und des Freigabelinks gleichzeitig Fluch und Segen. Eine wirkliche Übersicht der Zugriffe hat man hierbei nur auf Dateiebene und dadurch nur begrenzte Möglichkeiten der Überwachung und Kontrolle. Im Gegensatz dazu können implizit gesetzte Berechtigungen immer direkt auf der Seite eingesehen werden.

Da die Teilen-Funktion global auf verschiedene Stufen eingestellt werden kann, schränken viele Unternehmen die Funktion so weit ein, wie es das Unternehmen für den sichersten Bereich im SharePoint benötigt. Das Ziel dabei ist klar, die Sicherheit für diese Seite und alle weiteren Seiten zu garantieren. Allerdings wird so häufig wertvolles Potential verschenkt, da durch diese globale Einschränkung schlichtweg viele Nutzungsmöglichkeiten nicht mehr gegeben sind.

Einsatz clever genutzter Label

Die bessere Lösung bietet die Office 365 Funktion „Sensitivity labels“. Hierbei handelt es sich um eine Klassifizierungsmöglichkeit aus dem Compliance Bereich. Basierend auf dem Label pro Seite kann bestimmt werden, welche Teilen und Sicherheitseinstellungen die jeweilige Seite besitzt. Somit kann beispielsweise eine Seite mit dem Label „internal only“ auch nur intern geteilt werden, bei Bedarf sogar gar nicht. Durch die Label kann das Sicherheitslevel auf jeder Seite individuell vergeben werden. So kann die globale und universelle Einschränkung verhindert werden und die vielfältigen Möglichkeiten von SharePoint optimal genutzt werden.

Um zu entscheiden, welches Label eine Seite benötigt, sollte sich folgende grundsätzliche Frage gestellt werden:

Was ist der Zweck der SharePoint Site?

• Handelt es sich um eine interne Seite, welche auch intern keine Freigaben ermöglichen soll?
• Ist es eine Kollaborationsseite mit festgelegten, sichtbaren Gästen?
• Dient die Seite Endkunden, die nur mit einem Link Daten zur Verfügung gestellt bekommen sollen?

Basierend auf der Entscheidung sollte nun das passende Label vergeben werden.

Sicherheit gewährleisten

Dies ist alles schön und gut, es bleibt aber noch immer die Frage offen, wie garantiert werdenkann, dass gewisse Seiten auch das korrekte Sicherheitsniveau haben.

Hierbei kommen nun zwei Eigenschaften der Label ins Spiel: Das Default Label und die Label-Pflicht. Bei der Verwendung der Labels im Unternehmen kann ein Label als Standard für jede Seite definiert werden. Hier empfehlen wir für grundsätzlich die höchste Sicherheitsstufe zu wählen.

Anmerkung: Durch die Label-Pflicht muss jede Seite ein Label besitzen. Dieses Label können danach nicht einmal die Besitzer einer Ressource (einer SPO-Site oder einem Teams Team) entfernen.

Wenn mehrere Labels im Unternehmen eingerichtet bzw. verwendet werden, bestehen nun zwei Möglichkeiten, um Benutzern das Wechseln auf „liberalere“ Label zu ermöglichen.

Der direkte Ansatz, bei dem Benutzer selbst wechseln dürfen, erlaubt Ressourcenbesitzern die für sie freigegebenen Label frei zu tauschen. Bei Bedarf kann zusätzlich die Angabe einer Begründung vorausgesetzt werden. Hierbei ist zu beachten, dass eine allgemeine Label-Pflicht gilt, SharePoint verlangt also nur ein Label, wobei egal ist welches. Somit legt man an dieser Stelle das Vertrauen in die Ressourcenbesitzer. An dieser Stelle müssen Sie entscheiden, ob der Strukturansatz, den Sie verwenden, ein solches Vorgehen unterstützt (z. B. alle Ressourcenbesitzer sind Administratoren).

Bei dem indirekten Ansatz gibt man den Benutzern lediglich das minimale Label frei, wodurch selbst Ressourcenbesitzer nicht die Möglichkeit haben dieses zu entfernen. Hierbei muss das Wechseln zu einem liberaleren Label dann entweder durch einen Key-User, nach Genehmigung, erfolgen oder sogar durch die Verwendung von Microsoft Power Automate. Bei der Automatisierung könnte ein Prozess z. B. mit der Genehmigung eines Entscheidungsträgers für die Sicherheit beginnen und anschließend das gewünschte Label durch einen Service Benutzer der Seite angepasst werden.

Ich hoffe dieser Einblick in die generelle Absicherung des SharePoints konnte aufzeigen, dass ein SharePoint, sofern korrekt eingerichtet, gut verwaltbar ist und Kernfunktionen auch mit einer hohen Sicherheit verwendbar sind. Als Abschlusskommentar möchte ich an dieser Stelle kurz anmerken, dass sich der gesamte Blogartikel speziell mit der Plattformsicherheit beschäftigt hat. Eine spezialisierte Datensicherheit kann man dann durch das Klassifizieren der Daten selbst erhalten. Dies funktioniert jedoch genauso wie auf einem Standard-Fileserver und ist daher keine Spezialität von SharePoint wie das hier besprochene Teilen (Sharing).

Herausforderungen

Im Geschäftsumfeld steht man regelmäßig vor der Herausforderung, klassische Softwareapplikationen zu verteilen und aktuell zu halten. Hierbei soll der Installationsvorgang nach Möglichkeit vollständig bedienerlos, also ohne notwendige Interaktion mit dem Benutzer auskommen. Die Konfiguration der Software soll nach Möglichkeit automatisch erfolgen und die automatische Suche nach evtl. verfügbaren Updates soll möglichst unterbunden werden, um ein zentrales Management von Updates zu ermöglichen. Die für eine automatische Verteilung der Software benötigte Infrastruktur ist womöglich bereits in Form von Intune oder Microsoft Endpoint Configuration Manager vorhanden und leisten gute Dienste bei der Umsetzung der Verteilung fertiger Pakete. Jedoch fehlt diesen Systemen oft das passsende Werkzeug, um die wiederkehrenden Anforderungen einer einfachen und flexiblen Erstellung der benötigten Softwarepakete zu unterstützen. In diesem Beitrag geht es um die Vorstellung des PowerShell App Deployment Toolkit, das für diesen Zweck entwickelt worden ist und seit nunmehr einigen Jahren wertvolle Dienste im Bereich der Softwarepaketierung leistet. Anhand eines einfach gehaltenen Beispiels sollen einige Möglichkeiten aufgezeigt werden, die das Toolkit bietet. Das Deployment Toolkit ist von bemerkenswert guter Qualität, sehr ausführlich dokumentiert und erfreut sich daher großer Beliebtheit.

Erste Schritte

Dieser Beitrag verwendet Notepad++ als Beispiel für eine zu installierende Applikation, weil sich die Paketierung hierbei besonders einfach gestaltet, Notepad++ kostenlos verfügbar ist und einen recht hohen Bekanntheitsgrad besitzt. Das gezeigte Beispiel lässt sich jedoch auch auf andere Softwaretitel übertragen.

Download der benötigten Dateien

Zunächst wird die aktuelle Version des PowerShell App Deployment Toolkit heruntergeladen. Der Download wird in Form einer Zip-Datei angeboten, die zunächst in einen lokalen Ordner entpackt werden muss. Nachdem man dies erledigt hat, zeigt sich folgender Inhalt:

Das Toolkit Unterverzeichnis enthält die zentralen Dateien des PowerShell App Deployment Toolkit und dient gleichzeitig als Vorlage für zu erstellende Pakete. Die begleitende Dokumentation, die im Toolkit als PDF-Datei enthalten ist, stellt eine sehr umfangreiche Anleitung und Referenz dar, die weit über die hier vorgestellte Einführung des Toolkit hinaus geht.

Um das Beispielpaket erstellen zu können, wird natürlich auch die Installationsdatei von Notepad++ benötigt. Hierbei handelt es sich um eine vollständige Installationsdatei, die alle benötigen Quellen beinhaltet und somit vollständig offline, d. h. ohne Dateien aus dem Internet nachladen zu müssen, installiert werden kann. Falls man die Wahl hat, sollte immer ein solcher Offline Installer bevorzugt werden, da diese i. d. R. besser für eine Paketierung geeignet sind.

Vorbereitungen

Um mit der Paketierung zu beginnen, kopiert man zunächst den gesamten Inhalt des Ordners Toolkit in ein neu angelegtes Verzeichnis. In diesem Beispiel nennen wir das Verzeichnis Notepad++ - 8.4.0.0. Zum Zeitpunkt, als dieser Beitrag entstand, war 8.4 die aktuell verfügbare Version von Notepad++:

Der neu angelegte Ordner zeigt folgenden Inhalt:

• Das Unterverzeichnis AppDeployToolkit enthält die zentralen Komponenten des Toolkit, die aus einigen Skript- sowie einer Konfigurationsdatei bestehen. Außerdem enthält der Ordner eine PNG Datei, mit der sich die Darstellung zur Laufzeit des Toolkit an eigene Bedürfnisse anpassen lässt.
• Der Ordner Files ist zunächst leer und dient vereinbarungsgemäß zur Aufnahme der Quelldateien, die für die Installation der zu paketierenden Software benötigt werden, also z. B. eine MSI oder Setup.exe Datei. Bei umfangreicheren Installationen können auch mehrere Dateien oder ganze Verzeichnisstrukturen im Ordern Files enthalten sein.
• Das Verzeichnis SupportFiles ist für Dateien gedacht, die zwar nicht unmittelbar mit der Installation zu tun haben, die aber womöglich zur Konfiguration oder zum Entfernen vorhergehender Versionen benötigt werden.
• Deploy-Application.ps1 ist die Datei, mit der die eigentliche Logik der Installation festgelegt wird und in den meisten Fällen gleichzeitig die einzige Datei, die inhaltlich angepasst werden muss. Die Skriptdatei enthält bereits rund 200 Zeilen PowerShell Code, der lediglich an festgelegten Stellen ergänzt werden muss. Falls sich einem der Sinn der bereits vorhandenen Codezeilen nicht erschließt, so macht das nichts, da die wenigen Stellen, die angepasst werden müssen, auffällig markiert sind.
• Deploy-Application.exe ist eine ausführbare Datei, die im Wesentlichen das zuvor genannte PowerShell Skript Deploy-Application.ps1 zur Ausführung bringt. Vereinbarungsgemäß wird die Installation durch Ausführen von Deploy-Application.exe gestartet. Das Verhalten kann durch Kommandozeilenparameter noch beeinflusst werden, was später noch gezeigt wird.
• Bei der Datei Deploy-Application.exe.config handelt es sich um eine Konfigurationsdatei, die aus technischen Gründen erforderlich ist, hier aber nicht näher betrachtet wird.

Erstellen des Softwarepakets

Zuerst wird die heruntergeladene Setupdatei von Notepad++ in den Ordner Files kopiert:

Anschließend wird die Datei Deploy-Application.ps1 zum Bearbeiten geöffnet, z. B. mit PowerShell ISE:

Variablen

Gleich zu Beginn der Skriptdatei befindet sich ein Block mit Variablendeklarationen, der zunächst in etwa so aussieht:

Die Variablen werden für das Paket Notepad++ entsprechend wie folgt angepasst:

Die so angegeben Werte dienen nicht nur zur Dokumentation des Pakets, sie treten zusätzlich zur Laufzeit der Installation an verschiedenen Stellen wieder in Erscheinung, dazu später mehr.

Schließen von Anwendungen

Eine häufige Herausforderung beim Update einer bereits installierten Software besteht darin, zu erkennen, ob die zu aktualisierende Software womöglich gerade in Verwendung ist und beendet werden muss, bevor die Aktualisierung störungsfrei erfolgen kann. Zu diesem Zweck bietet das PowerShell Application Deployment Toolkit eine spezielle Funktion, die im Skript bereits eingebaut ist, aber noch angepasst werden muss. Etwa in Zeile 120 unterhalb des Kommentars PRE-INSTALLATION findet sich diese Zeile:

Die Funktion Show-InstallationWelcome erfüllt gleich mehrere Aufgaben, u. a. lassen sich laufende Programme erkennen und schließen. Das erneute Starten der so identifizierten Programme wird außerdem für die Dauer der Installation unterbunden. Je nachdem, wie die Ausführung des Skripts über Deploy-Application.exe gestartet worden ist, erfolgt die Aufforderung zum Schließen der Programme interaktiv oder die Programme werden im Hintergrund automatisch geschlossen. Im Falle einer interaktiven Ausführung hat der Benutzer außerdem die Möglichkeit, die Installation bis zu drei Mal hinauszuschieben. In der Skriptvorlage ist Internet Explorer als Beispiel aufgeführt, was in unserem Fall nicht viel Sinn ergibt, da wir ja Notepad++ installieren und ggf. schließen wollen. Die Skriptzeile muss also wie folgt geändert werden:

Der Name, der hier angegeben wird, muss dem Dateinamen der ausführbaren Datei entsprechen, allerdings ohne die Endung .exe. Es lassen sich hier auch mehrere Applikationen, jeweils durch Komma getrennt angeben. Zusätzlich ließe sich, mit einem Gleichheitszeichen eingeleitet, auch ein beschreibender Name angegeben werden, z. B. ‚‘winword=Microsoft Word‘.

Zur Laufzeit der Installation wird der Benutzer aufgefordert, Notepad++ zu schließen. Dieser Dialog erscheint allerdings nur dann, wenn Notepad++ tatsächlich in Verwendung sein sollte:

Die Funktion Show-InstallationWelcome lässt sich auch so verwenden, dass dem Benutzer an dieser Stelle ein Countdown angezeigt wird, nach dessen Ablauf die geöffnete Anwendung gezwungenermaßen geschlossen wird.

Deployment Modes

Das Anzeigen eines Dialogs, den der Benutzer womöglich noch interaktiv beantworten muss, entspricht nicht unbedingt den Anforderungen einer bedienerlosen Installation. Das Verhalten des Toolkit lässt sich daher beim Aufruf von Deploy-Application.exe über das Argument DeployMode steuern und den jeweiligen Anforderungen entsprechend anpassen. Folgende Deployment Modes stehen zur Auswahl:

• Interactive – Alle interaktiven Dialoge werden angezeigt. Dies ist gleichzeitig der Standard, wenn kein Deployent Mode explizit angegeben wird.
• Silent – Weitgehend alle Benachrichtigungen werden unterdrückt, außer den oben erwähnten Willkommensdialog zum Schließen laufender Anwendungen.
• NonInteractive – Keine Dialoge werden angezeigt.

Ausführen der Notepad++ Installationsdatei

Die meisten professionellen Installationsprogramme ermöglichen die bedienerlose Installation durch Angabe geeigneter Kommandozeilenparameter, die dazu führen, dass das Setup im Hintergrund ausgeführt wird, ohne dass ein Benutzer oder Administrator interaktiv in die Installation eingreifen muss. Herauszufinden, welche Kommandozeilenparameter zu diesem Zweck verwendet werden müssen, kann mehr oder weniger aufwändig sein und erfordert in aller Regel eine entsprechende Recherche. Im Falle von Notepad++ erfolgt eine bedienerlose Installation sehr einfach durch Angabe des Parameters /S auf der Kommandozeile:

npp.8.4.Installer.x64.exe /S

Diese Kommandozeile muss nun durch das Deployment Skript ausgeführt werden. Hierzu sucht man den bereits in der Vorlage vorhandenen Kommentar <Perform Installation tasks here> und fügt darunter die dargestellten Zeilen in den Skriptcode ein:

Um den Skriptcode wiederverwendbar zu gestalten, wird hier der Dateiname der Notepad++ Installationsdatei dynamisch ermittelt. Dies bietet den Vorteil, dass derselbe Skriptcode auch noch mit zukünftigen Versionen von Notepad++ funktionieren wird, ohne angepasst werden zu müssen. Die Variable $dirFiles ist eine durch das Toolkit bereitgestellte Variable und enthält zur Laufzeit des Skripts den absoluten Pfad zum weiter oben erwähnten Files Ordner.

Um die für Notepad++ notwendige Kommandozeile im Deploymentskript auszuführen, bieten sich in PowerShell verschiedene Möglichkeiten, z. B. das Cmdlet Start-Process. Das PowerShell App Deployment Toolkit bietet aber zu diesem Zweck eine eigene Funktion namens Execute-Process, die in diesem Zusammenhang einige Vorteile bietet und daher hier verwendet werden soll. Einige Vorteile, die sich bei der Nutzung von Execute-Process gegenüber nativen PowerShell Funktionen ergeben:

• Ausführliches Logging mit Umleitung der Konsolenausgaben
• Gezieltes ignorieren bestimmter Rückgabecodes mit Hilfe des Arguments -IgnoreExitCodes
• Berücksichtigung des Ordners Files zur Laufzeit, d. h. Dateien in diesem Ordner brauchen nicht mit absolutem Pfad angegeben zu werden

Bevor die Installation von Notepad++ im Rahmen des PowerShell App Deployment Toolkit zum ersten Mal getestet wird, sollte man sich zunächst isoliert davon überzeugen, dass die bedienerlose Installation an sich so funktioniert, wie erwartet. Bei umfangreichen Installationen kann es Sinn ergeben, eine VM (Virtuelle Maschine) für die Durchführung der Tests zu verwenden, die mit Hilfe von Snapshots jederzeit wieder „auf Anfang“ zurückgesetzt werden kann, also auf einen Zeitpunkt vor der Installation der zu paketierenden Software. Im Falle von Notepad++ kann aber nach einem Testdurchlauf die Software auch einfach mit Windows-Bordmitteln wieder deinstalliert werden, um den Test ggf. wiederholen zu können.

Hinzufügen einer Deinstallation

Eine Paketierung sollte nicht nur den Installationsfall berücksichtigen, sondern immer auch die Deinstallation der jeweiligen Applikation. Das Toolkit sieht hierfür die Sektion UNINSTALLATION in der Datei Deploy-Application.ps1 vor. Der Skriptcode, der für die bedienerlose Deinstallation zuständig ist, kann im Falle von Notepad++ so aussehen:

Testlauf

Um das erstellte Softwarepaket zu testen, sollte man das gesamte Paketverzeichnis auf einen Testcomputer kopieren, falls man es nicht ohnehin bereits dort entwickelt hat. Anschließend öffnet man eine PowerShell oder klassische cmd Konsole „als Administrator“, wechselt in das Paketverzeichnis und startet die Installation mit dieser Kommandozeile:

.\Deploy-Application.exe -DeploymentType Install -DeployMode Interactive

Die hier gezeigten Kommandozeilenargumente sind nur zur Anschauung erwähnt und könnten in diesem Fall sogar komplett entfallen, weil Install und Interactive die Standardwerte der jeweiligen Argumente darstellen.

Falls, wie hier angenommen, Notepad++ zum Zeitpunkt der Installation verwendet wird, erfolgt eine Aufforderung, das Programm zu schließen:

Anschließend wird während der Installation dieses Fenster angezeigt:

Bei erfolgreichem Abschluss erfolgt diese Meldung. Wie der Hinweistext vermuten lässt, kann und sollte der Wortlaut der Meldung noch angepasst werden:

Der Hinweistext befindet sich ebenfalls in der Skriptdatei Deploy-Application.ps1 in der Sektion POST-INSTALLATION:

Ein Blick in das Windows Startmenü bestätigt, dass die Installation von Notepad++ erfolgreich war:

Die Deinstallation des Softwarepakets lässt sich mit folgender Kommandozeile testen:

.\Deploy-Application.exe -DeploymentType Uninstall -DeployMode Interactive

Fehlersuche

Falls die Installation nicht erfolgreich gewesen sein sollte, bietet das umfangreiche Logging des PowerShell App Deployment Toolkit eine Möglichkeit, den Einstieg in die Fehleranalyse zu finden. Falls nicht anders konfiguriert, erstellt das Toolkit seine Logdateien im Verzeichnis C:\Windows\Logs\Software.

Der Name der Logdatei wird aus den Werten der Variablen generiert, die wir zu Beginn in der Skriptdatei eingestellt haben.

Das Problem

Bestehende Telefonanlagen oder auch der Telefonanbieter bieten selten eine einfache und schnelle Möglichkeit der Einrichtung einer eigenen Hotline. Mögliche Lösungen sind in der Regel sehr teuer und unflexibel. Personen in der Hotline können dabei z. B. häufig nicht mobil arbeiten.

So erging es auch einem unserer Kunden. Während eines Workshops zur Migration zu Exchange Online, berichtete er uns von diesem Problem.

Die Lösung

Das Unternehmen des Kunden setzt allerdings bereits seit einiger Zeit erfolgreich auf Microsoft Teams zu Kollaboration. Zusätzlich dazu erfolgt die aktuelle Migration auf Exchange Online. Da der Kunde bzw. die Mitarbeiter so bereits das Arbeiten mit Microsoft Teams gewohnt waren, empfahlen wir die Einbindung der Hotline über Microsoft Teams bzw. genauer gesagt die Microsoft Teams Telefonie zu lösen.
Der Prozess zur Einbindung und Einrichtung einer solchen Hotline ist einfach und kostengünstig realisierbar. Es müssen nur die nachfolgenden Voraussetzungen erfüllt werden.

Voraussetzungen Office 365:

• Microsoft 365 Identitäten (AD synchronisiert oder AAD only)
• Postfächer in Exchange Online oder auf einem Exchange Server 2016 im Hybrid
  (Achtung, wenn die Postfächer On-Premises liegen, gibt es Funktionseinschränkungen)
• Basis Konfiguration von den Sicherheit Feature von Office 365 (MFA, Conditional Access, etc…)
• Ein Endgerät auf dem Microsoft Teams läuft.
• Ein Microsoft Teams zertifiziertes Headset
• Eine Kreditkarte, die in Office 365 hinterlegt werden kann

Voraussetzungen Hotline:

Für jeden Benutzer der Hotline:

• Microsoft/Office 365 Lizenz die Microsoft Teams und Exchange Online enthält (z.B. O365 E3)
• Falls kein Microsoft 365 oder Office 365 E5 genutzt wird „Microsoft Teams Telefon“
• Einen Calling Plan (z. B. Microsoft 365 Domestic Calling Plan (120 min))
• Empfohlen: Audio Conferencing (wird auch für Dreierkonferenz benötigt)

Für jede Hotline/Warteschlange:

• Microsoft Teams Phone Standard - Virtual User (kostenfrei)

Einmalig für alle:

• Empfohlen: Communications Credits (hier wird die Kreditkarte hinterlegt für automatische Guthabenaufladungen.)

Die verschiedenen Lizenzen

Die Microsoft Teams Telefon Lizenz wird benötigt, um die Telefonie Funktionalitäten in Teams freizuschalten. Die sog. Calling Plans sind die Telefoneinheitenpakete von Microsoft. Diese werden benötigt, um externe Telefonate aufbauen zu können.

Die Audiokonferenzen Lizenz wird bei Dreierkonferenzen benötigt, wenn ein oder mehrere Teilnehmer/innen über das öffentliche Telefonnetz eingewählt sind. Daher empfehlen wir unseren Kunden diese ebenfalls zu lizenzieren.

Die Microsoft Teams Phone Standard - Virtual User Lizenzen werden für die Serviceaccounts benötigt. Darüber hinaus gibt es noch die Communications Credits. Hierbei handelt es sich um ein Prepaid-Guthaben, von dem die Gebühren für Anrufe ins Ausland bezahlt werden.

Die Umsetzung

Wenn alle Voraussetzungen erfüllt werden, müssen den Benutzern die beschriebenen Lizenzen nur noch entsprechend zugewiesen werden. Unsere Empfehlung: Die Lizenzierung kann einfach und schnell über Group Based Licensing verwaltet werden. Hierbei werden den Benutzern basierend auf der eigenen Gruppenmitgliedschaften automatisch die Lizenzen zugewiesen.

Im nächsten Schritt muss eine sog. Emergency address (Notfalladressen für Standorte) in Microsoft Teams eingepflegt werden. Dies kann direkt über das Microsoft Teams Admin Center oder mithilfe von PowerShell umgesetzt werden. Im Admin Center können im Anschluss direkt die notwendigen Telefonnummern beantragt werden.

Um die Administration der Warteschlange zu vereinfachen und alle verfügbaren Funktionen nutzen zu können, muss für die Hotline zwingend ein separates Team in Microsoft Teams erstellt werden. In diesem Team werden alle Benutzer der Hotline hinzugefügt.

Nun müssen noch zwei Ressourcen Accounts erstellt werden. Der erste Account ist dabei für den Auto Attendant zuständig und der zweite für die Call Queue. Beiden Accounts werden die Microsoft Teams Phone Standard - Virtual User Lizenzen zugewiesen. Zusätzlich wird ihnen eine Rufnummer zugeordnet (Dieser Schritt ist für die Call Queue optional).

Der Auto Attendant ist in unserem Szenario der Pförtner, der die Anrufe in die Call Queue lässt oder an den Anrufbeantworter weiterleitet. Zur richtigen Zuweisung müssen im Auto Attendant dazu die Geschäftszeiten der Hotline hinterlegt werden. Tipp: Es sollten auch Wochenenden und Feiertage hinterlegt werden, an denen die Hotline nicht besetzt ist. Die Einrichtung erfolgt, wie gewohnt, im Microsoft Teams Admin Center.

Nun ist die Call Queue - die eigentliche Warteschleife - an der Reihe. Hier wird konfiguriert und eingestellt, wie die Anrufe verteilt werden sollen. Wir empfehlen unseren Kunden an dieser Stelle immer die Einstellung „Attendant-Routing“. Dies bedeutet, dass beim Eingang eines neuen Anrufes alle Telefone der Hotline klingeln. Ausgenommen sind alle Benutzer, die sich in einem Telefonat oder einem Meeting befinden. Zusätzlich aktivieren wir die Einstellung, dass sich Nutzer aus der Warteschleife ausbuchen können. Im letzten Konfigurationsschritt wird eingestellt das Anrufe, die nicht innerhalb von 90 Sekunden angenommen werden, automatisch an die Voicemail des Teams weitergeleitet werden.

Das Ergebnis

Nach erfolgreicher Einbindung und Umsetzung sieht die Oberfläche für die Hotline Mitarbeiter wie folgt aus: