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 wieder. Kann jemand etwas zum Hintergrund sagen?

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.

Der Aufbau einer VPN-Verbindung vom LANCOM Advanced VPN Client zu einem 1781EF+ Router mit Zertifikat gemäß der folgenden Anleitung (und einer weiteren Anleitung zur Erstellung von Zertifikaten mit LANCOM Smart Certificate) gelang nicht:

https://www2.lancom.de/kb.nsf/1275/04D07E79A859D7A6C125824F003613D4?OpenDocument

Der Client meldete nur: “Benutzername oder Passwort falsch” und “error 2110 xauth wrong userid or password“, “Ikev2: Notifymsg=<IKEV2_NOTIFY_AUTHENTICATION_FAILED>“.

Der Router protokollierte dies: “VPN: Error for peer V2TEST: IKE-R-IKE-key-mismatch“.

Bei einem VPN-trace auf der Console des Routers fiel mir sofort diese Meldung auf: “Received Digital Signature altough we do not support it“.

Damit war die Lösung schon nah: Im Widerspruch zu allen Anleitungen und Videos von LANCOM, die ich gefunden habe, müssen in der Konfiguration auf dem Router unter IKEv2/IPSec sowohl die “Lokale Authenfizifierung” als auch die “Entfernte Authentifizierung” von “RSA-Signature” auf “Digital-Signature” umgestellt werden.

Offenbar war das früher anders und die Anleitungen sind nicht aktuell. Meine Feststellungen betreffen den Client Version 5.00 und das LCOS 10.32.0156RU4.