Default Domain Policy | Fehlende Remote Installation Services in der GPO

Eigentlich habe ich die Default Domain Policy in den Active Directory Domains (AD) meiner Kunden nie verändert. Jetzt, da ich durch den Verlust meines geliebten Small Business Servers vermehrt den Synology Directory Server einsetze (sagen wir einfach mal Samba dazu) bin ich beim Aufräumen auf eine veränderte Default Domain Policy gestoßen. Deren Einstellung wurden im Zuge einer Migration auf den Windows Small Business Server erweitert (Remote Installation in der User Configuration).

image

Von den Zeitstempeln (Created und Modified) würde das passen.

image

Ein Löschen der Einträge war leider nicht möglich, da diese nicht im Editor (gpedit) angezeigt wurden. Schließlich konnte ich aber die dazugehörige Richtlinien-Datei mit der GUID {31B2F340-016D-11D2-945F-00C04FB984F9} im SysVol finden und die Default Domain Policy bereinigen.

image

Man kann auch mit einem dir nachschauen, ob die Einstellungen dort wirklich zu finden sind (just to be sure).

image

Gelöscht wird über eine mit administrativen Rechten ausgeführte cmd.exe oder PowerShell und zwar der USER\Microsoft\Remote Installation Ordner und nicht die Policy selbst!

:: Löschen des Ordners "Remote Install" in der Policy
rd "\\synology-nas\sysvol\mydomain.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\USER\Microsoft\Remote Install" /s /q

Nochmals und aus gegebenem Anlass, nicht die Policy löschen da es sich auch noch um die Default Domain Policy handelt und dcgpofix nur auf einem Windows Domain Controller ausgeführt werden kann, der ja in diesem Fall nicht vorhanden ist.

Enjoy it, b!

Synology L2TP-VPN mit Windows

Der Synology VPN Server bietet eine einfache und vor allem kostenlose Möglichkeit gesicherte Zugänge ins lokale Netzwerk herzustellen.

Der größte Vorteil ist, dass auf einem Windows-System keine zusätzliche Software installiert werden muss, es genügen ein oder zwei Einstellungen in der Registry und die Konfiguration des VPN-Tunnels per PowerShell. Vor allem wird die Geschwindigkeit des Windows Systems nicht beeinflusst, wie das zum Beispiel bei einem Lancom Advanced VPN-Client der Fall ist, mit dem sich der Startvorgang von Windows deutlich verlängert.

In diesem Blog geht es um die Einrichtung des VPN unter Windows. Damit der VPN-Server funktioniert, müssen die folgenden Punkte berücksichtigt werden:

  • Öffentliche IPv4-Adresse des Routers muss über einen DynDNS-Dienst erreichbar sein. Auch wenn eine feste IP-Adresse vom Provider vorhanden ist, empfehle ich deren Maskierung über einen DNS-Namen!
  • Der VPN-Server muss auf dem Synology NAS installiert und konfiguriert sein
  • Die Ports 500, 4500 und 1701 müssen für UDP vom Router auf das Synology NAS weitergeleitet werden

Hier der Screenshot einer FRITZ!Box mit den Weiterleitungen für L2TP, auf die interne IP-Adresse des Synology NAS (und damit dem VPN-Server) mit 172.16.16.13

image

Einmalig zu konfigurierende Einstellungen für das L2TP-VPN unter Windows

Microsoft beschreibt in diesem Artikel, mögliche Werte für die Konfiguration. Nach meiner Erfahrung befinden sich fast immer, sowohl der VPN-Client (also das Windows System) als auch das Synology NAS (und damit der VPN-Server) hinter einer mit NAT umgesetzten Umgebung. Darum habe ich den Wert 2 als Default in meinem Skript verwendet.

PowerShell L2TP-VPN Registry-Setting

Auszuführen ist der Code mit erweiterten Rechten in einer PowerShell-Sitzung (elevated), was aber im Skript ebenfalls abgeprüft wird. Nach dem Setzen des Wertes ist ein Neustart von Windows sinnvoll. Danach können von jedem Benutzer eigene, auf L2TP basierende VPN-Tunnels erstellt werden.

Erstellen eines L2TP basierten VPN-Tunnels

Der VPN-Zugang kann natürlich in den VPN-Einstellungen von Windows “durchgeklickt” werden, vor allem bei mehreren Benutzern und einfacher, ist die Verwendung der PowerShell und des folgenden Skriptes.

image

