Ist Ferdi das bessere Franz?

Ferdi, das OpenSource Ding, dass Franz kopiert ist nun einige Wochen hier im Einsatz. Ein kleines Resumee.

Viel universeller einsetzbar

Meine 42 Dienste brauchen auch zum Teil zeitweise bis zu fünf Gigabyte RAM. Auch mit durchkonfiguriertem Ruhezustand der Dienste. Dank den eigentlich bezahlten Premium-Funktionen von Franz tut Ferdi für mich viel mehr. So ist es mit den Custom Websites ohne Probleme möglich mal eben PocketCasts in der Web-Variante oder Spotify zu integrieren. Damit macht Ferdi auch viel mehr audiovisuelles als Franz es getan hat, ersetzt aber auch einiges an Apps, die ich sonst hätte neben Franz verwendet.
Da es prinzipiell dafür da ist, die Hälfte meines großen 21:9 Bildschirms zu füllen, passt es auch gut für YouTube, dort wäre eh der Platz wo ich die Popouts der Videos hingeschoben hätte.

Keine ToDo’s

Was mich überhaupt nicht stört, sind fehlende ToDo’s. Das macht Microsoft ToDo und das ist – Ihr ratet es schon – als Dienst eingebunden. Das brauche ich nicht als Kopie in Ferdi (oder Franz) selbst, zumal es sich dort ja nicht zwischen den Geräten synchronisieren würde – oder wieder extra über Franz/Ferdi Accounts gehen würde.

Das neue Reddit Interface ist bescheuert

Die einzigen Abstürze erzeugte – wie soll es anders sein – das neue Reddit-Interface. Es wird so oder so von Techies wie CGP Grey verteufelt, spätestens mit Ferdi weiß man auch warum. Reddit ist dort quasi nicht bedienbar.

Hardwareanforderung identisch

Vom Rest erwarte ich etwa gleiche Anforderungen. Last und RAM-Verbrauch ist nahezu identisch mit Franz. Dank Aufbau auf Electron verhält sich Ferdi nicht viel anders als Franz und auch nicht viel anders als jeder ressourcenhungrige Google Chrome – weil Electron nicht viel anderes als Chrome ist …

Die bessere Chrome-Apps-Variante

Kennt ihr noch die Chrome Apps? Bzw. die Möglichkeit im Google Chrome Websites als „App“ in Windows so zu schreiben, dass sie auf Desktop und Startmenü stehen?
Ferdi und Franz sammeln genau diese Anwendungen in einer, sodass es nicht viele verschiedene Fenster sein müssen, die in Menge immer unübersichtlicher werden würden.

Ich werde also erst einmal bei Ferdi bleiben. Leider tut es mir für Franz ein wenig Leid, ist die Basis der Entscheidung doch ein Bug in Franz …

Ferdi als Franz-Alternative

Die Software für Kollaboration, die ich einsetze, war bisher immer Franz. Die hat allerdings seit einigen Wochen ein nerviges Problem. Die Menüleiste überdeckt den Inhaltsbereich und macht ihn nicht klickbar. Ganz als hätte man vergessen im Visual Studio einzustellen, dass man eben nicht das Fensterframework von Windows verwenden möchte.

Nach kurzem Mailwechsel zum Entwickler ist das ganze bekannt und man arbeitet daran. Vielleicht doch nicht so easy zu suchen – und vielleicht eben auch einfach nicht sowas Banales wie die Framework-Einstellung in Visual Studio – wer weiß.
Dennoch fehlte mir Franz irgendwie. Die Oberseite der Services ist eigentlich die wichtigste, wenn die nicht klickbar ist, bleibt man ständig „hängen“. Um zumindest Twitter aufrechtzuerhalten, habe ich dann mal wieder Tweeten angeworfen.
Im Vergleich zu Franz ist Tweeten aber eben nur Twitter. Das reicht bei den 42 Diensten nicht. WhatsApp, Reddit, Gmail, eigentlich sämtliche Google Dienste, MS Teams, Instagram, Skype, Telegram, ProtonMail, GitHub, Feedly – ihr wisst, worauf ich hinaus möchte.
Es musste also eine Alternative her, die mehr als nur Tweetdeck als Webdienst bündeln kann.

