NilsK

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

Moin, könnte denn ein Virenscanner das Problem verursachen? Verhält sich der Browser ohne diesen genauso? Gruß, Nils

Moin, fast. Lud wäre richtig. Aber meinst du, dass das weiterhilft? Gruß, Niös

Moin, und, hilft der Lösungsansatz, der in dem Mozilla-KB-Artikel angegeben ist? Gruß, Nils

Moin, ja. Gruß, Nils

Moin, gibt es auf der Seite mit der Fehlermeldung einen Link zu näheren Informationen? Das kann evtl. hilfreich sein, weil die Browser da teilweise unterschiedliche Ansichten haben, was ein Sicherheitsproblem ist und was nicht. Ist das Rootzertifikat auf einer eigenen CA erzeugt? Ist diese evtl. neu eingerichtet worden? In solchen Fällen hatte ich Kompatibilitätsprobleme des Firefox mit bestimmten Algorithmen festgestellt, so mag es der FF nicht, wenn man in einer Windows-CA die Option "AlternateSignatureAlgorithm" aktiviert. Hier könnte es also evtl. helfen, die Fehlermeldung genauer zu inspizieren und ggf. die Konfiguration der CA zu prüfen. Gruß, Nils

Moin, das würdest du nur um den Preis hinbekommen, dass die interne Namensauflösung nicht mehr bzw. nicht mehr zuverlässig funktioniert. Da man das normalerweise nicht will, ist die Antwort: Geht nicht. Stell sicher, dass die internen DNS-Server ausreichend verfügbar sind. Hintergrund: Theoretisch kannst du zwar einem Client einen internen und einen externen DNS-Server eintragen, sodass vordergründig deine Anforderung erfüllt ist. Sobald aber ein (Windows-) Client einmal auf den externen DNS-Server ausweicht und von diesem eine gültige Antwort bekommt, wird er weiter immer den externen fragen, auch wenn der interne wieder erreichbar ist. Damit würde der Client ab diesem Zeitpunkt keine internen Adressen mehr auflösen können. Gruß, Nils

Moin, mit "eine ADS" meinst du eine Active-Directory-Domäne? Die hat mit Freigaben und NTFS-Berechtigungen nahezu nichts zu tun. Das sind Dinge, die es auf einem Dateiserver gibt, nicht im AD. Deine Frage ist auch darüber hinaus etwas konfus. Wenn du wissen willst, welche Berechtigungen es gibt, musst du dir die Berechtigungen ansehen und nicht einen User erzeugen. Je nachdem, wie umfangreich das Dateisystem ist, können dafür Hilfsmittel wie tenfold interessant sein. Man kriegt das aber auch manuell durch Nachgucken raus. Oder halbautomatisch durch Berechtigungs-Reports, für die man auch kostenlose Tools findet. Vielleicht ist es im konkreten Fall auch einfacher, nur die Berechtigungen der Ordner anzusehen, an die der Praktikant nicht randarf, und diese bei Bedarf zu ändern. Oder die Holzhammer Methode: Man richtet eine Deny-Gruppe ein, der man ausdrücklich den Zugriff verweigert, und nimmt dort den Praktikanten auf. Gruß, Nils

Moin, ich stimme @testperson zu. Es gibt an einigen Stellen eben Unterschiede in den Features verschiedener Systeme. Der Versuch, sowas irgendwie nachzubauen, wird erfahrungsgemäß schiefgehen - sei es, weil es Nebenwirkungen gibt, sei es, weil beim nächsten Update der Nachbau nicht mehr geht. Als vor zehn, fünfzehn Jahren bei SMB-Kunden eine größere Umstiegswelle von Tobit auf Exchange war, gab es solche Themen dort auch. In solchen Fällen ist es praktisch immer besser, die Arbeitsweise anzupassen. Prüfen, was man am Ende wirklich erreichen muss und dann einen neuen Lösungsweg finden. Wenn man den emotionalen Teil erst mal überwunden hat, kommt man damit am besten klar. Gruß, Nils