We lost remotewebaccess.com …

Update 14.05.2022:
Seit dem letzten Samstag (14.05.2022) ist remotewebaccess.com wieder funktional. Wer während des „Offline“ sein RWA auf dem SBE nicht kaputt konfiguriert hat, sollte wieder eine korrekte Aktualisierung der Domain sehen und Zugriff darauf haben.

Eigentlicher Blog
Seit dem 01. Mai 2022 funktioniert remotewebaccess.com nicht mehr zuverlässig. Alle die nicht wissen, was https://<hostname>.remotewebaccess.com ist oder war, brauchen hier nicht weiterzulesen.

Der Windows Server SBE (Small Business Essentials) bietet ein Feature mit dem der Zugriff auf den Arbeitsplatz innerhalb der Firma über eine Webseite, wie z.B. https://sbsland.remotewebaccess.com/remote möglich ist. Damit das Mapping von aktueller IP-Adresse des Internet-Zugangs und remotewebaccess.com funktioniert, steckt dahinter ein DynDns-Mechanismus, der über ein Zertifikat abgesichert ist, was wiederum den Zugriff mit HTTPS und damit ohne Fehlermeldungen im Browser ermöglicht.

Das Problem wird durch die folgenden Meldungen protokolliert:

image

Windows Logs / Application and Services Logs / Microsoft / Windows / ServerEssentials / Admin

image

Da zumindest auf meinen SBE-Servern alle Zertifikate in Ordnung sind, vermute ich das der Server selbst ein Problem hat den Dienst der hinter remotewebaccess.com steht zu erreichen.

Betroffen sind von dem Problem alle, die diesen Dienst nutzen. Die Auswirkungen sind aber nur im Fall einer Änderung der IP-Adresse spürbar. Kunden mit einer festen IP vom Provider sehen dieses Problem nicht. Es sei denn, sie bekommen einen neuen Internet-Tarif und in diesem Zusammenhang auch eine neue feste IP. Dann versucht der SBE die neue IP zu aktualisieren, was ebenfalls fehlschlägt.

Ich gehe mal davon aus, dass die meisten Nutzer des SBE diesen noch auf Basis des Windows Server 2012 R2 betreiben, was zumindest bei mir die Mehrheit ist. Wenig sind noch mit dem Windows Server 2016 unterwegs. Beide Produkte sind inzwischen aus dem Mainstreamsupport draußen und besitzen nur noch den erweiterten Support. Darum sollten wir uns auch über einen Call bei Microsoft bzw. dem OEM keine Hoffnung machen, sondern müssen über Alternativen nachdenken. Was der Aufbau von VPN-Zugängen sein kann.

Bisher habe ich meine VPN-Zugänge ausschließlich mit Lancom oder dem Synology VPN-Server realisiert und muss sagen, dass beides sehr gut und zuverlässig funktioniert.

Wie sehen den bei Euch die Alternativen aus?

Enjoy it, b!

Hyper-V 18560, Triple Fault

Es gibt Probleme, die erwischen einen auf dem falschen Fuß. Während der Einführung und Konfiguration von Synology Active Backup for Business musste ich feststellen, dass eine wichtige VM noch auf einem Windows Server 2012 R2 Hyper-V Host lief. Das tat sie seit Jahren sehr zuverlässig und vfel damit in die Kategorie “never touch a running system …”

Synology Active Backup for Business benötigt aber mindestens die Hyper-V Version 6 der VM oder besser und damit einen Hyper-V Host der mindestens mit Windows Server 2016 oder höher läuft. Damit war notgedrungen eine Neuinstallation des Servers notwendig, da ich in diesem Fall auf den kostenlosen Microsoft Hyper-V Server 2019 zurückgreifen wollte.

