Mit Android 8 Oreo hält eine neue nervige Funktion in das Betriebssystem Einzug, die leider standardmäßig aktiviert ist und für deren Abschaltung man erstmal eine Odysee durch die Einstellungen machen muß:

Password in Formulare von Google ausfüllen lassen speichern?

Sobald das Betriebssystem auch nur annähernd den Eindruck hat, man möchte gerade ein Kennwort speichern, öffnet sich ein Popup mit der oben genannten Frage und den Optionen “Nein Danke” sowie “Speichern” und leider keiner Möglichkeit, die Funktion direkt zu deaktivieren.

Will man die Funktion abschalten, so führt die Suche in “Einstellungen” > “System” > “Sprachen & Eingabe” > “Erweitert” und nennt sich “AutoFill-Dienst”, doch leider bietet ein Klick auf das “Einstellungen”-Zahnrad zwar die Möglichkeit, gespeicherte Daten einzusehen, aber keine Möglichkeit, den Dienst zu deaktivieren.

Dies geht über einen Klick direkt auf “AutoFill-Dienst”, wo die Option “Keine” gewählt werden kann, womit auch das Zahnrad in den Einstellungen verschwindet und im Nachhinein die Dienstkonfiguration fast logisch erscheint.

Nach dem Wechsel von einer AMD zu einer NVIDIA-Graphikkarte fiel auf, daß der Bildschirminhalt nicht nur heller, sondern insgesamt blasser dargestellt wurde. Die Ursache hierfür fand sich nach einiger Suche in der “NVIDIA Systemsteuerung” - und zwar nicht wie erwartet unter “Desktop-Farbeinstellungen anpassen” sondern unter dem Punkt “Auflösung ändern”:

Standardmäßig scheint der NVIDIA-Treiber bei einem über HDMI angeschlossenen Bildschirm davon auszugehen, daß es sich um ein Fernsehgerät statt um einen Monitor handelt und wählt ohne weitere Nachfrage “Begrenzt” als Einstellung fü den dynamischen Ausgabebereich.

Mithilfe des dynamischen Ausgabebereichs kann der Benutzer den dynamischen Bereich (…) der Ausgabe auswählen, der in den angezeigten Bildern Schatten- und Glanzlichtdetails beibehält.

Typische Verwendungs-Szenarios:

• Die Einstellung Begrenzt (16-235) wird in vielen Fernsehgeräten verwendet

• Die Einstellung Voll (0-255) ermöglicht in einigen Inhalten u.U. mehr Detail in den dunklen und weißen Bereichen

Nach einem Wechsel von “Begrenzt” auf “Voll” wurden die Bildschirminhalte dann auch wieder sichtbar dynamischer dargestellt.

Leider hat Microsoft in der GUI des WSUS keine Möglichkeit vorgesehen, die monatlichen Vorschau-Updates beim Einsatz automatischer Genehmigungen über einen Filter ausschließen zu können.

Gelöst werden kann diese Problem mittels der Powershell bzw. eines Powershell-Skripts, das auch als Powershell-Laie mit einem guten Tutorial sowie Google in endlicher Zeit zusammengesucht- und kopiert werden kann.

Als erstes müssen die für WSUS notwendigen Assemblies geladen werden

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | Out-Null

Dann wird die Verbindung zum WSUS-Server hergestellt

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer()

Sofern die Freigabe der Updates nicht für alle Computer, sondern nur für bestimmte Gruppen vorgenommen werden soll, kann die entsprechende Gruppe zur späteren Verwendung festgelegt und zur Kontrolle ausgegeben werden

$group = $wsus.GetComputerTargetGroups() | where {$_.Name -eq 'Update mit WSUS'}
Write-Host ($group | Format-Table | Out-String)

Für die Freigabe bzw. das Ablehnen interessieren nur solche Updates, die zum einen noch nicht genehmigt (oder abgelehnt) wurden und auch erforderlich sind:

$updateScope = New-Object Microsoft.UpdateServices.Administration.UpdateScope
$updateScope.ApprovedStates = [Microsoft.UpdateServices.Administration.ApprovedStates]::NotApproved
$updateScope.IncludedInstallationStates = [Microsoft.UpdateServices.Administration.UpdateInstallationStates]::NotInstalled

Zu Informationszwecken kann die Menge an zu bearbeitenden Updates ausgegeben werden

$totalUpdateCount = $wsus.GetUpdateCount($updateScope)
Write-Host "Updates to process:", $totalUpdateCount

Dann werden die Updates in einer Schleife abgearbeitet

