Kategorie-Archiv: Microsoft 365

IIS SMTP stürzt nach einem in-place upgrade auf Windows Server 2022 ab (Fehler 7031 und Fehler 1000)

Veröffentlicht am von — 1 Kommentar ↓

Nach der Durchführung eines In-Place-Upgrades von Windows Server 2016 oder 2019 hat der gute alte IIS SMTP Dienst scheinbar ein ernstes Problem: Er stürzt mit einem Fehler ab wenn an eine E-Mail über diesen versenden will. In manchen Fällen erfolgt der Crash auch schon beim einfachen start des SMTPSVC.

Im Ereignisprotokoll (Anwendungsprotokoll) gibt es auch sofort den dazu passenden Fehler:

Name der fehlerhaften Anwendung: inetinfo.exe, Version: 10.0.20348.1, Zeitstempel: 0x20d57e42
Name des fehlerhaften Moduls: SMTPSVC.dll, Version: 10.0.20348.1, Zeitstempel: 0xba4e29ad
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0000000000059abb
ID des fehlerhaften Prozesses: 0x850
Pfad der fehlerhaften Anwendung: C:\WINDOWS\system32\inetsrv\inetinfo.exe
Pfad des fehlerhaften Moduls: C:\WINDOWS\system32\inetsrv\SMTPSVC.dll
[...]

Wir wissen zwar das der IIS6 „deprecated“ ist, haben aber keine Erklärung für Microsofts offensiver „Your Problem“ Haltung zu dieser oftmals vitalen Windows-Komponente.

Es gibt schliesslich einen Haufen guter Gründe, weiterhin ein internes SMTP-Relay zu betreiben. ERP-Software muss in aller Regel Mails versenden, Scanner-Systeme, Alarmmelder und Maschineninformationen wollen Kontakt halten. Kaum eines dieser Systeme beerrscht die sichere Authentifizierung, noch weniger eines möchte man sowas für den Versand ins Internet lassen.

Lösung

Der Trick ist einfach: man muss einfach vor dem Upgrade ein Backup der IIS-Site machen und nach dem Upgrade widerherstellen. Dann läuft alles wie gewohnt und weiterhin geschmiert. Der Grund ist unsinniges Update-Gefummel in der IIS-Metabase, die sich aber erledigt hat wenn man seine alte (fehlerfreie) Version einfach weiterverwendet.

VOR dem Upgrade ein IIS Backup erstellen

Die CMD-Shell „Als Administrator“ öffnen

%windir%\system32\inetsrv\appcmd.exe ADD BACKUP %computername%

Die Backup-Dateien landen sofort in diesem Pfad:

%windir%\system32\inetsrv\backup\%computername%

NACH dem Upgrade das Backup widerherstellen

Die Backup-Dateien gehen wärend des Upgrades zwar nicht verloren (aber paranoide Admins wie wir kopieren den Inhalt des Verzeichnisses natürlich an einen sicheren Ort).

Auch nach dem Update wird die CMD-Shell „Als Administrator“ benötigt:

%windir%\system32\inetsrv\appcmd.exe RESTORE BACKUP %computername%

Außerdem stellt das Setup den IIS SMTP Dienst auf den manuellen Start um, was nach Server-Neustarts zu Kopfkratzen führen könnte. Der Dienst sollte also möglichst wieder automatisch starten:

sc config smtpsvc start=auto
sc start smtpsvc

Und schon funktioniert der SMTP-Server auch unter Windows Server 2022 wieder.

Kalender einer Ressource zeigt keinen Betreff an, sondern den Namen des Organisators

Veröffentlicht am von — Keine Kommentare ↓

Ein Ressourcenpostfach (z.B. Shared Mailbox) ist in Exchange Online mit „AutoAccept“ (automatische Zusagen, AutomateProcessing) konfiguriert, damit der Kalender Besprechungsanfragen bestätigt.

Die Besprechungsanfragen werden auch korrekt automatisch angenommen. Der Besprechungsbetreff wird im Postfach des Organisators auch angezeigt.

Aber alle anderen Benutzer (mit Berechtigungen auf dem Postfach) sehen statt des Besprechungsbetreffs nur den Namen des Organisators.

Lösung

Dies ist das Standardverhalten von Exchange Online (und Exchange seit 2010) und seither irritierend. Das passiert immer dann, wenn AddOrganizerToSubject und/oder DeleteSubject auf True festgelegt sind.

Aktuelle Einstellung anzeigen:

Get-CalendarProcessing -Identity <RESSOURCE> | fl *subject*

Einstellungen ändern:

Set-CalendarProcessing -Identity <RESSOURCE> -DeleteSubject $false -AddOrganizerToSubject $false

