Archiv der Kategorie: Computers and Internet

Fedora Workstation 44 | Jetzt will die Maus garnicht mehr

Veröffentlicht am von
Antwort

Manche Hardware funktioniert einfach, die Microsoft Bluetooth Mouse 3600 unter Fedora 44/GNOME 50 gehört leider nicht dazu. Während sie am Surface Laptop 3 unter Windows jahrelang perfekt lief, war der Umzug auf Linux für das ‚Mausi‘ der Anfang vom Ende. Das Pairing mit Bluetooth wurde stetig schlechter, bis sie mit dem Upgrade auf Fedora 44 nun komplett unbrauchbar geworden ist.

Man muss dazu wissen, dass der mit Fedora 44/GNOME 50 eingeführte Bluetooth-Stack eine gewisse Zurückhaltung gegenüber BLE-HID-Geräten zeigt, was häufig zu Verbindungsproblemen führt.

Eine kurze Beschreibung des Problems

  • Nach dem Upgrade verbindet die Maus nicht mehr automatisch
  • Manuelles Pairing funktioniert, aber nur mit Geduld
  • Und die MAC‑Adresse der Maus wechselt fröhlich hin und her1

1) und ja, auch Bluetooth-Mäuse haben eine MAC-Adresse

Zeit also, der Sache auf den Grund zu gehen, bevor ich die Anschaffung einer neuen Maus überhaupt in Erwägung ziehe. Man ist ja irgendwo auch Schwabe 😉

Das Sympton ist, die Maus wird angezeigt aber Linux tut so als ob es eine neue wäre

Nach dem Upgrade auf Fedora 44 zeigt bluetoothctl folgende Info an:

Device F1:00:85:92:CA:34 (random)

Die Maus meldet sich mit wechselnden BLE‑Adressen. Das ist normal, nennt sich „Resolvable Private Address“ RPA . BlueZ erkennt solche Geräte über einen Identity Resolving Key (IRK). Wenn der IRK fehlt, denkt Fedora bei jeder neuen Adresse: „Noch nie gesehen …“ und das Theater geht los.

Das erklärt, warum AutoConnect nicht funktioniert, obwohl die Maus korrekt gepairt ist.

Die Ursache liegt in einem blockierten AutoConnect vor der Anmeldung

Mit GNOME 50 (und der damit einhergehenden Entwicklung in den zugrunde liegenden Bibliotheken wie bluez) wurde das Sicherheitsmodell für Bluetooth verschärft. BLE-HID-Geräte (wie die Mouse 3600) benötigen oft einen aktiven Austausch von Schlüsseln beim Reconnect. Wenn der Agent der User-Session noch nicht aktiv ist, schlägt dieser Austausch fehl oder wird vom System ignoriert, um unautorisierte Verbindungen auf Hardware-Ebene zu verhindern.

Letztendlich sehen wir die folgenden Syptome:

  • kein AutoConnect beim Boot von Linux
  • manueller Connect funktioniert (bei Fedora 44 auch nicht immer und davor doch recht zuverlässig) oft erst nach 60 bis 120 Sekunden
  • Zur Verbindung muss eine User-Session vorhanden sein

Der erste Schritt ist, dass wir mit der Maus ein neues Pairing durchführen müssen:

bluetoothctl
remove <DEVICE-MAC>
scan on
pair <DEVICE-MAC>
trust <DEVICE-MAC>
connect <DEVICE-MAC>

Schauen wir uns aber die info-Datei für die Maus an, so sind nach einen korrekt erfolgtem Pairing alle notwendigen Einträge vorhanden.

# Speicherung der Bluetooth-Informationen der Maus in der info
/var/lib/bluetooth/<ADAPTER-MAC>/<DEVICE-MAC>/info

Die Datei beinhaltet alle notwendigen Informationen wie den IRK, LTK und HID-Services.

Wir merken uns:

  • ADAPTER-MAC = Hardware-Adresse des Bluetooth-Controllers im Laptop (die ist und bleibt statisch)
  • DEVICE-MAC = Hardware-Adresse der Maus (Device), die sich in Grenzen dynamisch verhält

Den Pfad oben bauen wir als wie folgt zusammen, und dazu wechseln wir der Einfachheit halber in den interaktiven Sudo (wer in diesem verbleibt, spart sich in den kommenden Konfigurationen das nervige tippen von Befehl und Passwort):

# Wechsel in den interaktiven sudo-Modus
sudo -i

Am einfachsten (und damit ohne Tipp-Fehler), lassen sich Verzeichnispfade mit ls und der TAB-Taste verwenden:

# Dazu ls und TAB für die Expansion des folgenden Pfads verwenden
#- wichtig ist, dass die MAC-Adresse des Controllers bei Euch anders heißt!
ls '/var/lib/bluetooth/F0:1D:BC:9C:AC:9D'

Hängen wir dann an diesen Pfad die DEVICE-MAC mit an, können wir im Verzeichnis die info-Datei der Microsoft Bluetooth 3600 finden.

Damit ist die technische Basis gelegt.

Die zweite Baustelle sind die wechselnden MAC-Adresse der Maus (DEVICE-MAC)

Die Microsoft Maus nutzt Adressen, die immer mit F1:00:85: beginnen. Der Rest ändert sich.
BlueZ erkennt die Maus über den IRK, aber GNOME 50 leider nicht zuverlässig.