Vor dem Upgrade dachte ich mir das bestimmt ein Updates des BIOS sinnvoll wäre, das auf dem Server verwendete war von 2014 und Supermicro hat für dieses Board nochmals 2021 ein neues BIOS bereitgestellt. Damit also zuerst den Microsoft Hyper-V Server 2019 installiert und gleich im Anschluss das BIOS aktualisiert. Für den Server war das eine so große Neuerung, dass er mir den konfigurierten SET weggeworfen hat und den Ethernet-Adapter 2 als Nummer 3 präsentierte. Kein Thema, ließ sich alles fixen.

Der Import der einzigen darauf verbliebenen VM (die zwar Generation 2, aber mit Version 5.0 lief) funktionierte funktionierte ebenfalls ohne Probleme, aber der Start wollte nicht gelingen und nach ca. 2min befand sich die VM wieder im ausgeschalteten Zustand.

Zuerst hatte ich das BIOS im Verdacht, aber eine neu eingerichtete VM mal schnell mit OpenSuse installiert, funktionierte ohne Probleme und auch die Hyper-V Replika zu dem anderen Windows Server 2019 Hyper-V Host lief ohne Probleme. Was also tun?

Ein Blick in das Eventlog offenbarte die beiden folgenden Events.

Critical 03/18/2022 20:13:12 Hyper-V-Worker 18604 None
'mt-app-1' has encountered a fatal error but a memory dump could not be generated. Error 0x2. If the problem persists, contact
Product Support for the guest operating system. (Virtual machine ID 0FDEE7BD-2627-4EC8-BE76-5EDF093B447B)
Critical 03/18/2022 20:13:12 Hyper-V-Worker 18560 None
'mt-app-1' was reset because an unrecoverable error occurred on a virtual processor that caused a triple fault. If the problem persists,
contact Product Support. (Virtual machine ID 0FDEE7BD-2627-4EC8-BE76-5EDF093B447A)

Der Fehler wurde zwar schon 2019 mit dem Update KB4497934 behoben, dass hatte aber noch nicht den Weg auf den neu installierten Hyper-V Host gefunden und damit musste ich auf den Workaround zur  Änderung des MAC Address Ranges greifen, was mit einem Aufruf in PowerShell recht einfach funktioniert.

Die folgende Abbildung zeigt den alten Adress-Bereich.

image

Für die Änderung muss man wissen wie eine MAC-Adresse überhaupt aufgebaut ist. Die ersten drei Oktette, also 11-22-33 oder in diesem Fall 00-15-5D sind dem jeweiligem Hardware-Hersteller zugeordnet, hier also Microsoft. Wenn nun der Bereich geändert werden soll, ist es am einfachsten das 4te Oktett zu inkrementieren.

# Anzeigen des aktuellen MAC-Adress Pools auf dem Hyper-V Host
Get-VMHost | Select ComputerName, MacAddressMinimum, MacAddressMaximum | ft
# Konfiguration eines neuen MAC-Adress Bereichs auf dem Hyper-V Host, das 4te Oktett wurde von 23 auf 24 geändert
Set-VMHost -MacAddressMinimum 00155D24AE00 -MacAddressMaximum 00155D24AEFF

Danach habe ich der VM den Netzwerk-Adapter entfernt und im Anschluss gleich wieder reinkonfiguriert. Danach startete mein Sorgenkind ohne Probleme.

Enjoy it, b!

racknex nextmount AVM 007

oder

Jetzt geht die FRITZ!Box ins Rack

(Hinweis: Das ist Werbung, die keine ist. Der Rackmount wurde regulär gekauft und ich stehe in keiner Verbindung zum Hersteller, dieses zugegebener Maßen genialen Produkts.)

Credits und Copyright liegen bei racknex

Bei einem meiner Kunden wurde spontan der Internet-Tarif bei Vodafone umgestellt, dass ist erst einmal positiv zu sehen da nun anstatt der bisherigen 100/20 MBit/s, schnellere 1000/50 MBit/s vorhanden sind. Für die 50 MBit/s im Upstream bedankt sich vor allem Microsoft Teams, wenn mehrere Mitarbeiter gleichzeitig eine Sitzung haben und die 1000 MBit/s Downstream helfen generell, vor allem aber bei VPN-Verbindungen über diesen Kanal.

