Weisheiten - der Netz-Weise Blog

Hier finden Sie Tipps und Tricks für vor, während und nach der Schulung.

Tastarlayout in Windows Server Core umstellen

Im letzten Artikel Default Shell in Server Core ändern habe ich beschrieben, wie Sie Powershell zur Default-Shell in Servercore machen können. Sie können aber auch das Tastaturlayout anpassen, wenn Sie bei der Installation die falsche Sprachversion ausgewählt haben. Hierzu passen Sie den Schlüssel HKEY_CURRENT_USER\Keyboard Layout\Preload an. Unter dem Schlüssel Preload sind die konfigurierten Tastaturlayouts gespeichert, die Servercore unterstützt, und zwar in numerischer Reihenfolge, wobei das Layout mit der Nummer 1 Priorität hat uns als erstes geladen wird.

Um das Tastaturlayout für den angmeldeten Benutzer anzupassen, setzen Sie einfach den Sprachcode Ihrer Tastatur für den Wert mit dem Namen 1. Für deutsche Tastaturen ist das 00000407. Das können Sie einfach im Regedit machen, oder mit folgender Codezeile:

Set-ItemProperty -Path HKCU:\Keyboard Layout\Preload -Name 1 -Value 00000407

Die vollständige Auflistung aller Codes finden Sie unter Default Input Profiles in Windows auf der Microsoft Website.

 

586 Aufrufe
0 Kommentare

Default Shell in Server Core auf Powershell ändern

Wenn Sie sich in Windows Server Core einloggen, wird als Standard-Shell die Cmd.exe geöffnet. Das ist zwar unkritisch, da Sie den Server-Core im Normalfall eh nur remote konfigurieren, aber trotz allem manchmal nervig. So lange Microsoft die Standard-Shell nicht endlich auf Powershell umstellt, hilft es, die Default-Shell in der Registry anzupassen. Hierfür ersetzen Sie unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell explorer.exe durch Powershell.exe. Das geht ganz einfach über regedit, denn der Registry-Editor kann unter Server-Core direkt ausgeführt werden, oder Sie benutzen folgendes Powershell-Kommando:

Set-ItemProperty -Path HKLM:SOFTWARE\Microsoft\Windows NT\CurrentVersion\ -Name Winlogon -Value Powershell.exe

Die Shell wird für alle Benutzer auf den neuen Wert gesetzt, ist jetzt also der neue Default.

Wie Sie das Tastaturlayout in Server Core ändern, finden Sie unter Tastarlayout in Windows Server Core umstellen.

429 Aufrufe
0 Kommentare

Ein niedrig priveligiertes Konto zum Entsperren von Domänenbenutzern anlegen und damit Benutzer-Sperren retten

Das Sperren von Benutzerkonten ist ein bewährtes Mittel, um Brute-Force-Attacken gegen Kennwörter im Unternehmen zu verhindern. Allerdings empfehlen sowohl Microsoft als auch das BSI inzwischen, Kontosperrungen nicht zu verwenden, da eine Malware oder ein Hacker durch das Sperren sämtlicher Benutzerkonten ein Netzwerk komplett lahm lagen kann - man spricht auch von einem denial of Service.

Die alternative Empfehlung lautet, lange Kennwörter in Form von Passphrases und am Besten Multifaktor-Authentifizierung einzusetzen. Grundsätzlich ist das ein vernünftiger Ansatz, aber leider scheitert er in vielen Netzwerken immer noch an der Praxis. Zum einen muß man den Benutzern erklären, dass Sie jetzt lange komplexe Kennwort-Sätze verwenden sollen, zum Anderen muß man mit dieser Variante auch für eine ordentliche Anmeldungs-Überwachung sorgen, da ein großangelegter Angriff auf die Benutzerkennwörter sonst gar nicht auffällt. Mit aktivierter Kennwortsperrung merkt man normalerweise sehr schnell, dass etwas nicht stimmt.

Mein pragmatischer alternativer Ansatz, um die Kontosperrungen weiterhin nutzen zu können, arbeitet mit automatisierten Prozessen und Powershell. Denn mit Powershell ist es sehr schnell und einfach möglich, Benutzerkonten zu entsperren. Verwenden Sie dafür die Cmdlets Search-ADAccount und Unlock-ADAccount. Search-ADAccount kann mit dem Parameter -Lockedout alle gesperrten Benutzerkonten in einem Rutsch auflisten, Unlock-ADAccount kann sie  direkt entsperren. Mit Hilfe des Cmdlets Out-Gridview können Sie sich auch gleich noch eine grafische Benutzeroberfläche einrichten, um nur ausgewählte Benutzer zu entsperren.

