E-Mails die in Outlook von einem gemeinsamen Postfach aus versendet werden, landen nicht im gemeinsamen „Gesendete Objekte“ Ordner

Seit Office 2010 ist die Standarteinstellung von Outlook-Ablageobjekten nicht immer optimal. Neue Nachrichten, die von einem gemeinsamen (ob fremdgeöffnet oder als shared Mailbox angelegt ist egal) Postfach gesendet werden, werden nicht im Ordner „Gesendete Objekte“ des freigegebenen Postfachs abgelegt, sondern im Postfach des absendenden Benutzers. Das sorgt oft für Verwirrung.

Das liegt daran, das in Exchange 2010+ und Office 365 freigegebene Postfächer keine Lizenz mehr benötigen und man Outlook nicht mehr als „unabhängiges“ Postfach verbinden kann. In so einem Fall meldet man sich konsequenterweise aber beim eigenen Postfach an und öffnen das freigegebene Postfach zusätzlich. Beim Senden nimmt Outlook dann standartmäßig das Konto des Absenders. Daher werden Nachrichten – im Prinzip folgerichtig – auch immer im Ordner „Gesendete Objekte“ das Postfach des Absenders (also angemeldeten Nutzers) gespeichert.

Dieses Verhalten ist reine Outlook-Sache (nicht Exchange) und lässt sich schnell in der Registry anpassen:

HKCU\Software\Microsoft\Office\<VERSION>\Outlook\Preferences
DWORD: DelegateSentItemsStyle
Wert: 1 (für Ablage in geöffnetem Postfach)
Wert: 0 (für Ablage in eigenem Postfach, Standart)

Outlook / Office 365 „Ihr Postfach wurde temporär auf den Microsoft Exchange-Server verschoben. Ein temporäres Postfach ist zwar vorhanden …“

Problem

Outlook 2013/2016 startet nur noch mit dieser Fehlermeldung. Gesehen haben wir den fehler bei On-Premise Serverinstallationen und Office 365. Der Fehler selber liegt in der Art, wie Outlook Cache-Daten interpretiert.

Das Postfach wurde temporär auf den Microsoft Exchange-Server verschoben. Ein temporäres Postfach ist zwar vorhanden, aber enthält möglicherweise nicht alle vorherigen Daten.„Ihr Postfach wurde temporär auf den Microsoft Exchange-Server verschoben. Ein temporäres Postfach ist zwar vorhanden, aber enthält möglicherweise nicht alle vorherigen Daten. Sie können eine Verbindung zum temporären Postfach herstellen oder offline mit allen alten Daten arbeiten. Wenn Sie mit den alten Daten arbeiten möchten, können Sie keine E-Mail-Nachrichten senden oder empfangen.“

An sich funktioniert Outlook aber problemlos.

Lösung

Die Ursache ist ein Fehler in Outlook, unser Case-Manager sagt ein Fix sei „in Arbeit“. Mal sehen wann das passiert, die Meldung ist von 2014 … 🙂

SICHERE Lösung, die immer funktioniert:

  1. Neues Outlook-Profil im Onlinemodus (!!) erstellen. Ja, komplett ohne Cachemode.
  2. Das betroffene alte Profil entfernen
  3. Outlook starten und Erstsynchronisation abwarten (~20 Sekunden)
  4. Outlook schliessen
  5. Cachemode wieder einschalten (wenn gewünscht), Outlook neu starten, fertig.

Es gibt auch Fälle, in denen hat es schon geholfen, die bestehende OST-Datei (%LOCALAPPDATA%\Microsoft\Outlook) zu löschen und durch einen Outlook Neustart erneut zu synchronisieren.

Outlook 2013/2016 „Ein unbekannter Fehler ist aufgetreten, Error-Code 0x80090345“

Unter Windows 8.1 oder höher mag sich ein nagelneu eingerichtetes Outlook nicht mit dem Exchange-Server verbinden. Das passiert gleichermaßen bei lokalen Exchange-Servern und auch unter Office 365. Statt sich zu verbinden erscheint nach dem Autodiscover, also nach dem „Exchange-Servereinstellungen suchen“.

