Eigentlich passt das auch im weiteren Sinne noch zu meinem Beitrag Windows 10 zähmen:

Vermutlich wird Microsoft mit gleichem Druck versuchen, Windows 10 Nutzer zum Windows 11 Upgrade zu drängen, wie es beim Upgrade von Windows 7 auf Windows 10 der Fall war.

Stand heute sollten diese Registry-Einträge dagegen helfen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealthCheck]
"installed"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"TargetReleaseVersion"=dword:00000001
"TargetReleaseVersionInfo"="22H2"

Die Microsoft 365-Benutzer-ID aaa@aaa.xx wurde geändert in bbb@bbb.xx. Obwohl die neue Adresse als Antwortadresse und somit als primäre Adresse definiert wurde, ließ sich die alte nicht über die Admin-Oberfläche entfernen, bzw. tauchte immer wieder neu auf. Des Weiteren wurde im Exchange Admin Center weiterhin die alte Benutzer-ID angezeigt.

Abhilfe brachte dieser Weg über die Powershell:

Set-Mailbox bbb@bbb.xx -MicrosoftOnlineServicesID bbb@bbb.xx
Set-Mailbox bbb@bbb.xx -EmailAddresses @{remove="aaa@aaa.xx"}

Passwortregeln können eine Herausforderung sein, aber so viele Versuche wie hier, habe ich noch nie gebraucht, um alle zu erfüllen …

Bei mir stürzte Outlook 2016 sehr häufig ab, nach Installation des Windows 10 Update 2004:

Name der fehlerhaften Anwendung: OUTLOOK.EXE, Version: 16.0.13901.20336, Zeitstempel: 0x6065c83d
Name des fehlerhaften Moduls: atidxx32.dll, Version: 27.20.14527.2002, Zeitstempel: 0x60065459
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0086f457
ID des fehlerhaften Prozesses: 0x32d8
Startzeit der fehlerhaften Anwendung: 0x01d732b600cbddc5
Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Microsoft Office\root\Office16\OUTLOOK.EXE
Pfad des fehlerhaften Moduls: C:\WINDOWS\System32\DriverStore\FileRepository\u0363193.inf_amd64_e89a8015b2ee3cd6\B363259\atidxx32.dll
Berichtskennung: 29ff500e-718c-49db-8bb4-e98ce3b704e8

Ein Update auf Outlook 2019 brachte keine Besserung. Auch nicht das Anlegen eines neuen Outlook-Profils. Mit Einrichtung eines neuen Windows 10 Benutzers verschwand das Problem … leider nur für einige Tage.

Mit dieser Einstellung sieht es bisher gut aus:

Datei -> Optionen -> E-Mail -> Editoroptionen -> Erweitert -> Hardwaregrafikbeschleunigung deaktivieren

Ein Update des AMD-Radeon-Treibers kommt nicht in Frage, da sonst das hier beschriebene Flackern auftritt – zumindest auf einem Lenovo ThinkPad E485.

Eine Verteilerliste kann durch die dort definierten Besitzer nicht in Outlook, sondern in OWA (Outlook Web Access) über diese Adresse (im Falle von MS-Exchange-Online / Office 365) verwaltet werden:

https://outlook.office365.com/mail/options/general/distributionGroups

Voraussetzung ist, dass dem Besitzer über das Exchange Admin Center (EAC) -> Berechtigungen -> Administratorrollen die Rolle „Distribution Groups“ zugewiesen wurde.

Externe Mailadressen können auf diesem Weg einer Verteilerliste nur hinzugefügt werden, wenn diese als sichtbarer Kontakt (Objekt) angelegt sind.

„Beim Verschlüsseln dieser Nachricht für die aufgeführten Empfänger sind Probleme aufgetreten. Entweder ist das Zertifikat nicht vorhanden oder ungültig, oder die Verschlüsselung ist inkompatibel oder wird nicht unterstützt.“

Diese Fehlermeldung hatte ich beim Versuch, verschlüsselt an Empfänger zu senden, deren aktuelles Zertifikat im Globalen Adressbuch hinterlegt ist – und dies, obwohl die Empfänger explizit aus dem Globalen Adressbuch ausgewählt wurden.