Eine Kette ist immer nur so stark wie ihr schwächstes Glied, und bei den Vodafone-Anschlüssen war mir immer die Kombination aus Hitron- und Lancom-Router ein Dorn im Auge, wird doch jedes dieser Teile über ein separates Netzteil versorgt und besonders bei den Hitron-Routern hatte ich hier schon mehrere Ausfälle zu beklagen.

Der Hitron muss weg

Ein Vorteil der Hitron-Router ist, dass man sie (genauer gesagt das Modem) in den Bridge-Modus schalten kann und damit den dahinter liegenden Router für den Access verwendet. Der Bridge-Modus ist zumindest bei den neueren FRITZ!Boxen wie der 6591 Cable, nicht mehr einstellbar. Darum habe ich mich entschlossen die FRITZ!Box selbst für den Access zu verwenden und den Lancom-Router auf die Bereitstellung von VPN und VLAN zu reduzieren. Wie so ein Umbau aussieht, werde ich in einem anderen Blog beschreiben, ich habe selten so viele Routen konfigurieren müssen.

Erworben haben wir das NM-AVM-007, mit den Anschlüssen aber ohne Kabel-Kit, ich muss zugeben das ich das auf der Homepage auf die Schnelle nicht gecheckt habe. Rückblickend war das aber kein Thema, ich habe für die Verbindung 4x 50cm LAN-Kabel sowie 2x 50cm USB 3.0 Kabel (A-2-A) verwendet. Die waren von der Länge grenzwertig, hier wären ca. 60 oder 70cm (oder halt die von racknex angebotenen 1m Kabel) besser gewesen, es ging aber ohne die Kabel knicken oder biegen zu müssen.

IMG_20220422_125149_ON1

Die FRITZ!Box wird in ihrer Position im Rackmount über einen Anschlag gehalten, der diese unverrückbar gegen die Frontblende drückt. Darüber hinaus schlingt sich eine Art Sicherheitsgurt in Form eines Klettbandes um die FRITZ!Box der ein Herausfallen während der Montage verhindert. Man kann diese Lösung als stabil und solide bezeichnen.

Bezahlt wird das mit zwei Höheneinheiten im Rack, wie auf dem Bild zu sehen ist. Das ist es aber allemal wert und bietet nun auch für die FRITZ!Box einen “würdigen” und sichern Platz. Bisher standen die Hitron-Router immer auf dem obersten Server rum und mussten bei Montagearbeiten mit besonderer Vorsicht behandelt werden.

Mit der Lösung von racknex, befindet sich FRITZ!Box wo sie hingehört, fest und sicher verschraubt im Rack.

Enjoy it, b!

AD-Migration von Windows Server 2012 SBE auf Windows Server 2019

Farewell Small Business Essentials Server

Dieser Blog war nur eine Frage der Zeit, aber es war klar, dass er kommen wird (und leider muss). Nachdem mit dem Windows Server 2019 lediglich das Lizenz-Modell des SBE übriggeblieben ist, gibt es zwei Möglichkeiten in welche Richtung eine Small Business Server Umgebung entwickelt werden kann.

  1. Windows Server Standard
  2. Synology NAS

Den Weg in Richtung Windows Server Standard (also aktuell Windows Server 2019 oder 2022) wähle ich, wenn sich in der SBE-Umgebung eine Anwendungslandschaft etabliert hat, sprich einige Applikationsserver vorhanden sind und dazu auch noch virtualisiert wird.

Spoiler

Man kann aus zwei Synology NAS Systemen (dem darauf laufendem Synology Directory Server) und zwei Intel NUC PCs (als Hyper-V Hosts) ebenfalls eine interessante Infrastruktur bauen, dass soll aber das Thema in einem anderen Blog sein.

