Softwarepaketierung mit dem PowerShell App Deployment Toolkit

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.

Microsoft Teams Telefonie – So richten Sie Ihre Hotline ein

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:

Es war einmal: der Gordische Doppelknoten

Bei der iteracon wurde seit der Firmengründung eine eigene IT-Umgebung mit verschiedenen Systemen wie File-/Print-Server, Exchange, Client-Management (SCCM), Skype-for-Business etc. betrieben. Traditionell wuchs die Menge der Server etwa genauso stark wie die Menge der Mitarbeiter, was für ein IT-Systemhaus vielleicht auch gar nicht so ungewöhnlich ist. Vor allem für Tests wurden immer wieder Server aufgesetzt und nach Test-Abschluss nicht unbedingt wieder zurückgebaut. So entstand über die Jahre ein solider „Gordischer Doppelknoten“ von fast 60 Servern, die alle irgendwie wichtig und alle irgendwie voneinander abhängig waren. Dabei war es gelungen, auch noch Azure, Exchange-Online und OneDrive als Cloud-Dienste in unser informationstechnisches Kunstwerk mit einzuweben. “hmm…?” sagte da der Chef, den scheinbar der hohe technische Anspruch unserer Leistung nicht recht begeistern wollte.

Als wir Anfang 2018 in die Planungen für ein neues Firmengebäude einstiegen, wurde irgendwann klar, dass der Umzug dieser IT-„Lösung“ recht aufwändig würde, weil für alle Server entsprechende Migrationsüberlegungen unter Berücksichtigung der Abhängigkeiten und Netzanbindungen anzustellen wären. Da auch die vorhandenen Computing-Ressourcen schon älter waren, wurde vom Chef die Parole ausgegeben, möglichst alles in die Cloud zu verlagern, den Umzug lokaler Systeme auf ein Minimum zu reduzieren und Investitionen in neue lokale Hardware zu vermeiden. Vor allem sollte die Verwaltung der Systeme zukünftig einfacher werden, so dass später ein standardisierter IT-Betrieb nach einfachen Regeln die frühere Verwaltung einzelner Systeme durch die jeweils dafür zuständigen Experten ersetzen würde.

Probleme? Lösungen!

Wir starteten also ein Cloud-Projekt und suchten Lösungen für unsere vorhandenen „Schätzchen“. Aus File-Server wurde SharePoint Online, aber geht das auch für alle Dateitypen? Im Prinzip ja. Die befürchteten Probleme mit nicht Cloud-fähigen Dateitypen blieben aus. Zudem haben wir Home-Shares in OneDrive abgebildet. Dank des aktuellen OneDrive Sync-Clients binden sich SharePoint und OneDrive elegant in den Explorer ein und können auch von Laien leicht bedient werden. Mobiles Arbeiten wird kinderleicht.

Aus Exchange on-premises wurde Exchange Online, wobei wir Exchange Online schon seit mehreren Jahren nutzten und im Hybrid-Modus betrieben. Das war also eigentlich nicht mehr neu. Durch den Umstieg auf einen reinen Exchange Online konnten wir jedoch nun auf alle lokalen Lösungen zum Internet-Publishing (Reverse-Proxy, split-brain DNS, Jonglieren mit öffentlichen Zertifikaten) verzichten. Es war ein befreiendes Gefühl, all diese komplexen Teillösungen inkl. der dazugehörenden Firewall-Regeln einfach abzuschalten. Zudem brauchen wir neue Mailboxen nun nicht mehr lokal anzulegen und in die Cloud zu schieben, alles geschieht online.

Wir hatten uns aus akademischem Ehrgeiz früher eine klassische Software-Verteilung mit dem MS SystemCenter Configuration Manager (SCCM) geleistet. Über diese installierten wir Windows, verteilten einige Client-Applikationen und hielten die Client-Betriebssysteme inklusive ihren Virenscannern (MS Defender) aktuell. Hier heißen die neuen Lösungen Microsoft Intune und Autopilot. Über Autopilot werden heute die Windows-Betriebssysteme selbst bereitgestellt und in einen definierten Grundzustand gebracht. Über Intune werden die Systeme dann verwaltet und abgesichert. Die Unternehmens Portal App von Intune wird als Store für die Verteilung von Software genutzt. AV- und Patchmanagement kommen direkt online von Microsoft.

