NilsK

Moin, bei Umgebungen mit einer "Handvoll" Objekten wäre ja auch eine Migration kein großer Akt. Bei mehreren Händen sieht das aber schnell anders aus. Und zufällig hast du exakt die Argumente genannt, die alle Kunden an dieser Stelle bringen ... Gruß, Nils

Moin, naja, dann wird alles Nähere zur Einrichtung ja sicher in der Doku des Herstellers stehen. Wie man das konkret einbindet, ist von System zu System im Detail unterschiedlich. Ist der Mailstore-Server denn vom Internet aus erreichbar? Nur dann kannst du mit Let's Encrypt sinnvoll arbeiten. Falls er nur intern erreichbar ist, nutze ein selbstsigniertes Zertifikat oder eins von einer internen PKI. Gruß, Nils

Moin, ein TLS-Zertifikat hat mit einer IP-Adresse nichts zu tun. Es soll ja bestätigen, dass der DNS-Name der richtige ist. Let's Encrypt ist ein vollautomatisiertes Verfahren für TLS-Zertifikate. Unterstützt Mailstore das denn? Wenn nicht, wirst du das nicht nutzen können, jedenfalls nicht ohne größeren Entwicklungsaufwand. Gruß, Nils

Moin, du willst deinem Browser nicht sagen, dass er ungültige Zertifikate ignorieren soll. Gruß, Nils

Moin, Mit "Surfen im Netz" meinst du jetzt nur die Website von dem Tool? Welche Details nennt denn die Fehlermeldung im Browser? Gruß, Nils

Moin, richtig gut sind erst erwartete Mails. Da biste nahezu machtlos. [Phished! - michael wessel Blog] https://www.michael-wessel.de/blog/2019/07/09/phished/ Gruß, Nils

Moin, korrekt. Die Unterscheidung zwischen Rolle und Berechtigungsgruppe lässt sich am besten umsetzen, wenn man zwei verschiedene Gruppentypen hat - eben die Globalen und die Domänenlokalen Gruppen. Dadurch wird die grundlegende logische Trennung noch deutlicher, als wenn man nur eine Namenskonvention nutzen würde (die man natürlich auch braucht). Ein weiterer Grund für die verschiedenen Gruppentypen: Domänenlokale Gruppen sollen explizit nur die Berechtigungen auf Ressourcen in der eigenen Domäne umfassen (also in dem Sicherheitsbereich, den man verwaltet). Daher können sie nur bei Ressourcen der eigenen Domäne eingesetzt werden. Globale Gruppen hingegen sollen absichtlich in anderen Domänen sichtbar sein, falls es mehrere gibt, weil sie organisatorische Zwecke erfüllen. Gruß, Nils

Moin, ich würde halt kein HCI empfehlen. Unterhalb einer bestimmten - ziemlich großen! - Größenordnung ergibt das schlicht keinen Sinn. Man halte sich vor Augen, dass "Hyperscale" das Vorbild war - die ganz großen Web-Rechenzentren. Nicht die mittelständische Umgebung mit einstelliger Host-Anzahl. Gruß, Nils

Moin, zumindest im Marketing sehen mehrere Anbieter das anders. Und Microsoft hat seinen ursprünglich nur als Bastelei vorgesehenen 2-Node-PoC auch zum offiziell unterstützen Produkt gemacht. Man mache sich dabei nichts vor: Solche Minimal-Aufbauten sind eigentlich gar nicht dafür gedacht, dass man sie kauft. Sie sollen nur den Kunden anlocken, damit er dann eine höherwertige Variante kauft. Typische Masche, kennt man von Discountern. Finger weg davon. Gruß, Nils

Moin, kurz: außerhalb von großen RZ-Aufbauten sehe ich für keine HCI-Variante einen sinnvollen Einsatzzweck. Das ist höchstens dann interessant, wenn man Bedarf hat, in großen Schritten zu wachsen. Nur dann hat man Vorteile von dem integrierten Building-Block-Prinzip. Von "Selbstbau-HCI" à la Windows-S2D oder VMware-vSAN würde ich in jedem Fall die Finger lassen - es sei denn, ich habe eine große Mannschaft, die das in der Tiefe selbst supporten kann. Und 2-Knoten-Systeme sind eine komplette Fehlentwicklung. Nicht umsonst haben die Pioniere wie Nutanix und Simplivity ursprünglich nichts unterhalb von drei Nodes verkauft. Ich habe vor Kurzem einen Vortrag genau zu dem Thema auf der Storage2Day gehalten, vielleicht gibt es dazu bald die Aufzeichnung online. Gruß, Nils

