„GParted Bug: Eine Partition kann nicht (xxx) nach dem Ende des Laufwerks enden (%2)“

Problem

GParted beschwert sich bei der Anpasung von Partitionsgrößen: „GParted Bug: Eine Partition kann nicht (xxx) nach dem Ende des Laufwerks enden (%2)“

Die gleiche Meldung gibt es auch auf Englisch: „GParted Bug: A partition cannot end after the end of the device (%2)“

Das tritt beim resizing oder verschieben einer Partition auf, obwohl noch genug Platz da ist und das Ende des Laufwerks noch nicht erreich scheint.

Lösung

Der Fehler (Bug) liegt in der Berechnung der Partitionsgrenzen bei der Verwendung des Binärpräfixe gemäß IEC (MiB/KiB …). Man stelle den Dialog also einfach einfach auf „Zylinder“ (Cylinder) um, schon funktioniert die selbe Operation fehlerfrei.

Office 365 auf Windows (RDS) Server ist plötzlich „nicht lizenziert“ und das Office Anmeldefenster verschwindet einfach

Problem

Office 365 wurde korrekt und mit aktiviertem „Shared Computer Activation“ installiert. Nach einer Weile berichten Benutzer von „unlizenziertem Office“ und das man seine Lizenz nicht mehr aktivieren könne.

Das Anmelde-Feld erscheint zwar, man kann hier seine E-Mail Adresse auch eingebene, aber dann verschwindet es wieder und Office wird nicht aktiviert. Es gibt keine Fehler und sogar die Ereignisanzeige bleibt leer.

Lösung

Standardmäßig verwendet Microsoft Office 365 ProPlus (seit Version 2016) die Frameworkbasierte Authentifizierung der Azure Active Directory-Authentifizierungsbibliothek („ADAL“). Nach der Umstellung auf die neue „modern Authentication“ via „WAM“ passieren aber leider häufiger mal Fehler.

Es hilft zuverlässig, WAM und ADAL einfach zu überspringen:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
"DisableADALatopWAMOverride"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
"DisableAADWAM"=dword:00000001

Das geht natürlich auch per Gruppenrichtlinie (GPO) im Benutzerkontext (Benutzerkonfiguration) und benötigt nicht mal einen reboot.

Erlärung

Ab Build 16.0.7967 verwendet Office nun den „moderneren“ Web Account Manager („WAM“) für Office-Anmelde-Workflows. Es war auch mal wieder Zeit für neue TLAs. Selbiger bringt, wie immer, einige spannende neue „Eigenheiten“ mit.

WAM sucht beim Start nach den neuen Voraussetzungen für den Identity Providers (IdP), die beim Zusammenführen von Office 365 Konten verwendet werden (IdP IDReg_Match). Für synchronisierte Domänen an sich ein segen – es funktioniert nun auch der lokale UPN. Theoretisch.

Wenn Windows 10 oder Windows Server 2019 mit einem lokalen Active Directory verbunden ist, muss der IdP für WAM/O365 nun aber das sogenannte „WS-Trust-Protokoll“ (respektive Flag) unterstützen. Dies geschieht aber nicht automatisch in allen Konfigurationen; warum das oft nicht der Fall ist, haben wir noch nicht herausgefunden. Wenn beispielsweise das Authentifizierungstoken eines Benutzers ungültig wurde, zum Beispiel beim Kennwort-Zurücksetzen oder deaktivieren eines Nutzers, versucht das WAM den Benutzer erneut zu authentifizieren. Soweit idst das ja auch richtig – aber man erwartet hier nun das altbekannte Popup-Fenster des IdP, das bei einem fehlgeschlagenen Zugriff aber nur kurz geöffnet und dann sofort wider geschlossen wird wenn das Flag nicht korrekt/lesbar/vorhanden ist.

CUPS: Alle Drucker auf einmal aktivieren

Nach einem abgeschlossenen „dist-upgrade“ sind konfigurierte CUPS Drucker gerne mal deaktiviert („disabled“). Man kann einen Drucker nach dem anderen natürlich manuell einschalten („enable“), aber schöner wäre es die ganze Liste auf einmal zu aktivieren. Dafür gibt es das tool „cupsenable„.

Die konfigurierten Drucker zeigt „lptstat -t“ an.

Liste inaktiver Drucker anzeigen

