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.

Office 2013 auf Office365 offline herunterladen/installieren oder im Netzwerk verteilen

OfficeSetupDas Setup für die Office 2013 Programme aus Office 365 (die Clickstream-Installation) ist sehr einfach erledigt und bei einer schnellen Internetverbindung in relativ kurzer Zeit passiert.

Wie aber installiert man mehrere Computer in einem Netzwerk? Oder einen PC mit langsamer Internetanbindung? Microsoft hat diesen Fall immerhin vorgesehen, wenn auch nicht unbedingt einfach zugänglich gemacht. Es wäre ja auch VIEL zu einfach, wenn ein Admin das Officepaket herunterladen und direkt installieren könnte *kopfschüttel*. wie auch immer, so funktioniert die Office 365 Netzwerkverteilung (neudeutsch ‚On Premise deployment‘).

Lösung

  1. Das „Office Deployment Tool for Click-to-Run“ herunterladen und den Inhalt der Datei mit 7Zip auf den deployment UNC-Netzwerkshare (\\server\foobar) auspacken. Eine Installation ist NICHT notwendig.
  2. Die configuration.xml wie folgt bearbeiten:
    <Configuration>
     <Add SourcePath="\\server\foobar\ordner\" OfficeClientEdition="32" >
     <Product ID="O365ProPlusRetail">
     <Language ID="de-de" />
     <ExcludeApp ID="InfoPath" />
     </Product>
     </Add>
     <Updates Enabled="TRUE" UpdatePath="\\dcw1\install$\office365\" />
     <Display Level="None" AcceptEULA="TRUE" />
    </Configuration>

    Es ist hier auch möglich, das Setup noch weiter anzupassen:

    1. Office-Apps von der Installation ausnehmen
    2. Office-Apps hinzufügen (Visio, Project …)
    3. Setup-Optionen (EULA, Logging …)
  3. Das Setup zum Herunterladen der Office-Click-to-Run Setupdateien auffordern (das Paket ist etwa 1.4gb groß):
    setup.exe /download <pfad>\configuration.xml
  4. Aus diesen Ordner kann man dann das Officepaket nun lokal im Netzwerk installieren:
    setup.exe /configure <pfad>\configuration.xml

Wird das Setup mit „/download“ aufgerufen, werden die Dateien auf der Netzwerkfreigabe (oder dem lokalen Laufwerk) gespeichert. Wenn das Setup dann zum Installieren mit „/configure configuration.xml“ gestartet wird, holt der Installer die notwendigen Dateien ebenfalls vom selben Ort ab. Mehr Details zu dem Tool gibt es bei Microsoft unter http://technet.microsoft.com/en-us/library/jj219422.aspx.

Keine RDS-Berechtigung in Office365 „Business“Plänen.

Seit dem 1. September 2014 gibt es mit shared computer activation die neue Terminalserver-Installationsmethode für Office 365 ProPlus. Das Office-Paket aus Office 365 E3 und Office 365 ProPlus kann jetzt mit Hilfe des Office Deployment Tool auf Terminalservern ab Windows Server 2008 R2 (mit aktivierter RDS-Rolle) oder auch in virtuellen Desktop Pools installiert werden. Das bedeutet, dass man endlich nicht mehr diesen (ansonsten) unsinnigen einzelnen zusätzlichen Office 2013 Professional Plus-Datenträger (+Key) braucht.
Bei der Installation muss auch nicht mehr das gesamte Paket installiert werden, sondern man kann mit Hilfe der Steuerdatei für die Installation auch einzelne Anwendungen von der Installation ausschließen. Das ist ja schon fast Praxisnah! 🙂

Jetzt kommt der fiese Teil.

Die neuen Office 365-Businesspläne bringen dafür keine RDS-Berechtigung mehr mit. In den M-Plänen und E-Plänen als OpenValue -Volumenvetrag war das PUR dazu enthalten, in Business nicht mehr. Alle Kunden die Office 365 Business oder Office 365 Business Premium in Zukunft kaufen, verfügen nicht über den gleichen Programm- und Funktionsumfang wie Office 365 ProPlus. Und so sehen die „neuen“ Berechtigungen im Detail aus:

office365-officeproplus-pur-table-2014

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 …