Archiv der Kategorie: Computers and Internet

M365 | Aufbewahrung von Mails in freigegebenen Postfächern

Veröffentlicht am von
Antwort

In M365 können freigegebene Postfächer gelöschte Mails eine Zeitlang im Ordner „Gelöschte Objekte” aufbewahren. Die Aufbewahrungsdauer generell sowie die maximale Zeitspanne von 30 Tagen sind über PowerShell konfigurierbar.

# Aufbewahrung von gelöschten Mails in einem freigegebenen Postfach "Service"
Set-Mailbox -Identity "Service" -RetainDeletedItemsFor 30.00:00:00

# Abfrage des Aufbewahrungszeitraums für das Postfach "Service"
Get-Mailbox -Identity "Service" | Select RetainDeletedItemsFor

image

Die Konfiguration erfolgt Über das Exchange-Online PowerShell-Modul, dass natürlich eine Anmeldung benötigt.

Hier noch die Befehle wie das Exchange-Online PowerShell-Modul installiert wird und wie die Anmeldung erfolgt (die Installation als Admin in der PowerShell durchführen):

# Ausführungsrichtlinie setzen
Set-ExecutionPolicy RemoteSigned -Force

# PowerShellGet aktualisieren (falls nötig)
Install-ModuleInstall-Module PowerShellGet -Force -AllowClobber

# Exchange Online Management Modul installieren
Install-Module -Name ExchangeOnlineManagement

Und hier die Anmeldung an M365 / Exchange Online:

# Verbindung zu Exchange Online herstellen
Connect-ExchangeOnline -UserPrincipalName admin

Enjoy it, b!

M365 | Outlook und ein ehemals freigegebenes Postfach

Veröffentlicht am von
Antwort

Innerhalb von M365 besteht die Möglichkeit ein freigegebenen Postfach in ein Benutzerpostfach und umgekehrt zu konvertieren.

Infos zu freigegeben Postfächern gibt es direkt bei Microsoft und auch der Prozess der Konvertierung ist dort sehr gut beschrieben.

Als Erinnerung oder Überbleibsel bleibt dabei der Name des ehemals freigegebenen Postfachs stehen und kann über Outlook (Classic) selbst auch nicht entfernt werden. Ein einfaches “schließen des Ordners” wird mit einem Fehler quittiert.

Sehr elegant kann das nun nicht mehr vorhandene Postfach über eine Deaktivierung des Auto-Mappings mit PowerShell entfernt werden. Sinnvoll aber nicht notwendig ist es, davor Outlook zu schließen.

# Remove Auto-Mapping via PowerShell (Admin Required)
Remove-MailboxPermission -Identity "ConvertedMailbox@domain.com" -User "AffectedUser@domain.com" -AccessRights FullAccess -InheritanceType All

Nach dem Start ist der alte Ordner verschwunden und Outlook sieht aus, wie es soll. Sinnvoll macht das der M365 Admin von einem System aus, auf dem die Exchange PowerShell-Module vorhanden sind.

https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/?view=exchange-ps

Enjoy it, b!

Mailstore Server 2/2 | Umstellung auf M365 Entfernen der Journalregel

Veröffentlicht am von
Antwort

In diesem Beitrag hatte ich bereits die zusätzlichen Schritte bei einer Umstellung der Mailstore Server-Archivierung auf M365 (Modern Auth) beschrieben.

Das Journaling selbst, sprich die noch vorhandene Journalregel in M365 (Microsoft Purview) und die dazu verwendete externe Mailbox, existierten noch und müssen ebenfalls gelöscht werden.

In einem ersten Schritt wird die Journalregel in Microsoft Pureview gelöscht.

image

  • Anmelden im https://purview.microsoft.com mit einem Admin-Konto
  • Navigieren zu:
    Lösungen / Datenlebenszyklusverwaltung / Exchange (Legacy) / Journalregeln

  • Auswahl der zu entfernenden Journalregel 
  • Klick auf das Papierkorb-Symbol (Löschen).
  • Bestätigen um die Regel endgültig zu entfernen

Nun kann auch die externe Mailbox, die bei einem Provider außerhalb von M365 liegt, gelöscht werden.

Enjoy it, b!

Synology VMM | Windows VM mit starker CPU Auslastung durch “System interrupts”

Veröffentlicht am von
Antwort

Ich muss hier einen Fall von Layer-8 Ignoranz schildern – mit etwas Vorgeschichte.

