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).

DomainKeys Identified Mail (DKIM) in Office365 aktivieren

DomainKeys Identified Mail (oder auch kurz „DomainKeys“) ist ein Identifikationsprotokoll zur Sicherstellung der Authentizität von E-Mail-Absendern, das zwar ursprünglich von Yahoo entwickelt wurde, aber 2004 etwa weitere Verbreitung findet. Im wesentlichen veröffentlich man via DNS seinen Mailserver-PublicKey und die SMTP-Haaderangaben bei ausgehenden Mails werden vom MTA mit den zugehörigen private Key verschlüsselt. Der Empfänger(server) kann im DNS nachschlagen und die Header lesbar machen. Damit ist die Identität des Absenders einer Nachricht sichergestellt.

Eine gute Erfindung, macht das an und nutzt das auch.

In Office365 ist das einfach umgesetzt und schnell erledigt:

  1. Eigenen domainGUID aus dem Portal besorgen.
    1. ENTWEDER aus dem MX-Eintrag: DOMAINGUID.mail.protection.outlook.com
    2. ODER: Office365 Portal > Admin Center > Exchange > Schutz > dkim > Domain auswählen, rechts auf „aktivieren“. In der gelben Meldung steht die DomanGUID drin:
    3. office365-dkim-dns-eintraege
  2. Der TENANT-NAME ist der Name, der beim einrichten von Office365 vergeben wurde, zum Beispiel „meinefirma“(.onmicrosoft.com). Das kann man unter „Domains“ im Portal nachsehen.
  3. Veröffentlichen der DKIM-Verweise via DNS. Das geht komfortabel über CNAME-Einträge die auf Server von Microsoft verweisen, eigene Schlüsselpaare zu generieren ist nicht notwendig:
    Host:     selector1._domainkey
    Ziel:     selector1-<domainGUID>._domainkey.<TENANT-NAME>
    TTL:      3600
    
    Host:     selector2._domainkey
    Ziel:     selector2-<domainGUID>._domainkey.<TENANT-NAME>
    TTL:      3600
    
  4. Nach 10 Minuten (in etwa) reicht dann der Klick auf „aktivieren“ im Office365 DKIM-center.

Ergänzung: Copy+Pasta für BIND. DomainGUI ist „contoso“, der Tenant heisst „contoso-com“.

selector1._domainkey.contoso.com IN CNAME selector1-contoso-com._domainkey.contoso.onmicrosoft.com
selector2._domainkey.contoso.com IN CNAME selector2-contoso-com._domainkey.contoso.onmicrosoft.com

selector1._domainkey.fabrikam.com IN CNAME selector1-fabrikam-com._domainkey.contoso.onmicrosoft.com
selector2._domainkey.fabrikam.com IN CNAME selector2-fabrikam-com._domainkey.contoso.onmicrosoft.com

Office 365 Powershell Download/Setup/Installation

Die Windows PowerShell für Office 365 ist ein sehr leistungsfähiges Tool. Erweiterbar wie ein IBM Universal  Business Adapter und in etwa auch so komplex. Es gibt einen Punkt in der Lernkurve, an dem Anfänger häufig den Faden verlieren; dies passiert in der Regel nach dem Erlernen der einfachsten Cmdlets und bevor die Erstellung nützlicher Lösungen vollständig verstanden worden ist. Es ist eine einfache Sache „Get-Process“ auszuführen, aber eine andere eine Reihe von Cmdlets in eine Pipeline für einen Remotecomputer einzureihen, um eine Aktion remote auszuführen. Grade Office 365 ist beispielsweise nicht vollständig in die „Ausliefershell“ integriert und benötigt einige zusätzliche Module und die Initialisierung der Remote-Shell.

So gehts auf in die Office 365 Powershell

  1. Betriebssysteme unter Windows7/2008R2 brauchen WinRM2.0 mit der Powershell 2.0
  2. Download und Installation Microsoft Online Services Sign-in Assistant
  3. Download und Installation Azure Active Directory (AD) Module (x64, eine 32-bit-VErsion gibt es noch, wird aber nicht mehr supported)
  4. Optional: „SharePoint Online Module“ (Zur Sharepoint-Verwaltung)
  5. Optional: „Skype for Business Online Module“ (Zur Lync Skype for Business Verwaltung)

Verbindung zur Office 365 Powershell

$credential = get-credential
Import-Module MSOnline
Connect-MsolService -Credential $credential

Verbindung zur Skype for Business Powershell

Import-Module LyncOnlineConnector
$lyncSession = New-CsOnlineSession -Credential $credential
Import-PSSession $lyncSession

Verbindung zur Sharepoint Powershell

Import-Module Microsoft.Online.Sharepoint.PowerShell
Connect-SPOService -url https://contoso-admin.sharepoint.com -Credential $credential

Verbindung zur Exchange Powershell

$ExchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://outlook.office365.com/powershell-liveid/" -Credential $credential -Authentication "Basic" -AllowRedirection
Import-PSSession $ExchangeSession

Verbindung zu den Office 365 Onlinediensten via Poweshell-Function

function Connect-O365 {
<#
.Synopsis
 Connects powershell to Office 365
.DESCRIPTION
 Use this to connect powershell to Office 365. You will be prompted for credentials.
.EXAMPLE
 Connect-O365
#>
 Set-ExecutionPolicy RemoteSigned
 $Cred = Get-Credential
 $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $Cred -Authentication Basic -AllowRedirection
 Import-Module (Import-PSSession $Session -Allowclobber) -Global
 Connect-MsolService -Credential $Cred
}

(Danke Alex)

Office 365 Volumenlizenz kann nicht aktiviert werden

Problem

