bookmark_borderHowto: Outlook Roaming Signature deaktivieren

Seit Anfang November rollt Microsoft das Roaming Feature für Outlook aus. Für die meisten Anwender ist diese Funktion sicherlich sehr praktisch, bei Postfächern mit mehreren Benutzer/innen und individuellen Signaturen führt das aber schnell zur Verwirrung und Problemen.

Auf einem einzelnen Rechner kann man die Änderung über einen Registry-Eintrag manuell vornehmen:

Wir öffnen die Registry (regedit) und navigieren zu folgendem Pfad:

HKEY_CURRENT_USER\Software\Microsoft\Office.0\Outlook\Setup\

Dort legen wir dann einen neuen DWORD-Wert (32bit) an: DisableRoamingSignaturesTemporaryToggle . Als Wert setzen wir “1”.

Nach setzen des Wertes muss Outlook einmal neugestartet werden. Die bisher gesetzten Einstellungen in den Signaturen bleiben aber aktiv, bis man diese einmal manuell neu setzt. Diese Änderungen sollten dann nicht mehr in die Cloud übertragen werden.


Möchte man die Änderung an mehrere Rechner verteilen, können wir dies auch über eine GPO setzen.

Hierzu legen wir eine neue Gruppenrichtlinie an und verknüpfen diese in der jeweiligen OU und setzen die User oder Gruppen Sicherheitsfilterung.

Über Rechtsklick -> Bearbeiten kommen wir dann in das Bearbeitungsfenster. Dort öffnen wir den Pfad:

Benutzerkonfiguration -> Einstellungen -> Windows-Einstellungen -> Registrierung

Dort machen wir einen Rechtsklick und wählen Neu -> Registrierungselement.

Im folgenden Fenster füllen wir die Informationen wie folgt aus:

Aktion: Aktualisieren
Struktur: HKEY_CURRENT_USER
Schlüsselpfad: Software\Microsoft\Office.0\Outlook\Setup\
Name: DisableRoamingSignaturesTemporaryToggle
Werttyp: REG_DWORD
Wertdaten: 1

Danach müssen die GPOs natürlich noch auf den jeweiligen Rechnern geupdatet werden und der Registry-Eintrag wird dann wie vorgegeben übernomen.

bookmark_borderHowto: Abschalten von Azure AD Sync nach der Migration

Es kommt der Tag, an dem man alle User und Postfächer in die Cloud migriert hat und man die Azure AD Synchronisation abschalten möchte. Dieser Artikel beschreibt die nötigen Schritte, um die Synchronisation zu stoppen.

Im ersten Schritt muss das Programm Azure AD Sync deinstalliert werden. Daher deinstallieren wir das Programm vom Server auf dem es installiert war.

Im nächsten Schritt verbinden wir uns via Powershell mit Azure AD. Das funktioniert nicht unter Linux, weshalb wir hier auf jeden Fall ein Windows-System benötigen. Man öffnet Powershell als Administrator und tippt folgendes:

Install-Module -Name MSonline

Falls eine Abfrage kommt, muss diese mit “Y” bestätigt werden.

Im nächsten Schritt stellen wir die Verbindung zu Azure AD her:

Connect-MsolService

Im sich öffnenden Fenster müssen die Zugangsdaten für den Tenant eingetragen werden.

Nun überprüfen wir, ob Azure AD Sync im Moment aktiviert ist:

(Get-MsolCompanyInformation).DirectorySynchronizationEnabled

Lautet die Antwort “True” ist AD Sync aktuell aktiviert. Lautet sie “False”, ist es aktuell deaktiviert und man kann an diesem Punkt stoppen.

Mit dem folgenden Befehl deaktivieren wir die Verzeichnissynchronisierung:

Set-MsolDirSyncEnabled -EnableDirSync $false

Danach kann noch einmal überprüft werden, ob die Synchronisierung deaktiviert wurde. Als Status sollte “False” erscheinen:

(Get-MsolCompanyInformation).DirectorySynchronizationEnabled