Alles Cloud …

Vor vier Monaten erzählte mir ein Freund, dass er eine Praxis übernehmen würde – mit einer Softwarelösung, die zu 100% in der Cloud läuft. „Wir brauchen nur ein paar Tablets und Internet, da kannst du mir vielleicht helfen?“ Wo fängt man da an …

  1. Es gab PCs, Baujahr 2018 oder 2019 – so genau wusste das niemand. Man hielt sie für „relativ neu“. OK – relativ. Und mit <Panikmodus>Festplatten</Panikmodus>
  2. Ein neues, dreidimensionales Röntgengerät musste her. Die Daten sollten direkt in die Cloud gespeichert werden – allerdings braucht es dazwischen ein „Laufwerk“ als Cloud-Cache
  3. Dazu kamen diverse Konnektoren – wofür auch immer

Die Informationen sickerten nach und nach durch. Ein vollständiges Bild hatten wir erst 14 Tage vor der Wiedereröffnung der Praxis.

Where the rubber meets the road …

Für Punkt 1 konnte ich mit etwas Überzeugungsarbeit ein Synology-NAS (RS822+) ins Spiel bringen. Dank Synology Directory Server gab es eine kleine Domäne, über die sich die PCs (nun mit SSDs ausgestattet) verwalten ließen.

Mit maximalem RAM ausgestattet, liefen darauf zwei bis drei kleine VMs. Der AMD Ryzen 1500B ist zwar kein Kraftpaket, aber für kleine Aufgaben reicht’s. Die Bereitstellung der VMs übernahm der Synology Virtual Machine Manager (VMM), also QEMU/KVM so mehr oder weniger.

Zwei Windows-VMs wurden eingerichtet:

  • Eine mit 4 vCPUs, 16 GB RAM und 2 TB Speicher für den Cloud-Cache (Punkt 2).
  • Eine weitere mit 10 GB RAM für einen Healthconnector.

Nach einigen Optimierungen liefen die VMs stabil und flott – auch dank SSD-Cache im NAS.

Punkt 3: Die Konnektoren

Der erste Konnektor ließ sich problemlos installieren. Kein Thema. Dann kam der RISE-Konnektor – und wie so oft: ein Dienstleister, der sich als besonders „resistent“ erwies.

Natürlich, der Dienstleister ist immer der andere … Winking smile

Die „Anforderung“, in der virtuellen Windows-VM (QEMU/KVM-basiert) das „Hyper-V Networking“ zu installieren, war für mich nicht nachvollziehbar. Angeblich sei das für WireGuard-VPN nötig?! Das Eventlog zeigte jedenfalls mehr als nur „Hyper-V Networking“ – vielleicht hatte er sich jemand verklickt.

image

Mir ist kein explizites „Hyper-V Networking“ bekannt. Windows bietet auf dem Client die folgenden Features an:

Vor dem Reboot sah der Taskmanager noch wie folgt aus …

image

Die Konsequenzen waren aber dem Reboot zu sehen und verheerend.

image

Der Screenshot zeigt nicht das gesamte Ausmaß des Desasters, die virtuellen CPUs liefen über weite Strecken auf 100% und ein Arbeiten war nicht mehr möglich. Weder RDP-Sitzungen noch TeamViewer funktionierten. Auch mehr vCPUs halfen nicht wesentlich.

Ich konnte die Last auf etwa 40 % drücken – aber die VM blieb träge. Sehr träge.

image

Sobald die Hyper-V-Rolle innerhalb des Windows 11-Gastsystems installiert ist, beginnt sich die virtuelle Maschine selbst wie ein Hyper-V-Host zu verhalten (oder versucht es zumindest). Dies verändert die Art und Weise, wie Windows mit der zugrunde liegenden Hardware und der Virtualisierungsschicht interagiert und führt häufig zu:

  • Konflikten bei verschachtelter Virtualisierung: Hyper-V innerhalb einer VM (Nested Virtualization) kann mit den eigenen Virtualisierungsmechanismen von QEMU/KVM interferieren.
  • Problemen bei der Interrupt-Verarbeitung: Das System kann auf andere Taktquellen oder Interrupt-Modelle umschalten (z. B. hyperv_clocksource_tsc_page vs. tsc), was zu übermäßigen System-Interrupts und einer verschlechterten Leistung führen kann
  • Verändertes Timer- und Polling-Verhalten: Hyper-V kann beeinflussen, wie das Gastbetriebssystem Leerlaufzustände und Interrupts behandelt – insbesondere, wenn Funktionen wie halt_poll nicht abgestimmt sind

