Auf Windows Druckserver schlägt es manchmal fehl, den Treiber eines Druckers zu aktualisieren oder neu zu installieren. Die Einrichtung läuft scheinbar zuerst fehlerfrei durch, doch nach dem „OK“ Klick am Ende erschient die Fehlermeldung „Die Druckereinstellungen konnten nicht gespeichert werden. Dieser Vorgang wird nicht unterstützt.“
Lösung
Abhilfe schafft es, die Option „Drucker freigeben“ aus- und wieder ein zu schalten.
Bevor der Treiber geändert werden kann, muss die Freigabe des Druckers aufgehoben werden, nach der Aktualisierung kann der Haken wieder rein.
Unter Windows 10 werden PDF-Dateien Standartmäßig im neuen Edge geöffnet. Auch in Webseiten verlinkte PDFs werden stets im Browser integriert geöffnet. Leider scheint der interne Betrachter des öfteren Problem mit dem Druck von PDF-Dateien zu haben (vor allem seit dem großen Update 2004) und stellt auch sonst nicht alle PDF-Features fehlerfei dar.
So aktiviert man externe PDF-Tools in Edge, wie den Adobe Reader
Auf das „…“ Menü klicken > Einstellungen
Dann unter den „Webseitenbrechtigungen“ auf „PDF-Dokumente“ und den Schalter von „PDF-Dateien immer extern öffnen“ nach rechts („ein“) schieben.
Schon werden beim nächsten öffnen alle PDFs an den In den Windows-Einstellungen konfigurierten Betrachter weitergereicht.
Ich hatte grade auf mehreren Maschienen den überaus ärgerlichen Effekt, das die „Einstellungen“ App nicht mehr freiwillig aufgehen wollte. Ich konnte auf das Zahnrädchen im Startmenü klicken so oft ich wollte, es passierte nichts. Es ging auch überhaupt keine Settings-App mehr aus, auch über den Desktop oder den Defender nicht.
Lösung
PowerShell (oder CMD) „als Administrator“ starten
start ms-settings: (mit dem Doppelpunkt am Ende)
Es hat einen Moment gedauert, aber „Einstellungen“ ist dann fehlerfrei gestartet und funktioniert seitdem wieder einwandfrei.
Was die wirkliche Ursache davon ist weiß ich nicht und ich kann auch nicht sagen ob das die totale Lösung für alle Fehler dieser Art ist; aber in diesem (überaus nervigen) wars sehr hilfreich.
Die Einstellung „IP-Filter“ fehlt in der NPS-Konsole 😱
Lösung
Die Konsole „Als Administrator“ starten 💩 Hint: Das geht auch nicht aus de RRAS-Konsole heraus. Dieser Inkonsistente Mist kann einen Admin Wahnsinnig machen 🤪
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.
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 …
Manchmal möchte man schnell ein Dokumuent unterschrieben, das als PDF vorliegt. Das PDF auszudrucken, zu unterschrieben und wieder einzuscannen ist heute glücklicherweise nicht mehr nötig.
So scannt man seine Unterschrift ein, um diese im Adobe reader als „Stempel“ zu verwenden.
1. Unterschrift einscannen
Das Autogramm muss natürlich einmal digitalisiert werden. Das geht durch das einscannen oder auch direkt digital, zum Beispiel mit einem Stift auf einem Tablet.
2. Unterschrift freistellen
Mit einem Grafikprogramm muss die Unterschrift von ihrem „Untergrund“ befreit werden. Wenn beispielsweise ein weißes Stück Papier mit eingescannt wurde, muss dies entfernt werden. Andernfalls würde der Stempel auch das weiße Rechteck „mitstempeln“, aber wir benötigen ja nur die Unterschrift. Das Speicherformat muss hinterher ein transparentes PNG oder GIF sein.
Das geht beispielsweise mit Photoshop – und hier kann man das Ergebnis auch direkt als transparentes PNG aufspeichern.
3. Die Signatur als PDF ablegen
Da das in keine Programm (außer dem Acrobat) direkt zu funktionieren scheint, nutzen wir diesen recht zuverlässigen Weg :
Die Unterschrift in Microsoft Word einfügen (sonst nichts tun)
Das neue Dokument „Als PDF speichern“
4. Dieses PDF im Adobe Acrobat Reader als Stempel einfügen
Reader öffnen
Oben auf den Tab „Werkzeuge“ wechseln, dann „Stempel“ öffnen
„Benutzerdefinierte Stempel“ -> „Durchsuchen“ und die PDF-Datei auswählen
Namen und wenn gewünscht Kategorie vergeben, fertig.
Ab jetzt steht der Stempel zur Auswahl beim einfügen zur Verfügung.