Eine neue Office 365 Volumenlizenz kann nicht in einem bestehenden Account aktiviert werden.
Fehlercode 2001 97eeff0e-58b7-4193-9173-9133e41cedf9
Volumenlizenz

Dieses Problem tritt nach der Durchführung folgender Schritte auf:
1. Anmeldung im VLSC
2. Aktivierung der entsprechenden Lizenz
3. Auswahl „Ich muss ein Konto für meine Organisation erstellen“
4. Daten für neues Konto eingegeben
5. auf „weiter“ geklickt
6. Fehlercode 2001 97eeff0e-58b7-4193-9173-9133e41cedf9 mit dem Lösungshinweis: „Kehren Sie zur vorherigen Seite zurück.“ (siehe oben)
Das Zurückkehren zu der Seite hilft aber nicht weiter.

Lösung

Noch einmal die vorherigen Schritte ausführen, jedoch bei Schritt drei „Ich verfüge über ein Konto für meine Organisation“ auswählen und mit den zuvor im ersten Durchlauf eingegebenen Daten anmelden.
Und umgehend ist die Aktivierung möglich.
Wichtig: InternetExplorer nutzen!

Office 365 Offline Installation für Business, Business Premium und andere Pläne und Update auf Office 2016

Problem

Das Office 365 Offline Setup mit herunterladen („Bereitstellen„) und offline installieren funktioniert sehr gut, leider nur mit „Office ProPlus“, nicht jedoch mit dem „Office Business Retail“ das in den anderen (Business-) Plänen enthalten ist. Die Clientseitige Umstellung („Konto wechseln“) geht zwar immernoch schneller als neu herunterladen, aber die Fehlermeldung nervt doch.

Lösung

Mit einer kleinen Anpassung in der configuration.xml lässt sich auch das passende Produkt herunterladen. Es gibt für das „Product ID“ Element in der configuration.xml Datei neue gültige Bezeichner:

Office 365-plan

Produkt-ID

Office ProPlus
Office 365 Enterprise E3
Office 365 Enterprise E4
Office 365 (M-Plan)
O365ProPlusRetail
Office 365 Business
Office 365 Business Premium
O365BusinessRetail
Office Small Business Premium O365SmallBusPremRetail

Zudem gibt es auch neue IDs für das Office 365 Setup für die Einzelprodukte:

  • AccessRetail
  • ExcelRetail
  • HomeBusinessRetail
  • HomeStudentRetail
  • InfoPathRetail
  • ProfessionalRetail
  • O365HomePremRetail
  • O365SmallBusPremRetail
  • OneNoteRetail
  • OutlookRetail
  • PowerPointRetail
  • ProjectStdRetail
  • PublisherRetail
  • VisioStdRetail
  • WordRetail

Ein Beispiel für ein „Office 365 Business Premium Offline Setup“ sieht also so aus:

<Configuration>
  <Add SourcePath="\\SERVER\FREIGABE\PFAD\" OfficeClientEdition="32" >
    <Product ID="O365BusinessRetail">
      <Language ID="de-de" />
    </Product>
  </Add>
  <Updates Enabled="TRUE" UpdatePath="\\SERVER\FREIGABE\PFAD\" />
  <Display Level="None" AcceptEULA="TRUE" />
</Configuration>

Offline Update auf Office 2016

Das Upgrade vorhandener Installationsdateien lässt sich durch die neue Version des Deployment-Tools und erneutes ausführen von

setup.exe /download <pfad>\configuration.xml

durchführen. Die Clients übernehmen das danach selbstständig, von online oder erneutes ausführen von /configure.

[Update: Microsoft hat einen KB-Artikel nachgereicht, der die aktualisierten Product-IDs enthält]

[Update: Microsoft hat einen Technet-Artikel nachgereicht, der auch das Exclude-Element dokumentiert]

Office 365: Fehler beim Lokalisierungsvorgang „Die Standardordner können nicht lokalisiert werden“

Problem

Bei einigen Nutzern wird unter Office 365 sowohl in Outlook als auch in der Outlook Web App der Ordnername „Inbox“ anstatt „Posteingang“ angezeigt. Das gilt auch für die anderen Ordner, also Outbox, Calendar, Deleted Objects und so weiter.

office365-standartordnernamen-inbox-umbenennenDie „richtige“ Lösung, die Ordner nach dem passenden Namensschema umzubenennen funktioniert aber nicht. Man versucht über OWA > Optionen > Allgemein > „Region und Zeitsone“ den Hake bei „Standartordner umbenennen“ zu setzen und erhält nach dem Klick auf „Speichern“ diese Fehlermeldung:

Fehler beim Lokalisierungsvorgang für die Standardordner von Postfach „EURFOOBARA003.prod.outlook.com/Microsoft Exchange Hosted Organizations/TENANT.onmicrosoft.com/whatever“: Die Standardordner können nicht lokalisiert werden.

Dasselbe Ergebnis zeigt die die Powershell bei der Verwendung von

Set-MailboxRegionalConfiguration <UserIdentity> -LocalizeDefaultFolderNam

und auch Outlook mit dem berühmten /resetfoldernames Parameter.

Lösung

Ordnernamen von Systemordnern („Gesendete Objekte“, „Postausgang“, „Posteingang“ …) dürfen nicht doppelt vorkommen. In 100% aller Fälle (bei uns) gab es einen Ordner mit dem selben Namen schon. Ob der beim importieren als Unfall erschienen ist (Outlook macht da manchmal nicht nachvollziehbare Verdoppelungs-Phänomene) oder manuell erstellt wurde ist irrelevant. Wenn die doppelten Ordner aber entfernt sind, klappt es auch mit dem /resetforldernames sofort.