Ein zeitaufwändig erstellter Dump des Systemprozesses (PID 4) zeigte massenhaft IRPs – ein weiteres Indiz für Probleme durch Hypervisor-Verschachtelung.

image

Hyper-V musste also wieder runter

Final blieb nur die Möglichkeit Hyper-V zu entfernen, was dem Dienstleister nicht wirklich gefallen hat. Die Lösung war die Installation des RISE-Konnektors auf einen der PCs in der Praxis, wobei hier auf das Hinzufügen der Hyper-V Rolle verzichtet wurde?!Wir fragen nicht und nehmen die Alternative mal einfach so hin Sick smile

Die beiden folgenden PowerShell Aufrufe zeigten halfen das System dann anschließend zu korrigieren und in einen nutzbaren Zustand zu versetzen:

# Anzeigen aller aktivierten (enabled) Features in Windows 11
Get-WindowsOptionalFeature -Online | Where-Object {$_.State -eq "Enabled"}
# Deaktivieren der Hyper-V Rolle + manuellem Reboot hinterher
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

Nach dem Neustart lief der RISE-Konnektor mit ~10 % Systemlast. Der Dienstleister war da schon am nächsten PC – und ich hatte ehrlich gesagt keine Lust mehr. Hauptsache, die VM lief wieder.

So, genügend Angry smile – einfach aufpassen und schauen, was “Fachkräfte” auf den Systemen so installieren und sich die Systemanforderungen im Vorfeld schriftlich per Mail besorgen.

Enjoy it, b!

Mailstore Server 1/2 | Umstellung auf M365 (Modern Authentication)

Veröffentlicht am von
1

Vor einiger Zeit habe ich einen Mailstore-Server geerbt und das muss man dem Produkt lassen, es läuft sehr zuverlässig. Der Server wurde im Jahr 2015 in Betrieb genommen und hat seitdem eine Menge an Updates und auch ein Betriebssystem-Upgrade von Windows Server 2016 auf 2022 hinter sich gebracht.

Natürlich wechselte dabei auch im Lauf der Jahre der Mailserver (Exchange), von On-Prem nach M365, zusammen mit einer Reihe von Kundenwünschen. Der letzte war die Umstellung auf Microsoft 365 (Modern Authentication).

Mailstore selbst liefert mit dem Support-Artikel „E-Mail-Archivierung von Microsoft 365 – Modern Authentication” eine nahezu perfekte Anleitung. Zusätzlich mussten noch die Namensformate in den Archiven angepasst werden. Das ist ebenfalls sehr gut im Artikel „Umstellung der Archivierung von Microsoft Exchange Server auf Microsoft 365” beschrieben. Insgesamt sind drei Artikel aus der Mailstore-Hilfe notwendig: Mailstore muss nämlich als App in M365 (genauer gesagt in der Microsoft Entra ID) registriert werden, wie hier beschrieben: „Synchronisieren von Benutzerkonten mit Microsoft 365 – Modern Authentication – MailStore Server Hilfe”.

Zusammenfassend hier nochmals die Links der drei Artikel von gerade eben:

Synchronisieren von Benutzerkonten mit Microsoft 365 – Modern Authentication – MailStore Server Hilfe

Umstellung der Archivierung von Microsoft Exchange Server auf Microsoft 365 – MailStore Server Hilfe

E-Mail-Archivierung von Microsoft 365 – Modern Authentication – MailStore Server Hilfe

In diesem Blog soll es nicht um eine erneute Beschreibung der Umstellung gehen, sondern um Dinge, über die ich gestolpert bin und bei denen ich froh war, sie eingeplant zu haben.

Die Anleitung selbst

Fangen wir kurz mit den oben verlinkten Anleitungen an. Solange es sich um Konfigurationsschritte im MailStore Server handelt, werden diese sehr ordentlich mit Screenshots ergänzt. Das ändert sich mit der Registrierung des MailServers in M365: Der Text wird kursiv und somit schwer lesbar. Hier ein Beispiel:

image

Mag sein, dass es ein persönliches Problem ist, aber ich habe mich ein paar Mal „verhaspelt“, wie man bei uns sagt.

Testen, wieso denn Winking smile ?

Mailstore empfiehlt einen Test der Umstellung.

image

