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 , , , , , , , , , | 2 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 , , , , , , | 1 Kommentar

AMD System hängt mit Windows 10

image_pdfimage_print

Zumindest in meinen Kundenumfeld trifft man so gut wie nicht mehr Windows 7 oder gar ältere Betriebssysteme an.

Bei der Umstellung von meist Windows 7 auf Windows 10 prüfe ich auch immer gerne ob die alte Hardware nicht doch noch verwendet werden kann.

Meist genügt schon der Austasuch der alten Festplatte gegen eine morderne SSD und schon läuft der alte Rechner mit Windows 10 spürbar besser als mit Windows 7 auf der alten HDD.

Dennoch gilt es gut zu prüfen, ob der alte Rechner auch in naher Zukunft noch den Anforderungen von Windows 10 und seinen Aktualisierungen genügt.

Für die Umrüstung eines PC auf SSD, Migration des Betriebssystemes oder Neuinstallation auf der SSD fallen doch in Summe ca. 150,- Euro an. Ob das Sinn gegenüber einer Neuanschaffung macht, muss eben im Einzelfall geprüft werden.

Hartnäckig und kritisch sind dabei ältere Systeme mit AMD-Chipsets.
Zuletzt hatte ich es mit einem ältern MSI All-in-One PC mit AMD Chipset zu tun. Ich wollte das Gerät in meiner eigenen Umgebung einsetzen und mir deshalb etwas mehr Mühe gegeben, als es beim Kundeneinsatz angesichts des Aufwand und der Kosten Sinn ergeben hätte.

Die CPU-Belastung der zweikern-CPU lag nach dem Update auf Windows 10 im Mittel auf 40%. Am deutlichsten zeigte sich die Belastung am Mauszeiger. Die Mausbediehnung blieb immer wieder hängen, so dass ich fast nur mit dem Touchscreen zum Ziel kam. Das System war faktisch nicht mehr nutzbar.

Wenn ich das System neu aufgesetzt hatte, war der Fehler weg, bis zum ersten automatischen Update.

Natürlich hatte ich sofort die AMD-Problematik mit dem Spectre-Bug im Sinn. Aber so recht kam ich mit einfachem Experimentieren nicht weiter. Auch eine Deinstallation des per Windows Update ausgebrachten AMD und Radeon-Treibers brachte nichts.
Die Grafikeinheit (Radeon HD 8230) gibt AMD immerhin als vollständig supportet an

https://www.amd.com/en/support/kb/faq/gpu-615

Der Taskmanager zeigt mir als Quelle für die hohe CPU Auslastung nur „System“ an. Also habe ich den Prozess-Explorerer aus den Sysinternals bemüht.

https://docs.microsoft.com/de-de/sysinternals/downloads/process-explorer

Dort habe ich relativ schnell den Treiber atikmdag.sys als Quelle ausmachen können. Das Tool ist wirklich ein sehr praktisches Werkzeug, einem PC mal auf die Bits und Bytes zu sehen. Oft nutzt man es auch, um evtl. Schadsoftware zu erkennen und dingfest zu machen.

Wie sich raustelle war atikmdag.sys das „ATI Radeon Kernel Mode Driver Package“ welches sich wohl mit dem Radeon-Treiber als Kernel-Treiber über Windows Update eingeschlichen hatte, aber mit dem Deinstallieren des Treibers nicht wieder entfernt wurde.

Bevor ich nun angefangen habe lange nach dieser Treiberkomponente zu suchen und die Registrierung im System von Hand herauszunehmen, griff ich zum AMD Cleanup Utlitity. Ich wollte ja schnellstens ein „cleanes“ System.

https://www.amd.com/en/support/kb/faq/gpu-615

Nachdem das Utiltiy das System frei von AMD-Treibern machte, pendelte sich die CPU-Last im Leerlauf wieder auf erträgliche Werte ein. Unterm Strich, macht es wenig Sinn ein solches System (AMD E2, ältere RADEON-Grafik) weiterhin produktiv zu nutzten.
In meinem Fall wollte ich ein wenig mit dem Touch-System des All-in-One experimentieren und habe mal wieder den Prozess-Explorer als Tool genutzt. Schließlich kann man nur, was man auch übt.



Veröffentlicht unter Projekte / Erfahrungen | Verschlagwortet mit , , , , , , , | Hinterlasse einen Kommentar