DeleteSubject: Soll der Betreff entfernt werden? (true=ja)

AddOrganizerToSubject: Soll der Name des Organisierenden den Betreff ersetzen? (true=ja)

Microsoft 365 Exchange Online E-Mails zählen

Veröffentlicht am von — Keine Kommentare ↓

Manchmal muss man wissen, wie viele Nachrichten an einen bestimmten Empfänger gesendet wurden. Zum Beispiel „Wie viele Nachrichten wurden in den letzten 24 Stunden an dieses Postfach gesendet?“.

Das ist leider nicht ganz so einfach, weil Get-MessageTrace nur 1000 Zeilen ausgibt. Man kann das Commandlet zwar mit -PageSize 5000 etwas tunen, aber wenn es um mehr Nachrichten geht, muss man die abzufragende Zeit eingrenzen und addieren.

Anzahl empfangener E-Mails in 24h anzeigen

Wenn man erst mit Import-Module ExchangeOnlineManagement das Exchange Online PowerShell-Modul importiert hat und sich via Connect-ExchangeOnline auch verbunden hat, kann man Nachrichen auflisten und zählen:

Get-MessageTrace -PageSize 5000 -RecipientAddress [email protected] -Start ((get-date -hour 0 -Minute 0 -Second 0).adddays(-1)) -End (get-date -Hour 0 -Minute 0 -Second 0) | Measure-Object

Microsoft 365 Kennwort sofort ablaufen lassen (Änderung des Kennwortes erzwingen)

Veröffentlicht am von — Keine Kommentare ↓

Manchmal möchte man ein bestimmtes Office 365 Konto schnell geändert wissen. Möglicherweise weil das Kennwort auf einem Zettel unter der Tastatur aufgetaucht ist oder ein Gerät verschwunden ist. Es wäre toll, wenn man den Benutzer schnell zur Änderung zwingen könnte.

Leider gibt Microsoft dem Administrator dafür kein GUI-Werkzeug in die Hand. Man kann in der Oberfläche das Kennwort zwar gewaltsam „zurücksetzen“, aber leider nicht als „abgelaufen“ markieren. Eine Kennwortablaufrichtline gibt es nur Unternehmensweis und nur in Tagen.

Lösung

An der PowerShell ist das natürlich möglich. Man muss dazu das MSOnline Modul in seiner PowerShell aktive haben (import-module MSOnline) und mit dem Microsoft-Tenant verbunden sein (Connect-MsolService).

Erzwingt die sofortige Änderung

Set-MsolUserPassword -UserPrincipalName "[email protected]" -ForceChangePassword $true -ForceChangePasswordOnly $true

⚠ Die Dokumentation des Commandlets „Set-MsolUserPassword“ ist leider unvollständig.

  • ForceChangePassword $true erzwingt das der Benutzer bei der nächsten Anmeldung sein Kennwort ändert
  • ForceChangePasswordOnly $true sorgt dafür, das kein neues Kennwort automatisch vergeben wird

Man kann natürlich auch an der Kommandozeile ein neues Kennwort vorgeben:

Set-MsolUserPassword -UserPrincipalName "[email protected]" -NewPassword "GEHE1MK3NNW0RT"

Oder von der Powershell ein neues Kennwort generieren und setzen lassen:

Set-MsolUserPassword -UserPrincipalName "[email protected]" -ForceChangePassword

Erzwingt die Änderung des Kennwortes nach Datum

Man kann in Set-MsolUserPassword auch beliebige Selektionen hinein-pipen. Das vereinfacht beispielweise die Vorgabe nach einem bestimmten Datum (hier der 24. Juli 2021) oder nach Alter.

Get-MsolUser | where LastPasswordChangeTimestamp -lt (Get-Date 24.07.2021) | Set-MsolUserPassword -ForceChangePassword $true -ForceChangePasswordOnly $true

Hinweis: „Sonderfall“ Outlook

Nachdem man für den nächsten Login eine Passwortänderung „erzwungen“ hat, funktioniert nun allerdings noch das bestehende Passwort und vor Allem Outlook kann wunderbar mit einem bestehenden Session-Token weiterarbeiten (auch mehrere Wochen lang).

Um im Outlook einen neuen Login zu erzwingen, muss man das Session-Token revoken. Das geht ebenfalls per PowerShell, benötigt aber das AzureAD Modul (😑):

Get-AzureADUser -SearchString "[email protected]" | Revoke-AzureADUserAllRefreshToken

Oder für die selben Benutzer wie oben (nach letztem Änderungsdatum):