Ja und das habe ich auch gemacht. Die Test-VM ließ sich aus dem Snapshot der produktiven Mailstore-VM erstellen. Diese ohne Netzwerk gestartet, konnte mit einem lokalen Admin für den Parallelbetrieb eingerichtet (rekonfiguriert) werden. In diesem Fall ging es um knapp 20 Archive und aktuell 12 aktive Benutzer. Die Mailboxen in M365 sind teilweise mehr als 50GB groß. Damit musste ich mit ~ 750GB an Mailarchiven rechnen, was den bereitgestellten PowerShell-Skripten eine gewisse Laufzeit abverlangte.

Für den Test kann nicht der eigentliche Lizenzschlüssel verwendet werden, sondern der Support (Mailstore oder elovade) stellen hier einen Trial-Key aus. Nachdem ich in der Test-VM keine Optimierungen durchgeführt hatte, konnte ich die eigentliche Umstellung durch die folgende Einstellung deutlich beschleunigen.

image

Die Länge der Disk-Queue sank von 5 auf unter 2, die Umstellung der Mailboxen war damit in der halben Zeit fertig (~ 6 Stunden). Zu setzen war die Einstellung auf allen Disks und dem Betriebssystem selbst, wobei die Disks mit den Archiven die wichtigen waren.

Untitled-01

Die Umstellung ist damit eine Sache für ein Wochenende. Bei mehr und größeren Archiven, hätte ich zur Sicherheit auf unseren Server-Pool zurückgegriffen und die VM vom NAS auf einen Server mit SSDs umgezogen.

Die PowerShell-Skripte

Im Artikel Umstellung der Archivierung von Microsoft Exchange Server auf Microsoft 365 – MailStore Server Hilfe / MailStore Migrationsskripte werden PowerShell-Skripte zum Download angeboten, die ich auch verwendet habe. Allerdings habe ich den Pfad, in dem die MailStore-Benutzer und die MailStore-Folder in einer Datei gespeichert werden, in den Skripten geändert.

image

Damit kann die Migration in einem Ordner wie beispielsweise D:\Temp durchgeführt werden. Leider geben die Skripte keine wirkliche Auskunft über ihren Fortschritt. Dafür kann man sich aber im Testlab ein Bild machen. Die Verwendung von Measure-Object wäre hier eine Erleichterung gewesen. Ich habe aber auf eine Erweiterung der Skripte in diesem Fall verzichtet, da es sich um den einzigen mir bekannten Mailstore-Server handelt.

In diesem Sinne: Happy Migration und bleibt mir gewogen!

Enjoy it, b!

Synology NAS | Replikation von Shares funktioniert nach Update vom 08.10.2025 nicht mehr

Veröffentlicht am von
Antwort

Mahlzeit zusammen, den Beitrag will ich heute ein Stück weit anders aufziehen. Gestern habe ich auf zwei NAS-Systemen ein Update einer Reihe von Paketen gemacht, einige unter anderem auch die Snapshot Replication, trugen den Verweis der Kompatibilität zur neuen Version 7.3 des DSM.

Das Problem

Nach dem Update der Pakete befindet sich die Replikation in folgendem Zustand.

image

Das Einrichten neuer Replikas schlägt mit einer nicht mehr endenden wollenden Replikation fehl.

Erste Lösungsversuche

Nach einigem Suchen, habe ich mich entschlossen einen Support-Case zu öffnen und hier war bis jetzt die Aussage, dass ich ein Upgrade des DSM auf die 7.3 versuchen soll. Zumindest auf den Synology RS1619xs+ wird die 7.3 nicht direkt angeboten sondern muss aus dem Support-Bereich geladen werden.

Hier der Download auf der Supportseite von Synology:

https://www.synology.com/de-de/support/download/RS1619xs+?version=7.2#system

Konkret wird es um ein Upgrade von 7.2.272806 auf 7.3-81180 gehen.

image

Heute Abend / Nacht will ich das Upgrade wagen …. stay tuned und …

Update 10.10.2025

Das manuelle Upgrade des DSM auf die Version 7.3-81180 wahr erfolgreich. Allerdings gab es auch hier zwei Punkte zu beachten.

  1. Die Snapshot Replication meldete einen “… ongoing Task”
  2. Eine Reihe von Anwendungen mussten nach dem Update auf 7.3 manuell aktualisiert werden
    – Active Backup * (Alle Active Backup Anwendungen wie Active Backup for Business und Active Backup for Microsoft 365 …)
    – PHP von 7.x auf 8.2