Migration

Die Umstellung auf Windows Server Standard verläuft wie im Folgenden dargestellt.

  1. Installation des neuen Servers als Member-Server in der bestehenden Domain
  2. Erstellen eines domain-basierten DFS-Roots
  3. Migration von vorhandenen Freigaben und der bereitgestellten Daten in das domain-basierte DFS
  4. Anpassung von Gruppen-Richtlinien und des Login-Scripts auf die Freigaben die nun über das DFS auf dem neuen Server (der ja aktuell noch als Member-Server läuft) abgebildet werden
  5. Heraufstufen (Promote) des neuen Member-Servers zu einem zweiten Domain-Controller und anpassen dessen DNS-Einträge
  6. Verschieben der FSMO auf den neuen Server
  7. Entfernen der Active Directory Zertifikatsdienste (mit der Webregistrierung muss beginnen werden) und zwingend danach einen Neustart durchführen
  8. Herunterstufen (Demote) des alten Servers
  9. Spätestens jetzt eventuell vorhandene Drucker auf dem Server migrieren
  10. Den alten Server aus der Domäne entfernen, oder besser erst einmal 14 Tage ausgeschaltet lassen (falls man was vergessen hat)
  11. Den domain functional level und den forrest functional level heraufstufen

Jeden der genannten Schritte werde ich hier nicht im Detail ausführen, dafür verkaufen andere Webseiten ganze Migration-Guides und ich denke, dass robocopy geläufig sein sollte.

Was ich aber für sinnvoll halte ist, sein (mein) Schaffen zu überprüfen. Sprich verhalten sich die Systeme so wie ich mir das vorstelle. Darum werde ich unten eine Reihe von Tests beschreiben, mit denen eine Prüfung zum jeweiligen Stand möglich ist.

Zu den Schritten 1 bis 4

Die Installation des Member-Servers ist selbstredend und da er im Verlauf der Migration ein Domain-Controller wird, sollte er auch gleich eine statische IP bekommen.

Wenn alle Scripte und GPOs angepasst sind, sollten auf den neu eingerichteten Member-Server auch die Zugriffe erfolgen. Genauso wichtig ist es, dass der alte Domain-Controller keine Zugriffe über SMB mehr zeigt.

# Anzeige von offenen Dateien über die SMB-Shares auf dem noch aktuellen Domain-Controller
Get-SmbOpenFile

Das folgende Beispiel finde ich gut, da es einen “false positive” zeigt.

image

Eine Session (dazu noch eine Anmelde-Sitzung) haben wir, dass NAS zur Datensicherung vergnügt sich noch mit diesem DC. Sobald wir den neuen DC und damit auch einen weiteren DNS haben, muss auf allen Clients dieser neue DNS auch eingetragen werden (der alte DC ist ab Schritt 8 nicht mehr vorhanden).

Zu Schritt 5

Mit Install-WindowsFeature muss auf dem Member-Server sowohl das Active-Directory als auch der DNS installiert werden, was in einem Schritt möglich ist.

# Installation des Active Directory und DNS
Install-WindowsFeature -Name AD-Domain-Services, DNS -IncludeAllSubFeature

image

Nun lauert im Server-Manager versteckt was früher der DCPromo war, in Form eines Wizards zur Fertigstellung des Domain-Controllers. In diesem Fall wird der Server als weiterer DC in die bestehende Domain und Forest integriert.

Zu Schritt 6

Der neue Server muss nun, wenn er funktional wirklich ein Domain-Controller ist, den NETLOGON- und den SYSVOL-Share bereitstellen. Bei mehreren Migrationen von Windows Server 2012 SBE (auch R2) auf Windows Server 2019 war das nicht der Fall und jedes Mal, war eine dysfunktionale SYSVOL-Replikation der Grund.