Search-ADAccount -Lockedout | Out-Gridview -Passthru | Unlock-ADAccount

Damit wird das Entsperren nach einem Denial of Service zu einem Kinderspiel. Allerdings muß noch ein zweites Problem gelöst werden. Wenn Sie nämlich das Standard-Administratorkonto auf der Domäne deaktivieren, haben Sie eventuell gar keine Möglichkeit mehr, die Domäne zu entsperren, weil Ihr Administrator auch gesperrt ist. Deswegen legen Sie sich nun ein niedrig privilegiertes Konto an, dass neben dem Entsperren von Benutzern in der Domäne nichts kann, aber nicht gesperrt wird.

Weiterlesen
2349 Aufrufe
0 Kommentare

Computerkennwörter, der Secure Channel und die Fehlermeldung „Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden”

Wenn ein Domänen-Computer gestartet wird, sucht er im Netzwerk zuerst nach einem Domänen-Controller, indem der den DNS-Server nach den LDAP-Service-Records seiner Domäne fragt. Anschließend versucht er, mit dem Domänencontroller einen Secure Channel, also eine verschlüsselte, sichere Datenverbindung aufzubauen. Dies geschieht über einen RPC Netlogon. RPC ist ein Challenge-Response-Protokoll, bei dem der Client und der Server sich gegenseitig einen zufälligen 64 Bit-Zufallswert, den Client- bzw. Server Challenge, zuschicken, aus denen mit Hilfe des Computerkennworts (wegen gegenseitige Authentifizierung sowohl auf dem Client als auch auf dem Server) ein Session-Key berechnet wird. Das funktioniert, weil sowohl der Client als auch der Domänencontroller über das Computerkennwort des Clients verfügen. Wenn der Domänencontroller und der Client nicht das gleiche Kennwort gespeichert haben, schlägt die Erstellung des Secure Channels allerdings fehl und dem Client wird die Verbindung zum Domänencontroller verweigert. Stattdessen wird eine Fehlermeldung angezeigt, die vermutlich jeder Administrator schon einmal gesehen hat: „The trust relationship between this workstation and the primary domain failed” bzw. "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden".

Wie und wo wird das Computerkennwort verwaltet

Der Client generiert beim Aufnehmen in die Domäne ein komplexes Kennwort, dass er ab Windows 2000 alle 30 Tage automatisch ändert. Da Computerkonten sind von den Kennwortrichtlinien der Domäne ausgenommen sind, können Sie auch nicht gesperrt werden, wenn sie länger offline sind.
Die Kennwortänderung führt der Client zuerst zuerst lokal aus. Danach ändert er sein Kennwort im AD. Schlägt die Aktualisierung im AD fehl, setzt er wieder das alte Kennwort. Das aktuelle Kennwort und sein Vorgänger werden im geschützten Kennwortschlüssel HKLM\SECURITY\Policy\Secrets\$machine.ACC gespeichert. Im AD sind die Kennwörter in den Attributen unicodepwd und lmpwdHistory abgelegt.
Ob und wie oft der Client sein Kennwort ändert, kann in der Systemregistrierung unter HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters konfiguriert werden. Für die Konfiguration sind drei Schlüssel verantwortlich:

MaximumPasswordAge: Der Eintrag MaximumPasswordAge legt fest, nach welchem Zeitraum der Netlogon-Dienst versucht, das Kennwort zu ändern. Der Standardwert ist 30 (Tage).

ScavengeInterval: Das Scavengeinterval legt fest, wie häufig der Computer prüfen soll, ob das maximale Kennwortalter erreicht ist. Der Standardwert beträgt 900 (Sekunden), also 15 Minuten. Der Eintrag ist nicht in der Registry hinterlegt, kann hier aber geändert werden. Der Typ des Eintrags ist REG_DWORD.

DisablePasswordChange: Sie können die Kennwortänderung des Computers mit diesem Schlüssel auch komplett deaktivieren, indem Sie den Wert auf 1 setzen.

Weiterlesen
7465 Aufrufe
0 Kommentare

Das Administrative Windows-Startmenü (Alt+X) um eigene Werkzeuge erweitern

