Ein einfacher Überblick über die Microsoft Office Lizensierung

image_pdfimage_print

Und warum man Office 365 nutzen sollte

Derzeit setzen treffen wir im Mittelstand im Wesentlichen drei unterschiedliche Microsoft Office-Lizensierungen an:

  • Einzellizenzen in Form sogenannter Key-Cards.
  • Microsoft Open Vertrag für die Nutzung am Terminal-Server
  • Office365 Lizenz

Die FPP Lizenz, die bunte Verpackung

Das größte Problem stellt dabei die Lizensierung über die Key-Card in Form der FFP (Full Package Produkt) Lizenz dar. Diese „Packerl“-Lizenz hat ein paar wesentliche Nachteile:

  • Die Lizenz ist nach der Aktivierung unveränderlich an ein privates Microsoft Konto gebunden.
  • Sie gilt nur für jeweils einen PC, trotz der Lizensierung an ein persönliches Microsoft-Konto
  • Sie erhält keine Funktionserweiterungen bzw. Funktions-Updates sondert gilt als „zu nutzten wie gekauft“.
  • Sie darf nicht auf einem Terminalserver oder ähnlichem eingesetzt werden.
  • Es gibt keine Support-Unterstützung von Microsoft. Der Support muss vom Verkäufer bereitgestellt werden.

Aus diesem Grund haben wir in Umgebungen mit mehr als 3 Usern schon lange aufgehört diese Lizenzform zu vertreiben.
Gerade die Bindung an ein privates Microsoft-Konto wiederspricht dem Einsatz in größeren Umgebungen.

Beim Wechsel von Mitarbeitern oder Computern stellt dies in der Regel ein Problem in der Lizensierung vor allem aber in der Administration dar.

Das Microsoft Open Lizenz Programm

Die Open Verträge waren in der Vergangenheit die bessere Lizenzform für Unternehmen.

  • Die Lizenzen wurden für das Unternehmen lizensiert und konnten jederzeit neu zugewiesen werden.
  • Der Umfang der Nutzungsrechte ist größer. Z.B. dürfen diese Lizenzen auch auf Terminalservern eingesetzt werden.

Gegen Aufpreis gibt es auch eine Software Assurance, Die „Wartung“ beinhaltet z.B. das Recht innerhalb der Laufzeit dieser Software Assurance (meist drei Jahre) die jeweils aktuelle Version der Software einzusetzen,

Preislich ist diese Variante am oberen Ende. Diese Lizenzen haben den höchsten Preis und mit der Software-Assurance kommen noch einmal ca. 50% Wartungsgebühr für drei Jahre dazu.

Die Office 365 Lizensierung, flexibel und günstig

Inzwischen hat sich in vielen Fällen die sogenannte Cloud-Lizensierung über Office 365 durchgesetzt.

Im Gegensatz zu den beiden vorigen Lizenzformen erwirbt man dabei jedoch kein dauerhaftes Nutzungsrecht, sondern mietet die Software in der jeweils aktuellen Version.

Ein weiterer, wesentlicher Unterschied ist, dass die Lizenzform an Personen im Unternehmen und nicht an Computer oder Geräte gebunden ist.

Der jeweilige Benutzer darf eine Office Lizenz dann aber z.B. auch auf bis zu fünf dieser Person zugewiesenen Computern einsetzen. Also z.B. auf einen PC in der Firma, dem Notebook, einem Terminalserver und einem Home-PC.

Die Lizenzsteuerung erfolgt über ein Cloud-Portal, welches in das Office 365 Portal integriert ist. Dort können die Lizenzen völlig beliebig den Personen zugewiesen aber auch wieder entfernt werden.

Dabei bleibt das Unternehmen aber sehr flexibel. Je nach Vertragsart und Preisstaffel sind die Lizenzen monatlich oder jährlich anpassbar.

Nur die über diese Art lizensierten Microsoft Office Programme werden laufend mit neuen Funktionen versorgt und gegebenenfalls neuen Umgebungen und Anforderungen angepasst.

Der Support wird von Microsoft und dem jeweiligen Vertriebspartner erbracht.

Preislich kann man ganz grob kalkulieren, dass die Mietkosten auf drei Jahre in etwa einer ähnlichen Kaufversion entsprechen. Durch das mehrfache Installationsrecht und die flexible Anpassung stellt diese Lizenzform tatsächlich auch meist die kostengünstigste Variante dar.