Zur Ausführung des Skriptes sind die folgenden Punkte zu beachten.

  • Das Skript wird im Benutzer-Kontext ausgeführt und ist individuell für jeden Benutzer anzupassen
  • Dafür sind ist die Variabel $User entweder mit einem Benutzer aus der Domäne zu belegen oder mit einem lokalen Benutzer auf dem Synology NAS. Ist ein AD / Domäne vorhanden, empfiehlt es sich diese zu verwenden, da dann das gleiche Passwort wie zur Anmeldung verwendet werden kann. Darüber hinaus bitte immer nur den Benutzernamen eintragen, die Domäne ist nicht notwendig

Generell sind für alle Benutzer die einen Zugang per VPN erhalten sollen, die folgenden Einstellungen zu treffen:

  • $ServerAddress = Ein über DNS (DynDNS) auflösbarer Name der vom Provider zugewiesenen IPv4 Adresse, die Konfiguration des DyDns-Providers kann man auf dem Router, dem Synology NAS oder einem anderen Endgerät durchführen
  • $L2tpPsk = Der im Synology VPN-Server hinterlegte Pre-Shared Key

Der Pre-Shared Key ist auf dem VPN-Server hinterlegt und muss auch in allen Konfigurationen auf den Endgeräten verwendet werden, er ist also immer gleich. Wer bei der Einrichtung einen hinreichend langen Key erstellen will, kann sich der auskommentierten Zeile 13 und PowerShell bedienen.

image

Damit ist die Konfiguration auch schon fertig, nun stellt sich nur die Frage was tun, wenn der Zugang nicht funktioniert?

Update 01.05.2024

Will man ein L2TP-VPN von einem Apple IOS Device nutzen (iPad Pro), dann darf der Pre-Shared Key nicht länger als 128 Zeichen sein. Thanks Apple for this unnecessary limitation. Sonst klappt die Verbindung nicht!

Das hat übrigens nichts mit diesen Support-Artikel von Apple zu tun. Dieser besagt lediglich, dass die Option Enable SHA-254 compatible mode (96Bit) nicht aktiviert werden darf.

Troubleshooting, Allgemeine Checks (DNS und Ports)

Ein korrekt über das Skript angelegter VPN-Zugang taucht als zusätzlicher WAN Miniport (L2TP) Adapter in den Netzwerkverbindungen auf, konfiguriert man mehrere Zugänge, dann gibt es auch mehrere Netzwerkverbindungen.

image

Prüfen ob von Windows aus der Synology VPN Server per nslookup auflösbar ist.

Nochmalige Prüfung on die drei UDP-Ports wirklich auf das NAS zeigen und ob auch wirklich UDP und nicht TCP verwendet wurde. Die Portnummern sind, nochmals zur Vollständigkeit 500, 4500 und 1701

Troubleshooting, Fehler 787

Für den Fall, dass der Aufbau des VPNs mit einem Fehler 787 fehlschlägt, ist ebenfalls in einer PowerShell-Sitzung mit erweiterten Rechten der unten stehende Code zur Ausführung zu bringen. Die dort beschriebene Änderung hat Microsoft ebenfalls in einem Artikel dokumentiert.

image

Bisher musste ich diesen Wert nur 2x setzen, darum habe ich ihn im als Download verfügbaren Skript deaktiviert.

Troubleshooting, die Namensauflösung durch den Tunnel funktioniert nicht

Bei einem aufgebauten VPN-Tunnel funktioniert die Auflösung der dahinter liegenden DNS-Namen nicht. Der Grund dafür ist relativ einfach, Windows verwendet den DNS-Server mit dem Netzwerkadapter mit der kleinsten InterfaceMetric.

image

Wird nun der VPN-Verbindung die niedrigste InterfaceMetric zugewiesen, dann gehen die Abfragen des DNS durch den Tunnel.

image

Abfragen und ändern der InterfaceMetric kann man über die folgenden beiden PowerShell-Befehle erreichen.

image

Damit wird der, auf dem VPN-Server konfigurierte DNS verwendet und eine Verwendung und Abfrage von Namen als FQDN ist möglich.

Die niedrige InterfaceMetric für den VPN-Netzwerkadapter spielt im Betrieb ohne VPN keine Rolle, da dann der Netzwerkadapter deaktiviert ist.

Für und wider dem Synology VPN Server

Der Synology VPN Server hat eine Reihe von Eigenschaften die bekannt sein sollten, bevor man sich für diese Lösung entscheidet.

  1. Es ist nicht möglich ein Site-2-Site VPN zu erstellen, dass behält Synology seinen Routern vor
  2. Die Verwendung von DNS-Splittunneling ist nicht möglich, auch das geht nur mit Synology Routern (oder natürlich alternativen VPN-Lösungen)
  3. Wireguard ist schneller

Warum verwende ich dann trotzdem den Synology VPN Server?

  • Er ist kostenlos
  • Windows ist als VPN-Client einfach per PowerShell zu konfiguieren und es muss kein Agent installiert werden. Damit entfallen Updates und es werden Sicherheitsrisiken reduziert

Enjoy it, b!

LSA 40970 | Fehlende SPNs im Synology Directory

Hier geht es nicht nur um den Synology Directory Server, sondern auch um ein Problem in einer Samba-Domain allgemein. Letztendlich basiert der Synology Directory Server auf Samba und damit kann für eine Fehleranalyse und Behebung auf die Informationen im Samba-Wiki zurück gegriffen werden und natürlich auch (mit einer gewissen Vorsicht) die RSAT-Active Directory Tools vom Microsoft zum Einsatz kommen.

Hier noch ein Hinweis in eigener Sache:
Es handelt sich hier um eine Test/Labor-Umgebung, allerdings aus einem Kundenumfeld, darum habe ich die Namen entsprechend ersetzt.

Nach einer Reihe von Reparaturen in der Labor-Domain dslab.local, zeigte ein Computer die folgende Warnung im Ereignissprotokoll.

image

Da die Domain zwei DCs hat, war es kein großes Ding die SPNs beider Systeme miteinander zu vergleichen und tatsächlich fehlten dem nc-nas-11 eine Vielzahl von SPNs, die auf dem nc-ncs-14 zu finden waren.

image

Gegenüber den Einträgen des nc-nas-14 ist das recht spärlich Smile

image

Nachdem die fehlenden SPNs, analog zu den Einträgen des nc-nas-14 mit setspn registriert waren, verschwand auch der LSA 40970 im Ereignisprotokoll.

Enjoy it, b!

Synology DS | NVMe-SSD im RAID1

Ich glaube, dass hier über meine Zuneigung zu den Synology NAS-Systemen keine Zweifel herrschen. Allerdings gehe ich persönlich nicht ganz mit der Produktpolitik von Synology konform. Die bessere Integration oder sogar “only-supported”-Strategie von Synology-Festplatten und Synology-SSDs erschließt sich mir nicht vollständig, zumal diese gewisse Lücken offen lässt. So, um was geht es den hier genau?

Dieser Blog beschreibt die Konfiguration eines Volumes mit non-Synology NVMe-SSDs in einem RAID1. Zuerst erfolgt die Konfiguration und im Anschluss eine Reihe von Gedanken die ich mir zu diesem Thema gemacht habe. Für die Nerds unter uns, ist der Blog nach der Konfiguration fertig Smile

Hinweis:
Die hier gezeigte Konfiguration entspricht nicht den Support-Vorgaben von Synology und erfolgt auf eigenes Risiko.

Konfiguration eines RAID1 mit Samsung NVMe-SSDs

Die Ausgangssituation für diesen Beitrag ist die Folgende:

Das Ziel ist ein weiterer Storage Pool (Storage Pool 2) mit einem Volume bestehend aus den beiden Samsung NVMe SSDs in einem RAID1-Verbund.

Die Voraussetzungen, sind die folgenden:

  • Beide NVMe-SSDs sind eingebaut und werden von der Synology im Storage Manager erkannt
  • SSH wurde auf der Diskstation aktiviert

Die ersten Schritte erfolgen in der SSH-Session und erstellen einen weiteren Available Pool 1 / Verfügbaren Pool 1 (je nachdem welche Sprache die Diskstation verwendet).

image

image

Die Befehle oben gibt es hier in einer ZIP-Datei zum Herunterladen. Ich bevorzuge zum Öffnen entweder Visual Studio Code oder Notepad++ da damit eine ansprechende Formatierung möglich ist.

Dem Rahmen in Orange entnehmen wir, dass der Available Pool 1 assembliert werden muss – Online Assemble was im Fenster rechts oben über die drei, in einer Reihe liegenden Punkte erfolgt (Rahmen in Blau)

image

Hinter diesen drei Punkten ( ) befindet sich die Option Online Assemble, die nach anklicken noch mit Apply bestätigt werden muss.

image

Der Storage Manager zeigt daraufhin einen Storage Pool 2 an, der assembliert wird.

image

Öffnet man den Storage Pool 2 findet man die beiden Samsung M.2 SSDs mit ihrer Kapazität (Drive Size) und darunter das Volume 2 mit einer knapp darunter liegenden Kapazität von 889,9GB

image

Damit ist das Volume 2 erstellt und kann verwendet werden. Für mich war der Grund, darauf eine VM laufen zu lassen, die von der deutlich besseren Performance der Samsung SSDs profitiert. Dazu muss ich das neue Volume 2 im Virtual Machine Manager noch hinzufügen, was über das Menü Storage/Add möglich ist.

image

Nach einem Klick auf Add erscheint der Wizard um eine Storage Ressource zu erstellen (Create Storage Resource) der mit Start gestartet wird. Dort steht wiederum das erstellte Volume 2 zur Auswahl …

image

… das nach Konfiguration genereller Einstellungen, verwendet werden kann.

image

Existiert, wie in diesem Fall, schon auf Volume 1 eine VM, so kann diese auf das Volume 2 im Virtual Machine Manager migriert werden. Wie schnell der Vorgang von statten geht, hängt hauptsächlich von der Lese-Geschwindigkeit des Quell-Volumes ab.

Überlegungen zur Konfiguration der Samsung SSDs

Die Verwendung der beiden M.2 Slots für eine NVMe SSD ist natürlich verlockend. Wirft man einen Blick in die Synology-Kompatibilitätsliste, tritt hier schnell Ernüchterung ein. Außer den beiden Synology SSDs der SNV3410 und SNV3400-Serien mit jeweils 400 und 800GB sind keine Alternativen zu finden.

Die Synology-Laufwerke haben mindestens zwei Einschränkungen.

  1. Sie sind teuer (SNV3410-800G für ~ 300€ netto, Samsung 990 Pro M.2 mit 1TB für 83,00€ netto)
  2. Die maximale Kapazität endet bei 800GB und damit lassen sich größere Kapazitäten (mit 2 oder 4TB) mit Boardmitteln nicht erreichen

Betrachten wir die Synology SNV3410-800G, so wird für diese der 3,5-fache Preis einer Samsung SSD 990 Pro mit 1TB aufgerufen und auch die Samsung ist zum Einsatz im Dauerbetrieb geeignet (wenn auch nicht für eine Synology NAS zertifiziert).

Synology verhindert im Storage Manager offiziell die Konfiguration von NVMe-SSDs anderer Hersteller zu einem Volume, belegt aber deren Verwendung als Cache mit lediglich einer Warnung. Sogar die Speicherung von BTRFS-Metadaten im Cache ist mit nicht-zertifizierten SSDs möglich.

Unter dem technischen Aspekt, befindet sich in Cache oberhalb des eigentlichen Volumes, ein zusätzlich konfiguriertes Volume mit einem RAID1 ist parallel dazu angeschlossen. Gibt es also mit dem NVMe-RAID1 Probleme, dann erwarte ich hier wenig bis keinen Einfluß auf andere Volumes, als wenn diese NVMe-SSDs als Cache dazwischen arbeiten. Im Worst-Case wären die VMs auf dem “nicht-supportetem” Volume weg, die wir aber mit Active Backup for Business sichern können.

Ich hätte ein anderes Verhalten im Storage Manager hinterlegt, bei 3rd-Party SSDs wäre eine Warnung beim Erstellen von Volumes angebracht gewesen, als Cache würde ich deren Nutzung unterbinden.

To Cache or not to Cache

Diese Frage kann man nur differenziert beantworten und genau darum will ich das in einem weiteren Artikel beschreiben.

Damit erstmal viel Spaß mit dem neuen NVMe-Raid Winking smile

Enjoy it, b!

Synology SMB | Probleme mit Windows Juli-Updates (07/2023) | SecureChannel

Mit den Juli-Updates für Windows (10, 11 und Windows Server 2012R2 bis 2022), gibt es Probleme mit der Authentifizierung an einem Synology-NAS. Die sich wie im Folgenden beschrieben, äußern können.

Fehlerbilder (zumindest jene, die mir untergekommen sind)

  1. Windows meldet einen 3210, Netlogon Fehler mit dem Hinweis das die Authentifizierung mit dem “Windows Domain Controller” fehl geschlagen ist. In diesem Falle ist der “Windows Domain Controller” ein Synology NAS mit dem dem Synology Directory Server (Samba)


    image

  2. Die Anmeldung an einem Windows-System über Remote Desktop und konfigurierter NLA, funktioniert nur noch im lokalem Netz aber nicht mehr über das Internet

    image

  3. PowerShell meldet einen Fehler beim Test des SecureChannels zwischen dem Windows System und dem Synology NAS (das durch den Synology Directory Server als Domain Controller arbeitet

    Test-ComputerSecureChannel (Rückgabe = False), korrekt wäre hier True

    image

    Die Option –Repair funktioniert übrigens auch nicht

    image

  4. Der Zugriff auf Freigaben der Synology-NAS über den FQDN schlägt fehl oder ist nicht stabil

Ein Workaround aber keine Lösung, stellt die Deinstallation des Updates dar.

:: Deinstallation Juli-Update Windows 10 21H2/22H2
wusa /uninstall /kb:5028168

(für andere Windows Betriebssysteme, oben die entsprechende KB-Nummer einsetzen)

Hintergrund

Zum einen verwenden Synology und andere NAS-Hersteller Samba für die Implementierung des Dateidienstes (Fileservices) auf ihren NAS-Geräten. Da wird in der Regel nur angepasst, aber die Basis ist immer Samba. Dort ist das Problem in Form eines Bugs (15418) schon bekannt.

Genau genommen ist das aber kein Bug bzw. Fehler im eigentlichen Sinne, sondern eine noch nicht erfolgte Anpassung an die Strategie von Microsoft die Verwendung des Kerberos-Protokolls in Windows abzusichern. Dieses Ansinnen tut Microsoft aber nicht in dem entsprechenden KB-Artikeln zum Juli-Update kund, sondern erläutert die Roadmap explizit in KB5020805: How to manage Kerberos changes related to CVE-2022-37969

Samba als sagen wir mal Server-Komponente auf den NAS-Systemen, muss das neue verhalten der Windows-Systeme und des Kerberos interpretieren können. Was zumindest bis heute, noch keine offizielle Implementierung im SMB-Packet von Synology zur Folge hatte.

Die Lösung

Im Rahmen eines Support-Calls bei Synology war aber das Problem schon bekannt und man konnte mir mit einem “Private-Fix” des SMB-Services (SMB-Packets) weiterhelfen. Dieses Paket ist inzwischen auch zum Download über die englisch-sprachige Synology-Community erhältlich.

https://community.synology.com/enu/forum/1/post/161649

Ich bitte darum den Artikel dort ausführlich zu lesen und ggf. doch einen Support-Call bei Synology zu öffnen. Einfach aus dem Grund, da es für unterschiedliche DSM-Versionen und Prozessor-Architekturen der NAS-Systeme verschiedene Antworten gibt.

Bei mir hat das bereitgestellte und manuell installierte Paket die Probleme gelöst. Eine positive Rückmeldung an den Support von Synology ist ebenfalls erfolgt und darum hoffe ich, dass ein offizielles Update nicht zulange auf sich warten lässt.

Enjoy it, b!

Synology DSM | Selfhost DDNS

Das Synology DSM bietet die Möglichkeit einen DDNS Service Provider (DynDns) zu konfigurieren um damit die DNS-Auflösung des NAS im Internet zu ermöglichen. Oft wird ein DynDns gerne dem Router konfiguriert, es kann aber sinnvoll sein das alternativ auf einem Synology NAS zu tun. Zum Beispiel, wenn der Router eine entsprechende Konfiguration nicht erlaubt oder den eigenen DDNS Service Provider nicht anbietet.

Ich habe schon seit Ewigkeiten meinen DDNS / DynDns bei selfhost.de in Döbeln. Den Service kann man in einem Satz beschreiben. Er ist schnell, zuverlässig und stabil – die Hotline freundlich und sehr hilfsbereit, vor allem wenn man ein Problem nicht zu 100% verorten kann, wirklich super!

Damit man seine eigene DDNS-Domain von selfhost.de im Synology NAS eintragen kann, wird der DynDns-Account ganz normal bei Selfhost konfiguriert. Allerdings muss eine Option zusätzlich gesetzt werden. Die Authentifizierung läuft per HTTP (Basic Authentification) und nicht per GET, was der Standard bei selfhost.de ist (grüne Box im Screenshot).

image

Auf dem Synology NAS erfolgt der Eintrag im Control Panel / External Access / DDNS.

image

Die Konfiguration selbst ist einfach und selbsterklärend.

image

Hier noch das Mapping zwischen Synology und Selfhost.de in tabellarischer Form:

Synology Selfhost Wert/Beispiel
Hostname Hostname <i2fb02.ddns-domain.tld>
Username/Email Benutzername <Benutzername>
Password/Key Password <Das Passwort halt>

Läuft, wie man so sagt.

Enjoy it, b!

racknex UM-INT-001 | SBE Compute Unit

Langsam muss ich mir doch Gedanken über die Umbenennung dieses Blogs machen, eine Anregung war SBE = Small Business Environments, was mir persönlich sehr gut gefällt. Der SBS (Small Business Server) verliert mit jeder Migration bei meinen Kunden, für mich an Bedeutung und auch aus Sicht des Supports von Microsoft sind seine Jahre gezählt.

Zeit über neue Ansätze nachzudenken und wieder einen Artikel über meine Freunde in Österreich zu schreiben, hiermit beste Grüße an racknex und die erfolgreiche Verwendung der UM-INT-001 als Rackmount für meine SBE Compute Unit.

UM-INT-001

Credits und Copyright liegen bei racknex

“Für was brauchen wir den eigentlich noch die beiden Server?” Fragte mich ein Kunde, nachdem wir seine Datei- und Anmeldedienste (und alles andere, was ein Small Business Server Essentials 2012 R2 so macht) auf zwei Synology NAS Systeme migriert hatten. Sein Szenario sah zu diesem Punkt wie folgt aus:

  • VPN-Server
  • Anmeldedienste (Synology Directory Server) und DNS
  • Dateidienste (SMB/CIFS)
  • DHCP
  • Backup der Arbeitsplätze und virtuellen Maschinen (VMs)
  • Surveillance (für die Videokameras in der Werkstatt) sowie Cloud-Backup
  • Docker Container mit WSUS Offline Update

Das alles verbunden mit einem zweiten Synology NAS welches zusätzlich den Anmeldedienst aktiv absichert und ansonsten für die Replikation von Snapshots und die Sicherung des primären NAS zum Einsatz kommt.

Gut, natürlich wir haben ja immer noch die Server, die inzwischen nicht mehr viel zu tun haben. Dort laufen gerade mal drei VMs (virtuelle Maschinen), eine für das Management der Drucker, die zweite für das ziemlich schrottig programmierte Warenwirtschaftssystem sowie eine dritte mit einem virtuellen Desktop und Windows 11. Die Absicherung der VMs erfolgt zum einen durch das Active Backup von Synology und natürlich über eine Hyper-V Replikation. Aufgefallen sind die beiden Server vor allem, da sie einen besonders hohen Geräuschpegel verursachten, der besonders im Sommer ziemlich auf die Nerven ging.

Darum musste auch hier eine Alternative her und war durch einen Zufall schnell gefunden. Während der Suche nach Treibern auf der Intel Homepage bin ich auf einen Artikel gestoßen, dass Intel NUC Systeme (zumindest einige von ihnen) 24×7 betrieben werden können. Bei fast allen meiner Kunden laufen die PCs ohnehin 24×7 und das nicht nur 3 oder 4 Jahre, insofern hatte ich keine Probleme mit der Vorstellung das sowas auch mit einem Intel NUC möglich wäre und sogar, im Falle von Intel, unterstützt wird. Eine Analyse der auf den Servern vorgehaltenen Kapazitäten ergab, dass zwei Intel NUCs mit dem i5 der 11ten Generation sowie 32GB Hauptspeicher und einer 2TB NVMe ausreichen würden. Das Ganze hat Brutto keine 2.000 € gekostet und konnte mit dem Rackmount von racknex sauber in das Rack eingebaut werden.

UM-INT-001

Nach der Migration der VMs hatten wir (der Kunde und ich) zwei Aha-Erlebnisse.

  • Zum einen reduzierte sich die Temperatur im Serverraum um 5° und die Kühlung musste im Sommer nicht mehr aktiv sein
  • Der Intel NUC mit der NVMe war so schnell, dass die VMs bei einem Neustart des Intel NUCs sogar eine reconnect einer RDP-Session ermöglichten

Die Ausfallsicherheit wird nach wie vor durch die Hyper-V Replica und dem Microsoft Hyper-V Server 2019 sichergestellt und auch hier sichert Synology Active Backup die VMs.

Das Setup läuft nun seit 3 Monaten ohne Probleme, mit Crystaldiskinfo prüfe ich die NVMe Laufwerke und lasse mir einen Alert schicken, wenn sich gravierende Parameter ändern.

Damit stellen sich zum Schluss zwei Fragen.

  1. Wieso hast Du nicht den Synology Virtual Machine Manager und die beiden NAS Systeme verwendet?
  2. Brauchst Du jetzt keine “echten” Server mehr?

Zu 1. muss ich sagen, dass in diesem Fall zwei der drei VMs schon eine ordentliche Rechenleistung benötigen. Nichts mit High-End, aber mehr als üblicher Weise ein Atom oder Celeron-Prozessor von Intel liefern. Ein Setup analog zu den Intel NUCs auf den beiden Synology NAS Systemen hätte deren Kosten und vor allem auch deren Geräuschpegel deutlich nach oben geschraubt. Dazu stellen die Intel NUC Systeme eine einfach Exit-Strategie dar, sollte die Idee aus irgendeinem Grund nicht funktionieren, dann machen wir normale Arbeitsplätze draus und kaufen wieder “echte” Server.

Zu 2. Für genau diese Anforderung des Kunden reichen die Intel NUCs mit Hyper-V Replica definitiv aus, zumal wir ja auch eine ordentliche Datensicherung haben. Richtige und damit vor allem teure und laute Server werde ich nach wie vor verwenden, wenn die Option mit den Synology NAS Systemen und nur zwei bis drei kleineren VMs nicht besteht. Dann machen wir alles wie gehabt, erprobt und solide aber auch deutlich teurer und wärmer. Da wir aber im kommenden Winter nicht wissen, wie kalt es bei uns werden wird, kann der Kunde ja die alten Server als Heizung mitlaufen lassen Smile

Bis bald mal wieder und enjoy it, b!

Synology Directory Server | Passwort beim Zugriff auf ein Netzlaufwerk

image

An dieser Stelle möchte ich auf den vielleicht wichtigsten Artikel im Synology Knowledge Center hinweisen Smile

https://kb.synology.com/en-id/DSM/tutorial/domain_user_not_get_group_permission

Es geht hier um eine nicht korrekte Auswertung von Gruppenmitgliedschaften beim Zugriff auf ein Netzlaufwerk.

Technischer Hintergrund

Einem Benutzer in der Domain wird über ein Anmeldeskript (login.cmd) ein neues Netzlaufwerk verbunden. Die Vergabe der Berechtigungen dazu erfolgt relativ einfach indem der Benutzer Mitglied in einer dafür erstellen Gruppe in der Domain wird. Diese Gruppe hat wiederum entsprechende Berechtigungen auf dem Netzlaufwerk.

  • Sepp (Benutzer) – Mitglied in der Gruppe “_ SN Immobilien Users”
  • Die Gruppe “_ SN Immobilien Users” hat R/W-Zugriff auf den Share \\sn-nas-15\immo

Das Problem

Für das neue Netzlaufwerk, muss auf einmal im Fenster des Anmeldeskript ein Passwort angegeben werden, das funktionale Passwort von Sepp wird hier aber nicht akzeptiert. Es bleibt nur die Möglichkeit das Fenster zu schließen und damit die darauffolgenden Maßnahmen (weitere Laufwerke usw.) abzubrechen.

Das erwartete Verhalten wäre, dass Sepp durch seine Mitgliedschaft in der Gruppe “_ SN Immobilien Users” die entsprechenden Berechtigungen auf dem Netzlaufwerk besitzt. Durch seine neue Anmeldung, wird der Security-Token neu erstellt und die (neue) Gruppen-Mitgliedschaft fließt in diesen mit ein.

Die Lösung

Auf dem Synology NAS müssen die folgenden beiden Änderungen durchgeführt werden.image

https://kb.synology.com/en-id/DSM/tutorial/domain_user_not_get_group_permission

Der Windows Client muss wie folgt behandelt werden, wobei bei mir ein Neustart genügte.

image

Danach war das Netzlaufwerk über die passende Gruppenmitgliedschaft im Zugriff.

Update: Ein defektes Computerkonto, kann ebenfalls den Zugriff auf ein Laufwerk verhindern. Die Symptome sind dabei die gleichen, es wird ebenfalls nach einem Benutzer und Passwort gefragt und dieses nicht akzeptiert. Es genügt dann den PC aus der Domäne heraus- und wieder reinzunehmen.

Enjoy it, b!

Synology DS | Ausführen von WSUS Offline Update unter Docker

Auf dem Windows Small Business Essentials war bei mir immer der WSUS zur Aktualisierung der Server und Clients installiert. Das hat immer ganz gut funktioniert und ja ich gebe zu, es gab hier auf meinem Blog den einen oder anderen Artikel, der sich nicht immer positiv gegenüber dem WSUS gezeigt hat. Aber, letztendlich habe auch immer versucht eine Lösung zu meinem WSUS-Problem zu liefern.

Wird im Netzwerk, als Datenspeicher nur ein NAS, wie zum Beispiel eine Synology Diskstation (DS) verwendet, fehlt erst einmal die Möglichkeit einen WSUS zu betreiben und damit auch das zentrale Update der Server und Clients.
Schon seit langer Zeit habe ich zusätzlich zum WSUS für die Server gerne das WSUS Offline Update verwendet, welches wiederum als Community Edition (CE) auf GitLab verfügbar ist. Darüber hinaus existiert auf GitHub ein Docker Image, mit dem wiederum WSUS Offline Update in einem Docker Container ausgeführt werden kann.

Wie man so etwas angeht, soll dieser Beitrag beschreiben.

Voraussetzungen

  • Synology Disk Station mit der Unterstützung von Docker als Container Host
  • Das aus dem Synology Paket Zentrum installierte Docker-Paket

    image

  • Auf der Diskstation muss nun noch eine Freigabe erstellt werden, mit den folgenden Rechten und Eigenschaften

    image

    Ob man die Freigabe in der Netzwerkumgebung verstecken will oder nicht ist Geschmackssache, ich blende den Ordner immer aus, wenn die Installation der Updates exklusiv durch einen Admin oder automatisiert erfolgt und damit die Benutzer ihn nicht sehen sollen.
    Wird hingegen die Installation der Updates den Benutzern überlassen, dann sollte der Ordner eingeblendet werden.
    Darüber hinaus aktiviere ich die folgenden beiden Erweiterte Einstellungen

    image

    Dazu gebe ich der lokalen Gruppe users das Leserecht (Schreibgeschützt) und den Domain-Users ebenfalls.

    image

    Die Admins (lokal und Domain-Admins) haben ja per Default Lesen/Schreiben als Zugriffsrecht gesetzt.
    Dieser Ordner, also wsusoffline wird später in den Docker Container abgebildet.

Installation des Docker-Images

Nach der Installation von Docker, wird dieser gestartet, um das Image aus der Docker Registry herunterzuladen.

Dazu einfach ins Suchfeld R0gger (das ist der Entwickler des Images, 0 = Null) eingeben und Download klicken.

image

Wichtig ist hier die Auswahl der Community Edition (ce) um die aktuellste Version zu erhalten.

image

Die CE mit Auswählen bestätigen und der Download startet. Unter Image erscheint danach die 1, was den Download von einem Image signalisiert der nach ca. 250MB abgeschlossen ist.image

Konfiguration des Docker-Images

Durch einen Klick auf Starten wird das Docker-Image gestartet und dazu der Dialog zur Konfiguration aufgerufen.

Als Netzwerk verwenden wir die bridge und klicken auf Weiter.

image

Neben einem Automatischen Neustart, sind die Erweiterte Einstellungen interessant.

image

In den erweiterten Einstellungen werden die Laufzeit-Variablen für den Container festgelegt, Änderungen führe ich hier nur an den folgenden Variablen durch:

  • SYSTEM = w100-x64, w63-x64
  • OFFICE – löschen der Variabel, einfach aus dem Grund da alle meine Clients auf Microsoft365 laufen und die Updates aus der Cloud bekommen. Den Speicherplatz spare ich mir damit

image

Mit Speichern und Weiter, geht es dann weiter, wobei wir die Port-Einstellungen zu belassen wie sie sind und nur die Volume-Einstellungen konfigurieren müssen. Dort wird der Inhalt des Docker-Containers in die oben erstellte Freigabe wsusoffline gemounted.

image

  • wsusoffline = /wsus/wsusoffline

Mit dem Klick auf Weiter sind wir fertig und können den Container im Anschluss ausführen.

image

Running the Docker-Image

Damit kommen wir zum spannenden Teil, woher wissen wir eigentlich genau, ob wir alles richtig gemacht haben?

Läuft der Container, dann bietet uns die Option Details einen umfassenden Einblick was im Container vor sich geht.

image

Dort sind unter anderem der Ressourcen-Verbrauch, dass Mapping des Update-Ordners (wsusoffline) und die Laufzeitvariablen zu sehen.

image

Zwei weitere Punkte will ich hier nicht unerwähnt lassen. Zum einen habe ich mich schwergetan herauszufinden, wie den der Pfad lautet auf den der wsusoffline-Ordner gemapped werden soll?

Diesen habe ich in einer Terminal-Session ermittelt, dazu einfach unter Terminal eine Sitzung mit der Bash öffnen und nach dem Verzeichnis wsus im Root suchen.

image

Dort, also unter /wsus/wsusoffline werden die Updates gespeichert und dieser Ordner wiederum auf den wsusoffline-Ordner des NAS abgebildet, um den Zugriff über SMB zu ermöglichen.

Zuletzt habe ich noch mit einer Fehlermeldung gekämpft, und hierzu ein Paket (JSON-Processor) nachinstallieren müssen. Das geht ebenfalls in der Terminal-Session über die beiden folgenden Befehle.

# Installation des Pakets für die JSON-Interpretation
apt-get update
apt-get install jq

So, damit bin ich erstmal fertig und habe einen weiteren Schritt für eine alternative zum SBE beschrieben.

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!