Das Problem konnte mit einer udev-Regel, die hilft den Connect auszulösen, sobald die Maus auftaucht, gelöst werden.

Die Sache wird nun als dritter Schritt an systemd übergeben und dort in eine Regel gepackt

# udev-Regel erstellen
sudo nano /etc/udev/rules.d/99-bt-mouse-autoconnect.rules

# Inhalt der Regel
ACTION=="add", SUBSYSTEM=="bluetooth", ATTR{address}=="F1:00:85:*", RUN+="/usr/bin/bluetoothctl connect %E{address}"

Genau genommen arbeitet die Regel die folgenden Aufgaben ab:

  • Sie reagiert auf jedes Bluetooth‑Gerät, dessen Adresse mit F1:00:85: beginnt
  • %E{address} übergibt die aktuelle (random) MAC an bluetoothctl
  • GNOME 50 wird komplett umgangen
  • Die Maus verbindet sobald sie auftaucht

Die Regel sollte automatisch ausgeführt werden und damit blieb nur der Weg das mit einem systemd-Service um GNOME „herumzubauen“ (zumindest habe ich keine andere Möglichkeit gefunden).

Damit umschiffen wir die folgenden Problemzonen:

  • GNOME‑Agent‑Blockade
  • Race‑Condition beim Login
  • 60–120‑Sekunden‑Timeout
  • verzögerten BLE‑Reconnect

Der funktionierende systemd-AutoConnect-Service:

# Als erstes muss der Service angelegt werden
sudo nano /etc/systemd/system/bt-mouse-autoconnect.service

# Und der Service in der Config definiert werden
[Unit]
Description=Auto-connect Bluetooth Mouse after GNOME startup
After=graphical.target bluetooth.service
Wants=bluetooth.service

[Service]
Type=oneshot
ExecStart=/usr/bin/bluetoothctl connect F1:00:85:93:CA:34
ExecStart=/usr/bin/sleep 2
ExecStart=/usr/bin/bluetoothctl connect F1:00:85:93:CA:34

[Install]
WantedBy=graphical.target

Das Timing im Logon-Prozess ist nicht ganz optimal, darum probiert es der Service mit dem Start nach 2s ein zweites Mal.

Zum Schluss fehlt nur noch die Aktivierung des Service verbunden mit einem Neustart:

# Aktivierung des Service
sudo systemctl daemon-reload
sudo systemctl enable bt-mouse-autoconnect.service

# Reboot
sudo reboot

Fazit

Die Maus läuft und ich muss keine neue mehr besorgen, zumal ich die Teile immer sehr mochte da sie wirklich robust und zuverlässig waren sind. Auch wenn ich mich erneut an dem Surface Laptop anmelde, ist die Maus nach ca. 30 Sekunden da. Man könnte hier sicherlich noch eine Reihe von Optimierungen und Retries bauen, ich will es aber dabei belassen. Wie sagt der Schwabe gerne „für me duats des“ … und er ist glücklich, muss er doch keine neue Maus kaufen.

Enjoy it, b!

Upgrade | Fedora Workstation 44

Veröffentlicht am von
Antwort

Ende April war es wieder so weit: Eine neue Fedora-Version stand vor der Tür. Mein bewährter Surface Laptop 3 wartete bereits auf das Upgrade auf die Version 44. Doch diesmal lief der Prozess über die Shell nicht ganz so reibungslos durch, wie ich es gewohnt war. Ein Paketkonflikt im Bereich des Power-Managements stoppte das Vorhaben abrupt.

Das Problem waren die Pakete für das Power-Management

Beim Versuch, das Upgrade einzuspielen, brach DNF mit einer Fehlermeldung ab. Der Kern der Nachricht: Dateikonflikte zwischen tlp und tuned-ppd. Beide Pakete versuchten, dieselben DBus-Service-Dateien unter /usr/share/dbus-1/ zu beanspruchen.

Hier der Fehler im Detail:

Fedora hat mit Version 44 den Wechsel hin zu tuned als Standard-Daemon für Stromsparprofile vollzogen. tuned-ppd dient dabei als Schnittstelle, damit die GNOME-Einstellungen (der Schieberegler für „Leistung/Ausbalanciert/Energiesparen“) weiterhin funktionieren. Wer – wie ich – in der Vergangenheit manuell TLP installiert hat, um das Maximum aus dem Akku des Surface herauszuholen, gerät hier in einen harten Ressourcenkonflikt.

Die Lösung war die Deinstallation von TLP

Da Fedora 44 nun massiv auf tuned setzt, habe ich mich dazu entschieden, TLP den Laufpass zu geben und auf den neuen Standard zu setzen. Damit war der Weg für das Upgrade frei.

Folgende Schritte in der Shell haben das Problem gelöst und beschreiben dazu noch das Upgrade:

Die Befehle und Fehlermeldungen findet ihr in dieser Datei, aber bitte nur Schritt für Schritt ausführen.

Nach dem Upgrade ist vor dem Upgrade …

Was mir sonst noch aufgefallen ist (nach dem Upgrade):

Das bisher verwendete Hintergrundbild stammte noch aus Fedora 43 und wurde beim Upgrade entfernt. Daher musste ich ein neues Wallpaper aus dem Fedora‑44‑Paket auswählen.

Die OneDrive‑Integration schlug wiederholt fehl. Erst nach dem vollständigen Entfernen der bestehenden Verbindung und einer neu erforderlichen App‑Registrierung über GNOME konnte die Synchronisation wiederhergestellt werden