Punkt 1 habe ich mit einem reboot in den Griff bekommen:

Untitled-a

# Erzwingt einen Neustart ohne Synchronisierung oder Umount des Dateisystems. Dies sollte nur verwendet werden, wenn das System nicht mehr reagiert..
sudo reboot -f

Die VMs hatte ich davor natürlich heruntergefahren. Gerade im Bezug auf den Replikationsdienst lohnt sich vor dem Hammer mit oben (reboot -f) ein Beenden des eigentlichen Prozesses.

image

# Wenn der Prozess nicht auf SIGTERM reagiert, kann er mit dem Signal SIGKILL zwangsweise beendet werden
kill -9 pid

Punkt 2 war ebenfalls unproblematisch

Download der folgenden Pakete von Synology und manuelle Installation:

  • ActiveBackup-Office365-x86_64-2.6.1-14212.spk
  • ActiveBackup-x86_64-3.1.0-24948.spk
  • PHP8.2-x86_64-8.2.28-0107.spk

Ich habe die manuelle Installation durchgeführt (ohne die alten Pakete davor zu löschen).

Läuft Winking smile wieder …

Untitled-b

Zur Replikation noch drei Dinge die mir aufgefallen sind.

  1. Die auf “Replication Stopped” stehenden Replikas konnten manuell, nachdem beide NAS-Systeme auf DSM 7.3 aktualisiert waren, gestartet werden
  2. Neue Replikas konnte ebenfalls ohne Problem erstellt werden
  3. Nicht manuell gestartete Replikas wurden gemäß dem Zeitplan aktiviert und ausgeführt

Enjoy it, b!

Windows Recovery Partition löschen und neu erstellen

Veröffentlicht am von
15

Vor etwas mehr als 8 Jahren habe ich einen Blog über das Löschen der Windows Recovery Partition geschrieben. Hey, mehr als 8 Jahre in der IT ist eine halbe Ewigkeit, vielleicht sogar mehr. Damals ging es darum, ein Problem mit dem Client-Backup des Windows Small Business Essential Server zu lösen.

Wichtig:
Die Partitionsnummern können abweichen. Achtet deshalb unbedingt darauf, dass die ermittelte Nummer verwendet und das Skript nicht nach dem Prinzip „Fire and Forget“ ausgeführt wird. Dafür ist es nämlich nicht gedacht, sondern dient lediglich als Sammlung der verwendeten Befehle.

Unten gibt es dann auch das Update wenn die Winre.wim fehlen sollte, der eigentliche Beitrag ist ja aus dem Juni 2024.

Das Problem

Heute mit Windows 11 und dem Server 2022 ist die Recovery Partition immer noch ein Thema. Meistens, wenn die Systempartition erweitert werden muss, befindet sich die Windows Recovery Partition am Ende der Festplatte.

Genau genommen sprechen wir vom Windows Recovery Environment (Windows RE), zu dem auch die Windows Recovery Partition gehört.

Die folgende Abbildung zeigt die Recovery Partition auf einem Windows Server 2022.

image

Wird die Disk nun erweitert (auf 196GB), dann sieht das wie folgt aus.

image

Natürlich gibt es eine Reihe von 3rd-Party-Tools, die hier helfen können, und einige davon sind sogar OpenSource, andere wiederum laufen in den kostenlosen Versionen nicht auf den Servern und müssen (und sollten) für den kommerziellen Einsatz bezahlt werden.

Wenn noch eine größere Anzahl von Servern oder (z.B. VMs) erweitert werden muss, ist die Unterstützung von PowerShell oder Kommandozeile (cmd.exe) hilfreich.

Die Vorgehensweise (Ablauf)

Die Erweiterung wird mit den folgenden Schritten durchgeführt.

  1. Deaktivieren von Windows RE
  2. Löschen der Windows Recovery Partition
  3. Erweitern der Systempartition (bis zum Maximum abzüglich 524MB)
  4. Erstellen der neuen Recovery Partition im freien Bereich (524MB) mit NTFS als Dateisystem und ohne Laufwerksbuchstaben
  5. Anpassen der Attribute der neuen Windows Recovery Partition
    – Partition Type = de94bba4-06d1-4d40-a16a-bfd50179d6ac
    – Partition Attribute = 0X8000000000000001
  6. Aktivieren von Windows RE