Moin, nur um es noch mal zu betonen: Nicht nur für Großunternehmen. Schon bei einem Unternehmen mit gerade mal gut 1000 Usern ist die Schwelle zu "kostet sechsstellig" schnell überschritten. Das kann dazu beitragen, dass so ein Unternehmen ins Schlingern gerät. Gut, wenn man das nicht machen muss. Gruß, Nils ... der durchaus mehrfach zu solchen Kunden fährt, um sie von sowas abzubringen. Meist erfolglos ... dann verdiene ich halt dran.

Moin, also ... in einem Blogartikel kann man natürlich nicht jedes Detail beleuchten und diskutieren, aber ich finde schon, dass mein Artikel alles enthält, was man zu dem Thema wissen muss. Ich gebe aber gern noch ein paar Ergänzungen. Technisch und auch aus Sicherheitssicht spricht erst mal nichts dagegen, für das AD denselben DNS-Domänennamen zu verwenden wie für die externe Webseite. Dadurch wird keine interne Ressource "aus dem Internet" erreichbar - das ist kein Thema für eine Firewall. Die Probleme liegen dann eher innerhalb des eigenen Netzwerks: Da das AD sich für diese Domain zuständig sieht, wird es alle DNS-Anfragen dazu selbst beantworten: www.meinedomain.de kennt das AD entweder nicht (dann erreicht man von innen den eigenen Webserver nicht) oder man muss die IP-Adresse des externen Webservers selbst eintragen. Ebenso für alle weiteren Hostnamen, die "draußen" verwendet werden. Das meint mein Artikel mit "zusätzliche Konfiguration". Kann man machen, ist aber nicht schön. Eine Subdomain umgeht dieses Problem, bleibt aber problematisch, wenn das Unternehmen mal den Namen wechselt. Und nein, das ist nicht exotisch. Ich betreue jedes Jahr mehrere Kunden, die sowas machen müssen. Die Kosten liegen typischerweise empfindlich im fünfstelligen, oft auch im sechsstelligen Bereich. Nur um den Namen zu ändern, ohne jede technische Verbesserung (die würde extra kosten). Lässt sich vermeiden, wenn man es gleich richtig macht. Warum man keine Domain nehmen sollte, die einem nicht selbst gehört, zeigt dieser Artikel an einem Fallbeispiel: https://www.faq-o-matic.net/2014/02/12/wenn-und-warum-nslookup-unerwartete-ergebnisse-zeigt/ In Kürze: Ich empfehle schon seit Jahren, nur noch mit abstrakten Namen zu arbeiten und sich einen Domänennamen zu suchen, der noch frei ist. Diesen registriert man, nutzt ihn aber im Web nicht - er ist also auch nicht identisch mit dem Webauftritt, sondern man registriert ihn nur für interne Zwecke. Das muss nicht mehr als zehn bis fünfzig Euro im Jahr kosten. Damit umgeht man alle genannten Probleme, weil man den Domänennamen selbst kontrolliert und weil der Name nicht vom Namen des Unternehmens abhängt. Gruß, Nils

Moin, soll der SBS als Server bestehen bleiben? Oder soll der sowieso weg? Falls er weg soll, kannst du ihn auch einfach abschalten und aus dem AD entfernen, ohne vorher dcpromo zu machen. Die Informationen im AD zur Zertifizierungsstelle könntest du danach aus dem AD löschen, wenn du sie nicht per Backup auf einen neuen Server übertragen willst (was man in SBS-Umgebungen so gut wie nie braucht). Gruß, Nils

Moin, ja, aber da gab es auch noch einen Buß- und Bettag. Gruß, Nils

