Veröffentlicht in Betriebssysteme, Übergreiffend

Wie kann man überprüfen, ob die Domaincontroller miteinander synchronisiert sind?

Schritt 1 – Überprüfung des Zustands der Replikation

Führen Sie den folgenden Befehl aus:

Repadmin /replsummary

Die Operation „/replsummary“ gibt einen schnellen Überblick über den Replikationsstatus und den relativen Zustand eines Forests.

Schritt 2 – Überprüfen Sie die eingehenden Replikationsanforderungen, die in der Warteschlange stehen.

Repadmin /Queue

Dieser Befehl listet die Elemente auf, die sich noch in der Replikationswarteschlange befinden. Er zeigt die eingehenden Replikationsanforderungen an, die der Domänencontroller stellen muss, um mit seinen Quellreplikationspartnern konsistent zu werden.

Schritt 3 – Überprüfung des Replikationsstatus

Repadmin /Showrepl

Dieser Befehl zeigt den Replikationsstatus an, als der angegebene Domänencontroller zuletzt versucht hat, eine eingehende Replikation von Active Directory-Partitionen zu implementieren. Er hilft dabei, die Replikationstopologie und Replikationsfehler herauszufinden.

Schritt 4 – Synchronisierung der Replikation zwischen Replikationspartnern

Repadmin /syncall

Sie gewährleistet die Synchronisation zwischen den Replikationspartnern

Schritt 5 – Erzwingen der Neuberechnung der Topologie durch das KCC

Repadmin /KCC

Dieser Befehl zwingt den KCC (Knowledge Consistency Checker) auf dem/den anvisierten Domänencontroller(n), die Topologie der eingehenden Replikation sofort neu zu berechnen. Er überprüft und erstellt die Verbindungen zwischen den Domänencontrollern. Standardmäßig wird KCC alle 15 Minuten im Hintergrund ausgeführt, um zu prüfen, ob eine neue Verbindung zwischen den DCs hergestellt wurde.

Schritt 6 – Replikation erzwingen

Repadmin /replicate

Dieser Befehl erzwingt die Replikation der angegebenen Verzeichnispartition vom Quell-DC zum Zieldomänencontroller.

Veröffentlicht in Betriebssysteme

KMS Aktivierung ohne Domänenmitgliedschaft

Wie man an der Abbildung oben erkennt, wird ein KMS über einen SRV-Eintrag im DNS gefunden. Damit dieser vom Client nun aucht tatsächlich zum Zwecke der Aktivierung angefragt wird , muss das primäre DNS-Suffix des KMS-Clients so konfiguriert werden, dass es der DNS-Domäne entspricht, in der der “_VLCMS“-Eintrag erstellt wurde. Im Beispiel oben ist das “contoso.com“.

Das besondere ist hierbei, dass ausschließlich der Eintrag über die Systemeigenschaften relevant ist (rechte Maustaste auf den Arbeitsplatz bzw. “Computer”, Eigenschaften). DNS-Suffixe, die in der Netzwerkkonfiguration festgelegt werden, beachtet das System diesbezüglich nicht. Da beim Eintritt in eine Domäne genau dieser Wert automatisch festgelegt wird, ist bei vielen Admins der falsche Eindruck enstanden, dass der Eintritt in die Active Directory-Domäne erforderlich sei. Im Umkehrschluss ließe sich daraus eine Grundsicherung des KMS ableiten. Diese Annahme ist falsch.

Die zweite Möglichkeit, einen KMS ohne Domänenmitgliedschaft zu nutzen, zeigt die folgende Abbildung:

Dieser Fall wird in den Microsoft Whitepapern empfohlen. Durch den Aufruf von

slmgr.vbs -skms

wird ein Registrywert gesetzt, wie in der dritten Abbildung zu sehen ist:

Abschließend ist noch die Frage offen, wie man diese Aktivierung denn nun verhindern kann. Die Antwort ist: nicht über den KMS, der kennt keine Zugriffsbeschränkungen. Welche Clients aktiviert werden dürfen lässt sich nur über den beschränkten Zugriff auf das Intranet definieren. VLANs, 802.1X-Authentifizierung, IPSec etc. bieten Möglichkeiten der Absicherung des Datenverkehrs. Andererseits gibt es keinen Anlass für übertriebene Panik: ein KMS aktiviert unabhängig von der tatsächlich lizensierten Hardware prinzipiell unbegrenzt Clients. Man braucht also nicht zu fürchten, dass der KMS die Dienste ab irgendeinem Schwellwert einstellt.

QUELLE: https://www.thorsten-butz.de/kms-aktivierung-ohne-domanenmitgliedschaft/

Veröffentlicht in Windows Server 2012

Windows Server „Ereignisprotokollierung“ zu warum wurde der Server unerwartet heruntergefahren, erscheint bei jeder Anmeldung

Bei jeder Anmeldung an einem Windows Server oder einem Windows 10 erscheint das Eingabefenster „Ereignisprotokollierung“ mit der Frage, warum denn das System so unerwartet heruntergefahren wurde. Egal wie oft man dies ausfüllt und egal was man einträgt, die Meldung erscheint immer wieder. Ob „Anderer Grund“ oder Geplant, ständig nervt dieses Fenster.

Ereignisprotokollierung

Windows legt die Informationen über den letzten „Unerwarteten“ Systemshutdown in einem Registry-Schlüssel ab. Um die Meldung loszuwerden, setzt den DirtyShutdown auf „0“:

registry Eintrag
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Reliability

DirtyShutdown

… und schon ist die Meldung verschwunden.