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
• Als nächstes installieren wir manuell das fehlerhafte Update KB5022352 aus dem Windows Updatekatalog: https://www.catalog.update.microsoft.com/Search.aspx?q=KB5022352

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.

Der Beitrag Server 2012r2 / Windows 8.1 KB5022352 Fehler 80070570 erschien zuerst auf MEB-IT | Blog.

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

Der Beitrag Howto: Outlook Roaming Signature deaktivieren erschien zuerst auf MEB-IT | Blog.

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.

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.

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.

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.

Der Beitrag Howto: Windows 11 Upgrade in Domäne blockieren erschien zuerst auf MEB-IT | Blog.

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

Der Beitrag Howto: Abschalten von Azure AD Sync nach der Migration erschien zuerst auf MEB-IT | Blog.

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

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

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.

Der Beitrag Howto: DKIM in Microsoft 365 aktivieren erschien zuerst auf MEB-IT | Blog.

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

Get-MailboxLocation -Identity user@domain.com

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

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

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.

Der Beitrag M365 Mailbox auf einen anderen Datenbankserver verschieben erschien zuerst auf MEB-IT | Blog.

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.

Der Beitrag Powershell unter Linux erschien zuerst auf MEB-IT | Blog.