Die Lösung dazu aber immer beeindruckend einfach, der als neuer Domain-Controller gedachte Windows Server 2019 wurde wieder aus dem AD entfernt (demoted) und die Replikation auf dem Windows Server 2012 repariert. Danach den Windows Server 2019 wieder zum Domain-Controller promoten und schauen, ob die beiden Shares nun verfügbar sind. Alle Maßnahmen, bei denen man die Shares auf anderem Wege erstellt hat, führten zumindest bei mir, früher oder später zu Problemen.

image

# Anzeige des SysVol und Netlogon Shares
Get-SmbShare | Where-Object { $_.Description -match "Logon server share" }

Zum Verschieben der FSMO-Rollen, wird der folgende PowerShell-Befehl verwendet.

# Verschieben der FSMO-Rollen
Move-ADDirectoryServerOperationMasterRole -Identity Neuer-Domain-Controller -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

Sollte der Befehl funktionieren, hat man mit einem Rutsch alle Rollen migriert. Ich schreibe hier bewusst im Konjunktiv, da auch hier gelegentlich das Problem aufgetreten ist, dass der Befehl nicht wie erwartet funktioniert.

Dann haben die beiden folgenden Möglichkeiten bisher zum Erfolg geführt.

  • Verwenden von Move-ADD… mit immer nur einer Rolle
  • Verschieben der Rollen in den entsprechenden MMCs
# Abfrage ob die FSMO-Rollen nun auf den neuen DC sind
netdom query fsmo

Klar, kann man die Rollen auch mit PowerShell abfragen, dazu sind aber zwei Befehle notwendig, bzw. man muss in unterschiedlichen Kontexten arbeiten.

# Abfrage ob die FSMO-Rollen nun auf den neuen DC sind
Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster

Hier alle drei Aufrufe als Screenshot.

image

Abschließend schaue ich immer, ob die wichtigen Active Directory Dienste laufen.

# Anzeige von wichtigen Diensten für das Active Directory
Get-Service adws,kdc,netlogon,dns

image

Wie vielleicht bisher schon zu sehen war, teste ich möglichst viel und zwischendurch, um ein Gefühl zu bekommen, ob die Migration sauber läuft. Das hat sich über die Jahre hin als sinnvoll herausgestellt, da oftmals nur kleine Korrekturen zwischendurch notwendig waren und nicht am Ende ein großes nicht sauber funktionierendes Nichts steht Smile

Zwischen Schritt 6 und 7 kann man ein paar Tage vergehen lassen. Man muss hier lediglich mit den Meldungen des alten Windows Server 2012 SBE leben, der ein Fehlen der FSMO-Rollen zurecht, als Lizenzverstoß reklamiert.

Zu Schritt 7

Bevor nun der alte Windows Server 2012 SBE seine Rolle als Domain-Controller verliert, müssen die Active Directory Certificate Services deinstalliert werden. Macht man das von Hand, zuerst die Certification Authority Web Enrollment und dann den Rest danach deinstallieren.

# Anzeige der Roles und Features
Get-WindowsFeature -Name ADCS-Web-Enrollment, ADCS-Cert-Authority, AD-Certificate

image

Auch mit PowerShell muss das in zwei Schritten erfolgen.

# Deinstallation der Active Directory Certificate Services
Remove-WindowsFeature -Name ADCS-Web-Enrollment
Remove-WindowsFeature -Name AD-Certificate

image

Nun ist ein Neustart zwingend notwendig, auch wenn das durch die PowerShell-Ausgaben nicht den Eindruck erweckt. Wird der vergessen, jagt man hinterher eine Reihe von komischen Dingen nach. Also nun einfach durchstarten (den alten Domain-Controller).

# Neustart des alten Servers
Restart-Computer -Force

Nach dem Neustart kann der alte Domain-Controller heruntergestuft werden.

Zu Schritt 8

Alle Informationen dazu kann man bei Microsoft hier nachlesen. Obwohl ein großer Freund von PowerShell, führe ich diesen Schritt immer in der GUI durch. Dazu im Server Manager einfach die Rolle Active Directory Domain Services entfernen.