Achtung, bei MBR-Disks (die ich nicht mehr verwenden würde), lautet der Partition-Type anders, nämlich 27 und nicht de94bba4-06d1-4d40-a16a-bfd50179d6ac.

Die Schritte im Einzelnen

Vor dem ersten Schritt ist es sinnvoll, sich einen Überblick über den Zustand von Windows RE zu verschaffen und dann im Anschluss Windows RE zu deaktivieren.

image

Die grün umrandete Informationen zu Disk und Partition kann über die beiden PowerShell-Befehle Get-Disk und Get-Partition verifiziert werden.

image

Im Gegensatz zu meinem Blog zu beginn, habe ich inzwischen eine Möglichkeit gefunden, die Recovery-Partition mit PowerShell zu löschen.

image

Im Diskmanagement ist danach die Recovery Partition nicht mehr vorhanden.

image

Nun wird die Systempartition (Laufwerk C) auf die maximale Größe, abzüglich des Platzes für die Recovery Partition erweitert.

image

Was im Diskmanagement anschließend wie folgend aussieht. Wir sehen das Laufwerk C mit 195GB und 524MB freiem Platz für die Windows RE Partition.

image

Ok, jetzt die Frage Smile warum wird die Windows RE Partition mit 524MB angelegt, wenn sie doch vor dem Löschen 523MB hatte?

Grob geschätzt habe ich das bestimmt einige hundert Mal gemacht, ein einziges Mal hat Windows RE danach mit einer 523MB großen Partition nicht mehr funktioniert. Eine wirklich gute Analyse konnte ich aus Zeitgründen nicht durchführen. Der Workaround, der funktionierte, war eine Partition mit 524MB statt der ursprünglichen 523MB.

Nun geht es um den Wiederaufbau von Windows RE.

Der verbleibende Platz auf der Disk 0 (524MB) wird nun der neuen Windows RE Partition zugewiesen, darüber hinaus mit NTFS formatiert und kein Laufwerksbuchstabe verwendet.

image

Jetzt müssen wir noch die ID der Windows RE Partition und das GPT-Attribut ändern. Das ist auch der einzige Punkt, wo PowerShell keine Möglichkeit bietet.

Partition Type = de94bba4-06d1-4d40-a16a-bfd50179d6ac
Partition Attribute = 0X8000000000000001

Falls jemand von Euch eine bessere Lösung hat, bitte in die Kommentare schreiben – Danke!

image

Beide Einstellungen können mit diskpart.exe überprüft werden.

image

Sieht gut aus, würde ich sagen.

Fehlt nur noch die Aktivierung von Windows RE, vorher sollte man aber prüfen, ob Winre.wim im Verzeichnis C:\Windows\System32\recovery vorhanden ist.

image

Da Winre.wim eine versteckte Datei ist, wurde der Befehl Get-ChildItem mit der Option -Attributes h ausgeführt. Der Befehl reagentc /enable kopiert dann die Datei auf die Windows RE Partition (was ein paar Sekunden dauert).

Update 08.10.2025 – die Winre.wim fehlt …

Durchaus möglich ist, dass die Windows RE-Datei (Winre.wim) fehlt und damit reagentc das Image nicht auf die neue Recovery-Partition kopieren kann.

image

In diesem Fall empfiehlt sich die folgende Vorgehensweise.

  1. Bereitstellen einer ISO-Datei des entsprechenden Betriebssystems
    – Kopieren der ISO-Datei auf den Server
    – Ein Doppelklick mit dem Windows Explorer mounted das ISO
  2. Erstellen eines Verzeichnisses um die install.wim zu mounten
  3. Mounten der install.wim Datei nach $winDir
  4. Wechsel in das Recovery-Verzeichnis der gemounteten install.wim
  5. Kopieren der Winre.wim nach C:\Windows\System32\Recovery
  6. Aktivierung von Windows RE
  7. Unmount der install.wim

Auch hier die Schritte im Detail

Nach dem Doppelklick mit dem Windows Explorer ist das Windows Server 2022 Image auf Laufwerk G vorhanden.

image

Erstellen eines Verzeichnisses um die install.wim zu mounten und bereitstellen dieser mit dism.exe

image

Wechsel in das Recovery-Verzeichnis der gemounteten install.wim und kopieren der Winre.wim nach C:\Windows\System32\Recovery

image

Jetzt muss noch die Recovery Partition aktiviert (reagentc /enable kopiert die Winre.wim) und die install.wim wieder entfernt werden.