Fedora Workstation verwendet aktuell noch den 6er‑Kernel. Das ist jedoch kein Nachteil – das System läuft stabil, wie schon seit langer Zeit.

Fazit

Wieso es genau zu diesem Konflikt kam? Wahrscheinlich habe ich in Fedora 43 zu intensiv an den Energieeinstellungen optimiert und dabei TLP als Ergänzung oder Ersatz installiert. Da Fedora 44 nun eine eigene, moderne Architektur für diese Profile mitbringt (tuned-ppd), vertragen sich die beiden Ansätze auf Dateiebene nicht mehr.

Nach dem Reboot lief mein Surface Laptop 3 anstandslos unter Fedora 44 hoch. Wer also vor einem ähnlichen „Transaction failed“ steht: Prüft eure installierten Power-Management-Tools und werft einen Blick auf die Gnome-Extensions, nicht alle waren zum Start von Fedora 44 kompatibel.

No Panic please!

Ja, nein, vielleicht — und bevor ich mich weiter in dieser Antwortmatrix verliere, schreibe ich jetzt einfach ein paar Sätze. Dieser Blog hier nennt sich Windows SBS und Essentials Blog, und genau so ist er im Mai 2008 gestartet. Der erste Beitrag? Natürlich ein Defekt des CPU‑Lüfters in einem Lexmark X502n Multifunktionsdrucker. Ein würdiger Auftakt für eine lange Reise voller Themen, die streng genommen alle aus dem Small‑ und Medium‑Business‑Umfeld stammen. Und ja: Ich dachte damals, das könnte vielleicht irgendjemandem helfen.

Zur Überraschung: Hat es und tut es immer noch, auch wenn sich die KI an den Themen sattfrist und 50% der Hits weggefallen sind.

Den eigentlichen Windows Small Business Server (SBS) und seinen Nachfolger, den Windows Server 2012 Essentials (SBE), hat uns Microsoft dann genommen — in der charmanten Annahme, kleine Firmen würden natürlich alle in die Cloud wechseln.

Spoiler: Das war gleichzeitig richtig und komplett daneben. Die Chance, Exchange aus den Kellern der Kunden zu befreien und in kompetente Hände zu legen, konnte ich mir jedenfalls nicht entgehen lassen. Also habe ich ASAP eine Menge Migrationen von Exchange (SBS 2008 R2) nach BPOS durchgeführt. Und obwohl ich im Enterprise‑Bereich schon einige Exchange‑Wiederherstellungen überlebt hatte, wollte ich mir diesen Nervenkitzel bei kleinen Kunden nicht mehr antun. Man wird ja nicht jünger. Zusätzlich gibt es im SMB-Umfeld eine Reihe von LOB-Anwendungen die ein wahres Horrorkabinet darstellen … und während die Hyperscaler an die Cloud denken, kämpfe ich mit „lokalen Admins“ damit die Praxissoftware überhaut läuft!

Linux und ich — das ist übrigens keine Beziehung, die erst begann, als virtuelle Router plötzlich „hip“ wurden oder eine SSH‑Session auf ein Synology‑NAS die Tür zu erweiterten Konfigurationen (oder nennen wir es ruhig „Hacks“) öffnete. Nein, Linux war mein zweiter Dateiserver nach Novell NetWare 3.1. Irgendwann in den 90ern habe ich mich — schneller als manche Großunternehmen — entschieden, im Heimnetz auf TCP/IP umzusteigen. Aus Kostengründen lief auf dem Server Linux mit einem Kernel 1.x und Samba. Der Client war bis 1996 OS/2 Warp 3, und erst dann haben Windows NT 4.0 und ich uns endlich gefunden. Eine späte, aber stabile Beziehung.

Grundsätzlich soll hier jedes Betriebssystem seinen Platz finden, das im SMB‑Umfeld sinnvoll ist und mich gelegentlich an den Rand der Verzweiflung bringt — äh, ich meine: vor interessante Herausforderungen stellt.

Darum wird es in diesem Blog auch weiterhin um Themen aus dem SMB‑Kosmos gehen. Vielleicht nenne ich ihn irgendwann sogar „Small‑ und Medium‑Business‑Blog“ oder etwas ähnlich Kreatives. Was meint ihr dazu?

Enjoy it, b!

Windows 11 | Warum sich das WLAN trotz einer LAN-Verbindung einschaltet

Veröffentlicht am von
Antwort

Wer viel oder ausschließlich mit einem Windows-Notebook arbeitet, kennt das Phänomen: Obwohl eine LAN-Verbindung aktiv ist, verbindet sich Windows zusätzlich mit dem WLAN.
Das wirkt zunächst unnötig, kann aber durchaus Sinn haben – und manchmal auch Probleme verursachen.

Warum macht Windows das eigentlich?

  • Redundanz und Ausfallsicherheit: Windows hält mehrere Schnittstellen aktiv, um bei Ausfall einer Verbindung sofort umschalten zu können.
  • Automatische WLAN-Verbindung: Bekannte Netzwerke werden standardmäßig verbunden, selbst wenn LAN aktiv ist.
  • Routing-Logik: Der Datenverkehr läuft über die Schnittstelle mit der niedrigsten Metrik (meist LAN), WLAN bleibt aber als Backup bestehen.

Natürlich kann das zu Problemen führen