Zudem ist die Office 365 Lizensierung nahtlos mit den integrierten wie auch optionalen Diensten in Office 365 wie z.B. dem Exchange Online vernetzt. Im Office 365 sind viele Dienste bereits in die reinen „Lizenz-Produkte“ integriert.

Damit erhält der Kunde, der über Office 365 lizensiert, neben der besseren Lizenz für eine lokale Installation auch das Nutzungsrecht auf z.B. OneDrive vor Business, Skype for Business, Micosoft Forms und viele weitere Dienste.

Veröffentlicht unter Allgemein | Verschlagwortet mit , , , , , | Hinterlasse einen Kommentar

Server 2019 als Terminalserver ungeeignet

image_pdfimage_print

Bitte entschulden Sie zunächst einmal die reißerische Überschrift, aber ich habe in den letzten Wochen gelernt, dass die Information noch nicht bei jedem angekommen ist.

Natürlich lässt sich mit dem Windows Server 2019 fast genau so wie beim Vorgänger, dem Server 2016, ein RDP-Server also ein Remote Desktop Szenario aufsetzten.

Der Server 2019 bring jedoch an dieser Stelle zwei wesentliche, einschneidende Änderungen welche den Einsatz als RDP-Server in vielen Fällen verhindern.

  • Office 365 wird auf Windows Server 2019 nicht unterstützt.
  • Keine Unterstützung von RemoteFX mit Server 2019.

Kein Office 356 auf Server 2019

Das ist in meinen Augen der ein echter Showstopper. In einem RDS-Szenario mit Windows Server 2019 als RDS-Host wird ausschließlich Office in den Perpetual Lizenz also einer dauerhaften Lizenz ohne regelmäßige Funktionsupdates supportet.

Das ist in mehrfacher Hinsicht schwer zu verdauen. Gerade jetzt wechseln wir aus vielerlei guten Gründen gerade an allen Stellen auf Lizenzmodel CSP, also Office 356.

Für einen Terminalserver unter Windows Server 2019 müssten wir also weiterhin Perpetual Lizenzen über die Open Volume Lizensierung verwenden. Je nach Szenario der möglichen Mehrfachinstallation unter Office 365 kommen wir auch wieder in das Thema der Mehrfachlizensierung.

Aus Kundensicht viel einschneidender, der Funktionsumfang von Office 365 und der Perpetual Lizenz driftet mit zunehmendem Tempo auseinander. Das Look & Feel und der Funktionsumfang ist unterschiedlich.

Keine RemoteFX Unterstüztung unter Server 2019

Ok, zugergeben, die Anzahl der Installationen welche die Graphik-Funktionen von RemoteFX verwenden mag keine wesentliche Rolle spielen.

Ich dagegen habe die RemoteFX Funktion sehr gerne verwendet, um Remote USB Ports an die RDP-Session durchzuleiten. Damit ist unter Windows Server 2019 auch Schluss.

Gründe und Ausblick

Was jetzt kommt, ist eine sehr persönliche Betrachtung. Natürlich fragt man sich, warum Microsoft das tut?

Nun, wenn wir die Entwicklung von Windows Server ansehen, dann stellen wir fest, das wir uns hier immer mehr von der bekannten GUI verabschieden. Die Installationsoption als Core-Variante wird immer häufiger der Standard. Tools wie Windows Admin Center tragen dem Rechnung und machen die Verwaltung von „Core-Servern“ einfach und praktikabel. Microsoft empfiehlt die Core-Installation als Standard.

Wer weiß, ob die nächste Serverversion überhaupt noch eine eigene GUI bringt? Und ohne eine dem Deskop-System ähnliche GUI ist auch ein RDP-Server nicht denkbar.

In meinen Augen lässt Microsoft hier den klassischen RDP-Server langsam sterben.

Windows 10 Multi-Session-Host

Das der klassische RDP-Server sterben sollte, wäre in meinen Augen kein Drama, steht doch schon der nächste Stern am Horizont.

Mit Windows 10 Mulit-Sesscion-Host bringt Microsoft das Client-Betriebssystem in die RDP-Serverrolle mit echten Multi-Session Eigenschaften.

Damit kann eine oder gar mehrere Installationen solcher Windows 10 Versionen den Terminalserver ersetzten.

Und endlich arbeiten die RDP-User tatsächlich auf einem echten Client-Betriebssystem und nicht mehr auf einem „verbogenen“ Server.

Denken wir an die Third-Party-Anwendungen die sich meist auch recht schwer taten, Ihre Software sowohl für den Client wie auch für einen RDP-Server bereitzustellen. Auch wenn hier die wirklichen Herausforderungen wie Profiles und Registry erhalten bleiben. Mir gefällt der Ausblick.