Schon recht komplex war unsere frühere Lync Infrastruktur mit ihrem Session Border Controller, Frond-End- und Edge-Server, Office WebApp Server und einigen Sonderlösungen für Fax und Co. Troubleshooting am Call-Routing war im hybriden Zustand ein Albtraum. Regelmäßig suchten wir an den Firewalls nach möglichen Ursachen für abgebrochene Sessions oder einseitige Voice-Verbindungen. Das alles konnten wir über einige Zwischenschritte inklusive unseres Amtskopfes (+49-2451-9434) nach Teams Online überführen. Wir waren skeptisch, ob Microsoft wirklich die von klassischen Providern wie der Telekom gewohnte Qualität liefern kann. Die Antwort lautet hier: ja – und die klassischen Provider werden weiter für die Bereitstellung von zuverlässigen Netzen / Internet-Zugängen benötigt. Allerdings bedarf es wohl bei Microsoft noch einiger liebevoller Arbeit am Teams-Client, um ihn bezüglich der Telefonie wirklich business-tauglich zu bekommen. Das kommt dann hoffentlich als nächstes.

Die meisten unserer Unternehmens-Applikationen waren von vorneherein als Cloud-Lösungen implementiert (CRM, Lohnbuchhaltung, Antragswesen etc.) und konnten bleiben, wie sie sind. In MS Azure haben wir dann zusätzlich noch 4 Server für besondere Zwecke eingerichtet und angebunden. Hier wurden die z.B. WLAN-Authentisierung und ein Ticket-System angesiedelt. Es findet sich auch ein Remote-Desktop-Server als Ausgangspunkt für den gesicherten Übergang in von uns betreute Kundenumgebunden. Diese Systeme sind allesamt in die Azure AD Domain-Services eingebunden und erzeugen damit das etwas nostalgisches Flair eines internen und sicheren Netzbereichs. Test-Maschinen laufen nun auch in Azure, aber natürlich nicht mehr in unserer primären Subscription. Die Consultants bauen sich in Azure ihre Testumgebungen nach Bedarf und reißen sie angesichts der fortlaufenden Mietkosten nach Testende auch wieder ab.

Das Azure-AD war natürlich von Anfang an mit unserem lokalen AD synchronisiert. Das aufwändige ADFS konnten wir zunächst durch PTA ablösen. Die Aufgabenstellung für die Cloud-Migration war aber, diesen Sync vollständig abzuschneiden und das AAD als reine Cloud-Instanz zu betreiben. Dies war nach der Client-Umstellung auf Autopilot/Intune der letzte Schritt im gesamten Migrationsablauf. So konnten sukzessiv alle lokalen Server inklusive der Domain-Controller des alten on-premises AD ausgeknipst werden, bis wir schließlich nur noch ein Blech für die Datensicherung von O365-Daten übrigbehielten. Das verlagern wir dann zukünftig einmal in die Cloud.

Was hat uns diese Umstellung nun insgesamt gebracht?

Für den Umzug in unser neues Gebäude müssen wir nun nur noch einen lokalen Datensicherungs-Server und das Thema Netzwerk berücksichtigen. Die ca. 60 ursprünglichen Server sind aus und werden nicht mehr benötigt. Die Mitarbeiter können relativ unabhängig vom Unternehmensnetz von überall sicher arbeiten; eine VPN-Einwahl wird nur noch für Sonderaufgaben benötigt. Die früher für lokale Systeme über Firewalls und Reverse-Proxies erreichte Zugangssicherheit ist heute im Wesentlichen auf die Applikationsebene verschoben – der Zugriff auf Online-Daten erfordert immer zwei Faktoren wie z.B. Username/Password + regelkonformes Firmenendgerät.

Insbesondere sind wir im Tagesbetrieb deutlich unabhängiger von allen komplexen Abhängigkeiten der ursprünglichen lokalen Server, der per Firewall isolierten Netzbereiche und dem über etliche Consultants verteiltem Know-how. Der größte Teil der Administration findet heute in den Verwaltungsportalen von Microsoft Azure und Office365 statt, ist dort deutlich kompakter und damit einfacher an die zuständigen Administratoren delegierbar. Auch bringen uns Ausfälle in der lokalen Basis-Infrastruktur (Strom / Klima) nicht mehr so sehr ins Schwitzen: wir können notfalls ins Home-Office umziehen und dort ohne funktionelle Einschränkungen weiterarbeiten.