lpstat -t | grep disabled | awk '{ print $2; }'

Alle diese Drucker aktivieren

lpstat -t | grep disabled | awk '{ print $2; }' | xargs -I{} cupsenable {}

Windows Server 2016/2019 RDS (extrem) langsame Benutzeranmeldung

Gewisse „Eigenheiten“ in den Windows Server 2016/2019 RDS Diensten (früher „Terminaldienste“) reißen nicht ab.

Problem

In vielen Setups klagen Benutzer, wie Administratoren, über sehr langsame Anmeldevorgänge. Man nur einen schwarzen Bildschirm mit seiner Maus darauf und wartet lange bis der Desktop erscheint.

Das können 20 Sekunden sein, wir haben aber auch bis zu 4 Minuten (!) gesehen. An der Leistung der Maschine liegt es nicht.

Der gemeinsame Nenner scheint aber der Einsatz der Sessionhost-Rolle zusammen mit dem Broker/Gateway zu sein und -vor allem- die „User Profile Disks“. So sinnvoll die Erfindung der Benutzereigenen VHDX-Festplattencontainer auch erscheinen mag, der Einsatz der Profilplatten scheint den Anmeldezeit extrem zu verlängern.

Lösung

Es sind zwar nicht direkt die UPDs, aber eine Eigenheit des ShellExperienceHost im Zusammenhang mit der automatischen Ausführung durch den Dienst „App-Vorbereitung“ (AppReadiness). Es hilft diese Ausführung einfach zu deaktivieren:

  1. Den Dienst „App-Vorbereitung“ stoppen
    • Stop-Service AppReadiness
  2. Registry öffnen: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Config
  3. Dirt den Schlüssel „Microsoft.Windows.ShellExperienceHost_*******“ umbenennen (zum Beispiel ein „.backup“ anhängen oder den Schlüssel exportieren und löschen)
  4. Die „App-Vorbereitung“ wieder starten
    • Start-Service AppReadiness

Maschine rebooten und neu anmelden. Die Wartezeit sollte nun der Vergangenheit angehören.

Alternativ

Es gibt auch Software, die sich hier mit mehr oder weniger korrekten Schlüsseln verewigt. Ein Test der Schlüssel (anch und nach entfernen und die Anmeldung testen).

Besagter Dienst hat schon einige Probleme, Patches und Probleme hinter sich. Mal durch selbstgemachte Schwierigkeiten, mal durch Anpassungen Dritter. Es scheint hier zumindest größeres Fehlerpotential vorzuliegen …

Word/Excel Fehlermeldung bei Nutzung mehrere OneDrive Konten auf einem Computer

Problem

Verwendet man mehrere OneDrive-Konten auf einem Computer, kommt es gelegentlich zu diesem Fehler, wenn man Dateien aus dem „zweiten“ OneDrive Ordner öffnet. Die Meldung kommt immer, unabhängig ob man die Dateien „on demand“ nutzen möchte oder vollständig synchronisiert hat.

Ihre Änderungen können nicht hochgeladen oder heruntergeladen werden, weil ihre zwischengespeicherten Anmeldeinformationen abgelaufen sind.

Wenn man sich dann anzumelden versucht, wie von Excel so prominent vorgeschlagen, erhält man die Fehlermeldung:

Leider ist an diesem Computer bereits ein anderes Konto aus Ihrer Organisation angemeldet.

Lösung

Das Problem sind die Office-Apps, die direkt versuchen mit dem angemeldeten Benutzer in das „fremde“ OneDrive zu schreiben. Das schlägt natürlich fehl, aber Office ignoriert hier scheinbar (äußerst penetrant) die erfolgte und korrekte Einrichtung als zweites OneDrive.

Glücklicherweise kann man dem OneDrive Client abgewöhnen, die Office-Apps zu konfigurieren. Die Option ist nur etwas seltsam benannt.

OneDrive-Symbol > Einstellungen > Office > „Office-Dateien, die ich öffne, mit Office-Anwendungen synchronisieren“ abschalten

Und schon funktrioniert der Zugriff wieder fehlerfrei – es ist nicht einmal ein Neustart notwendig (außer von den Office-Apps).

Allerdings gehen durch diese Umstellung die synchronen Online-Features verloren, wie die gleichzeitige Bearbeitung einer Datei durch mehrere Benutzer oder das automatische Online-Speichern.