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.

Word druckt einzelne Dokumente nicht auf Briefpapier

Es gab ein kleines Problem auf das ein angehender ITler gelegentlich mal im Anwendersupport stoßen könnte. Direkt in der Anwenderanfrage „Wenn ich genau diese Dokumente drucke, und dafür Briefpapier auswähle, dann kommt es trotzdem immer auf Normalpapier im Drucker raus“.

Das Phänomen dabei: öffnet man Word, auch beim Anwender direkt, kann dieses problemlos ein Testdokument auf Briefpapier drucken. Öffnet man das vom Anwender erwähnte Dokument wird dieses nicht auf Briefpapier gedruckt.
Vorerst muss ich aber anmerken dass dies hier beschriebene nur ein Workaround ist – keine endgültige Problembehebung.

Um das ganze zu verstehen setzt man sich aber nicht an die Lösung, sondern erst an die Umformulierung des Poblems:

  • Der Drucker scheint die eingestellten Druckoptionen zu ignorieren
  • Die von der Anwenderin gewünschten Druckoptionen werden durch andere Programme oder Richtlinien überschrieben

Genau da liegt dann auch das Problem. Die Anwender scheinen in dem Fall mit einer Vorlage zu arbeiten (oft auch komplett unbemerkt – z.B. durch kopieren und anpassen ähnlicher Dokumente zum erstellen neuer Dokumente).

Um dahinter zu kommen tut man folgendes:

  • .docx Datei kopieren und die Kopie in .zip umbenennen
  • diese .zip-Datei entpacken
  • im Unterordner /docProps/ die Datei app.xml öffnen
  • in dieser XML-Datei steht unter <Template> das entsprechend verwendete (oder durch Domänenrichtlinie vorgeschriebene) Template
  • Dieses Template kann einen Druck auf Briefpapier oder anderen Formaten als Normalpapier verhindern.

Hier hat man also das verwendete Template und könnte für die endgültige Lösung z.B. bei einem vorgeschriebenen Template durch eine Domänenrichtlinie eine Anpassung durchzuführen. Ist dies nicht möglich oder würde für dringende Dokumente zu lange dauern tut man folgendes:

  • Im entsprechenden Word-Dokument „Datei“->“Optionen“->“Add-Ins“-> Im Dropdown-Menü „Vorlagen“ auswählen.
  • Auf den Button neben dem Feld klicken
  • unter Dokumentvorlage kann eine andere Vorlage ausgewählt werden, normal.dotm ist in dem dann geöffneten Ordner die Standardvorlage von Word.

Damit sollte in dem Fall für dieses Dokument der Druck wieder auf jeglichem Papierformat möglich sein. Für sämtliche Kopien dieses Dokuments (auch nach Anpassungen) auch. Wird allerdings ein anderes Dokument mit alter Vorlage kopiert tritt der Fehler erneut auf – hier empfiehlt es sich also eine Datei zu speichern die für Anwender als Vorlage zum kopieren gilt.