Schließlich konnte der anstehende Ersatz der veralteten Server- und Storage-Systeme zugunsten der Online- und IAAS-Dienste von Microsoft entfallen. Die Erneuerung der Virtualisierungs-Hardware allein hätte voraussichtlich wieder mehrere 10 Tausend Euro verschlungen. Dem gegenüber stehen heute Mietkosten im dreistelligen Bereich pro Monat für Azure-IAAS Dienste (virtuelle Server inkl. Lizenzen). Die im Wesentlichen genutzten Office-365 Online-Dienste Exchange, SharePoint mit OneDrive etc. sowie Security Services wie Intune und Advanced Threat Protection waren von vorneherein über die Microsoft Online Lizenzen abgedeckt – wir haben sie früher nur nicht in letzter Konsequenz genutzt oder auch nutzen können.

Lt. unserem Chef erfüllen wir jetzt unser Credo, dass IT einfach, flexibel und sicher sein muss, perfekt und leben das vor, was wir vermarkten.

Let´s encrypt-Zertifikate automatisieren

Let´s encryp-Zertifikate autmatisieren

Sparfüchse aufgepasst! :) Sicher hat der ein oder andere schon von Let´s encrypt gehört: Eine tolle Sache! Kostenlose SSL-Zertifikate, die von allen gängigen Browsern als vertrauenswürdig angesehen werden, SAN support…

Ab 01/2018 sollen sogar Wildcard-Zertifikate unterstützt werden. Über z.B. SSLforFree lässt sich recht bequem arbeiten und man erhält vor Ablauf der Zertifikate eine Erinnerungsmail, praktisch. Mindestens mal für Test- und Entwicklungssysteme sehr interessant!

Nicht ganz so trivial ist dabei aber die Erbringung des Nachweises, dass man Besitzer der jeweiligen öffentlichen Domänen ist. Es stehen 3 Überprüfungsmethoden zur Verfügung: Upload von Infos zu einem FTP-Server (noch keine Erfahrung), Upload zu einem HTTP-Server oder Upload zum öffentlichen DNS. Wir schauen uns kurz die letzten beiden an.

  • DNS: Wenn ich ein Zertifikat für "sub.domain.com" beantragen möchte, muss ich für diesen Namen im öffentlichen DNS einen speziellen TXT-Eintrag mit kryptischem Inhalt erstellen. Soweit, so gut. Wenn ich eine Reihe von SANs benötige, wird das schon etwas aufwändig und mühselig – je nach DNS-Provider und Güte des Tools kann es auch nervtötend werden.
  • HTTP: Wenn ich ein Zertifikat für "sub.domain.com" beantragen möchte, muss ich einen unter diesem Namen per HTTP (ohne "s") erreichbaren Web-Server bereitstellen (!) und dort im WWW-Root ein Verzeichnis namens ".well-known" sowie einen Unterordner "acme-challenge" anlegen. Dort hinein kommen spezielle Dateien mit kryptischen Namen. Klingt kompliziert? Ist es auch. Mal eben einen Web-Server für jeden Namen bereitstellen ist schon eine Herausforderung. Hier ist es ja nicht nur damit getan, z.B. ein zusätzliches Binding im IIS zu konfigurieren (wenn denn überhaupt IIS zum Einsatz kommt). HTTP-Anfragen müssen auch von extern hereinkommen können und an die richtige Stelle gelangen - ein geeignetes HTTP-Publishing ist also Pflicht. Wenn ich auch noch eine Reihe von SANs benötige, brauche ich für alle Namen auch jeweils ein Publishing. Dieses muss jeweils zu einem Web-Server zeigen, in dessen WWW-Root ein Ordner ".well-known" existiert, usw.

Übrigens: Einmal präpariert, sind die Nachweise nicht von Dauer. Nach 90 Tagen verlieren sie ihre Gültigkeit und müssen erneuert werden.

Das wäre alles halb so schlimm, wenn die eigentlichen Zertifikate länger gültig wären. Sind sie aber leider nicht: Nach 3 Monaten ist auch hier Schluss und sie müssen erneuert werden. Dies gilt auch für die o.g. Autorisierungsnachweise. Und dann wäre da noch eine Kleinigkeit: Die neuen Zertifikate müssen ja auch noch den anhängigen Diensten wie z.B. Exchange, ADFS, WAP, RDS oder IIS bekannt gemacht werden, das war ja Ziel des Spiels. Natürlich kann man all das manuell machen. Mit einer guten Doku kann das sogar gut funktionieren. Aber bequem ist anders und wenn viele Dienste aktualisiert werden müssen, artet das in eine Menge Arbeit aus. Nun gut - ohne Herausforderungen wird es schnell langweilig. Es muss also eine bessere Lösung her…