bookmark_borderHowto: DKIM in Microsoft 365 aktivieren

DKIM (Domain Keys Identified Mail) sollte immer für alle Domains die zum E-Mail Versand genutzt werden aktiviert sein. Falls DKIM nicht eingerichtet ist, könnten Mails fälschlicherweise als Spam markiert werden. Das folgende Tutorial zeigt, wie man DKIM für Domains mit E-Mail Versand in Office365 / Microsoft 365 aktivieren kann.

Als erstes müssen wir eine Powershell Verbindung zu unserem M365 Tenant herstellen. Der letzte Absatz in diesem Artikel beschreibt diesen Schritt genauer.

Der folgende Befehl zeigt eine ausführliche Liste mit Informationen zu DKIM im Tenant an:

Get-DkimSigningConfig -Identity domain.com | Format-List

Falls wir uns nur den DKIM-Status anzeigen lassen wollen, reicht folgender Befehl:

Get-DkimSigningConfig
cmdlet Get-DkimSigningConfig

Das Beispiel zeigt, dass DKIM für die Tenant Domain aktiviert ist. Unsere Primärdomain ist jedoch nicht aktiviert. Bevor wir DKIM aktivieren können, müssen wir jedoch noch Einträge zur Verifikation im DNS hinterlegen.

Get-DkimSigningConfig -Identity domain.com | Format-List Selector1CNAME, Selector2CNAME
cmdlet Get-DkimSigningConfig

Die Einträge im DNS werden wie folgt gesetzt. Wir benötigen die Ausgabe hinter Selector1CNAME bzw. Selector2CNAME (Das Ziel im folgenden Beispiel muss durch die Ausgabe für Selector1 bzw. Selector2 ersetzt werden):

Host: selector1._domainkey
Ziel: selector1-domain-com._domainkey.youronmicrosoftdomain.onmicrosoft.com

Host: selector2._domainkey
Ziel: selector2-domain-com._domainkey.youronmicrosoftdomain.onmicrosoft.com

Nun müssen wir mindestens 10 – 15 Minuten warten, bis unsere DNS-Einträge sichtbar sind. In manchen Fällen kann dies auch länger dauern (bis zu 24 Stunden). Als nächster Schritt kann eine der drei folgenden Optionen gewählt werden:

Option 1: Via Powershell

Hierzu muss eine Powershell-Verbindung zum M365 Tenant hergestellt und folgender Befehl ausgeführt werden:

Set-DkimSigningConfig -Identity domain.com -Enabled $true