image

So, jetzt aber.

Natürlich gibt es alle Befehle als PowerShell-Datei zum Download.

Enjoy it und happy Recovery, b!

Synology NAS | „there is an ongoing replication…“

Veröffentlicht am von
Antwort

Die Synology SnapShot Replication dient zur Replikation von Freigaben (Ordnern) auf ein anderes Synology-NAS. Einmal eingerichtet, funktioniert diese sehr zuverlässig – mit einer Ausnahme.

Das Problem ist, wenn es zu einer Änderung der IP-Adressen kommt

Angenommen, an einem der zahlreichen Adapter einer RS822+ wird eine Konfiguration geändert, wodurch eine weitere IP-Adresse im DNS registriert wird.
Danach wird die Replikation mit dem FQDN anstatt einer IP-Adresse eingerichtet.

Unbenannt-1

Solange beide IP-Adressen funktional und erreichbar sind, ist das kein Problem. Fällt aber eine der beiden wieder weg, bleibt sie erst einmal im DNS vorhanden und wird gemäß dem Round-Robin-Mechanismus im DNS (RFC 1749) bei Abfragen zurück geliefert. Da das NAS über diese Adresse aber nicht mehr erreichbar ist, kommt die Replikation ins Stocken und schlägt fehl. Was bei einem versuchten Neustart zu der in der Überschrift gezeigten Meldung (there is an ongoing replication …) führt und diesen verhindert.

Manchmal dauert es Stunden, bis sich die Replikation wieder erholt (unter der Voraussetzung, dass der nicht mehr vorhandene DNS-Eintrag gelöscht wurde) und solange kann das NAS kann auch nicht ohne Weiteres rebootet werden.

Ein Neustart über die Weboberfläche des DSM schlägt mit der Meldung „There is an ongoing replication task …“ fehl.

Ein Neustart des NAS über SSH, nicht optimal aber möglich

Eine Lösung, wenn man nicht warten will, ist der Neustart des NAS über eine SSH-Session. Dazu muss SSH aber aktiviert werden …

Control Panel / Connectivity / Terminal & SNMP

Unbenannt-2

… und natürlich auf Apply (rechts unten) klicken, damit die Änderungen übernommen werden.
Damit ist der Zugang zum NAS per SSH aktiviert und ein „erzwungener“ Neustart mit einem Benutzer, der die entsprechenden Rechte hat, möglich.

image

Bevor man das NAS nun „abschießt“, ist es ratsam, manuell Prozesse soweit wie möglich zu stoppen. Das heißt, virtuelle Maschinen herunterzufahren eventuelle Container zu stoppen und so weiter.

Hier die entsprechenden Befehle und Möglichkeiten:

# Anmeldung
ssh admin_username@nas_ip_address

# Wechsel mit sudo in den Root-Modus (optional)
sudo -i

Für den Shutdown / Reboot gibt es die folgenden Optionen:

# Beendet Dienste vor dem Neustart ordnungsgemäß, funktioniert aber bei einer hängenden Snapshot-Replikation nicht.
sudo reboot

# Startet sofort neu, wobei einige Abschaltroutinen übersprungen werden. Hat meistens bei der Snapshot-Replikation funktioniert.
sudo shutdown -r now

# Erzwingt einen Neustart ohne Synchronisierung oder Umount des Dateisystems. Dies sollte nur verwendet werden, wenn das System nicht mehr reagiert..
sudo reboot -f

# Dadurch werden alle Shutdown-Skripte umgangen und das System wird sofort neu gestartet. Letzte Instanz 🙂
echo 1 | sudo tee /proc/sys/kernel/sysrq
echo b | sudo tee /proc/sysrq-trigger

Enjoy it, b!

Supermicro X11SSL-F | Windows Server 2022

Veröffentlicht am von
Antwort

Für das Supermicro-Motherboard X11SSL-F endet mit Windows Server 2019 der Support des Herstellers und auch der verbaute RAID-Controller (LSI MegaRAID SAS 9271-4I) hat schon einige Jahre hinter sich.

Dennoch war die Aufgabe, den Server mit Windows Server 2022 zu installieren. Da der Server bereits mit Windows Server 2019 (Hyper-V Server 2019) lief und ein Inplace-Upgrade von Microsoft unterstützt wird, lag diese Vorgehensweise nahe. Das Abenteuer endete oder begann – je nachdem, wie man es sehen will – mit einem BSOD.