Seit Windows 8.1 gibt es das administrative Startmenü (im englischen Power User Menü genannt), das man über Windows-Taste+X oder über das Kontextmenü des Startbuttons erreichen kann. Das Startmenü ist ausgesprochen praktisch, wenn es um das Aufrufen von administrativen Werkzeugen geht. Außerdem hat man hier die Möglichkeit, den Rechner sowohl herunterzufahren als auch eine Abmeldung durchzuführen, ohne unterschiedliche Menüs verwenden zu müssen.

Leider gibt es keine Bordmittel, um das Menü anzupassen. Prinzipiell kann man auf manuellem Weg mit ein paar Tricks die Einstellungen vornehmen, um eigene Tools im Menü zu verlinken. Es gibt aber auch einen angenehmen Weg, nämlich den Win+X-Editor. Er kann kostenlos bei WinAero heruntergeladen werden. Achten Sie darauf, dass Sie den richtigen Link erwischen, er ist ein wenig versteckt. Eine kleine Anleitung inklusiver der Handgriffe, die man ausführen muß, um die Anpassungen manuell durchzuführen, finden Sie bei Digital Citizen: All the ways to customize the WinX menu in Windows 10 (and Windows 8.1).

1881 Aufrufe
0 Kommentare

AD Domänenfunktionsebene und Forestfunktionsebene - Bedeutung und Best Practices

Die Active Directory Domänen-Funktionsebene (Domain Functional Level, DFL) und die Forest-Funktionsebene (Forest Functional Level) sind zwei Begriffe, die oft missverstanden werden. Ich werde hier versuchen, ein wenig Licht ins Dunkel zu bringen.
Die Funktionsebene einer Domäne bzw. eines Forest bestimmt, welche AD-Funktionen genutzt werden können. Mit jeder neuen Version von Windows wurden auch neue AD-Funktionalitäten implementiert, von denen einige durch eine Schemaerweiterung aktiviert werden können, während andere voraussetzen, dass alle Domänencontroller des AD sich auf dem gleichen oder einem höheren Betriebssystemstand befinden. Um sicherzustellen, dass alte und neue DCs miteinander kommunizieren können, muss das System sich auf den kleinsten gemeinsamen Nenner einigen. Daher werden neue Funktionen nicht automatisch freigeschaltet, sondern müssen nach dem Herunterstufen aller alten Domänencontroller manuell aktiviert werden. Dabei unterscheidet man zwischen der Funktionsebene einer einzelnen Domäne - um sie zu ändern, müssen alle Domänencontroller der Domäne auf dem gleichen minimalen Stand sein - und der Funktionsebene des Forest, für dessen Änderung alle Domänencontroller des Forest (also alle Domänen) den Versionsstand erreicht haben müssen, der aktiviert werden soll. Um die aktuellen Funktionsebenen abzufragen, öffnen Sie auf einem Computer, auf dem die AD-Verwaltungstools installiert sind, eine Powershell-Konsole und geben folgende Befehle ein:

(Get-ADDomain).DomainMode
(Get-ADForest).ForestMode

Um sich alle Domänencontroller Ihrer Domäne mit Betriebssystemversion ausgeben zu lassen, verwenden Sie

Get-ADDomainController -Filter * | Select-Object Hostname,Operatingsystem

Für alle Domänencontroller aller Domänen verwenden Sie

Weiterlesen
12739 Aufrufe
0 Kommentare

Zertifikate mit Powershell Base64-kodiert aus dem Zertifikatsspeicher exportieren

Mit Powershell auf den Zertifikatsspeicher zurückzugreifen, ist sehr simpel, denn Powershell stellt für den Zugriff auf Zertifikate einen Powershell-Provider bereit. Durch den Provider ist es möglich, Zertifikate wie Dateien zu behandeln. Der Provider legt hierfür ein "Laufwerk" mit Namen Cert: an. Möchten Sie z.B. die Zertifikate des aktuellen Benutzers sehen, geben Sie ein:

PS C:\Users\Holger> Get-ChildItem -Path Cert:\CurrentUser\My\

PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\My

Thumbprint                               Subject
----------                               -------
A83FA591D2D909D7465768ED4F7DE4019026F74D CN=Holger
7154EBF108BEB11587B1136B06EC5C24E3E6CAEA CN=NWCertRoot
6C0CEA5EC15CA5E6350CB9E7D02D90C9AA1DEBE3 CN=NwClientCert