Moin, ich finde auch, dass früher alles besser war. Nützt nur nix. Gruß, Nils

Moin, wenn es Gruppenrichtlinien usw. braucht, dann ist ein "normales" AD erforderlich. Also ein normaler lokaler DC oder eine VM in Azure. AAD oder AADDS reichen dann nicht. Falls das verzichtbar ist und man die Clients ggf. anders verwaltet, kann eine reine O365-Umgebung ausreichen, das hängt dann vom Kunden und seiner Arbeitsweise ab. Statt OneDrive "nativ" könnte man Dateiablagen auch über MS Teams organisieren, das kann ganz praktisch sein, wenn es passt. Gruß, Nils

Moin, noch ein ergänzender Gedanke: Ich weiß nicht, was da insgesamt der Vorgang im Hintergrund ist. Erfahrungsgemäß ist es aber oft so, dass man erst denkt, man müsse ja nur die Daten von einem Server zum anderen übertragen. Später merkt man dann, dass es doch noch weitere Datenbestände und Applikationen gibt. Vielleicht hilft es also, einen Schritt zurück zu machen und den Blick größer zu ziehen - und dann landet man vielleicht doch bei der Erkenntnis, dass man eine Site-to-Site-Verbindung braucht. Gruß, Nils

Moin, die Betrachtung ist in der rWdd* rein akademisch. Da betreibt fast niemand einen DC nur als DC. Da liegen immer noch irgendwelche Dateien, da nutzt jemand Sysvol als Verteilmechanismus, da sucht der Admin vom DC aus nach neuen Treibern ... Gruß, Nils * reale Welt da draußen

Moin, ohne dir zu nahe treten zu wollen - aber das ist doch jetzt Haarspalterei. Die Vermutung, dass es sich um eine Root Domain mit zwei DCs sowie eine Subdomain mit zwei DCs handelt. liegt jetzt nicht eben fern. Gruß, Nils

Moin, klingt auf einem Windows Server jetzt nicht viel weniger nach "von hinten durch die Brust ...". Ich denke schon, dass das mit IPSec zwischen den beiden Hosts klappen kann. Aber das ist eine reine Vermutung, mangels Bedarf hab ich sowas nie gebaut. Gruß, Nils

Moin, Probier es. Kann klappen, aber vermutlich gibt es kaum jemanden hier, der mit so einem Setup Erfahrung hat. Gruß, Nils

Moin, dabei wäre dann bei Gelegenheit vielleicht die Frage nach den Anforderungen zu klären. Auch in einem Lab fällt mir so recht kein Szenario ein, in dem es einen Grund gäbe, die DNS-Server nicht in Betrieb zu haben. Dazu wird der TO sicher mehr wissen. Die Proxy-Lösung würde voraussetzen, dass der Proxy per IP-Adresse angesprochen wird. Kann man machen, ist aber alles andere als schön. Und funktioniert nur für HTTP - der TO hat nicht angegeben, welche "externe Auflösung" er wozu braucht. Gruß, Nils

Moin, dann klingt das eher so, als wolltet ihr ein Site-to-Site VPN. Gruß, Nils

Moin, stimmt - und es hätte mit dem Thema dieses Threads auch nichts zu tun. Gruß, Nils

Moin, konkret ist das Erzeugen der Sites und das Zuordnen der Subnets ein notwendiger, aber nicht unbedingt hinreichender Schritt. Wichtig ist vor allem, dass die Clients wissen, zu welchem Standort sie gehören. In der Praxis sieht man immer wieder, dass noch weitere Subnets von den Clients genutzt werden, die keiner Site zugeordnet sind. Das führt dann zu dem Phänomen, das du beschreibst. Abhilfe ist in dem Fall relativ einfach: In den Eventlogs der DCs gibt es Meldungen, wenn Clients aus nicht zugeordneten Subnets kommen. Diese werden dann in einer Logdatei protokolliert, die man nutzen kann, um die fehlenden Subnets zu ergänzen. Parallel sollte man die DNS-Einträge der DCs prüfen. Es passiert immer mal wieder, dass diese nicht vollständig aktualisiert wurden und so ein DC am falschen Standort vermutet wird. Gruß, Nils