$wsus.GetUpdates($updateScope) | ForEach {

  Write-Host $_.Title, "- " -NoNewline

Sofern im Titel kein “Preview of” vorkommt, soll das Update genehmigt werden. Die Titel werden in englischer Sprache verarbeitet, so daß nach “2017-05 Preview of Monthly Quality Rollup for Windows 7 for x86-based Systems (KB4019265)” statt “2017-05 Vorschau des monatlichen Qualitätsrollups für Windows 7 für x86-basierte Systeme” gesucht werden muss:

  if (-not ($_.Title -like "*Preview of*")) {

Falls zur Installation eine Lizenzvereinbarung angenommen werden muss, kann dies ebenfalls über das Powershell-Skript erfolgen

    if ($_.RequiresLicenseAgreementAcceptance) {
      $_.AcceptLicenseAgreement()
    }

Anschließend wird das Update zur Installation in der oben festgelegten Gruppe genehmigt:

    $_.Approve("Install", $group)
    Write-Host "approved" -ForegroundColor green
  }

Sofern es sich um ein Vorschau-Update handelt, wird das Update stattdessen abgelehnt

  else {
    $_.Decline()
    Write-Host "declined" -ForegroundColor red
  }
}

Am Ende des Skripts erfogt dann noch die Ausgabe, daß das Skript tatsächlich am Ende angekommen ist

Write-Host "done."

Einer der Gründe, warum in der EDV zeitliche Voraussagen so schwer zu treffen sind, ist die Tatsache, daß man immer wieder über Dinge stolpert, mit denen man nicht gerechnet hat.

Beim Versuch, ein Aufräumskript für die Hinterlassenschaften des AMD-Treibers in Perl zu schreiben, wurde eine Datei nicht gefunden, die laut Explorer und Eingabeaufforderung aber sehr wohl vorhanden war:

C:\Windows\System32\drivers>dir ati2erec.dll
...
 Verzeichnis von C:\Windows\System32\drivers

21.11.2014  04:08            43.520 ati2erec.dll
               1 Datei(en),         43.520 Bytes

Die gleiche Aufgabenstellung als Perl-Skript

use strict;
use warnings;
if (-e 'C:\Windows\System32\drivers\ati2erec.dll') { print "found.\n"; }
else { print "not found.\n"; }

führte aber zur überraschenden Ausgabe

not found.

Wie so oft, wenn es um seltsame Dinge in Windows geht, handelt es sich hierbei aber um ein Feature und keinen Bug, wobei das Feature aber erst einmal gefunden werden muß. Im konkreten Fall hört es auf den Namen “File System Redirector” und sorgt dafür, daß

In most cases, whenever a 32-bit application attempts to access %windir%\System32, the access is redirected to %windir%\SysWOW64.

Dies erklärt das obige Phänomen, da die verwendte Perl-Version eine 32-bit Anwendung ist. Freundlicherweise liefert der MSDN-Artikel auch gleich eine Lösung

32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access. This mechanism is flexible and easy to use, therefore, it is the recommended mechanism to bypass file system redirection.

so daß der Zugriff auf ‘C:\Windows\Sysnative\drivers\ati2erec.dll’ dann tatsächlich ein

found.

als Ergebnis liefert. Das “flexible and easy to use” möchte ich aber durchaus in Frage stellen, denn

Note that 64-bit applications cannot use the Sysnative alias as it is a virtual directory not a real one.

bedeutet letztendlich eine entsprechende Abfrage im Skript, damit - je nach verwendetem Interpreter - der Pfad entweder auf “System32” oder “Sysnative” gesetzt wird.

Nach dem Wechsel von einer AMD zu einer NVIDIA-Graphikkarte blieb, trotz der Anweisung an den Uninstaller, bitte alles von AMD zu entfernen, noch das AMD External Events Utility als Dienst installiert, welches bei jedem Systemstart automatisch ausgeführt wurde. Leider ist unter “Programme und Funktionen” keine weitere Möglichkeit vorgesehen, den nicht mehr benötigten Dienst loszuwerden.

Der erste Weg sollte in die Dienst-Verwaltung von Windows führen, wo neben der Änderung des Starttyps auf “Deaktiviert” der Dienst auch direkt gestoppt werden kann.

Gleichzeitig kann aus diesem Dialog auch der interne Name des Dienstes (in diesem Fall identisch mit dem Anzeigenamen) sowie der Pfad zur ausführbaren Datei entnommen werden.

Die graphische Oberfläche bietet leider keine weiteren Möglichkeiten, einen Dienst aus dem System zu entfernen, dies kann aber über die Kommandozeile vorgenommen werden.

Nachdem man sich mit “query” nochmal vergewissert hat, auch den richtigen Dienst löschen zu wollen

C:\Windows\system32>sc query "AMD External Events Utility"

SERVICE_NAME: AMD External Events Utility
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

kann die eigentliche Löschung dann mittels dem Parameter “delete” der Dienst aus der Systemkonfiguration entfernt werden.

C:\Windows\system32>sc delete "AMD External Events Utility"
[SC] DeleteService ERFOLG

Wer mutig ist noch weiter aufräumen möchte, kann anschließend noch eine Säuberung des “%SYSTEMROOT%\System32”-Verzeichnisses vornehmen, in dem aber neben der eigentlichen Dienstdatei “atiesrxx.exe” noch weitere 37 Dateien zu finden sind, welche alle mit “ati*” beginnen.