Jump to content

NilsK

Expert Member
  • Content Count

    13,921
  • Joined

  • Last visited

Community Reputation

771 Excellent

About NilsK

Webseite

Recent Profile Visitors

4,423 profile views
  1. Moin, OK. Also, die Subnets in der AD-Konfiguration sind symbolische Einträge, die mit dem "realen" Netzwerk nichts zu tun haben. Solange die vier /24-Subnets also der Konfiguration des "echten" /22-Netzwerks nicht widersprechen, brauchst du nichts zu ändern. Wichtig ist nur, dass ein Client (damit sind auch Mitgliedsserver gemeint) eindeutig feststellen kann, zu welchem AD-Standort ("Site") er gehört. Dass ein /22-Subnet heute eher nicht mehr als empfehlenswert gilt, steht auf einem anderen Blatt. Gruß, Nils
  2. Moin, möglich ist das, aber bevor wir Tipps geben, die gar nicht passen ... Gruß, Nils
  3. Moin, gut, wenn du alles schon konzipiert hast, kannst du uns ja ein paar Rahmendaten nennen. Ein Virtualisierungs-Host richtet sich im Sizing immer nach den VMs, die darauf laufen sollen. Wie viele VMs planst du? Wie viel RAM sollen diese VMs zusammengerechnet haben? Wie viel Plattenplatz sollen die VMs zusammengerechnet haben? Wie viele (virtuelle) CPUs sollen die VMs zusammengerechnet haben? Sind weitere Applikationen vorgesehen, die hinterher auf dieser Plattform laufen sollen? Was ist über diese bekannt? Wie planst du die Datensicherung umzusetzen? Sind erhöhte Anforderungen an die Verfügbarkeit zu erfüllen? Sind weitere Anforderungen an die Hardwareplattform zu berücksichtigen? Mit diesen Fragen solltest du den größten Teil des Sizings dann auch schon selbst bewältigen können. Was musst du denn genau im Rahmen der Aufgabe abliefern? Gruß, Nils
  4. Moin, wer oder was ist ADSS? Meinst du vielleicht ADDS, also Active Directory? Gruß, Nils
  5. Moin, dann ist es sicher wenig sinnvoll, wenn wir dir hier alles vorkauen, du sollst ja selbst was lernen. Zu konkreten Fragen können wir dir dann ggf. Hilfestellung geben, Wie weit bist du denn schon? Gruß, Nils
  6. Moin, das klingt nach einer Aufgabe im Rahmen einer Ausbildung, richtig? Gruß, Nils
  7. Moin, das möchtest du künftig ändern. Jetzt ist eine prima Gelegenheit. Gruß, Nils
  8. Moin, welche Version hat der Host? VMs würde ich nur mit WS 2019 betreiben, wenn der Host auch mit 2019 läuft. Ansonsten gilt eigentlich immer: Keine OS-Upgrades bei Servern. Einen DC hat man viel schneller neu erzeugt als einen bestehenden anzupassen. Und einen Terminalserver will man auch lieber neu machen und die Benutzer umstellen. Gruß, Nils
  9. Moin, OK. Danke für die Rückmeldung. Gruß, Nils
  10. Moin, der Rest sind jetzt ausschließlich organisatorische Fragen. Auch dein VPN erzwingt keine tagelangen Wartezeiten - heute richtet man üblicherweise zwischen Standorten ein Replikationsintervall von 15 Minuten ein (das ist das Minimum), mit ein bisschen Kontrolle usw. reichen also 30 Minuten oder so zwischen den Vorgängen. Wenn du Skripte usw. hast, die einen DC-Namen enthalten, dann gibt es eigentlich nur zwei Möglichkeiten: Die Skripte machen Dinge, die nicht auf einen DC gehören. Dann umstellen auf ein anderes System. Die Skripte sprechen das AD an. Dann sollten die den Namen der Domäne nutzen,* nicht den eines DCs. Dahinter steckt ein simples Round Robin, das in aller Regel ausreicht und von konkreten Servernamen unabhängig ist. Und FSMO-Rollen sind in Wirklichkeit praktisch unkritisch für nahezu alle Situationen. Sie erfordern so gut wie nie andere Vorgehensweisen. Übertragen und gut. Da gibt es viele mythische Vorstellungen. [AD: Betriebsmaster-Ausfall – was tun? | faq-o-matic.net] https://www.faq-o-matic.net/2010/09/09/ad-betriebsmaster-ausfall-was-tun/ Gruß, Nils PS. * noch schlauer ist es, Skripte so zu bauen, dass sie nicht mal den Domänennamen enthalten, sondern diesen auslesen bzw. aus Umgebungsdaten ableiten.
  11. Moin, da sich deine DCs ja alle am selben Standort befinden, brauchst du nicht so lange Wartezeiten. Man kann das alles in einem Rutsch machen und zwischendurch halt Kaffeepausen einplanen (wenn überhaupt). Ein Tag für alles würde dicke ausreichen. Was den Namen anbelangt: Wenn du das wirklich willst (ich halte nichts davon, weil es ungünstige Abhängigkeiten festschreibt), dann kannst du zum Ende deiner Liste den Namen des DCs ändern, wenn du vorher den alten entfernt (oder ebenfalls umbenannt) hast. Wann du das wiederum tust, ist praktisch ausschließlich eine organisatorische Frage. Ich lese jetzt aber nur noch von einem DC, wolltest du nicht zwei tauschen? Gruß, Nils
  12. Moin, Azure AD ist kein Ersatz für ein lokales Active Directory. Auch die Azure AD Domain Services sind das nicht. Das erste hat nahezu nichts mit einem AD zu tun, das andere bietet nur rudimentäre Dienste. Der Rest hängt von den Anforderungen ab. Aber ziemlich sicher werden die meisten Firmen, die größer als ein neues Start-up sind, auf mittlere Sicht auch weiterhin ein "herkömmliches" AD brauchen. Gruß, Nils
  13. Moin, und nur mal der Vollständigkeit halber: TLS ist immer "mit Zertifikaten". Die technische Sicherheit unterscheidet sich auch nicht zwischen selbstsignierten, internen CA-Zertifikaten und kommerziellen Zertifikaten, da ist keins "sicherer" als das andere. Unterschiedlich ist nur, wie den Zertifikaten vertraut wird. Gruß, Nils PS. wenn wir schon dabei sind: Eine Root-CA sollte natürlich einem Server kein Zertifikat ausstellen, das ist Aufgabe einer Issuing CA.
  14. Moin, "bitte im ganzen Satz" (Loriot) ... Hinter meinem Link befanden sich drei Möglichkeiten, die Rechte zuzuweisen. Um hier weiterzukommen, müsstest du also bitte angeben, was du genau gemacht hast: Welche Berechtigungen hast du wo gesetzt? Wie bist du vorgegangen, um das zu testen? Gruß, Nils
×
×
  • Create New...