Lösung

Dieser Fehler tritt nur auf, wenn die Domäne unter Windows NT4 oder Samba betrieben wird. Die Lösung lautet, auf den neuen Credential-Manager-Schutz aus KB3000850 zu verzichten:

Einfach dazu im Schlüssel HKLM\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb den DWORD-Wert „ProtectionPolicy“ auf 1 setzen.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb]
"ProtectionPolicy"=dword:00000001

Die Samba-Leute sind mit ihren Credentials noch nicht so weit (siehe Wiki).

RootCA Updates (Office365 kann nicht aktiviert werden ERROR CODE „0xC004F017“)

Weitere Suchwörter: rootca, msrootca, rootca-update, Windows CA-Store Patch, rootcapatch, windowsca, caupdate

Problem

Eine neue Office365-Installation lässt sich nicht aktivieren und es erscheint die folgende Fehlermeldung:

Es gibt ein Problem mit Ihrem Konto. Versuchen Sie es bitte später erneut.

An der Kommandozeile lässt sich die Lizenz im Lizenzaktivierungsdienst aber korrekt anzeigen. Der Fehler an der Kommandozeile für die /act-Aktivierung lautet „ERROR CODE 0xC004F017“

Lösung

Vermutlich ist der Speicher der vertrauenswürdigen Stammzertifizierungsstellen beschädigt, leer oder ein wichtiges Zertifikat fehlt. Das kann durch ein fehlerhaftes Update aus dem Jahr 2013 passiert sein (Windows7/Server2008R2). Die Lösung ist relativ simpel: Zurücksetzen des Windows Zertifikatssspeichers und hinzufügen der passenden Zertifikate. Dazu gibt es auch ein passendes Update. KEINE SORGE, bei dem Update steht „Windows XP“, das läuft aber überall und macht seinen Job …

Office365 (Office 2013 ProPlus Programme) stürzen beim starten ab

Problem

Bei einem frisch installierten Windows 7 oder windows 8/8.1 System mit ebenso frisch installiertem Office365 – Office 2013, crashen die Anwendungen Word, Excel, Powerpoint un dPublisher sofort nach dem starten.

Problemsignatur
Problemereignisname:                       BEX
Anwendungsname:                            WINWORD.EXE
Anwendungsversion:                         15.0.4420.1017

die Option „Reparieren“ der Office-Installation löst das Problem nicht.

Lösung

Abby Finereader (gründlich) deinstallieren. Mehrere Versionen der Software haben Schwierigkeiten bei neu installierter Office2013 Software und mit Office2013 SP1 im allgemeinen. Leider wird Finereader wie Malware oft huckepack mit Druckertreibern, neu ausgelieferten PCs und auf ähnlichen Wegen mitgeliefert.

Excel 2010/2013 öffnet Dateien von Netzwerkservern immer schreibgeschützt und/oder sehr langsam

Problem

Microsoft Excel 2010 und 2013 öffnet Dateien von Windows-Dateiservern („Netzwerkserver“ im Mirosoft-Jargon) sehr, sehr langsam und meistens im Modus „schreibgeschützt“.

Lösung

Es gibt für dieses Phänemen meist mehr als eine Lösungskomponennte. Der findige Administrator hat aber sicher den lokalen Virenscanner und den Windows-Indexdienst bereits ausgeschlosses, daher bleibt nur noch Excel selber. Die Option „DisableRobustifiedUNC“ schaltet den Zugriff auf Excel-Dateien nach dem SMB2-Protokoll ab (keine Offlineverfügbarkeit, kein Failover, kein Multipathing …), löst das Problem aber in den meisten Fällen.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Excel\Options]
"DisableRobustifiedUNC"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Excel\Security\FileValidation]
"EnableOnLoad"=dword:00000000

Wie so viele Lösungen, ist auch diese von Microsoft nicht supportet und der Schlüssel soll „nur zu Testzwecken“ gesetzt werden.