Get-MsolUser | where LastPasswordChangeTimestamp -lt (Get-Date 24.07.2021) | foreach {Get-AzureADUser -SearchString $_.UserPrincipalName} | Revoke-AzureADUserAllRefreshToken

VPN mit Zertifikaten von iOS zu Windows RRAS mit Endpoint Manager (Intune) konfigurieren

Veröffentlicht am von — Keine Kommentare ↓

Wir möchten erfolgreich eine VPN-Verbindung auf iOS-Endgeräte verteilen. Das „OnDemand“ VPN soll verwendet werden und daher muss der Nutzer mit Zertifikaten authentifiziert werden. die Authentifizierung am NPS (Radius) ist noch eine andere Sache, dieser Beitrag konzentriert sich auf das IKEv2 zwischen iOS und Windows Server RRAS.

Unsere iOS-VPN-Intune Checkliste

  • Microsoft Endpoint Manager (ehemals Intune) soll die VPN-Verbindung via Konfigurationsprofil verteilen
    • Die Devices sind schon im EPM angekommen und synchronisieren fröhlich Richtlinien
  • Microsoft Endpoint Manager soll den Nutzern (auf den Geräten) automatisch ein Zertifikat ausstellen (via „Certificate Connector“)
    • Funktioniert perfekt mit einer Microsoft CA
    • Die CA und NPS sind nicht Teil dieses Beitrages, aber mit Anleitung durchaus machbar
  • Die iPhone/iPads Geräte haben iOS 14.2 oder neuer (!)
  • Es wird IKEv2 verwendet
    • Denn das ist die einzige Möglichkeit, iOS mit RRAS unter der Verwendung von Zertifikaten zu verbinden
  • Der RRAS Server ist ein Windows Server 2019
  • RRAS ist korrekt konfiguriert (Ports, Erreichbarkeit, Radius …)
  • NPS ist korrekt konfiguriert (Verbindungsanforderungs- und die Verbindungsrichtlinie …)

Im Prinzip folgen wir dem brauchbaren „Deploy Always On VPN“ Guide von Microsoft unter https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/always-on-vpn-deploy-deployment

Der Trick ist eine funktionierende Kombination aus iOS IKEv2-Parametern und den zugehörigen Phase1/2 Parametern auf der RRAS-Gegenstelle zu erstellen. Denn das ist nicht Default und leider auch praktisch nirgends dokumentiert.

RRAS-Server

Um erfolgreich eine IKEv2 Verbindung von iOS zum RRAS Server herzustellen, ist dem RRAS-Server (und iOS) die richtige Kombination der Ciphersuits vorzugeben. Das geht am RRAS via CustomPolicy. Natürlich exklusiv an der PowerShell.

Viele Kombinationen funktionieren nicht. Diese hier funktioniert:

Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -DHGroup Group14 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -PfsGroup PFS2048 -SALifeTimeSeconds 28800 -MMSALifeTimeSeconds 86400 -SADataSizeForRenegotiationKilobytes 1024000

Dann muss man dem RRAS-Server in aller Regel erklären, das er auch fragmentierte IKE Pakete annehmen soll. Bei einer Schlüsselgröße von 2048bit mit Zertifikaten und einer MTU von 1492 oder 1500byte wird es oft knapp und Pakete fragmentieren:

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\" -Name EnableServerFragmentation -PropertyType DWORD -Value 1 -Force

Wenn beides geschehen ist, muss der RRAS neu starten:

Restart-Service RemoteAccess

Microsoft Endpoint Manager

Innerhalb der VPN-Richtlinie kommt es auf die IKEv2 Parameter an. Die sind in einer bestehenden Richtlinie erreichbar unter Devices > Richtlinie (Name) > Properties > Configuration settings > IKEv2 Settings. Dort gibt es ab etwa der Mitte die „wichtigen“ (und nicht offensichtlichen) Einstellungen:

Perfect forward secrecy: Enable

Certificate revocation check: Disable

Use IPv4/IPv6 internal subnet attributes: Disable

Mobility and multihoming (MOBIKE): Enable

Redirect: Enable

Security Association Parameters

Encryption algorithm: AES-256

Integrity algorithm: SHA2-256

Diffie-Hellman group: 14

Lifetime (minutes): 1440

Child Security Association Parameters

Encryption algorithm: AES-256

Integrity algorithm: SHA2-256

Diffie-Hellman group: 14

Lifetime (minutes): 480

… und schon geht’s. Also schon ging es bisher bei unseren Systemen 🙂

Vielleicht schreiben wir irgendwann noch einen großen Artikel mit allen Schritten, also von der Zertifizierungsstelle bis zum Endgerät … oder jemand anderes tut das. Oder, wenn ihr sowas braucht, ruft ihr uns an 😋