Mögliche Lösungen

  • Automatisch WLAN deaktivieren, wenn LAN aktiv ist per Gruppenrichtlinie:
    Computerkonfiguration / Administrative Vorlagen / Netzwerk / Windows-Verbindungsmanager / WLAN deaktivieren, wenn LAN verbunden ist
  • Automatisch WLAN deaktivieren, wenn LAN aktiv ist, über eínen Registry-Key (analog zur Gruppenrichtlinie): 
    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WcmSvc\Local]
    "fMinimizeConnections"=dword:00000000

  • Netzwerkpriorität anpassen
  • In den Adaptereigenschaften die Metrik manuell setzen oder per PowerShell: 
    # Metriken der Netzwerk-Adapter setzen
    Set-NetAdapter -Name "Wi-Fi" -InterfaceMetric 50
    Set-NetAdapter -Name "Ethernet" -InterfaceMetric 10

    So bleibt WLAN aktiv, wird aber nicht genutzt

Fazit

Windows verhält sich hier nicht „falsch“, sondern vorsorglich. Wer jedoch klare Regeln braucht – etwa im Unternehmensnetzwerk oder für stabile VPN-Verbindungen – sollte die Prioritäten anpassen oder WLAN bei LAN-Verbindung deaktivieren.

Enjoy it, b!

Windows 11 | Transparente Taskbar mit Windhawk

Veröffentlicht am von
1

Hallo zusammen, ich wünsche euch ein gutes neues und vor allem gesundes Jahr!

Ich muss zugeben, dass dieser Beitrag eigentlich nicht mein Arbeitsgebiet ist. Er hat sich letztlich aus einer Kundensituation heraus ergeben.

“Losing my Religion?”

Selbstverständlich ist das Gras auf der anderen Seite immer ein bisschen grüner, weshalb in einem Kundenprojekt entschieden wurde, auf Apple-Hardware zu setzen. Es kam zur Ausstattung von Mitarbeitern mit MacBooks und iPads, da angeblich alles webbasierend ist. Ich will hier auch keinen Hate gegen Apple fahren und die Details wieso man auf einmal trotzdem Windows benötigt, spielen keine Rolle. Auf jeden Fall sollten auf einmal eine Reihe von Windows-Laptops zum Einsatz kommen. Man hatte sich für die Surface Laptops aus dem Hause Microsoft entschieden. Alles kein großes Ding, aber … der Kunde wollte einen „Mod“, damit die Microsoft-Geräte mehr nach Apple ausschauen? Bis mir klar wurde, worauf das hinausläuft, hatten wir satte zwei Stunden diskutiert, aber vor allem um den heißen Brei herumgeredet.

Windows 11 wäre nun wohl doch in Ordnung, aber die Taskleiste gefiel nicht – sie sollte mehr nach macOS von Apple aussehen. Damit kam Windhawk ins Spiel. Meine ohnehin schon minimierte Taskleiste unter Windows 11 genügte nicht.

{578D3CD8-38D6-4EC0-A5FA-60B7F37D406F}

Ich schalte generell die Suche, Task view und die Widgets ab und erreiche damit ein recht schlankes Aussehen, aber nein man wünschte sich eine “gewisse Transparenz”.

Installation von Windhawk

Windhawk ist kostenlos und kann direkt unter https://windhawk.net heruntergeladen werden. In diesem Fall war dazu noch ARM-Support gefordert, genauso wie der Einsatz als Portable-Version (was während der Installation ausgewählt werden kann).

Darum hatte ich mich entschieden das Portable unter \Users\Public\.Windhawk zu installieren und dafür schon ein Verzeichnis erstellt. Nach dem Download des Installers und der Auswahl der Sprache besteht die Möglichkeit zwischen einer Installation oder der Verwendung der Portable Version zu wählen.

{7C5F1C13-2F52-4F91-A683-F11E47502CAE}

Wie schon geschrieben, sollte es hier die Portable sein und darum habe ich das dafür erstellte Verzeichnis ausgewählt.

{520DF6AA-4A87-4D4C-BAB0-75ADD8232DC4}

Ein Klick auf Install schließt die Installation ab und Windhawk kann konfiguriert werden. Der Zugang ins Internet ist dabei zwingend notwendig, da Windhawk noch einiges an Dateien nachladen muss.

Ein Klick auf Browse for Mods bringt einem dann auch gleich zum Taskbar Styler.

image

Dieser wird mit einen Klick auf Details geöffnet und kann seiner Installation wiederum konfiguriert werden.

image

Nach dem Bestätigen eines Sicherheitshinweises startet die Installation und dauert wiederum eine Weile. Danach stehen über 10 Themes zur Verfügung, von denen ich dachte das Docklite wohl das richtige wäre. Aber weit gefehlt, am Ende fiel die Entscheidung für das SimplyTransparent-Theme, was mir wiederum auch recht sein sollte Smile

Das Theme kann unter Details ausgewählt und bei Bedarf nochmals angepasst werden.

image

Save Settings aktiviert das Theme und damit bleibt nur noch das automatische Start von Windhawk, der allerdings bei der Portable-Version über shell:startup nicht wirklich funktioniert.

Darum habe ich einen Task angelegt, der den Start von Windhawk mit der Anmeldung des Benutzers verbindet. Dazu den Task Scheduler starten und einen Task mit den folgenden Einstellungen anlegen.

Create a Basic Task / Name: Starting Windhawk with user logon

image

Next öffnet den Dialog für den Task Trigger, wo When I log on ausgewählt werden soll.