Option 2: Via Security Admin Center

  • In das M365 Admin Center einloggen (https://admin.microsoft.com)
  • Links auf Sicherheit klicken
  • Im Security Center auf Bedrohungsmanagement und dann auf Richtlinie klicken
  • DKIM auswählen
  • Die Sende-Domain auswählen
  • Den Slider von Deaktiviert auf Aktiviert ändern und speichern

Option 3: Via altem Exchange Admin Center

  • In das M365 Admin Center einloggen (https://admin.microsoft.com)
  • Links auf Exchange klicken
  • Im Exchange Admin Center das alte Exchange Admin Center öffnen
  • Dort auf Schutz -> dkim klicken
  • Die Sende-Domain doppelt anklicken und Aktivieren wählen

Falls es bei einem der Schritte zu einem Fehler kommt, ist sehr wahrscheinlich einer oder beide DNS-Einträge falsch bzw. noch nicht aktualisiert. Mit dem folgenden Linux-Befehl kann man die Einträge prüfen:

dig selector1._domainkey.domain.com
dig selector2._domainkey.domain.com

Die Ausgabe sollte die beiden CNAME-Einträge für Selector1/Selector2 liefern. Falls Windows verwendet wird, kann folgender Befehl genutzt werden:

nslookup -q=CNAME selector1._domainkey.domain.com
nslookup -q=CNAME selector2._domainkey.domain.com

Beide Selectoren müssen korrekt gesetzt sein, bevor Microsoft es uns erlaubt, DKIM für die Domain zu aktivieren. Falls die Einträge korrekt sind, kann es einfach noch ein wenig dauern. Nach 15 – 30 Minuten kann man dann erneut versuchen, DKIM über eine der drei obenstehenden Optionen zu aktivieren.

bookmark_borderM365 Mailbox auf einen anderen Datenbankserver verschieben

Falls man eine spezifische Mailbox in Microsoft 365 auf einen anderen Datenbankserver verschieben möchte, benötigt man die Powershell. Als erstes öffnet man die Powershell und stellt eine Verbindung zum M365 Tenant her. Diesen Schritt habe ich in folgendem Artikel im letzten Abschnitt beschrieben: Powershell unter Linux

Als erstes sollten wir uns ansehen, auf welchem Datenbankserver die Mailbox aktuell liegt:

Get-MailboxLocation -Identity user@domain.com
cmdlet Get-MailboxLocation

Wie im obenstehenden Bild ersichtlich, wird im Feld “DatabaseLocation” der Hostname des Datenbankservers angezeigt. Nun erstellen wir eine Anforderung zur Verschiebung der Mailbox. In Microsoft 365 / Exchange Online können wir den Zielserver nicht manuell festlegen. Microsoft wird die Mailbox auf einen anderen, zufälligen Server verschieben.

New-MoveRequest -Identity user@domain.com
cmdlet New-MoveRequest

Nachdem wir die Anforderung erstellt haben, müssen wir darauf warten, dass der Verschiebeprozess bearbeitet wird. Mit dem folgenden Befehl können wir uns den aktuellen Status anzeigen lassen:

Get-MoveRequestStatistics -Identity user@domain.com
cmdlet Get-MoveRequestStatistics, Status CreatingFolderHierarchy
cmdlet Get-MoveRequestStatistics, Status CopyingMessages

Das Verschieben dieser knapp 18GB großen Mailbox hat ungefährt 1,5 Stunden gedauert. Dies hängt hauptsächlich mit der Auslastung des Quell- und Zielservers zusammen. Nachdem die Verschiebung beendet ist, sollte der betroffene User Outlook einmal neustarten.

bookmark_borderPowershell unter Linux

Viele wissen nicht, dass Powershell auch unter Linux verfügbar ist. In manchen Fällen benötigt man die Windows Powershell um z.B. M365, Exchange Online oder Azure AD zu administrieren. Leider sind nicht alle cmdlets für die Linux Powershell verfügbar, aber die Installation ist recht einfach.

Linux-Derivate die offiziell für Powershell 7.1 unterstützt sind:

  • Ubuntu 16.04/18.04/20.04
  • Ubuntu 19.10 (via snap-packages)
  • Debian 9/10
  • CentOS/RHEL 7/8
  • Fedora 30
  • Alpine (from 3.11)

Installationsbeispiel (Ubuntu 20.04)

Die Powershell kann direkt über ein Repository installiert werden:

# Update the list of packages
sudo apt-get update
# Install pre-requisite packages.
sudo apt-get install -y wget apt-transport-https software-properties-common
# Download the Microsoft repository GPG keys
wget -q https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb
# Register the Microsoft repository GPG keys
sudo dpkg -i packages-microsoft-prod.deb
# Update the list of products
sudo apt-get update
# Enable the "universe" repositories
sudo add-apt-repository universe
# Install PowerShell
sudo apt-get install -y powershell
# Start PowerShell
pwsh

Zur Office365 Powershell verbinden

Nachdem Powershell installiert wurde, kann man sehr leicht eine Verbindung zu Office 365 herstellen. Dazu muss die Powershell geöffnet und folgendes eingegeben werden (Nach dem ersten Schritt werden die Office 365 Zugangsdaten abgefragt):

$O365Credential = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $O365Credential -Authentication Basic -AllowRedirection

Import-PSSession -Session $Session

Nach dem letzten Schritt dauert es einige Sekunden, bis die Session importiert wurde. Danach kann die benötigten cmdlets aufrufen.