In anderen Adressbüchern waren die Empfänger zwar teilweise auch vorhanden, aber ohne dort hinterlegtes Zertifikat. Geholfen hat mir in dieser Situation nur, die Empfänger aus allen lokalen Adressbüchern zu löschen (auch unter Gelöschte Objekte!) und dann diese mit Rechtsklick auf die Kontakte in einer empfangenen, signierten Mail inkl. Zertifikat neu anzulegen. Sodann konnte ich wieder verschlüsselt an diese Kontakte senden, auch wenn diese z.B. aus dem Globalen Adressbuch ausgewählt wurden. Mit Outlook 2016 sowie 2019 das gleiche Ergebnis. Ist dieses Verhalten normal?

Auf PCs, die das DATEV SiPa compact installiert haben, verlangte Outlook seit heute beim Versenden von E-Mails mit S/MIME-Signatur nach der DATEV-Smartcard (mIDentity-Stick).

Grund hierfür war, dass – in diesem Fall seit 1.3. (warum auch immer) – sich ein S/MIME-Zertifikat der DATEV für E-Mails auf den PCs befindet. Die Nutzung dieses Zerifikats kann unerwünscht sein, wenn andere S/MIME-Zertifikate vorhanden sind und verwendet werden sollen.

Nach Aufruf von certmgr.msc kann mit der rechten Maustaste über Eigenschaften, das DATEV-Zertifikat, welches „Sichere E-Mail“ unter „Beabsichtigte Zwecke“ vermerkt hat, für diesen Zweck oder ganz deaktiviert werden. Die Meldung „Windows-Sicherheit: Smartcardgerät auswählen“ beim Mailversand verschwindet somit.

Kleiner Nachtrag:

Nach jeder Datev-Anmeldung wird das unerwünschte Zertifikat leider neu installiert. Mit diesem Powershellbefehl (am besten als .ps1-Datei  speichern) kann es entfernt werden:

gci cert:\CurrentUser\My\00009E4405741151342B22000705029445215 | foreach { Remove-Item $_.PSPath }

Die obige Beispiel-Id-Nummer natürlich durch die des Zertifikats ersetzen. Diese kann so abgerufen werden:

gci cert:\CurrentUser\My | fl

Wenn man nun noch eine Desktopverknüpfung „nach Datev.cmd“ (oder ähnlich) anlegt, die das Powershellscript aufruft, kann man über diese nach jedem Datev-Logout das Zertifikat entfernen.

 %windir%\System32\WindowsPowerShell\v1.0\powershell.exe -File "[Dateipfad]\[Skriptname].ps1" 

Zuvor muss einmalig eine Powershell mit Admin-Rechten gestartet werden, um dort die Scriptausführung zu erlauben (Achtung, hiermit werden auch ggf. unerwünschte Scripts freigegeben, dies kann eine Sicherheitslücke darstellen):

Set-ExecutionPolicy -ExecutionPolicy Unrestricted

Hat jemand eine elegantere Lösung? Z.B. das Ganze Datev-seitig zu verhindern?

Nach einem Windows 10 Update auf Version 2004 hatte ich das von mir bereits hier beschriebene Bildschirmflackern.

Als dieses Problem gemäß meiner Anleitung behoben war, ließ sich die Bildschirmhelligkeit nicht mehr regeln. Der Regler bewegte sich mit F5/F6, jedoch änderte sich die Helligkeit nicht. Nach Herunterfahren des Systems über cmd mit „shutdown /p“, funktionierte es wieder.

Auf der Lenovo-Website gesehen …

… dürfte für einen ersten Test reichen. Ich überlege aber, ob ich schon auf ‚verlängern‘ klicke.

Bei ersten Versuchen mit dem „RDP Wiki embed„-Plugin für WordPress scheiterte ich an der Meldung „Protocol https not supported or disabled in libcurl„. Entsprechendes auch beim Versuch mit http.

Wer hier den Fehler in libcurl sucht, ist evtl. auf dem falschen Weg. Bei mir lag es an den falschen Anführungszeichen im Beispielcode, den ich von der Website des Plugins kopiert hatte.

Eine funktionierende Einbindung sieht z.B. so aus:

[rdp-wiki-embed url='http://de.wikipedia.org']

DHCP requests von diversen Clients schlugen bei mir fehl, seit Upgrade aller UAP-LR auf Version 4.3.13.

Ich konnte dies per Downgrade auf 4.0.80 nun zunächst beheben, für Tipps wäre ich aber dankbar. DHCP-Server ist ein LANCOM Router.