Zwei Punkte trüben die Vorfreude auf das Windows 10 Mulit-Session-Host: Zum einen ist Microsoft hier zeitlich in Verzug. Die Lösung ist seit einigen Tagen erst in der Public-Beta, zum anderen wird das neue OS (zunächst?) nur auf Azure gehostet angeboten.

Letzteres stellt zwar eine neue Herausforderung dar, aber tatsächlich bietet es in den meisten Szenarien die passende Lösung.

Und wenn nichts passt?

Für alle Installationen, in denen weder die eingeschränkten RDP-Funktionen von Windows Server 2019 noch das Windows 10 Mulit-Session-Host in Azure die passende Lösung darstellt, empfiehlt Mircosoft weiterhin auf Windows Server 2016 als RDP-Host zu setzen.

Eine eher fahl schmeckende Alternative. Windows Server 2016 verlässt bereits Januar 2022 den grundlegenden Support und schwenkt dann in den erweiterten Support. Für einen Server oft kein schwerwiegender Zeitpunkt. Für eine Server als RDP-Host in meinen Augen schon. Mit dem Ablauf des grundlegenden Supports wird es keine Funktions-Updates und Anpassungen mehr geben. Damit wird sich Bedienung, Funktionen und evtl. auch Kompatibilität mit neuere Anwendersoftware weiter vom Client-Betriebssystem Windows 10 entfernen.

Veröffentlicht unter Projekte / Erfahrungen | Verschlagwortet mit , , , , , , , , , | 4 Kommentare

winmail.dat verhindern

image_pdfimage_print

Wie uns EDV-Geschichte hilft Probleme zu verstehen.

Ich habe manchmal das Gefühl, das Problem mit der Winmail.dat ist so alt wie der erste Mail-Client von Microsoft. Und damit habe ich gar nicht unrecht.

Aber worum geht es und was ist winmail.dat?

Ein wenig Geschichtsunterricht

Mails waren früher, als noch alles gut und einfach war, eine reine Textnachricht, in etwa so wie heute eine reine SMS.

Reine Textformate sind noch relativ einfach in Ihrem Aufbau. Sie hatten und haben meist nur Probleme in der Darstellung des Zeichensatzes. Aber auf ASCII Code und Codepages will ich aber hier nicht weiter eingehen.

Wer jedoch mehr Informationen als nur reinen Text erstellen, bearbeiten und speichern möchte, braucht mehr als nur einen Zeichensatz. Farbe, Größe, verschieden Zeichensätze oder gar Bilder brauchen andere Formate.

Microsoft hat neben seinem .doc Format welches wir aus der Anwendung Word kennen, bereits 1987 ein weiteres Austauschformat für Texte eingeführt. Es sollte möglichst nahe am reinen Text sein, dennoch auch eine Formatierung zulassen.

Das Rich Text Format (RTF), welches das Programm Wordpad per default verwendete, aber auch von Apple von TextEdit verwendet wurde, kam einem einfachen Austauschformat für Texte schon sehr nahe.

Kein Wunder, dass Micosoft dieses Format auch in den ab Ender der 80er Jahre aufkomenden Mail-Programme verwendete.

Leider hat das properitäre RTF in den kommenen Jahrzehnten wenig überzeugen können. Apple setzte z.B. nur auf die einfachsten Funktionen und führte für z.B. eingebundene Grafiken eine eigene Erweiterung RTFD ein.

zurück in die Zukunft

Mit dieser kleinen Geschichtsstunde möchte ich aufzeigen, dass so manches Problem mit dem wir heute konfrontiert werden seine Ursprünge in einer der Vergangenheit hat.

Aber nun zur Zukunft. Was ist nun winmail.dat, wann passiert das und was können wir tun?

Wenn wir heute ein Mail schreiben, dann ist es für uns selbstverständlich dass wir den Text formatieren können, Bilder einfügen und vor allem auch eine Datei anhängen können.

Aber … E-Mail ist noch immer ein rein textbasierendes Format. Wie kommen also die bunten Bilder, Filmchen etc. in die Mail und vor allem beim Empfänger an?

Mail ist noch immer nur Text

Dazu wird die Mail in zwei Bereiche aufgeteilt. Einen Header der grob gesagt die Zustellinformationen enthält, und einem Body. Der Body, der eigentliche Inhalt, untergliedert sich wieder logisch in die Text-Information, einer Signatur und dem Anhang (Attachement).