image

Der Remove Roles and Features Wizard bietet einem danach die Möglichkeit den Server herunterzustufen.

image

Der Vorgang ist selbsterklärend, am Ende dessen muss eine Meldung ähnlich der folgenden vorhanden sein.

image

Ok, hier noch die Aktion in PowerShell.

# Windows PowerShell script for AD DS Deployment
Import-Module ADDSDeployment
Uninstall-ADDSDomainController -DemoteOperationMasterRole:$true -Force:$true

Mit einem Klick auf Demote im Wizard wird der Prozess gestartet und der Server startet nach dem Herunterstufen neu. Davor ist es sinnvoll einen Blick in die DNS-Einstellungen der Netzwerkkarte zu werfen, steht dort wie bei vielen Domain-Controllern in SBE-Umgebungen “nur” 127.0.0.1, ist es notwendig den DNS vom neuen Domain Controller mit einzutragen. Sonst geht die Anmeldung mit einem Konto aus der Domain schief.

Zum Schluss

Eigentlich war es das, aber die Erfahrungen der letzten Migrationen haben gezeigt das immer noch der eine oder andere Rest des alten Domain-Controllers zurückbleibt.

Diesen haben ich als Namespace-Server im DFS entfernt. Damit das ohne Probleme funktioniert sollte der alte Server noch vorhanden sein und für kurze Zeit als Member-Server arbeiten dürfen.

image

Der alte Domain-Controller (der nun keiner mehr ist) darf nun auch nicht mehr in der SYSVOL-Replication auftauchen.

image

Ein weiteres Problem, eher optischer Natur ist der Verbleib des alten Servers als Name-Server in der Reverse Lookup Zone (falls man überhaupt eine hat).

image

Hier diesen entfernen und wie im Bild oben zu sehen ist, für den neuen die aktuelle IP auflösen lassen. Im Allgemeinen ist es sinnvoll den DNS nach alten Einträgen zu durchsuchen und diese zu löschen.

Enjoy it, b!

Synology Active Backup for Business | Hyper-V PowerShell-Module

Die Sicherung von virtuellen Maschinen (VM) mit Synology Active Backup for Business, die auf einem Microsoft Hyper-V Server oder Windows Server Core betrieben werden, setzt die Existenz des Hyper-V PowerShell-Modules voraus.

image

Ist dieses nicht vorhanden, schlägt die Konfiguration in Active Backup fehl und das PowerShell-Modul muss auf dem Host nachinstalliert werden.

image

Der erste Befehl zeigt, ob das Modul vorhanden ist oder nicht.

# current status of the modules on this Hyper-V server
Get-WindowsFeature *hyper-v*

Mit diesem Aufruf wird das fehlende Modul unter PowerShell installiert.

# install the Hyper-V PowerShell module
Install-WindowsFeature -Name Hyper-V-PowerShell

Danach funktioniert auch die Aufnahme des Hyper-V Hosts in das Management von Synology Active Backup for Business.

image

Enjoy it, b!

Synology DS | Snapshots oder Vorgänger Versionen wiederherstellen

Die Möglichkeit für den Benutzer Dateien aus einem Snapshot (Schnappschuss) selbst wiederherzustellen ist eine große Entlastung für den Administrator. Diese Möglichkeit besteht unter Windows Server schon seit der Version 2003 und damit seit fast 20 Jahren. Dieses Feature kann auch auf einer Synology Diskstation (DS) für die Anwender bereitgestellt werden.

In einem ersten Schritt muss das Paket Snapshot Replication auf dem NAS installiert werden.

image

Nach der Installation kann unter Schnappschüsse, die entsprechende Freigabe ausgewählt und ein Zeitplan für die Ausführung konfiguriert werden. Für Freigaben mit wenig Änderungen genügt es den Schnappschuss 1x am Tag zu erstellen, für Freigaben wie die Benutzerverzeichnisse (homes) ist es sinnvoll eine höhere Frequenz von zwei oder auch 3x am Tag in Betracht zu ziehen.

