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„.
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:
Dirt den Schlüssel „Microsoft.Windows.ShellExperienceHost_*******“ umbenennen (zum Beispiel ein „.backup“ anhängen oder den Schlüssel exportieren und löschen)
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 …
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.
Wir finden: Das wurde auch Zeit. Danke HPE das ihr unseren Job damit nun nicht mehr künstlich verkompliziert 😉
Achtung: Das gilt nur für das Gen10 SPP. Dieses beinhaltet auch nur Gen10-relevante Inhalte. Es gibt zusätzlich auch ein SPP (Gen9/Gen10), hierfür ist aber nach wie vor ein/e gültige/r Supportvertrag/Serverregistrierung erforderlich („Entitlement required“).
Die Unterschiede sind aus den jeweiligen Release Notes und dem Contents-Report ersichtlich:
Die Rolle „Routing und RAS“ als Kernkomponente für den sicheren Fernzugriff via VPN hat seit Windows Server 2016 einen schlechten Ruf. Leider ist dieser unter Server 2019 noch mehr gerechtfertigt; die RRAS Services und deren Konfiguration sind bis zur Unbenutzbarkeit mit Fehlern behaftet.
Neu ist für uns aber der Installationsfehler: Fügt man via „Install-WindowsFeature Routing“ oder dem Server-Manager den RRAS Service hinzu („Remotezugriff“), beschwert sich der Server nach einer erfolglosen Installation:
Der Vorgang kann nicht abgeschlossen werden, da der angegebene Server neu gestartet werden muss.
Ein Neustart hilft hier (natürlich) nicht weiter.
Lösung
Die Installation scheitert an der WID, der „Internen Windows Datenbank“. WID ist eine SQL Express Instanz, die „Als Dienst anmelden“ Berechtigungen benötigt. Etwas ungeschickt ist hier, das der Dienst als „NT SERVICE“ starten will, der diese Rechte auf DCs (und einigen anderen Rollen) nicht (mehr) hat.
Also muss man die Default Domain Controllers Policy (bei DCs), die Default Domain Policy (bei „Hardened Networks“) oder die jeweils zutreffende Policy anpassen. Das macht man am besten nach einem sauberen Neustart.
Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Zuweisen von Benutzerrechten > Anmelden als Dienst
Hier müssen die folgenden Identities Mitglied sein:
DIENST
NETZWERK
Netzwerkdienst
IIS_WPG (wenn SSTP oder DirectAccess genutzt werden soll)
Schliessen, GPUPDATE /FORCE udn schon läuft die Installation fehlerfrei durch.