Ferdi landete auf dem PC, ein direkter OpenSource Fork von Franz.
Vorteil davon ist: Keine Bezahlfeatures mehr und alles, was Franz eigentlich verkaufen will, ist mal eben integriert.
Das macht zwar das Geschäftsmodell von Franz kaputt, aber damit bin ich den Bug los.

Man sollte genügend RAM installiert haben. 40+ Chrome Tabs mal nebenbei laufen zu lassen ist kein Zapfenstreich, auch für die CPU nicht. Hat Windows nicht die Möglichkeit, sich auf den achten bis 16. Thread zu schieben, leidet immer die Systemperformance.
So ziemlich jede Laptop-CPU unter i7er Klasse habe ich mit Franz schon in die Knie gezwängt. Nicht weil Franz schlecht wäre, sondern wegen der Menge an parallel zu überwachenden Websites.
Um hier mal Realwelt-Vergleiche zu schaffen. Der alte FX-8320 hat Franz locker gepackt, der neue Ryzen 7 5800x packt eh alles, was man ihm irgendiwe an Arbeit gibt – aber i5er Surface Pro 7 geht mit Franz (und womöglich auch Ferdi) mächtig in die Knie. Wobei das i5er SP7 ja so oder so auch nur einen Teams Videochat braucht um schon in die Knie zu gehen.

Dies nur mal als erste Notiz. Ehrlich gesagt nutze ich die Software gerade einmal 30 Minuten lang. Ein ausführlicher Vergleich mag irgendwann noch folgen.

BookStack läuft nun

Ich habe mir mal BookStack aufgesetzt. Es ist alles öffentlich sichtbar unter https://wiki.notizlo.ch/.

Seitdem ich den Blog bei Raidboxes habe ist mir gar nicht aufgefallen, dass der Uberspace dahinter ablief, die Subdomain fürs Wiki (eigentlich hätte ich es KB nennen sollen) läuft dafür auf einem neuen Space.

Initial hatte ich Confluence im Sinn um das KB dann per CNAME zu binden, dort ist anonymer Zugriff aber nur im 5,50 USD pro Monat pro User Modell inbegriffen – und diese 6 USD sind viel besser bei Uberspace aufgehoben.

Bei Raidboxes hätte man BookStack nur zwischen mogeln können, in dem man die WordPress-DB anfasst und erweitert. Das ging bei mir im Blog schon mal schief, deshalb gehts nun wieder in Richtung Uberspace. Auch würde ich gerne die Verantwortung für WordPress ein wenig mehr bei Raidboxes lassen, gerade weil die sich schon um Patchmanagement kümmern und spezieller auf WordPress eingeschossen sind.
Damit hätte ich dann zumindest irgendwann auch mal wieder MX (also Mails) auf der Domain, wobei ich Mails dann doch lieber in Google Workspace hätte, was momentan daran scheitert, dass Google die Schweizer Domain noch nicht an Endkunden verkauft.

Im Wiki landet alles was mehr so den Dokumentationsstil verfolgt, nichts sonderlich mitteilenswertes – das steht weiterhin hier, sondern einfach nur Aufschriften und Dinge die halt irgendwo mal stehen müssen.

UniFi Controller egal wo installieren

Kurze Notiz an mein späteres ich (weil ich schon mindestens dreimal über das Problem gestolpert bin):

Egal wo du mal Ubiquiti Controller brauchst, wegen der verrückt spezifischen Java-Abhängigkeit wirst du wahrscheinlich nie die richtige Kombination finden. Variante A funktioniert nicht, weil Dependency X nicht für die Architektur, Variante B funktioniert nicht, weil erst mal Paketquellen suchen …

Das hier machts richtig:

https://community.ui.com/questions/UniFi-Installation-Scripts-or-UniFi-Easy-Update-Script-or-UniFi-Lets-Encrypt-or-UniFi-Easy-Encrypt-/ccbc7530-dd61-40a7-82ec-22b17f027776

Das Ding kümmert sich von Update über erkennen von Versuchen mit MongoDB etc.
Haste dich danach vertan, apt-get purge unifi und wieder zurück zum Script.