image

Wiederum mit Next kommt man zur Konfiguration der eigentlichen Action mit Start a program. Hier wird der Pfad zur Windhawk.exe in Verbindung mit einem Parameter zur Anzeige von Windhawk im Windows Tray konfiguriert.

image

Abermals mit Next und dann Finish wird die Konfiguration abgeschlossen und Windhawk lädt die eingestellte Konfiguration automatisch nach der Anmeldung des Benutzers.

Noch ein kleiner Hinweis, die Pfade können selbstverständlich auch qualifiziert werden, also C:\Public anstatt \Public …

Sieht dann am Ende wie folgt aus, wem es gefällt … ?!

{858E22B1-4AFC-47A7-8E6D-24390C2F6280}

Nachtrag … natürlich ein wenig PowerShell-Magie

Den Task könnt ihr auch mit einem PowerShell-Skript anlegen.

Wichtig ist, dass die Einträge davor angepasst werden. Die Zeile 12 funktioniert sowohl bei PCs die in einer Domäne sind, als auch bei PCs in einer Workgroup. Ich halte es für sinnvoll, Windhawk nur für einen expliziten Benutzer laufen zu lassen und zum Beispiel einen lokalen administrativen Account davon auszunehmen – nur für den Fall, dass man den Explorer abschießen sollte Winking smile

Enjoy it, b!

Canon imageRunner | Drucken mit Windows on Arm (WoA)

Veröffentlicht am von
Antwort

Wer heute ein WoA-Device einsetzen möchte, stößt früher oder später auf ein altbekanntes Problem: fehlende Treiber. Besonders Druckerhersteller tun sich schwer damit, native ARM‑Treiber bereitzustellen – und Canon bildet hier leider keine Ausnahme. Für den Canon imageRUNNER ADVANCE DX C359i existiert bis heute kein offizieller Window on Arm‑Treiber.

Trotzdem wollte ich das Gerät sauber einbinden. Und ja: Es geht. Nicht elegant, aber stabil. In diesem Beitrag zeige ich meinen funktionierenden Workaround mit dem Xerox Global Print Driver (GDP) PCL6 V5.1055.3.0 und einer manuellen Installation.

Warum überhaupt ein Workaround?

Canon liefert ausschließlich x64‑Treiber für Windows. Windows on Arm kann zwar vieles emulieren, aber Druckertreiber gehören nicht dazu. Ohne nativen ARM‑Treiber bleibt der Canon schlicht unsichtbar.

Der Xerox Global Print Driver hingegen ist deutlich flexibler und funktioniert auch auf Windows‑on‑Arm‑Systemen. Er unterstützt PCL6 – und genau das reicht aus, um den C359i zuverlässig anzusteuern.

DNS‑Setup: getrennte A‑Records für getrennte Papierfächer

Mir ist schon klar, dass ein separates Druckobjekt und der damit verbundene A-Record die Sache zwar einfach macht aber im DNS selbst einen gewissen Mehraufwand darstellt, darum im Enterprise-Umfeld nochmals über eine logische Trennung nachdenken.

DNS-Name Funktion
c359iSo.testlab.local Canon imageRUNNER ADVANCE DX C359i – Schacht oben
c359iSu.testlab.local Canon imageRUNNER ADVANCE DX C359i – Schacht unten

Diese Trennung macht die spätere Nutzung deutlich komfortabler, weil Anwendungen gezielt den gewünschten Schacht ansteuern können.

image

Kleiner Hinweis und die Printer-Admins wissen das natürlich auch: Man kann das auch nur mit einem DNS-Namen machen, in diesem Fall hatte man aber historisch schon für jede Einstellung einen Namen angelegt und ein separates Druck-Objekt (Drucker) erzeugt.

Zweiter Hinweis: Unter Windows Server 2019 wurde der Xerox Treiber nicht korrekt angezeigt unter Windows Server 2022/2025 aberschon.

Vorbereitung: Xerox‑Treiber und Ports einrichten

Der Treiber wird nicht während der Installation heruntergeladen, sondern vorher manuell in den Print Server Properties des Windows‑Clients importiert:

  • Control Panel / Devices and Printers / Print Server Properties / Drivers

Dort den Xerox‑Treiber hinzufügen.

DNS-Namen in der Port-Konfiguration des Druckservers anlegen

Damit Windows später weiß, wohin gedruckt werden soll, müssen die DNS‑Einträge auch als Ports existieren:

  • Print Server Properties → Ports → Add Port
  • Standard TCP/IP Port auswählen
  • DNS‑Namen eintragen (z. B. c359iSo.testlab.local)

Das Ganze für beide Druckerobjekte durchführen.

Manuelle Installation des Druckers unter Windows on Arm

Jetzt kommt der eigentliche Installationsprozess – und der funktioniert nur manuell:

  1. Settings / Bluetooth & Devices / Printers & scanners / Add device / Add a new device manually / Add a local printer or network printer with manual settings

Im nächsten Schritt:

  • Den zuvor angelegten TCP/IP‑Port auswählen
  • Als Treiber Xerox GDP PCL6 … auswählen
  • Druckernamen vergeben (z. B. C359i – Schacht oben)

Nach Abschluss der Installation empfiehlt es sich, eine Testseite zu drucken. In meinem Fall funktionierte das sofort – ein gutes Zeichen, dass der PCL6‑Fallback sauber arbeitet.

image

