Dynamische DNS Updates in einer Zone erlauben mit „dnscmd“

Den Haken „Dynamische Udpates“ in den Eigentschaften einer Zone haben vermutlich viele Admins gesetzt. Wenn man die Einstellungen zu DNS-Updates ändern will, kann man das in den Eigenschaften auch komfortabel tun.

Wenn es aber um sehr viel Zonen und dere Einstellunge geht, ist die Kommandozeile hilfreich …

Lösung

Das geht mit dem tool dnscmd mit diesen Parametern:

dnscmd /config <ZONE> /AllowUpdate 1

Genauso funktioniert das natürlich auch bei Reversen Lookupzonen. Wenn man, wie ich, zu faul ist diese abzutippen, bietet sich die Auflistung aller Zonen an:

dnscmd /enumzones

In der Textausgaben (ist auch noch filterbar, zum Beispiel mit /primay) kann man dann beliebig mit einer for Schleife herumaktualisieren, eine bearbeitbare Liste erstellen oder nach bestimmten Namen suchen (find/grep).

ReFS-Clustergröße für Veeam Backup & Replication 64 KB oder 4 KB?

ReFS ab v3.1 unterstützt bekanntlich zwei verschiedene Clustergrößen: 4 KB und 64 KB. Welches nimmt man für ein B&R Repository?

tl;dr: 64KB für ReFS als Veeam-Repository

Aber warum?

Unter anderem Microsoft hat 2019 in einem Technet-Artikel einige Empfehlungen zur Clustergröße für ReFS und NTFS veröffentlicht. Die Standard-Clustergröße beider Dateisysteme ist 4K, was bis heute die Vorgabe ist, wenn man ein neues Volume formatiert. Der Artikel enthält aber auch eine detaillierte Erklärung, warum man eine bessere Performance mit 64K großen Zuordnungseinheiten erhält, wenn man große Dateien ließt oder schreibt.

64-KB-Cluster sind grundsätzlich immer dann sinnvoll, wenn man mit großen, sequentiellen E/A-Vorgängen (auf HDDs) arbeitet. Viel weniger Verwaltungsaufwand bei der Adressierung, mehr Payload und damit höherer Durchsatz bei deutlich weniger Last (etwa ein sechzehntel). Sicherungen und Wiederherstellungen erfolgen naturgemäß in aller Regel sequentiell, daher sind Veeam-Blöcke schon immer größer gewesen, nämlich 1Mbyte.

Insbesondere die „brutto“ Read/Write-Leistung unterscheidet sich erheblich, wenn dasselbe Volume auf derselben Hardware mit einer Clustergröße von 64 KB statt mit 4 KB formatiert wird. Eine bis zu vierfachen Steigerung der Netto-Geschwindigkeit von Merge-Vorgängen (Inkremental-Forever, Synthetic-Fulls …) ist üblich. Beide Vorgänge sind dank der Block-Cloning-API (ReFS-only!) immer noch erheblich schneller als „normales“ i/o, aber der Unterschied ist gewaltig. Die reine Backup-Schreibleistung hängt meist von der Quelle ab, daher fällt der gefühlte Unterschied hier ncht so groß aus.

Nachteile?

Ein Nachteil ist der zusätzliche Speicherplatzverbrauch. Dier beträgt, aus Erfahrung, etwa 5–10% der Dateigröße (nicht Volumengröße). Der Grund dafür ist, dass von Veeam erstellte Blöcke zunächst eine feste Größe von 1MB haben. In den allermeisten Veeam-Jobs ist aber standardmäßig die Komprimierung aktiv, die „im Durchschnitt“ die Größe nachträglich um etwa etwa 50% reduziert. Je nach Quelldaten fällt das natürlich leicht unterschiedlich aus, was in variabler „Verwendung“ von Cluster-„Rändern“ mündet.

Wir halten den Preis von <10% Speicherplatz für die Geschwindigkeits-Vervielfachung für hinnehmbar und empfehlen daher ebenfalls die 64KB Blockgröße.

Windows Installer uninstall, (MSI) Datei Fehler 2503 bei der Deinstallation

Manchmal möchte der Windows-Installer Programme die via MSI Datei auf das System gelangt sind nicht freiwillig deinstallieren. Der Installer zeigt stattdessen den Fehler „2503“ an.

Lösung um Fehler 2503 zu beheben

MSI-Dateien brauchen bei der Installation (meist Remote) andere Berechtigungen, als wenn man Sie lokal deinstalliert.

Die Lösung ist, in Verzeichnis %SystemRoot%\Temp der Gruppe „Benutzer“ („Users“) Vollzugriff zu gewähren:

icacls "%systemroot%\Temp" /grant Benutzer:F

Sobald man das getan hat, läuft der Deinstallter (Uninstall) sofort fehlerfrei durch.

Das Microsoft Defender Security Portal empfielt jetzt „Windows deinstallieren“

Das Microsoft Windows Server 2012 R2 seit dem 10. Oktober diesen Jahres wirklich am Support-Ende angekommen ist, ist nicht neu. ESU natürlich ausgenommen, die Installationsbasis ist ja immer noch relativ groß.

Neu ist, zumindest für uns, aber die eindringliche „Sicherheitsempfehlung“ im Defender-Portal, das Betriebssystem schlicht zu deinstallieren 😂

HPE Alletra / Nimble Storage software update „Precheck Fail“

Manchmal schlagen Firmware-Updates auf Alletra 5000 Storages (früher Nimble AF und HF) fehl. Die Fehlermeldung dazu lautet im GUI und an der Shell wenig hilfreich:

One of the HPE Nimble Storage services has become unreachable. If this occurred during a failover or planned outage, wait a minute and then refresh the GUI. This may also occur during security certificate update for group or array name changes or management ip and discovery ip changes. Wait a minute and then refresh the GUI. In some cases, you may also need to clear browser cache. If the service does not become reachable in a few minutes, contact HPE Nimble Storage Support.

Lösung

Es sieht so aus, als ob die Boot-Devices auf den aktiven (!) Controllern manchmal eine Zeitüberschreitung veraursachen. Das verursachte dann den Dienstfehler „Storage services has become unreachable“.

Dies kann man in den allermeisten Fällen durch einen Neustart des Controllers beheben – also durch einen einfachen Failover. Normalerweise kann man das im Web-GUI mit dem Button „Make active“ tun, was in diesem Fall aber ebenfalls nicht funktioniert.

Es hilft aber den Failover auf den anderen Controller an der SSH-Shell zu erzwingen:

failover --array <ARRAYNAME> --force

Und nach wenigen Minuten ist der Failover fertig, der Controller frisch neu gebootet und das Update läuft ohne Probleme durch.