Kann man das nicht irgendwie automatisieren?

Einige findige Leute haben sich diese Frage auch schon gestellt und bemerkenswerte Lösungen auf Powershell-Basis (ACMESharp Modul) entwickelt. Diese sind jeweils auf bestimmte Zielsysteme zugeschnitten, z.B.

a) für Exchange von Frank Zoechling,

b) für RDS-Server von Daniel Melanchthon oder

c) für IIS-WebServer von Marc Durdin.

Wohlgemerkt sind alle Lösungen auf exakt einen Server geeicht - also für jeden Server ein eigenes Zertifikat. Hat man mehr als 1 Exchange Server (z.B. in einer DAG) oder eine aus mehreren Servern bestehende RDS-Farm, muss man die Skripte nachfeilen.

Das Prinzip bei allen:

  1. Autorisierungsinfos für die öffentlichen Domänen erstellen
    • Der eine (b) favorisiert DNS , weil es simpler ist und weniger Anpassungen in der Infrastruktur erfordert. Allerdings ist hier die Automatisierung schwierig - je nach DNS-Provider mal mehr, mal weniger. Eine Standardlösung für alle DNS-Provider ist nur schwer vorstellbar.
    • Die anderen (a, c) favorisieren HTTP, weil es tatsächlich vollständig automatisierbar ist. Diverse Publishings mit geschickten Umleitungen etc. sind aufwändig und komplex, der Aufwand fällt aber bei gleichbleibenden Domänen nur einmal an.
  2. Anfordern des Zertifikats, dabei Überprüfung der in Schritt 1 erstellten Autorisierungsinfos
  3. Export des Zertifikats ins PFX-Format
  4. Einbinden des Zertifikats in die jeweiligen Dienste

Sofern man kein Problem mit der HTTP-Variante und ihren Nachteilen hat (und sich alles um Single-Server-Deployments dreht), lassen sich die Skripte a) für Exchange Server und c) für IIS-WebServer schon mal prima einsetzen. Gleiches gilt für RDS und b) wenn man mit einer Halbautomatik erst einmal zufrieden ist.

Ich für meinen Teil hatte für meine Testumgebung etwas speziellere Wünsche. Da ich dort nur eine öffentliche IP habe und einen großen Fuhrpark von Servern, Diensten und (sub-)domains versorgen muss, benötige ich ein SAN-Zertifikat mit sämtlichen DNS-Namen, das auf viele verschiedene Server zum Einsatz kommt. D.h. ich musste dafür sorgen, dass Autorisierungsinfos für alle Domänen zugreifbar sind. Nach einigen Modifikationen war das Skript von Frank Zoechling soweit, dass es im WWW-Root eines Web-Servers die Infos für alle Domänen ablegte.

2017-11-20_17h23_20

Nun noch eine Veröffentlichungsregel auf dem guten alten TMG, die incoming HTTP an diese Domänen zum obigen Web-Server leitet.

clip_image002

Damit war Punkt 1 erledigt, Punkt 2 und 3 funktionierten ohne weitere Modifikationen.

clip_image003

Punkt 4 sind eigene, separate Skripte auf den jeweiligen Zielservern (Exchange, ADFS, usw.), bislang noch nicht vollständig automatisiert. Bis hierhin zu kommen war schon eine Menge Arbeit, aber es hat sich gelohnt!

Es folgt eine Liste von Befehlen, die ich auf den jeweiligen Systemen abfeuere sowie ggf. weiterführende Infos.

Exchange 2016

  • Import-ExchangeCertificate -FileName \\centralserver\share\certnewest.pfx -FriendlyName "SAN domain.com" -Password (ConvertTo-SecureString "HOCHGEHEIMESPASSWORT" -AsPlainText -Force) -PrivateKeyExportable:$true | Enable-ExchangeCertificate -Services "SMTP, IMAP, POP, IIS" -force