Fazit: Kein offizieller Treiber, aber ein stabiler Workaround

Natürlich wäre ein nativer Canon‑Treiber für Windows on Arm die bessere Lösung. Aber solange Canon hier nicht liefert, ist der Xerox GDP PCL6 eine erstaunlich robuste Alternative. Mit ein wenig Vorbereitung – DNS‑Einträge, Ports, Treiberimport – lässt sich der Canon imageRUNNER ADVANCE DX C359i problemlos in eine Windows‑on‑Arm‑Umgebung integrieren.

Frohe Weihnachten und enjoy it, b!

M365 | Aufbewahrung von Mails in freigegebenen Postfächern

Veröffentlicht am von
Antwort

In M365 können freigegebene Postfächer gelöschte Mails eine Zeitlang im Ordner „Gelöschte Objekte” aufbewahren. Die Aufbewahrungsdauer generell sowie die maximale Zeitspanne von 30 Tagen sind über PowerShell konfigurierbar.

# Aufbewahrung von gelöschten Mails in einem freigegebenen Postfach "Service"
Set-Mailbox -Identity "Service" -RetainDeletedItemsFor 30.00:00:00

# Abfrage des Aufbewahrungszeitraums für das Postfach "Service"
Get-Mailbox -Identity "Service" | Select RetainDeletedItemsFor

image

Die Konfiguration erfolgt Über das Exchange-Online PowerShell-Modul, dass natürlich eine Anmeldung benötigt.

Hier noch die Befehle wie das Exchange-Online PowerShell-Modul installiert wird und wie die Anmeldung erfolgt (die Installation als Admin in der PowerShell durchführen):

# Ausführungsrichtlinie setzen
Set-ExecutionPolicy RemoteSigned -Force

# PowerShellGet aktualisieren (falls nötig)
Install-ModuleInstall-Module PowerShellGet -Force -AllowClobber

# Exchange Online Management Modul installieren
Install-Module -Name ExchangeOnlineManagement

Und hier die Anmeldung an M365 / Exchange Online:

# Verbindung zu Exchange Online herstellen
Connect-ExchangeOnline -UserPrincipalName admin

Enjoy it, b!

M365 | Outlook und ein ehemals freigegebenes Postfach

Veröffentlicht am von
Antwort

Innerhalb von M365 besteht die Möglichkeit ein freigegebenen Postfach in ein Benutzerpostfach und umgekehrt zu konvertieren.

Infos zu freigegeben Postfächern gibt es direkt bei Microsoft und auch der Prozess der Konvertierung ist dort sehr gut beschrieben.

Als Erinnerung oder Überbleibsel bleibt dabei der Name des ehemals freigegebenen Postfachs stehen und kann über Outlook (Classic) selbst auch nicht entfernt werden. Ein einfaches “schließen des Ordners” wird mit einem Fehler quittiert.

Sehr elegant kann das nun nicht mehr vorhandene Postfach über eine Deaktivierung des Auto-Mappings mit PowerShell entfernt werden. Sinnvoll aber nicht notwendig ist es, davor Outlook zu schließen.

# Remove Auto-Mapping via PowerShell (Admin Required)
Remove-MailboxPermission -Identity "ConvertedMailbox@domain.com" -User "AffectedUser@domain.com" -AccessRights FullAccess -InheritanceType All

Nach dem Start ist der alte Ordner verschwunden und Outlook sieht aus, wie es soll. Sinnvoll macht das der M365 Admin von einem System aus, auf dem die Exchange PowerShell-Module vorhanden sind.

https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/?view=exchange-ps

Enjoy it, b!

Mailstore Server 2/2 | Umstellung auf M365 Entfernen der Journalregel

Veröffentlicht am von
Antwort

In diesem Beitrag hatte ich bereits die zusätzlichen Schritte bei einer Umstellung der Mailstore Server-Archivierung auf M365 (Modern Auth) beschrieben.

Das Journaling selbst, sprich die noch vorhandene Journalregel in M365 (Microsoft Purview) und die dazu verwendete externe Mailbox, existierten noch und müssen ebenfalls gelöscht werden.

In einem ersten Schritt wird die Journalregel in Microsoft Pureview gelöscht.

image

  • Anmelden im https://purview.microsoft.com mit einem Admin-Konto
  • Navigieren zu:
    Lösungen / Datenlebenszyklusverwaltung / Exchange (Legacy) / Journalregeln

  • Auswahl der zu entfernenden Journalregel 
  • Klick auf das Papierkorb-Symbol (Löschen).
  • Bestätigen um die Regel endgültig zu entfernen

Nun kann auch die externe Mailbox, die bei einem Provider außerhalb von M365 liegt, gelöscht werden.

Enjoy it, b!

Synology VMM | Windows VM mit starker CPU Auslastung durch “System interrupts”

Veröffentlicht am von
Antwort

Ich muss hier einen Fall von Layer-8 Ignoranz schildern – mit etwas Vorgeschichte.

Alles Cloud …

Vor vier Monaten erzählte mir ein Freund, dass er eine Praxis übernehmen würde – mit einer Softwarelösung, die zu 100% in der Cloud läuft. „Wir brauchen nur ein paar Tablets und Internet, da kannst du mir vielleicht helfen?“ Wo fängt man da an …

  1. Es gab PCs, Baujahr 2018 oder 2019 – so genau wusste das niemand. Man hielt sie für „relativ neu“. OK – relativ. Und mit <Panikmodus>Festplatten</Panikmodus>
  2. Ein neues, dreidimensionales Röntgengerät musste her. Die Daten sollten direkt in die Cloud gespeichert werden – allerdings braucht es dazwischen ein „Laufwerk“ als Cloud-Cache
  3. Dazu kamen diverse Konnektoren – wofür auch immer