Google wirft dir alles Mögliche an den Kopf – womöglich weil du da nicht googeln kannst und immer wieder Raspberry und Raspbian und Co. angibst – und dann doch irgendwie klar ist, dass Google doch spezifischer fürs angegebene OS sucht und stand heute noch nicht schnallt, dass Raspbian mit Debian beinahe gleichzusetzen ist. Such am besten gleich nach Debian und nicht nach Raspberry …

In VDI-Umgebungen macht man kein Conferencing – Kapitel 4

Man kann in VDI-Umgebungen schon Teams und co einsetzen. Sollte dann mit den Software-Releases aber nicht schlafen.
Die Hersteller arbeiten daran Videostreaming zumindest möglich zu machen. Dazu sind sie auch verpflichtet, um Kundschaft halten zu können. Wer dann aber mit zeitnahen Updates spart schießt sich selbst ins Bein.

Nehmen wir einen Wyse 3040 und heben ihn sowohl vom Control-Server als auch vom eigenen Betriebssystem auf den aktuellst-verfügbaren Stand. Damit kann man in gewissen Grenzen auch Videochats tun. In ThinOS9 funktioniert nun auch endlich das Weiterleiten aller USB-Klassen und damit eben auch Headsets und allem.

Also eine aktualisierte Checkliste:

  • Updates: Aktuelle Citrix-Storefront, aktuelles alles…
  • USB-Redirection: Die Headsets, die angeschlossen werden, sollten auch für die Citrix-Maschinen die sein, die sie für andere Hosts wären. Weil die Citrix “virtual” Devices (sprich: irgendwelche vermurksten Treiber von Citrix) unter Garantie Features deaktivieren die Headsets sonst hätten und gewissermaßen auch brauchen. Zertifizierte Headsets für Unified Communications oder MS Teams sind da nur ein Beispiel.
  • Nicht die billigsten ThinClients.

Ein Wyse 3040 kann Video in so ungefähr 144px Qualität übertragen. Ob das mit einem 5470 auch so ist, konnte ich noch nicht analysieren…

Also: Man kann doch Conferencing in einer VDI-Umgebung machen. Sobald man die üblichen Hürden eines IT-Dienstleisters der oft veraltete Software auf Krampf am Leben hält (neue Lizenzen wären ja teuer und das wäre blöd für die Marge) hinter sich hat, ist es zumindest annehmbar aber auch noch weit von dem entfernt, was der übliche Anwender aus Universität und co. gewöhnt ist.

Hier geht es sicherlich wieder in Richtung Henne-Ei-Problem. Kunden wollen dafür kein Geld ausgeben, deshalb sind die Dienstleister dazu gezwungen auf Krampf out-of-support Software zu supporten und dann dreht sich die Spirale so lange, bis der Kunde notgedrungen die Arbeitskosten für Updates genehmigt. Dann ist auf einmal wieder alles super, was der Dienstleister dann wieder als eigenen Erfolg verbucht. Letztendlich aber doch normaler technischer Fortschritt der nicht zeitgemäß übernommen wird.

Firefox Gruppenrichtlinien vollständig umgehen

Ihr kennt das sicherlich, auf einmal ist man in einem Domänennetz und die Gruppenrichtlinien schreiben dem Firefox vor das alles was about: ist gesperrt ist.

Umgehen kann man das mit einer user.js im Profilordner. Bzw. schreibt man sich die Änderungen dessen GUI durch die GPO gesperrt ist direkt ins User-Profil vom Firefox. Das liegt in %AppData% und das anzufassen macht dem Endanwender seine Software doch kaputt. Also wissen wie:

%AppData%\Mozilla\Firefox\Profiles\

hier ein wenig raten welches Profil bei euch wirkt, schließlich könnt ihr about:profiles nicht aufrufen. Wenn da mehrere Profile sind schadet es sicherlich auch nicht eure user.js dann in jedes dieser Profile zu kopieren, dann wisst ihr dass sie auf jeden Fall wirkt.

Da drin gehört dann eine user.js-Datei. Wenn sie schon vorhanden ist, umso besser, dann müsst ihr sie nur erweitern. Nach folgendem Schema:

