Kategoriearchiv: Microsoft 365

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

• Die DKiM-Einträge und dren Erfolg lassen sich hier komfortabel nachprüfen: http://dkimvalidator.com
• Es gibt mittlerweile einen Blogeintag von Terry Zink zu dem Thema: https://blogs.msdn.microsoft.com/tzink/2015/10/08/manually-hooking-up-dkim-signing-in-office-365

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:

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]

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.

Die „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 „Standardordner 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.