Im Body finden wir auch die Fomatierungen wieder, welche wir bei der Mail angewandt haben.

Und hier schlägt das RTF-Format zu. In unserem E-Mail Client Outlook können wir noch heute das RTF-Format zur Formatierung auswählen. Das scheint auf den ersten Blick nicht falsch. Es ist schlank und bietet einige brauchbare Formatierungsoptionen.

Aber wenn wir eine Mail mit RTF formatieren, sendet unser Mail-Client auch in einem anderen Format als mit standardisierten „Header und Body“. Es wirft einfach gesagt die klare Ordnung in der Mail durcheinander. Das Attachement wird nicht mehr ganz konform nur am Ende der Mail transportiert.

Auch pure Microsoft Umgebnungen sind betroffen

Nun mag man sich denken, das wäre kein Problem wenn Sender und Empfänger doch ohnehin Outlook oder gar einen Exchange Server verwenden.

Dabei wird die Rechnung aber ohne den Wirt, in diesem Fall die transportierenden Systeme gemacht. Ob das nun ein Mailserver ist der als Relay zwischen Absender und Empfänger ist oder auch ein Anti-Spam-System irgendwo im Transportweg.
Irgendwo läuft man Gefahr, dass die Mail von einem System nach „Schema- F“ also dem heute geläufigen Standard gelesen und verabeitet wird. Und plötzlich wird alles dass was nicht mehr als reiner Body der Mail erkennbar ist, ganz nach hinten geschoben und landet als winmail.dat als Anhang der Mail beim Empfänger. Dabei kann es sich um ein ursprüngliches Attachement aber auch z.B. um eine umfangreiche Signatur handeln.

Outlook konfigurieren reicht nicht

Wie lösen wir nun ein solches Problem. Lange Zeit habe auch ich schon monoton darauf geantwortet „sendet keine Mails im Rich-Text-Format und nutzt als Standardformat Text oder HTML“
Natürlich haben wir auch im Outlook als Standardformat für das Senden von Mails Text oder HTML konfiguriert.

Geholfen hat das nicht wirklich und das lag nicht unbedingt an den Usern. Auch wenn man beobachten konnte dass es bei dem einen User zu winmail.dat kommt beim Kollegen gegenüber aber nicht, und das beim gleichen Empfänger.

er war stehts bemüht …

Outlook ist stehts bemüht, uns im besten Licht dastehen zu lassen. Dazu zählt auch dass es sich per default einfach auf die Sprache des Gegenüber einstellt. Wenn wir eine Mail in einem Text-Format erhalten, so ist die Antwort automatisch zunächst auch im Text-Format. Gleiches gilt auch für HTML und natürlich RTF. So manches RTF-winmail.dat-Problem wurde schon bei dem User erzeugt, der später eine winmail.dat als Antwort auf seine Mail erhielt. Wer RTF sendet, bekommt auch RTF als Antwort, unabhängig vom eingestellten Standarformat in Outlook.

Damit aber nicht genug, in seinen tiefen Speichermöglichkeiten merkt sich Outlook auch noch solche Besonderheiten und sendet so einem Empfänger, der uns einmal RTF gesandt hat oder den wir schon mit RTF beglückt hatten seine „Vorliebe“ und schon haben wir wieder eine winmail.dat.

Das Problem zentral lösen

Als Administrator gehen wir jetzt, da wir das Problem erkannt haben, an einer zentralen Stelle dagegen vor: Dem Mailserver.

Im Exchange Online, dem bevorzugten Mailsytem meiner Wahl, können wir dies recht einfach über die Web-GUI einstellen.
In den anderen Versionen ist es entweder ähnlich (Exchange 2016 / 2019) oder per PowerShell zu konfigurieren.

Wir verändern dazu einfach den Sendeconnetor und definieren für die Remote-Domänen, dass wir kein Richt-Text-Format zulassen. In der Regel ist nur ein „Default“ für alle Remote-Domänen definiert. Wer hier für verschiedene Empfangsdomänen unterschiedliche Remotedomänen definiert hat, muss dies entsprechend auch dort anpassen.

Mit der Auswahl „Rich-Text-Format verwenden“ „Nie“ sind wir das Problem mit den winmail.dat in diese Umgebung los.

Da der Exchange mit Outlook „spricht“ wird die Einstellung in den Client übernommen. Es ist gewissermaßen die abolute Anordnung keine Mails im Richt-Text-Format erstellen zu können.





Veröffentlicht unter Projekte / Erfahrungen | Verschlagwortet mit , , , , , , | 3 Kommentare