Zurückgeliefert wird der eindeutige Thumbprint des Zertifikats, sowie dessen Name. Um ein Zertifikat ins Dateisystem zu exportieren, verwenden Sie das Cmdlet Export-Certificate:

Weiterlesen
2886 Aufrufe
0 Kommentare

Windows Homeverzeichnisse werden als "my Document" angezeigt

Ihre auf den Server umgeleiteten Benutzerprofile heissen alle "My Documents" oder "eigene Datien"? Die Desktop.ini ist Schuld! Ein Problem beim Kunden: die meisten der auf den Server umgeleiteten Verzeichnisse werden im Explorer als ""My Documents"" oder ""Eigene Dateien"" angezeigt. Sehr merkwürdig, denn eigentlich kann ein ordnername ja nicht mehrfach im gleichen Verzeichnis auftauchen. Das Problem ist die desktop.ini, die den Explorer anweist, Ordner mit einem bestimmten Symbol zu versehen oder eben umzubennen. Die Desktop.ini liegt im Benutzerordner, und löschen führt dazu, dass wieder der Originalname angezeigt wird. Leider ist das Löschen nicht von Dauer. Um das wiederanlegen der desktop.ini zu verhindern, gibt es verschiedene Möglichkeiten. Zum einen kann man den Schreibzugriff auf die Datei verhindern. Am besten hat mir allerdings der Tipp gefallen, durch einen Eingriff in die Registry (per gpo verteilt) das erstellen der Desktop.ini vollständig zu verhindern - mit der Nebenwirkung, dass der Explorer nun natürlich gar keine desktop.ini Dateien mehr erstellt.

Schlüssel: HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
Name: "UseDesktopIniCache"
Typ:dword
Value: 00000000

2085 Aufrufe
0 Kommentare

Benutzerprofilkompatibilität in WIndows 7, 8 und 10

Auch das Benutzerprofil von Windows 10 ist wieder nicht mit den Vorgängerversionen kompatibel. Aber Microsoft hat vorgesorgt. Mit Windows 7 hat Microsoft zum ersten mal eine neue Verion des Benutzerprofils eingeführt, um zu verhindern, dass Benutzer mit servergespeicherten Profilen nicht beim Wechsel zwischen Betriebssystemversionen (z.B. auf RDP-Servern) ihr Profil zerschiessen. Dafür legt Windows 7 einen eigenen Profilordner mit der Endung .V2 an. Windows 8 und Windows 8.1 verwenden standardmässig das gleiche Verzeichnis wie Windows 7, nämlich .V2. Man kann allerdings aktivieren, dass auch Windows 8 (.V3) und Windows 8.1 (.V4) sich in eigenen Unterordern schreiben. Installieren Sie hierfür je nach Betriebssytem eines der beiden Hotfixes:

Für Windows 8 das in KB2887239 beschriebene.
Für Windows 8.1 das in KB2887595 beschriebene Hotfix Rollup. 

Danach setzen Sie den folgenden Schlüssel in der Registry:

Schlüssel: HKEY_LOCAL_MACHINE\System\CurrentControlset\Services\ProfSvc\Parameters
Name: UseProfilePathExtensionVersion
Wert: 1

Alternativ können Sie dieses Feature auch über Gruppenrichtlinien Einstellungen (Group Policy Preferences) setzen. 

Weiterlesen
3943 Aufrufe
0 Kommentare

Windows Datei- und Druckserver migrieren

Windows Server bringt eine Reihe von Migrationstools mit, die die Migration von Benutzern, Druckern und Dateien recht einfach machen Sie müssen lokale Benutzer, Gruppen, Drucker oder Dateien zwischen zwei Windows-Server migrieren? Kein Problem mit den Windows Server Migrationstools.

Szenario 1: Benutzer und Gruppen migrieren

Um Benutzer und Gruppen zu migrieren, verwenden Sie die Windows Migration Tools. Auf Windows Server 2008 R2 und 2012 (R2) installieren Sie diese über den Server-Manager oder über Powershell auf dem Quell- und auf dem Zielserver:

Install-WindowsFeature -Name Migration

Danach laden Sie in Powershell das Migrations Snap-In:

Add-PSSnapin Microsoft.Windows.ServerManager.Migration

