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!