Exchange 2010

  • $ex=Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path \\centralserver\share\certnewest.pfx -Encoding byte -ReadCount 0)) -FriendlyName $ExchangeSubject -Password (ConvertTo-SecureString "HOCHGEHEIMESPASSWORT" -AsPlainText -Force) -PrivateKeyExportable:$true
  • Enable-ExchangeCertificate -Services "SMTP, IMAP, POP, IIS" -force -thumbprint $ex.Thumbprint

IIS

RDS

ADFS

  • Die Funktion "Set-CertificatePermission" stammt auch aus den Tiefen des WWW
  • $certresult=Import-PfxCertificate -CertStoreLocation cert:localmachine\my -FilePath \\centralserver\share\certnewest.pfx -Password (ConvertTo-SecureString "HOCHGEHEIMESPASSWORT" -AsPlainText -Force)
  • $installedcert=Get-ChildItem Cert:\LocalMachine\My | ? {$_.Thumbprint -eq $certresult.Thumbprint}
  • Set-AdfsSslCertificate -Thumbprint $installedcert.Thumbprint
  • Get-AdfsSslCertificate
  • Set-CertificatePermission -pfxThumbPrint $installedcert.Thumbprint -serviceAccount "s_adfs"
  • Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint $certresult.Thumbprint
  • Restart-Service adfssrv

WAP

  • Hier fehlt noch die vernünftige Speicherung des "FederationServiceTrustCredential", bislang nur interaktiv
  • $certresult=Import-PfxCertificate -CertStoreLocation cert:localmachine\my -FilePath \\centralserver\share\certnewest.pfx -Password (ConvertTo-SecureString "HOCHGEHEIMESPASSWORT" -AsPlainText -Force)
  • $installedcert=Get-ChildItem Cert:\LocalMachine\My | ? {$_.Thumbprint -eq $certresult.Thumbprint}
  • Install-WebApplicationProxy -FederationServiceTrustCredential (Get-Credential) -CertificateThumbprint $installedcert.Thumbprint -FederationServiceName 'adfs.domain.com'

Work Folders

  • $certresult=Import-PfxCertificate -CertStoreLocation cert:localmachine\my -FilePath \\centralserver\share\certnewest.pfx -Password (ConvertTo-SecureString "HOCHGEHEIMESPASSWORT" -AsPlainText -Force)
  • cmd /c netsh http delete sslcert ipport=0.0.0.0:443
  • cmd /c netsh http add sslcert ipport=0.0.0.0:443 certhash=$certresult.Thumbprint appid="{CE66697B-3AA0-49D1-BDBD-A25C8359FD5D}" certstorename=MY

Kemp VLM, SharePoint

  • Offen: Hier muss ich mir noch etwas überlegen/auf die Suche gehen

Fazit: Das Ganze ist noch eine offene Baustelle, von einer vollständigen Automatisierung bin ich noch ein Stück entfernt. Nichtsdestotrotz ist auch der aktuelle Stand mehr als nützlich und vereinfacht die Angelegenheit enorm. Let´s encrypt-Zertifikate sind eine tolle Sache. Aller Automatisierung zum Trotz sollten diese jedoch meiner Meinung nach Stand heute besser nicht in produktiven Umgebungen eingesetzt werden. Dann lieber ein paar Euro in ein 3 Jahre gültiges Zertifikat investieren. Für Test- und Entwicklungsumgebungen eignet sich das Ganze aber sehr gut!

Ich hoffe, diese Infos sind für den ein oder anderen nützlich.

Entspannte Abwesenheit mit dem Exchange Abwesenheitsassistenten

Endlich Urlaub - abschalten und am Pool entspannen. Wäre da nicht das Handy... Die Mails trudeln im Minuten-Takt ein. Sie werden trotz Abwesenheit an Termine erinnert? Oder Kollegen rufen an, und erkundigen sich, warum Sie nicht am Meeting teilnehmen, dabei liegen Sie krank zu Hause? Wir zeigen Ihnen, wie Sie mit dem Exchange Abwesenheitsassistenten mit nur wenigen Klicks für eine entspannte Abwesenheit sorgen...
Der Online Abwesenheitsassistent von Exchange
Mit dem Online Abwesenheitsassistenten von Exchange können Sie Ihr Postfach und Ihren Kalender urlaubsreif gestalten - und das mit nur wenigen Klicks.  So können Sie auf Knopfdruck einstellen, dass in dem Zeitraum Ihrer Abwesenheit, Ihr Kalender geblockt wird und Termine und Terminanfragen automatisch für Sie abgelehnt oder abgesagt werden.