user_pref("about:config-Wert", boolean);
user_pref("about:config-Wert", "string/integer/etc");

Damit habt ihr nun alles was euch about:config bietet auch bei wirkenden Gruppenrichtlinien.
Das kann absolut jeder normale Benutzer der Domäne tun, weil er ja Schreibzugriff auf seine eigenes %AppData% braucht um überhaupt arbeiten zu können.

Persönliche Präferenz:

user_pref("network.http.max-connections", 96);
user_pref("network.http.max-connections-per-server", 64);
user_pref("network.http.pipelining", true);
user_pref("network.http.pipelining.maxrequests", 16);
user_pref("network.http.proxy.pipelining", true);

Exchange On-Premise: Mails von Freigegebenen Postfächern in der Outlook App

Nachgetragenes Vorwort

Letztendlich gibt es einige Methoden – von der besten hin zur schlechtesten:

  • Der OnPrem wird komplett zu einem Exchange-Online in der Azure Cloud transferiert, nach Umstellung den OnPrem komplett abschalten. (Dazu gehören allerdings auch Gedanken was man dann mit den Domaincontrollern tut)
  • Im Hybridbetrieb ist die Online-Variante mit Microsoft 365 autodiscover für die Mailabhandlung zuständig, der OnPrem Exchange schiebt dann nur ein noch nicht modernisiertes altes AD hoch und dient nur als Schnittstelle eines veralteten ADs hin zum Exchange Online. Die Variante anders herum, wenn der OnPrem die Mails abhandelt funktioniert meines Wissens nicht.
  • Das AD-Objekt vom Postfach aktivieren und ihm ein Kennwort setzen. Mit diesen Daten dann anmelden. Das verstößt allerdings gegen Lizenzrecht und bricht jeden Microsoft Audit. Ansatz hier ist dann das Umdrehen der gesamten Lizenzierung auf Gerätebasierte Lizenzen, damit könnt ihr womöglich dieses Problem umgehen.
  • die kommende Methode hier die vollkommen entgegen Datensparsamkeitsgedanken ist – damit kopiert ihr Mails

jetzt aber zurück zum Thema:

Eine direkte Methode gibt es nicht, aber eine indirekte. Die ist sehr sehr “dreckig”.
Die sauberste Lösung ist eine Kombi aus Azure AD und Exchange-Online – hier kann ich auch nur vermuten, meine aber gesehen zu haben dass sich hier Exchange verhält wie vom Anwender erwartet. Das tut OnPrem leider nicht.
Hier soll es aber um die dreckige Lösung gehen, weil man ja gewisse Datenschutz-Spinnereien bei der bloßen Erwähnung von “Azure” und “Exchange Online” hat

Gedanken zur dreckigen Methode

Mit der Methode kopiert ihr E-Mails. Das hat einmal den Datenschutz zur Folge, weil ihr automatisiert Mails an Postfächer anderswo hin kopiert.
Andererseits vergrößert es die Datenbank, da ja jede Mail doppelt abgelegt wird. Je nachdem wie viele Postfächer die Mail dann empfangen.
Speicherplatz sollte aktuell kein Problem mehr sein, dazu gehören aber Gedanken bzgl. der Performance und ob die Datenmenge in 2-3 Jahren weiterhin flüssig abgearbeitet werden kann. Stetig langsamer werdende Systeme wird der Anwender nicht bemerken, wohl aber abrupt nicht mehr funktionierendes.
Das hättet ihr mit der skalierbaren Lösung im Azure Umfeld mit Exchange Online direkt erschlagen. Siehe Vorwort und deren Priorisierung.

Die Mails zu kopieren ist also genau so viel Speicher wie bei einem Verteiler – es ist ja auch einer. Man könnte also auch absprechen ob man freigegebene Postfächer so umstellt, dass es dann Verteiler sind. Damit verliert man die übersichtliche Auflistung als extra Postfach und die Alten Mails aus dem Postfach zu kopieren ist ein ziemlicher Aufwand. Wenn die Anwender sich dazu keine Filterregeln im Outlook anlegen können ist das ein starker Negativ-Punkt der euch auch von Kunden oder Anwendern entgegen kommen wird.