image

Zusätzlich muss noch die Aufbewahrungsrichtlinie definiert werden, sonst erfolgt die Erstellung von Schnappschüssen bis der Speicherplatz aufgebraucht ist. Da die Snapshots nur die geänderten Blöcke sichern, entsteht hier kein großer Speicherbedarf. In der Erweiterten Aufbewahrungsrichtlinie findet sich nach meiner Meinung schon eine sinnvolle Grundeinstellung, bei der ich lediglich die Anzahl der zu behaltenden Schnappschüsse von 5 auf 10 ändere.

image

image

Nachdem der erste Schnappschuss erstellt wurde, erscheint dieser als Vorgänger Version oder Previous Version im Windows Explorer.

image

Natürlich kann auf den Schnappschuss nicht nur auf Ebene der Freigabe selbst, sondern auch auf die darunter liegenden Verzeichnisse und Dateien zugegriffen werden.

image

Für die Bereitstellung ist es notwendig, dass die Synology Diskstation die Software-Funktion Snapshot Replication unterstützt. Darauf muss beim Kauf zwingend geachtet werden.

Enjoy it, b!

Excel, Fehler mit zirkulärer Referenz

Wie auch immer das passiert ist, ich hatte einen Fehler mit zirkulärer Referenz in eine Excel-Tabelle eingebaut. Excel meldet das dann mit folgendem Hinweis.

image

Finden und lösen des Fehlers ist dabei recht einfach möglich, im Menüpunkt Formulas / Formula Auditing / Error Checking / Circular References wird dieser ausgewiesen und kann korrigiert werden.image

Noch als Hinweis zum Schluss, dass wird kein Office Blog aber auch ich schlage mich mit dem einen oder anderem Problem in Office herum.

Enjoy it, b!

Fix der SysVol-Replikation (DFS-R)

Neulich stand ich vor dem Problem, dass nach dem Einspielen von neuen Windows 10 ADMX-Dateien diese nicht zwischen den Domain Controllern (DCs) repliziert wurden.

Einen ersten Hinweis gab dazu das DFS Replication Event-Log, mit dem Event 4012.

image

Der Vorschlag direkt im Text ist, den DC der nicht an der Replikation teil nimmt aus der Replication Group zu entfernen und wieder hinzuzufügen ist ehrlichgesagt Bullshit, dass ist bei der SysVol Relikation mit DSF-R nicht möglich. Vielmehr muss man eine authoritative synchronization für das mit DFS-R replizierte SysVol durchführen.

Um trotzdem einen Blick auf die SysVol Replication Group werfen zu können, installiere ich gerne auf allen DCs oder in größeren Umgebungen auf Management Servern die DFS Management Tools aus dem Windows RSAT.

image

Mit PowerShell ist das ebenfalls möglich und kann für viele DCs automatisiert werden.

# Hinzufügen der RSAT DFS-Management Tools
Add-WindowsFeature -Name RSAT-DFS-Mgmt-Con

So, wie funktioniert nun die authoritative synchronization des SysVol?

Authoritative SysVol Replikation

Start von ADSIEDIT (über die Suchfunktion auf dem DC) oder das Startmenü, dort liegt das Tool unter Windows Administrative Tools / ADSI Edit.

image

In diesem Fall war die Ausgangslage wie folgt

  • slabad01.vmlabs.local (DC = OK)
  • slabad02.vmlabs.local (Replikation schlägt fehl)

Der slabad01 sollte also die Autorität für die SysVol Replikation werden und obwohl die Replikation ohnehin nicht mehr funktioniert, muss davor auf allen DCs die DFS Replication beendet und auf Manual gestellt werden.

image

image

Nachdem ADSI Edit (mit administrativen Rechten) gestartet wurde, bleiben die Standard-Einstellungen wie sie sind.