Exportieren Sie nun zuerst auf dem Quellserver die Benutzer und Gruppen mit Hilfe des Cmdlets Export-SmigServerSettings. Über den Parameter User können Sie angeben, welche Benutzer exportiert werden sollen. Es stehen Ihnen die Optionen "All","Enabled" und "Disabled" zur Verfügung. Wenn Sie auch die lokalen Gruppen exportieren wollen, verwenden Sie den Parameter Group. Achten Sie aber darauf, dass Sie die Gruppen in einem Befehl mit den Usern exportieren, da Sie sonst ein weiteres Export-Verzeichnis benötigen. Das Export-Verzeichnis sollte sinnigerweise von beiden Servern aus erreichbar sein. Da der Export mit Kennwort erfolgt, müssen Sie die Daten mit einem Kennwort verschlüsseln.

Weiterlesen
8078 Aufrufe
0 Kommentare

virtuelle Hyper-V Maschinen mit dem NAT-Switch verwenden - byebye Router-VM!

Dank Docker gibt es in der aktuellen Preview von Windows 10 und in der Rosetta-Jubiläums-Ausgabe, die Ende Juli erscheint, endlich die Möglichkeit, virtuelle Maschinen in einem isolierten, privaten Netzwerk per NAT mit dem physikalischen Netzwerk zu verbinden, ohne eine Router-VM installieren zu müssen. Der NAT-Switch wurde notwendig, um per Docker bereitgestellte Anwendungen mit den Netzwerk zu verbinden. Und so richtet man einen NAT-Switch ein: 

Legen Sie zuerste mit Hyper-V einen neuen internen VM-Switch an. In früheren Versionen von Windows 10 gab es einen speziellen NAT-Switch, aber der ist zugunsten des internen Switches wieder gewichen:

$NatSwitch = New-VMSwitch -SwitchName Nat -SwitchType Internal

Als nächstes benötigen wir eine Gateway-Adresse für das interne Netzwerk, die wir an den Switch binden. Ein interner Switch legt automatisch auch eine interne virtuelle Netzwerkkarte an. An diese wird die Gateway-IP gebunden. Das folgende Script fragt zunächst den zum Switch gehörenden Netwerkadapter ab. Das passiert in zwei Schritten: Erst wird die virtuelle Repräsentation mit Get-VMNetworkadapter abgefragt, und dann wird die dazugehörige physikalische Netzwerkkarte abgefragt. Es handelt sich dabei um dasselbe Gerät, aber mit zwei unterschiedlichen Cmdlets abgefragt. Diesen umständlichen Weg gehen wir, weil get-Vmnetworkadapter uns den Interface-Index nicht zurück liefert, den wir benötigen, um das NAT-Netzwerk einzurichten: 

$natNetworkAdapter = Get-VMNetworkAdapter -ManagementOS -SwitchName $NatSwitch.Name
$networkAdapter = Get-NetAdapter | Where-Object -FilterScript {
     $_.deviceid -eq $natNetworkAdapter.DeviceId
}

Weiterlesen
4039 Aufrufe
0 Kommentare

Dateien restlos entfernen und Festplatten rückstandslos löschen mit Windows Bordmitteln

Immer wieder liest man den Mythos, dass man eine Festplatte 37 mal überschreiben muß, bevor die Daten vollständig gelöscht sind. In der aktuellen c´t 13/2016 gibt es dazu einen sehr guten Artikel, der die Hintergründe dazu beschreibt. Das Fazit der Artikelserie lautet: Bei alten MFM-Festplatten, bei denen die Datensektoren der Festplatten noch so groß waren wie Pfannkuchen, war eine Datenwiederherstellung mit den enstprechenden Werkzeugen in der Tat noch möglich. Bei aktuellen magnetischen Datenträgern haben sich die Aufzeichnungsverfahren aber maßgeblich verändert, und auch Datenrettungsunternehmen sind mit Ihren Werkzeugen nicht in der Lage, einmal überschriebene Daten wiederherzustellen. Ach das BSI und das amerikanische Pendant NIST geben als Richtlinie inzwischen heraus, dass eine einfache Überschreibung reicht, um Daten rückstandlos zu entfernen.

Kommen wir nun dazu, wie die Datenlöschung am einfachsten auszuführen ist. Windows bietet dazu 2 Bordmittel an.

Zum Löschen von einzelnen Dateien oder Partitionen auf der Festplatte bietet sich das Tool cipher.exe an. Es ist das Tool zur Kommandozeilensteuerung von EFS (Encrypted File System) und bietet den Schalter /w, mit dem man einzelne Dateien, Ordner oder aber auch ganze Partitionen löschen kann. Um den Ordner c:\Temp\geheim zu löschen und zu überschreiben, geben Sie hierfür ein:

Cipher.exe /w c:\Temp\geheim

Die Löschung kann eine Weile dauern, da die Daten in 3 Durchgängen mit 0, dann mit 1 und anschliessend wieder mit 0 überschrieben werden. Um die ganze Partition zu löschen, geben Sie nur Laufwerksbuchstabe: ein:

Markiert in:
Weiterlesen
4830 Aufrufe
0 Kommentare

Root-Zertifikat aus dem Zertifikats-Store entfernen

Haben Sie schon einmal versucht, ein per Gruppenrichtlinien verteiltes Root-Zertifikat wieder zu entfernen? Wie sich herausstellt, ist das über das Zertifikats-Plug-In in der Management-Konsole gar nicht so einfach. Hilfe verschafft hier das Kommandozeilentools Certutil in Verbindung mit Powershell.

Certutil besitzt einen Parameter -delstore, mit dem man Zertifikate aus dem Store entfernen kann. Ruft man Certutil -delstore -? auf, so bekommtn man folgende Optionen angezeigt:

Optionen:

-enterprise -- Verwendet den Unternehmensregistrierungs-Zertifikatspeicher auf dem lokalen Computer
-user -- Verwendet HKEY_CURRENT_USER oder Zertifikatspeicher.
-GroupPolicy -- Gruppenrichtlinien-Zertifikatspeicher verwenden

Verwenden Sie die Option -GroupPolicy für Zertifikate, die per Gruppenrichtlinie verteilt wurden. Der richtige Speicher ist wichtig, da Certutil Ihnen sonst zwar Vollzug vermeldet, aber die Zertifikate nicht löscht. Weiterhin benötigen Sie den Thumbprint (Daumenabdruck oder Checksumme) des zu entfernenden Zertifikats. Den erhalten Sie über Powershell:

Weiterlesen
4142 Aufrufe
0 Kommentare

AD Replikation, Standorte und Change Notification

So konfigurieren Sie die AD-Replikation zwischen Standorten.
Wenn Sie eine größere Active-Directory Infrastruktur verwalten, verfügen Sie vermutlich auch über mehrere Standort. Diese Infrastruktur kann man zur effizienteren Nutzung der Netzwerkresourcen mit dem Tool Active Directory Sites and Services (Standort und Dienste) abbilden. Hierfür erstellt man IP-Subnetze, die Standorten zugewiesen werden - dadurch kann das AD anhand der IP den Standort des Servers feststellen. Die Standort werden über sogenannte Site-Links verbunden. Sie entsprechen den Netzwerkverbindungen (Standleitungen) zwischen den Standorten.
Während ein Domänencontroller innerhalb eines Standortes jede Änderung im AD innerhalb von 15 Sekunden an seine Replikationspartner versendet, wird zwischen Standorten ein anderes Replikationsintervall gewählt, das einstellbar ist, aber standardmäßig 180 Minuten (3 Stunden) beträgt. Änderungen werden nur in diesem Zeitrahmen repliziert - auch Kontosperrungen, die innerhalb eines Standortes als "urgent replication" augenblicklich repliziert werden.
Es ist mit einer kleinen Änderungen an den AD-Attributen des Site-Links jedoch möglich, Change-Notifications (also Update-Änderungen) zu aktivieren, so dass die Replikation im normalen Replikationsintervall durchgeführt wird. Davon sind dann entsprechend auch urgent Replications betroffen. Öffnen Sie hierzu Active Directory Standort und Dienst, wählen Sie Sites->Inter-Site-Transports-IP und dann den Site-Link, den Sie konfigurieren möchten. Im Kontext-Menü wählen Sie Properties, wechseln in den Reiter "Attribute Editor" und suchen das Attribut "Options". Wenn Sie Options auf 1 setzten, aktivieren Sie die Change-Notifications. Die Replikation findet dann, wie zwischen Standorten üblich, komprimiert statt. Wählen Sie 5, findet eine unkomprimierte Replikation statt. Sollte hier bereits ein Wert stehen, müssen Sie die Werte XOR verrechnen - es handelt sich um eine Bitmaske, die hier verwendet wird.

Links:
Active Directory Replication: Change Notification and you
https://blogs.msdn.microsoft.com/canberrapfe/2012/03/25/active-directory-replication-change-notification-you/

Advanced Replication Management
https://technet.microsoft.com/en-us/library/cc961787.aspx

2652 Aufrufe
0 Kommentare
Nach oben