In Kürze – oder für die Erfahrenen

ForwardingSMTPAddress, darauf achten dass DeliverToMailboxAndForward auf $true steht. Sonst stibitzt ihr den ganzen Desktop-Anwendern die Mails weg.
Begleitende Gefahren: ForwardingSMTPAddress ist als erweitertes AD-Attribut genügend intransparent und wird in kaum einer GUI angezeigt, oft ist es auch der letzte Punkt an dem der dann schon verzweifelte IT-Dienstleister nachsieht. Im MessageTrackingLog steht dann urplötzlich einfach ne andere Mailadresse drin.
Zudem sind alle Empfänger, auch externe möglich.
Das macht es enorm gefährlich, ForwardingSMTPAddress sollte also bei jedem IT-Sicherheitsmenschen auf der Liste stehen.

Code in der Management Shell:

Set-Mailbox -Identity "XY" -DeliverToMailboxAndForward $true -ForwardingSMTPAddress irgendeinemail@irgendeinedomain.com

Bei mehreren Empfängern benötigt es eine DistributionGroup, da das AD-Attribut nur eine Mail pro AD-Objekt fassen kann. Sind mehrere externe Empfänger notwendig arbeitet man mit Contacts.
Kontrolle:

Get-Mailbox -Identity "XY" | Format-List ForwardingSMTPAddress,DeliverToMailboxAndForward

Länger – für die nicht ganz so erfahrenen

Methodik: Mails von Freigegeben Postfächern an persönliche Postfächer weiterleiten. Microsoft hat stand heute (siehe Artikeldatum) noch nicht geschafft OnPrem-Exchanges den Abruf von Freigegebenen Postfächern in der eigenen Outlook App zu integrieren.
Geht die Mail doch ins persönliche gibts nen Pling auf dem Smartphone und Mobiluser sind glücklich.

Culprit: User von Outlook für den Desktop bekommen Mails doppelt zugestellt, solange sie das freigegebene Postfach ebenfalls abrufen.

Einrichtung

Erst einmal Exchange Management Shell aufmachen, ich gehe davon aus dass ihr wisst wie das geht. Ansonsten halt DuckDuckGo…
Jetzt gehts weiter:

Set-Mailbox -Identity "XY" -DeliverToMailboxAndForward $true -ForwardingSMTPAddress "irgendeinemail@irgendeinedomain.com"

Set-Mailbox: Fasse Postfach an, -Identity als Marker welche Mailbox gemeint ist
-DeliverToMailboxAndForward ist ein AD-Attribut, das sichert dass Mails zugestellt UND weitergeleitet werden, ist das nicht drin wird die Mail nur weitergeleitet und kommt gar nicht erst im Freigegebenen Postfach an. – $true ist ein Boolean, wollt ihr das nicht, lasst das Attribut weg, $false Booleans setzt man nur dann wenn man explizit false ausdrücken möchte.
-ForwardingSMTPAddress ist das wichtige Attribut hier, das muss die Empfängermail enthalten, als Mailadresse, nicht als -Identity. Kann alles sein, Hacker, externe Mails. Wir nutzen das hier aber nur um an intern weiterzuleiten, also Mail des persönlichen Postfachs rein an das weitergeleitet werden soll.

ForwardingSMTPAddress fässt genau eine Adresse, sind mehrere gefordert muss eine Verteilergruppe angelegt werden, dann ist der Verteiler der Wert fürs Attribut.

Der Befehl gibt nichts aus, wundert euch nicht. Deswegen die Kontrolle:

Get-Mailbox -Identity "XY" | Format-List ForwardingSMTPAddress,DeliverToMailboxAndForward

Get-Mailbox: Rufe Postfach auf,
-Identity kennt ihr schon.
| ist ein verketteter Befehl, ihr wollt was anderes als üblich haben.
Format-List (Ausgabe formatieren) – und dann die Attribute die wir eben angefasst haben.

Nun werden Mails an das freigegebene Postfach schön abgezwackt und in persönliche Postfächer zugestellt.
Nachteil wie oben aus dem Experten-Bereich: Niemand sieht das, jedenfalls niemand der nicht explizit daran denkt.

