Im Januar 2022 Patchday wurde seitens Microsoft das Update KB5022352 veröffentlicht, welches leider bei der Installation auf Windows 8.1 und Server 2012r2 Probleme macht.
Ihr merkt das daran, dass die Updates nur bis zu 95% heruntergeladen werden und auch nach langer Wartezeit nichts passiert. Falls ihr den Download abgebrochen und neugestartet habt, bleibt dieser direkt wieder bei 95% stehen.
Nach einem Reboot der Maschine tritt dann sehr häufig bei der erneuten Installation Fehlercode 80070570 auf.
Viele allgemeinen Hinweise für auftretende Fehler bei dem Download/Installieren von Patches empfehlen das löschen/umbenennen der Katalogordner im Windows-Verzeichnis. In diesem Fall ist die Lösung aber um einiges leichter:
Prüft, ob das SSU KB5018922 auf eurer Maschine bereits installiert ist. Falls ja, könnt ihr zum nächsten Schritt weitergehen. Falls nein, ladet das Update manuell aus dem Updatekatalog und installiert es: https://www.catalog.update.microsoft.com/Search.aspx?q=KB5018922
Bei mehreren Maschinen hat das o.g. vorgehen geholfen und die Patches wurden erfolgreich installiert. Lasst mich gerne wissen, ob es bei euch auch so war.
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:
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:
Microsoft scheint mittlerweile das Upgrade auf Windows 11 von Windows 10 so zu verteilen, dass die User für das Upgrade keine Administratorrechte mehr benötigen. Möchte man also verhindern, dass ein User “ausversehen” das Upgrade anstößt, hilft hierbei nur eine Gruppenrichtlinie.
Die Gruppenrichtlinie wird unter folgendem Pfad angelegt: Computerkonfiguration -> Richtlinien -> Administrative-Vorlagen -> Windows-Komponenten -> Windows Update.
Leider ist die zu setzende GPO auf den Serverversionen 2016, 2019 und 2022 veraltet, weshalb man nur die “Zielversion für Funktionsupdates” setzen kann. Da die Funktionsupdates für Windows 10 und Windows 11 die gleichen Bezeichnungen haben, bringt uns diese Einstellung leider nichts. Auf Server 2016 fehlt die Einstellung sogar komplett.
Server 2019: Zielversion des Funktionsupdates auswählen (ohne Admx-Update)
Wir müssen daher die Admx-Templates auf dem Server aktualisieren, um zusätzlich noch die Einstellmöglichkeit “Für welche Windows-Produktversion möchten Sie Windows-Updates erhalten?” zu bekommen.
Das aktuellste Admx-Template (Stand 27.05.2022) kann von hier heruntergeladen werden. Das entpacken erfolgt in einen lokalen Pfad. Von dort müssen die Daten dann auf den Domänencontroller kopiert werden, damit dieser auf die Templates zugreifen kann.
Entpacken der Admx-Templates
Dazu öffnet man den Ordner “C:\Program Files (x86)\Microsoft Group Policy\Windows 10 November 2021 Update (21H2)” im Explorer und kopiert den Ordner “PolicyDefinitions“. Dieser muss an in den folgenden Ordner eingefügt werden: “\\domain.local\sysvol\domain.local\Policies“. Der Wert “domain.local” muss mit der eigenen Domäne ersetzt werden.
Nachdem die Dateien vollständig kopiert wurden, kann man über die Gruppenrichtlinienverwaltung eine neue GPO anlegen. Im Gruppenrichtlinienverwaltungs-Editor öffnen wir den Pfad Computerkonfiguration -> Richtlinien -> Administrative-Vorlagen -> Windows-Komponenten -> Windows Update und öffnen das Template Zielversion des Funktionsupdates auswählen. Dort tragen wir im oberen Feld “Windows 10” und im unteren Feld “21H2” ein.
Server 2019: Zielversion des Funktionsupdates auswählen (mit Admx-Update)
Bitte beachten: Sobald ein neues Funktionsupdate veröffentlicht wurde und dies ausgerollt werden soll, muss der Wert im Feld Zielversion für Funktionsupdates wieder angepasst werden.
Nach einem Neustart eines Clients und dem abgleichen der GPOs sollte dann kein Hinweis mehr auf Windows 11 in der Taskleiste und unter Windows Updates eingeblendet werden.
Windows 11 Upgrade auf einem einzelnen Rechner blocken
Mit Hilfe der Gruppenrichtlinie kann das Windows 11 upgrade auch auf einem einzelnen, lokalen Rechner verhindert werden. Hierzu öffnet man über die Windows-Suche “gpedit.msc” (Editor für lokale Gruppenrichtlinien). Dort öffnen wir den Pfad Computerkonfiguration -> Richtlinien -> Administrative-Vorlagen -> Windows-Komponenten -> Windows Update und öffnen das Template Zielversion des Funktionsupdates auswählen.
Auf aktuellen Windows 10 Clients werden die Admx-Templates automatisch installiert, d.h. ein manuelles aktualisieren der Admx-Templates müsste für diese Einstellung nicht nötig sein. Die beiden Felder befüllen wir wieder mit “Windows 10” (oben) und “21H2” (unten). Nach einem Neustart wird dann ebenso in der Taskleiste und in Windows Updates nicht mehr auf Windows 11 hingewiesen.
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:
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:
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.
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):
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:
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:
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.
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:
cmdlet Get-MoveRequestStatistics, Status CreatingFolderHierarchycmdlet 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.
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):