image

Nach dem Klick auf OK, steht uns ein Klick-Marathon bevor. Die KB von Microsoft referenziert hier wie folgt:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC=msDFSR-Enabled=FALSE

Das ist zwar korrekt stellt aber die genau umgekehrte Reihenfolge dar wie der eigentliche Weg ist. Dazu folgen wir dem nächsten Bild.

image

In den SYSVOL Subscription Properties setzen wir nun die beiden folgenden Werte:

msDFSR-Enabled=FALSE
msDFSR-options=1

Das nächste Bild zeigt beide Einstellungen.

image

Für alle anderen DC (bei mir ist es nur ein weiterer) muss ebenfalls msDFSR-Enabled=FALSE gesetzt werden.

msDFSR-Enabled=FALSE

Nun wird auf dem DC von dem die Replikation (Authoritative) aus erfolgen soll, die DFS Replikation wieder gestartet und auf Automatic gesetzt.

image

Nun findet sich im Event-Log der DFS Replication die ID 4114, diese indiziert das die Replikation dieses DC nicht aktiv ist (haben wir ja auch mit msDFSR-Enabled=FALSE deaktiviert).

Hoffentlich habt ihr ADSI Edit offen gelassen, nun wird nämlich der Wert für msDFSR-Enabled=TRUE gesetzt und eine Replikation mit DFSRDIAG POLLAD erzwungen.

DFSRDIAG POLLAD

image

Nun finden sich im Event-Log der DFS Replication die ID 4602, die besagt das auf diesem DC das SysVol wieder erfolgreich repliziert wird.

image

Für alle anderen DCs wird nun zuerst der Dienst für die die DFS Replication auf Automatic gesetzt und gestartet. Sobald der Event 4114 im DFS Replication Event-Log aufgetaucht ist, muss mit ADSI Edit für die restlichen DCs msDFSR-Enabled=FALSE wieder auf msDFSR-Enabled=TRUE gesetzt werden.

Im Anschluss muss auch auf jedem anderen DC ein DFSRDIAG POLLAD ausgeführt werden.

Dazu kann man einfach mal nachschauen ob im SysVol die fehlenden Richtlinien ankommen.image

Das Ereignis mit er ID 4604 meldet dann, dass die Replikation mit den anderen DCs eingesetzt hat und damit wäre auch das Problem gelöst.

Zusammenfassung

Zuerst wird auf dem DC der die autoritative Rolle einnehmen soll, die SysVol Replication wieder in Gang gebracht (er repliziert dann mit sich selbst) und im Anschluss die restlichen DCs mit eingebunden.

Enjoy it, b!

Bluetooth-Maus hängt unter Windows

Wenn unter Windows (egal ob Version 10 oder 11) immer mal wieder die Bluetooth-Maus hängt und das zum Beispiel besonders gerne in RDP-Sitzungen macht, kann das mit einer Einstellung im Intel® Wireless Bluetooth® Gerät (Device) zusammen hängen.image

In den Eigenschaften dieses Devices, muss die Option Allow the computer to turn off this device to save power im Power Management deaktiviert werden.

image

Damit sind die Hänger verschwunden und die Maus läuft ohne Probleme.

Enjoy it, b!

Deinstallieren von Software mit PowerShell

Auf einem Windows Server Core, kann installierte Software mit den folgenden PowerShell Befehlen deinstalliert werden.

# Anzeige der installierten Software
Get-WmiObject -Class Win32_Product | Select-Object -Property Name
# Erstellen einer Variablen für die Deinstallation der Software
$App = Get-WmiObject -Class Win32_Product | Where-Object{$_.Name -eq "5nine Manager for Hyper-V"}
# Deinstallieren der Software
$MyApp.Uninstall()

Das funktioniert natürlich nicht nur auf dem Windows Server Core, doch dort ist es die einfachste Möglichkeit Software wieder los zu werden.

Enjoy it, b!