74rwmoxe_ON1_Cloud

Leider wurde kein Dump geschrieben, da ich aber genau diese Hardware 2024 mit Hyper-V Server 2019 installiert hatte und damals der Treiber aus dem Betriebssystem verwendet wurde, kam mir der Verdacht das möglicher Weise der Treiber das Problem verursacht. Der storport.sys deutet ja in die Richtung der Platten.

Im Verlauf der Fehleranalyse haben sich zwei Wege für die Installation von Windows Server 2022 herauskristallisiert:

  • Inplace-Upgrade von Hyper-V Server 2019 auf Windows Server 2022 mit einem zuvor aktualisiertem Treiber für den LSI 9271-4I
  • Neuinstallation von Windows Server 2022 und Bereitstellung des Treibers für den LSI 9271-4I während der Installation

Für beide Abläufe ist der aktuellste Treiber (MR Windows Driver 6.14-6.714.05.00) notwendig, der sich hier zum Download findet.

https://docs.broadcom.com/docs/MR_WINDOWS_DRIVER_6.14-6.714.05.00-WHQL.zip

Inplace-Upgrade

Bevor das Inplace-Upgrade gestartet wird, muss zwingend der Treiber aktualisiert werden. Läuft man auf der Core-Version eines Windows Servers, so geht das am einfachsten über das Server Core App Compatibility Feature on Demand (FoD), welches nach der Installation den Device-Manager mitbringt, oder mit pnputil.exe.

# Installation der Windows Server Core App Compatibility (online)
Add-WindowsCapability -Online -Name ServerCore.AppCompatibility~~~~0.0.1.0

# Alternativ mit pnputil.exe
pnputil.exe -i -a oemdriver.inf

Zusätzlich, da dies direkt vom Betriebssystem ausgemacht werden kann,habe ich noch das BIOS des Rechners mit SUM und auch die Firmware des BMC aktualisiert.

Jetzt das Setup über eine ISO-Datei oder besser einen USB-Stick starten.

Neuinstallation

Die Neuinstallation, verläuft wie gewohnt! Nur das der Server die Volumes des LSI 9271-4I schon sieht, hier wird nun trotzdem der neue Treiber über Load driver geladen.

image

Wenn die Installation von einem USB-Stick erfolgt, kann man den Treiber gleich in entpackter Form mit drauflegen.

Für beide Wege, gibt dieser Artikel entsprechende Hinweise wenn im Device-Manager nicht erkannte Treiber vorhanden sind.

Enjoy it, b!

Synology Directory Server | Zertifikat abgelaufen

Veröffentlicht am von
Antwort

Wenn im Synology DSM das Zertifikat für den Synology Directory Server (SDS) abgelaufen ist, gibt es die Möglichkeit dieses Online wieder zu verlängern. Dazu sind die folgenden Schritte notwendig:

  1. Der Vorgang muss auf jedem Synology Directory Server (also auf jedem NAS) explizit durchgeführt werden (in diesem Netzwerk sind zwei davon vorhanden)
  2. Der DNS muss “korrekt” konfiguriert sein, was einfach bedeutet das mit dem NAS eine Verbindung in das Internet möglich ist und externe Domains aufgelöst werden
  3. Das DSM muss von außen über Port 80 (HTTP) erreichbar sein. Dazu muss auf dem Router eine Weiterleitung von Port 80 extern auf die <NAS-IP>:80 intern eingestellt werden. Danach ist diese Regel sofort wieder zu deaktivieren!

Im Detail sieht das wie folgt aus:

image

  • Issued by: domain.tld | Beispiel home.local
  • Subject Alternative Name: domain-controller.domain.tld | Beispiel mausi.home.local

Hier die Regel im Router, in diesem Fall ein Mikrotik:

image

Das hätte man auch ein wenig anders realisieren können, aber für die zwei Minuten funktioniert es sehr gut.

Nun wird im DSM unter Security / Certificate das Zertifikat ausgewählt und mit Action / Renew certificate das Renewal angestoßen.

image

Zur Sicherheit gibt das DSM nochmals einen Hinweis auf die notwendige DNS / Firewall-Konfiguration.

image

Mit  Renew Certificate dauert der Vorgang nur wenige Sekunden und es ist lediglich erforderlich, die Seite erneut zu laden.

image

Jetzt wieder Port 80 auf dem Router schließen und wir sind fertig.

Enjoy it, b!