Dies ist nur die technische Methode, Datenschutz weiter auszuführen sollte jeder für sich machen. Das ist zu individuell.

Diese Methode weiterspinnen

Zusätzlich dazu sehe ich die Möglichkeit für die Empfänger von Freigegebenen Postfächern extra private-postboxes zu erstellen an die eben jene Mails dann weiter gehen, weil eben nur Private von Outlook Apps abgerufen werden kann. Damit haben die User dann eben zwei Postfächer in den Apps hinterlegt, von denen eins eine Spiegelung des freigegebenen ist.
Diese Methodik zieht allerdings andere Probleme mit, besonders wenn doppelte Privat-Postboxen eben auch doppelte AD-Accounts benötigen.

Fazit

Die Tage von On-Premise Exchanges sind gezählt. Heutzutage geht man statt lokaler Server eher den Weg zu redundanten Internet-Strecken um eben Azure und Microsoft 365 verlässlich erreichen zu können.
Microsoft wird sich also bezüglich Featureupdates für On-Premise Exchanges eher zurückhalten und die volle Energie in Microsoft 365 für Endkunden und Enterprise stecken. Das lässt die Zeitbombe für Unternehmen und Dienstleister ticken, die vielleicht aus finanzieller Sicht On-Premise weiterhin promoten, mit einem Stück Hardware, entweder beim Kunden oder als vom Dienstleister gemietetes Rechenzentrum lässt sich halt gut Marge fahren. Darauf sollte ein Vertrieb achten. Ich bin sowieso immer für sehr viel mehr Langzeit-Planung im vertrieblichen Bereich. Besonders beim Konflikt zwischen nachhaltig-verlässlicher Lösung und größerer Marge.

Das Problem von Freigegebenen Postfächern auf Mobilgeräten wird sich also auf längere Sicht selbst beheben, weil es früher oder später einfach gar keine andere Möglichkeit mehr als Exchange-Online geben wird.
Ein Quick-Win ist aber nur über diese “dreckige” Methode aus shared-postbox mails private-postbox mails zu machen verfügbar.

In VDI-Umgebungen macht man kein Conferencing – Kapitel 3

Im Grunde genommen funktioniert Videoconferencing in VDI-Umgebungen ganz gut. Sofern man sich auf die Basis-Funktionen einschränkt. Sprich: Bild und Ton von one-to-one, zwar mit mehreren, aber fokussiert auf One-To-One oder One-To-All Kommunikation. Ohne hitzige Diskussionsrunden.

Die Grundvoraussetzung dazu ist eine weit überdimensionierte Leitung. Gerade wenn potente Konferenz-Hardware eingesetzt wird kann es in aktiven Coronazeiten vorkommen dass neben dem eigentlichen Traffic auch mal zwei 4K-Streams durchgeschossen werden. Und dabei sind auch Teilstrecken zu beachten – aber das habe ich bereits zur Genüge erwähnt.

Letztes mal ging es darum dass Microsoft ja eigentlich keine zwei Varianten von Microsoft Teams hat. Sprich: Es hängt aktuell einzig und allein an Citrix oder dem VDI-System dies irgendwie zu wuppen.

Aber es gibt doch diese nette Funktion X?

Jeder Anwender wird Funktionen voraussetzen die Microsoft Teams in VDI-Umgebungen nicht unterstützt. Viele Anwender erwarten sogar alle Meetingteilnehmer zu sehen. (Die vereinzelten Personen die eine auf Gegenseite deaktivierte Kamera kritisieren mal ausgenommen).
Genau das unterstützt Microsoft in VDI noch nicht. Gerade im Desktop-Betrieb fällt es unbedarften Anwendern also schwer überhaupt zu realisieren wo man sich gerade befindet, deshal das Kriterium “Allen Anwendern ist bewusst was VDI ist und wo der Unterschied liegt” im letzten Kapitel.

Wir reden hier noch nicht von Anwendern die Funktionen aus Zoom oder BigBlueButton oder Jitsi oder welcher Software auch immer in Teams kopiert sehen wollen – wir reden hier von Basic Funktionen wie der Remotesteuerung oder simpel der Meetingaufzeichnung.