Die Informationen sickerten nach und nach durch. Ein vollständiges Bild hatten wir erst 14 Tage vor der Wiedereröffnung der Praxis.

Where the rubber meets the road …

Für Punkt 1 konnte ich mit etwas Überzeugungsarbeit ein Synology-NAS (RS822+) ins Spiel bringen. Dank Synology Directory Server gab es eine kleine Domäne, über die sich die PCs (nun mit SSDs ausgestattet) verwalten ließen.

Mit maximalem RAM ausgestattet, liefen darauf zwei bis drei kleine VMs. Der AMD Ryzen 1500B ist zwar kein Kraftpaket, aber für kleine Aufgaben reicht’s. Die Bereitstellung der VMs übernahm der Synology Virtual Machine Manager (VMM), also QEMU/KVM so mehr oder weniger.

Zwei Windows-VMs wurden eingerichtet:

  • Eine mit 4 vCPUs, 16 GB RAM und 2 TB Speicher für den Cloud-Cache (Punkt 2).
  • Eine weitere mit 10 GB RAM für einen Healthconnector.

Nach einigen Optimierungen liefen die VMs stabil und flott – auch dank SSD-Cache im NAS.

Punkt 3: Die Konnektoren

Der erste Konnektor ließ sich problemlos installieren. Kein Thema. Dann kam der RISE-Konnektor – und wie so oft: ein Dienstleister, der sich als besonders „resistent“ erwies.

Natürlich, der Dienstleister ist immer der andere … Winking smile

Die „Anforderung“, in der virtuellen Windows-VM (QEMU/KVM-basiert) das „Hyper-V Networking“ zu installieren, war für mich nicht nachvollziehbar. Angeblich sei das für WireGuard-VPN nötig?! Das Eventlog zeigte jedenfalls mehr als nur „Hyper-V Networking“ – vielleicht hatte er sich jemand verklickt.

image

Mir ist kein explizites „Hyper-V Networking“ bekannt. Windows bietet auf dem Client die folgenden Features an:

Vor dem Reboot sah der Taskmanager noch wie folgt aus …

image

Die Konsequenzen waren aber dem Reboot zu sehen und verheerend.

image

Der Screenshot zeigt nicht das gesamte Ausmaß des Desasters, die virtuellen CPUs liefen über weite Strecken auf 100% und ein Arbeiten war nicht mehr möglich. Weder RDP-Sitzungen noch TeamViewer funktionierten. Auch mehr vCPUs halfen nicht wesentlich.

Ich konnte die Last auf etwa 40 % drücken – aber die VM blieb träge. Sehr träge.

image

Sobald die Hyper-V-Rolle innerhalb des Windows 11-Gastsystems installiert ist, beginnt sich die virtuelle Maschine selbst wie ein Hyper-V-Host zu verhalten (oder versucht es zumindest). Dies verändert die Art und Weise, wie Windows mit der zugrunde liegenden Hardware und der Virtualisierungsschicht interagiert und führt häufig zu:

  • Konflikten bei verschachtelter Virtualisierung: Hyper-V innerhalb einer VM (Nested Virtualization) kann mit den eigenen Virtualisierungsmechanismen von QEMU/KVM interferieren.
  • Problemen bei der Interrupt-Verarbeitung: Das System kann auf andere Taktquellen oder Interrupt-Modelle umschalten (z. B. hyperv_clocksource_tsc_page vs. tsc), was zu übermäßigen System-Interrupts und einer verschlechterten Leistung führen kann
  • Verändertes Timer- und Polling-Verhalten: Hyper-V kann beeinflussen, wie das Gastbetriebssystem Leerlaufzustände und Interrupts behandelt – insbesondere, wenn Funktionen wie halt_poll nicht abgestimmt sind

Ein zeitaufwändig erstellter Dump des Systemprozesses (PID 4) zeigte massenhaft IRPs – ein weiteres Indiz für Probleme durch Hypervisor-Verschachtelung.

image

Hyper-V musste also wieder runter

Final blieb nur die Möglichkeit Hyper-V zu entfernen, was dem Dienstleister nicht wirklich gefallen hat. Die Lösung war die Installation des RISE-Konnektors auf einen der PCs in der Praxis, wobei hier auf das Hinzufügen der Hyper-V Rolle verzichtet wurde?!Wir fragen nicht und nehmen die Alternative mal einfach so hin Sick smile

Die beiden folgenden PowerShell Aufrufe zeigten halfen das System dann anschließend zu korrigieren und in einen nutzbaren Zustand zu versetzen:

# Anzeigen aller aktivierten (enabled) Features in Windows 11
Get-WindowsOptionalFeature -Online | Where-Object {$_.State -eq "Enabled"}
# Deaktivieren der Hyper-V Rolle + manuellem Reboot hinterher
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

Nach dem Neustart lief der RISE-Konnektor mit ~10 % Systemlast. Der Dienstleister war da schon am nächsten PC – und ich hatte ehrlich gesagt keine Lust mehr. Hauptsache, die VM lief wieder.

