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).
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 Windows Server 2012 R2 seit dem 10. Oktober diesen Jahreswirklich 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 😂
Wenn man eine Windows CA erfolgreich migriert hat (Backup+Restore), kommt beim Versuch den CertSvc-Webdienst via ServerManger zu installieren die folgende Fehlermeldung:
Webregistrierung der Zertifizierungsstelle: Konfiguration fehlgeschlagen.
Die Einrichtung der Active Directory-Zertifikatdienste ist mit folgendem Fehler fehlgeschlagen: Der Parameter ist falsch. 0x80070057 (WIN32: 87)
Das passiert nach einer Migration und auch nur mit dem Webdienst – den man korrekterweise erst nach der CA „dazuinstalliert“. Natürlich ist das ein bekannter und bisher (Windows Server 2003-2022) ungepatchter Bug.
Lösung
Das Problem besteht darin, dass der Wert von SetupStatus in der Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration noch den Wert „hat“Web ist installiert“ hat. Wenn das der Fall ist, scheitert der Windows ServerManager.
Der Hexadezimalwert 6003 sagt „ist schon installiert“ Der Hexadezimalwert 6001 sgat „ist frei“
Man ändere also mal eben den Wert von SetupStatus der Registrierung auf 6001 und dann läuft die Installation des „Zertifikatsregistrierungs-Webdienstes“ durch.
Update
Ich habe soeben herausgefunden, das das sogar an der Kommandozeile vie certutil möglich ist:
certutil -setreg config\setupstatus 0x6001
Es wird noch besser, es gibt sogar eine named procedure in certutil dazu, die ebenfalls genau das selbe tut:
Auf Exchange Servern seit 2010 wird gerne mal dieses Ereignis alle paar Minuten in das Anwendungsprotokoll geschrieben:
The performance counter '\\EXCHANGESERVER\MSExchange Assistants - Per Database(msexchangemailboxassistants-DATABASE)\Quarantined Assistant Count Total' sustained a value of '6.015,00', for the '10' minute(s) interval starting at '10.10.2020 12:00:00'. Threshold breached since '10.10.2020 21:12'. None Trigger Name:AssistantsQuarantinedTrigger. Instance:msexchangemailboxassistants-DATABASE
Oder auch mit etwas längerem Intervall:
The performance counter ‚\\EXCHANGESERVER\MSExchange Assistants – Per Database(msexchangemailboxassistants-DATABASE)\Event Dispatchers Catching Up‘ sustained a value of ‚2.730,00‘, for the ’30‘ minute(s) interval starting at ‚10.10.2020 19:39:00‘. Threshold breached since ‚10.10.2020 20:10‘. None Trigger Name:EventDispatchersCatchupQueueTrigger. Instance:msexchangemailboxassistants-DATABASE
Lösung
Das ist ein Fehler, den es in vielen Setup auch schon unter Exchange 2013 gab (Exchange 2016 hat das genauso). Es gibt für beide einen Workaround um die nervigen Fehler-Einträge loszuwerden.
Im Verzeichnis Microsoft\Exchange\Vxxx\BIN (Powershell: $exinstall\bin) findet sich die Datei Microsoft.Exchange.Diagnostics.Service.exe mit der zugehörigen *.config Datei:
Microsoft.Exchange.Diagnostics.Service.exe.config
Diese „als Admin“ bearbeiten. Darin muss nur ein Trigger auf „false“ geändert werden, und zwar diese Zeile:
