cj_berlin

Ja, so würde es gehen, aber ich würd's trotzdem nicht machen In Ruhe ein Cluster bilden und Failover testen können ist Gold wert.

Moin, um den zweiten Teil der Frage zu beantworten: Downtime musst Du schon einplanen. Besonders wenn - und das ist meistens zu bevorzugen - der Shared Storage tatsächlich als Block und nicht als File betrieben wird. Denn dann werden die LUNs als Cluster Shared Volumes betrieben, und die gibt es erst, wenn das Cluster gebildet wurde. SMB-Storage von einem Feld- und Wiesen-NAS würde ich persönlich nicht riskieren wollen, funktioniert aber, wenn das NAS einen SMB3-Dialekt spricht.

Moin, erstens, bei all seinen Verdiensten für die PowerShell-Community, ist nicht alles, was Adam Bertram sich überlegt hat, als "best practice" zu bezeichnen. Zweitens, es gibt sehr viele Entwickler, die zu PowerShell nicht von CMD/VBS/bash, sondern von C++/C#/etc. gekommen sind, wo starke Typdefinitionen vorgeschrieben sind. Diese Leute versuchen, das Bekannte auch in PowerShell durchzusetzen, meistens mit mäßigem Erfolg, weil PowerShell sich strikt weigert, ein "strongly typed language" zu werden. WENN Deine Funktion immer denselben Typ zurückgibt, kann es IntelliSense verbessern, wie Du auch bemerkt hast, wenn Du diesen auch in der Definition der Funktion angibst. Wer funktionale Programmierung lange und in großem Stil betrieben hat, wird vermutlich zustimmen, dass es an sich eine sehr gute Idee ist, wenn jede Funktion immer den gleichen Ergebnistyp zurückgibt. Das schreibt auch Uncle Bob irgendwo in "Clean Code", wenn ich mich recht erinnere. Nur ist es in Skriptsprachen in der Regel eher hinderlich, solche Restriktionen aufzuerlegen. Aber wenn Dein Skript- oder Moduldesign das hergibt, gibt es Dir ein zusätzliches Quentchen Sicherheit, wenn Du weißt, was Du von welcher Funktion zurück bekommst.

Wenn Du Windows Server-Workloads fährst, musst Du diese Lizenzen betrachten. Sollte es sich um so viele VMs handeln, dass Datacenter-Lizenzen bereits wirtschaftlicher sind als eine Anhäufung von Standard, kostet Dich das Windows-Cluster selbst mit S2D an Software nichts (zusätzlich). Wenn das oben aufgeführte NAS als Shared Storage für das Proxmox-Cluster fungieren soll, hast Du zwar Hochverfügbarkeit im Compute geschaffen, aber nicht im Storage. Das kannst Du mit einem Windows-Cluster auch genau so abbilden, selbst mit Standard-Lizenzen (die Du für die VMs eh brauchst). Kostet also an Software wieder nichts (zusätzlich).

Moin, auf dem DC listen diese Widgets, und auch NET USER, und auch Get-LocalUser, die Domain User auf. Das bedeutet nicht, dass sie auf dem DC ein Userprofil haben oder sich dort anmelden dürften. Insofern hast Du security-technisch vermutlich kein Problem, oder zumindest ist es nicht dadurch ersichtlich, dass diese User auf der Liste auftauchen. Mach GPRESULT /H auf dem DC und such nach der Einstellung "Diese Systemsteuerungssymbole einblenden" oder so ähnlich. Findest Du sie, dann wird daneben stehen, aus welcher Policy sie kommt.

OK, das sind zwei Fragen. 1. sind die User wirklich lokal oder sind das Domain-User? Falls es Domain-User sind, hast Du kein Problem. 2. warum ist das Control Panel-Widget aufrufbar? Da ist scheinbar wirklich eine Policy, die für DCs nicht gedacht war, auf diese angewendet worden. GPRESULT liefert Dir den Namen der Policy. Falls die User *wirklich* nicht Domain User sind, müsste man das troubleshooten.

Moin, da musst Du mal zeigen, wie das bei Dir aussieht, denn... wenn ein DC als DC ohne Einschränkungen funktioniert, ist die lokale SAM-Datenbank in der Tat nicht geladen

Moin, vielleicht übersehe ich etwas, aber wenn Höchstleistung eingestellt ist, wie kommt der Server dann in den Ruhezustand?

Nö, das geht in Richtung OSI-Modell und auf welcher Schicht eine Verbindung besteht.

OK, von WLAN hast Du nichts erwähnt. Bei einem Switch mit drahtgebundenem Ethernet wäre der Router egal, denn da spielen IP-Adressen keine Rolle. Mit WLAN könnte es aber im Bridged Mode eigentlich auch funktionieren.

Kannst ihnen ja IP-Adressen geben, die nicht um Subnet Deines Routers liegen

Innerhalb eines Forests ist UPN ein frei beschreibbares Feld (nur nicht mit ADUC/ADAC). Nur wenn Suffix Routing ein Thema wird, muss es in die Konfig. Natürlich packen wir es immer in die Konfig, wenn möglich, aber Kerberos innerhalb des Forests funktioniert auch ohne.

Moin, ketzerische Frage: braucht ihr die UPN-Suffixe der Kunden wirklich in der Forest-Konfiguration? So lange keine Cross-Forest-Authentifizierung im Spiel ist, kannst Du den userPrincipalName frei setzen, und innerhalb des eigenen Forests wird die Authentifizierung damit auch funktionieren.

Du meinst, Putzfrau stöpselt Server aus und Staubsauger ein?

Und bei LDAPS must Du prüfen, welche Systeme, die nicht Mitglied im AD sind, auf LDAP(S) zugreifen. Falls keine, kann die CA weg *und* Du brauchst gar kein Zertifikat auf dem DC, denn Domänenmitglieder brauchen kein LDAPS, siehe meinen Blog-Beitrag, der im zweiten Link oben verlinkt ist.

So hieß vermutlich die Syno des Entwicklers, der das SMB-Protokoll für die Syno-OS geschrieben hat.

Wieso? Du kannst alle FSMO-Rollen mit (drei verschiedenen) MMCs übertragen. Nur sollte man das nach Möglichkeit nicht tun.

Bei HOME_DS klingelt beim ganz ganz leise was... aber ich komme nicht drauf, in welchem Log oder Trace ich das schon mal gesehen habe. Ist es möglich, dass auf dem Gerät, das die Abfrage macht, irgendwelche Apps installiert sind, die nix mit Arbeit zu tun haben? Waschmaschinen-Steuerung, Luftqualität, sowas? LLMNR, falls nicht totgetreten, wird versucht, nachdem DNS fehlgeschlagen ist. Bedeutet vermutlich, dass der Versuch, HOME_DS per DNS aufzulösen, nicht in einem autoritativen NXDOMAIN gipfelte, sondern ergebnislos verhallte.

Ich habe keine Ahnung, aber bei APress glaube ich das eher nicht.

Jetzt könnte ich lässig auf mein Buch verweisen

Stop right there. So funktioniert AD nicht.

Moin, hast Du es denn versucht? Wenn Du einen 2022 promoten konntest, hat das ADPREP ja zumindest geklappt. Und die Kompatibilitätstabelle in Deinem Link ist ja unvollständig - die ist bei 2012R2 einfach abgeschnitten. So sah es in 2022 aus:

Ich glaube langsam, dass ALLES, was CISA, NIST und BSI verabschieden, auf der Vorstellung beruht, dass ein Hacker vor einer Anmeldemaske sitzt und Namen und Passwörter tippt...

Moin, deaktivieren, das DSRM-Kennwort kennen, beim Recovery zuerst im DSRM den RID-500 wieder aktivieren und dann im Recovery-Prozess damit arbeiten, falls und wo notwendig. Das ganze Thema akribisch dokumentieren, üben und die Dokumentation an einem Ort aufbewahren, den man ohne AD erreicht.

Wenn KEIN eigenes Zertifikat mit Private Key vorhanden ist, wird das Empfänger-Zertifikat verwendet. Die Mails wirst Du nie wieder entschlüsseln können.