Wie gehe ich jetzt also vor wenn ich auf VDI angewiesen bin?

Ihr schaltet euch Teams in eurer VDI Umgebung. Für die Entscheider die dies einsetzen wollen. Sämtliche darauf folgende Meetings, egal ob alle sich im Büro gegenseitig anstecken oder nicht – finden über diese Installation statt. Alle produktiven Meetings der Entscheider müssen über Teams veranstaltet werden. Klar kann es Ausnahmen geben, dies aber Betriebsrats-mäßig per Beschluss in einer Konferenz.

Wenn es eine Ausnahme gibt, ist zu klären woran die Teams-Sitzung scheiterte und/oder warum die Sitzung nicht über Teams stattfinden kann. “Wir müssen Kekse essen” oder “Es ist doch netter sich zu sehen” ist hier kein Argument welches es notwendig machen würde.

Seid ihr auf lange sicht auf Meetings angewiesen, sei euch angeraten ThinClients durch Fatclients, ratsam in Laptop-Form zu ersetzen. Damit meine ich PCs mit Windows-Desktopsystem und entweder ausgerollten Desktops oder besser noch: ausgerollten Apps die dann auf VDI basieren. Damit tatsächlich in Einzelfällen VDI umgangen werden kann. Sehen die Anwender Verbesserung wenn sie VDI umgehen, werden sie sich sehr schnell daran gewöhnen, haben aber keine andere Wahl als VDI zu nutzen wenn eine App nun mal eben nur so kommt. Deshalb ist der Anwendungsbasierte Rollout besser, weil die meisten Anwender dann nicht mehr zwischen VDI und Lokal unterscheiden können. Das klingt etwas paradox, aber integriert per GPO ausgerollte lokale Apps viel besser und bei gut gemachtem Citrix dann ohne viel Unterschied zwischen VDI-Apps.
Es kommt aber immer darauf an ob es buchhalterisch günstiger ist als eine deutlich schnellere Leitung zu schalten und den VDI-Terminalserver mehr oder weniger mit ordentlicher Grafikpower auszustatten.

Ich kann momentan nicht über ein System mit potentem Terminalserver sprechen. Gefühlt lagert ein nicht darauf ausgelegter Terminalserver quasi alles auf den Client aus, damit schauen ThinClients per se in die Röhre. Egal ob eine Webcam überhaupt möglich ist oder nicht (Mit beabsichtigtem Seitenhieb auf Dell).

In VDI Umgebungen macht man kein Conferencing – Kapitel 2

Grundvoraussetzungen für den halbwegs sicheren Betrieb von Videoconferencing in VDI-Umgebungen:
Logisch:
– jedem Anwender ist der Unterschied zwischen VDI und nicht-VDI bekannt, auch den Zero- oder noch Thin-Client-Benutzern, die letztlich keine Ebene außerhalb von VDI steuern können.
– den Anwendern wurde erklärt worin der Unterschied zwischen Teams in VDI und außerhalb von VDI liegt. Nicht zur Verfügung stehende Teams-Features sind ihnen bekannt. Dies werden nicht die Anwender ansprechen, sondern externe Meetingteilnehmer, die diese Funktion auf der VDI-Seite vermissen werden.

Technisch:
– Die LAN-Umgebung ist stabil, eine Umgebung aus WLAN-Accesspoints ist ausreichend getestet, Verbindungsabbrüche durch fehlerhafte Handover-Vorgänge können ausgeschlossen werden. Das Verhalten der Accesspoints bei Überlast ist bekannt und führt nicht zu Abbrüchen bei bereits vorhandenen Nutzern.
– QoS, die Leitung ist angemessen dimensioniert. Alle Netzwerksegmente sind ausreichend dimensioniert. Gigiabit-Leitungen zum VDI-Server sind sinnlos, wenn dieser selbst mit 50 Mbit/s angebunden ist. 50 Mbit/s ist bereits für eine Teams-Sitzung zu wenig.
– Die Sitzungen werden tunlichst nicht über ZeroClients abgehalten, auch wenn es eine Optimierung z.B. von Citrix gibt kommt es entscheidend auf Hardware an, und VDI setzt den Treibern für Kamera und Audiogeräten noch eine Ebene dazwischen, die unnötig und komplex ist.

