Die Mailadresse einer Freigabe 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.

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"}

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.

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?

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

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.

Immer wieder nett, „Germany“ dort zu finden, wo alphabetisch „Deutschland“ stünde.