So, genügend Angry smile – einfach aufpassen und schauen, was “Fachkräfte” auf den Systemen so installieren und sich die Systemanforderungen im Vorfeld schriftlich per Mail besorgen.

Enjoy it, b!

Mailstore Server 1/2 | Umstellung auf M365 (Modern Authentication)

Veröffentlicht am von
1

Vor einiger Zeit habe ich einen Mailstore-Server geerbt und das muss man dem Produkt lassen, es läuft sehr zuverlässig. Der Server wurde im Jahr 2015 in Betrieb genommen und hat seitdem eine Menge an Updates und auch ein Betriebssystem-Upgrade von Windows Server 2016 auf 2022 hinter sich gebracht.

Natürlich wechselte dabei auch im Lauf der Jahre der Mailserver (Exchange), von On-Prem nach M365, zusammen mit einer Reihe von Kundenwünschen. Der letzte war die Umstellung auf Microsoft 365 (Modern Authentication).

Mailstore selbst liefert mit dem Support-Artikel „E-Mail-Archivierung von Microsoft 365 – Modern Authentication” eine nahezu perfekte Anleitung. Zusätzlich mussten noch die Namensformate in den Archiven angepasst werden. Das ist ebenfalls sehr gut im Artikel „Umstellung der Archivierung von Microsoft Exchange Server auf Microsoft 365” beschrieben. Insgesamt sind drei Artikel aus der Mailstore-Hilfe notwendig: Mailstore muss nämlich als App in M365 (genauer gesagt in der Microsoft Entra ID) registriert werden, wie hier beschrieben: „Synchronisieren von Benutzerkonten mit Microsoft 365 – Modern Authentication – MailStore Server Hilfe”.

Zusammenfassend hier nochmals die Links der drei Artikel von gerade eben:

Synchronisieren von Benutzerkonten mit Microsoft 365 – Modern Authentication – MailStore Server Hilfe

Umstellung der Archivierung von Microsoft Exchange Server auf Microsoft 365 – MailStore Server Hilfe

E-Mail-Archivierung von Microsoft 365 – Modern Authentication – MailStore Server Hilfe

In diesem Blog soll es nicht um eine erneute Beschreibung der Umstellung gehen, sondern um Dinge, über die ich gestolpert bin und bei denen ich froh war, sie eingeplant zu haben.

Die Anleitung selbst

Fangen wir kurz mit den oben verlinkten Anleitungen an. Solange es sich um Konfigurationsschritte im MailStore Server handelt, werden diese sehr ordentlich mit Screenshots ergänzt. Das ändert sich mit der Registrierung des MailServers in M365: Der Text wird kursiv und somit schwer lesbar. Hier ein Beispiel:

image

Mag sein, dass es ein persönliches Problem ist, aber ich habe mich ein paar Mal „verhaspelt“, wie man bei uns sagt.

Testen, wieso denn Winking smile ?

Mailstore empfiehlt einen Test der Umstellung.

image

Ja und das habe ich auch gemacht. Die Test-VM ließ sich aus dem Snapshot der produktiven Mailstore-VM erstellen. Diese ohne Netzwerk gestartet, konnte mit einem lokalen Admin für den Parallelbetrieb eingerichtet (rekonfiguriert) werden. In diesem Fall ging es um knapp 20 Archive und aktuell 12 aktive Benutzer. Die Mailboxen in M365 sind teilweise mehr als 50GB groß. Damit musste ich mit ~ 750GB an Mailarchiven rechnen, was den bereitgestellten PowerShell-Skripten eine gewisse Laufzeit abverlangte.

Für den Test kann nicht der eigentliche Lizenzschlüssel verwendet werden, sondern der Support (Mailstore oder elovade) stellen hier einen Trial-Key aus. Nachdem ich in der Test-VM keine Optimierungen durchgeführt hatte, konnte ich die eigentliche Umstellung durch die folgende Einstellung deutlich beschleunigen.

image

Die Länge der Disk-Queue sank von 5 auf unter 2, die Umstellung der Mailboxen war damit in der halben Zeit fertig (~ 6 Stunden). Zu setzen war die Einstellung auf allen Disks und dem Betriebssystem selbst, wobei die Disks mit den Archiven die wichtigen waren.

Untitled-01

Die Umstellung ist damit eine Sache für ein Wochenende. Bei mehr und größeren Archiven, hätte ich zur Sicherheit auf unseren Server-Pool zurückgegriffen und die VM vom NAS auf einen Server mit SSDs umgezogen.

Die PowerShell-Skripte

Im Artikel Umstellung der Archivierung von Microsoft Exchange Server auf Microsoft 365 – MailStore Server Hilfe / MailStore Migrationsskripte werden PowerShell-Skripte zum Download angeboten, die ich auch verwendet habe. Allerdings habe ich den Pfad, in dem die MailStore-Benutzer und die MailStore-Folder in einer Datei gespeichert werden, in den Skripten geändert.

image

Damit kann die Migration in einem Ordner wie beispielsweise D:\Temp durchgeführt werden. Leider geben die Skripte keine wirkliche Auskunft über ihren Fortschritt. Dafür kann man sich aber im Testlab ein Bild machen. Die Verwendung von Measure-Object wäre hier eine Erleichterung gewesen. Ich habe aber auf eine Erweiterung der Skripte in diesem Fall verzichtet, da es sich um den einzigen mir bekannten Mailstore-Server handelt.

In diesem Sinne: Happy Migration und bleibt mir gewogen!

Enjoy it, b!