Offene Fragen:

Citrix bietet eine Optimierung für die Verwendung der Desktopversion von Microsoft Teams (1.2.00.31357 oder höher) in Citrix Virtual Apps and Desktops und der Citrix Workspace-App.

Optimierung für Microsoft Teams (citrix.com) – 04.01.2020

im Gegensatz zu Microsoft, welche eine spezielle Teams-Version für VDI-Umgebungen bereitstellen, dessen SHA256 bd405f1fd163bd703fb9615c28c93506073d92674fed4261a950a1350febb8c5 nicht anders ist als die Deployment-Variante von Teams ist.
Gibt es also überhaupt mehrere Teams Versionen, oder legt sich Microsoft hier schlafen und hofft darauf dass Citrix und andere VDI-Lösungen einen Weg finden werden? Den Einzigen sichtbaren Unterschied tut Microsoft bei GCC (US-Regierung) und DoD (US-Militär), nicht bei VDI.

In VDI Umgebungen macht man kein Conferencing

Es gibt Unternehmen die basieren auf Citrix oder anderen VDI Lösungen. Das ist verständlich, immerhin spart es nicht unmerklich ressourcen und die Administration ist in einer Thinclient Umgebung bedeutend leichter als in einer Umgebung voller Windows-Maschinen.
Dank Corona muss nun jeder aber seine Gesichter beim sprechen sehen, ein Telefonat reicht noch nicht aus.
Jedes Unternehmen dessen Struktur auf VDI gesetzt hat, hat dadurch nun Probleme

Ist da nicht gerade Microsoft / Citrix / VDI Hersteller XY dran?

Ja, wie auch für den Mittelstand und die kaputtgesparten deutschen Privat-ISPs ist der Conferencing-Bedarf für Microsoft zum Problem geworden. Niemand rechnet mit einem sprunghaften Anstieg der Nachfrage – dazu muss man sich nur Toilettenpapier während des ersten Lockdowns ansehen. So hat auch Microsoft nicht sehen können dass sich nun jeder von zu Hause aus über eine Leitung die für den Upload nie ausgelegt war für andere sichtbar machen möchte. Game-Streamer waren ja bisher nur ein Randphänomen.

Microsoft arbeitet daran Teams in VDI Umgebungen zu bringen, Citrix unterstützt in dem es die Rechenlast auf das Endgerät auslagern kann.
Was bedeutet das? Egal ob VDI oder nicht, Videochat und Conferencing wird für den Client nichts anderes sein als wäre VDI nicht vorhanden. Damit bekommt jede Firma, die Ihre Kosten durch Thinclients optimiert hat nun Probleme. Thinclients sind per Konzept nicht dazu geeignet lokale Rechenleistung auszuführen. Da ist es ganz gleich wie teuer der Thinclient ist oder wie überdimensioniert RAM und CPU in diesem sind. Der Teufel steckt im Konzept.

Aber was kann ich denn sonst tun?

Habt ihr nur Thinclients habt ihr Pech. Da Citrix oder eure VDI Lösung, wenn sie nicht App-Basiert austeilt nur Desktops verteilt können die Anwender kein Videoconferencing dort machen. Was bleibt ist der lokale Breakout – also Teams lokal zu verwenden. Verteilt ihr Desktops wird es unbequem, weil die Anwender ständig wechseln müssen.

Es bleibt also nur die Nutzung auf dem lokalen Endgerät und damit die komplette Umgehung von jeglichem Firlefanz den VDI in die Netzwerk-Wege schreibt. Keine Treiber-Virtualisierung, reines DSL, zur Not via VPN-Lösung. Lokal auf dem Device. Zumindest so lange bis Microsoft realisiert hat, dass man Techniken von Google Stadia auf zeitkritisches Videoconferencing übertragen kann. Dies wird meines erachtens spätestens mitte 2022 so weit sein – Microsoft hat sich ja immerhin (und das aus gutem Grund) relativ stark auf Hardware konzentriert.

Cookie Consent Banner von Real Cookie Banner