NilsK

Moin, ja, genau solche Überlegungen meine ich. Man muss hier unterscheiden zwischen "es wird unbequem" und "das Unternehmen steht vor dem Ruin". Gruß, Nils

Moin, naja, wenn dev eine Unterzone zu eurer Domain ist, dann muss das ja auch. :) Gruß, Nils

Moin, ja, so eine Antwort habe ich erwartet. Die klingt für mich nach "aus dem Bauch beantwortet, aber nicht erarbeitet und geprüft". Solche Spontanantworten höre ich ständig von Kunden. Einer Überprüfung halten sie fast nie stand. Nach 30 Minuten steht euer Unternehmen vor dem Abgrund? Dann wäre Norberts Frage zu klären, wie ihr bislang hingekommen seid. Und: Eine Lösung, die euch die 30 Minuten garantiert, würde in Budgetgrößen spielen, die vermutlich eurem Controlling die Tränen in die Augen treiben. Damit meine ich beileibe nicht nur die Infrastruktur, sondern auch die Personalkosten, die das bedeuten würde. Meine Empfehlung: Lasst euch eine Woche mehr Zeit und macht einen moderierten Workshop, um die tatsächlichen Anforderungen herauszufinden. Danach habt ihr dann eine Grundlage, um Lösungen zu entwerfen und das Budget festzulegen. Gruß, Nils

Moin, dann schau dir deine Kommandos doch noch mal an: Du setzt das Flag bei allen Usern, deren Kennwort 90 Tage alt ist. Und dann setzt du das Flag mit demselben Filter zurück - der jetzt aber eine andere Menge zurückgibt, weil das erste Kommando ausgeführt wurde ... Oder deutlicher: Die User, die du mit dem ersten Kommando behandelt hast, haben keinen Wert mehr bei pwdLastSet. Sie fallen durch den Filter deines zweiten Kommandos. Skripte und Massenoperationen testet man im Lab, nicht in der Produktion. Gruß, Nils

Moin, Browsercache löschen? Was dein DNS betrifft: Ganz offenkundig gibt es dort noch den Eintrag, es ist aber kein A-, sondern ein CNAME-Record. Gruß, Nils

Moin, hier hat er es erklärt: http://www.mcseboard.de/topic/207806-kennwortrichtlinie-im-ad-durchsetzen/?do=findComment&comment=1308180 Gruß, Nils

Moin, Storage-Replikation kommt erst mit Windows Server 2016. HP StoreVirtual ist schon eine klasse Sache, aber muss es denn repliziertes Storage sein? Wäre ein einfaches SAN nicht ggf. eine günstigere Alternative? Gibt es Betrachtungen in eurem Unternehmen, wie die Anforderungen an die Verfügbarkeit tatsächlich aussehen? Gruß, Nils

Moin, bei den Empfehlungen von Microsoft muss man den Kontext beachten: Es geht um massenweise Accounts für Privatuser. Die Studie basiert auf Microsoft-Accounts. Für Unternehmensumgebungen ist daher nicht alles so anwendbar. Besonders relevant sind die Punkte 4 bis 7 der obigen Liste. So stellt Microsoft das in dem Papier auch dar. Für die Punkte 1 bis 3 gibt es eine spezielle Argumentation, die vor allem mit der erwartbaren Bequemlichkeit von Anwendern zu tun hat. Als wichtigstes Element stellen die Forscher Punkt 4 heraus - wie Norbert schon anmerkt, gibt es dafür aber gar keinen Mechanismus, solange man keine Drittanbietersoftware einsetzt. Bei Punkt 1 neige ich zum Widerspruch. Es lässt sich zeigen, dass längere Kennwörter durchaus "per se" besser sind als kürzere. Die Einschränkung macht die Studie wieder bei der Bequemlichkeit von Usern, die dazu neigen, auch lange Kennwörter vorhersagbar zu setzen. Gruß, Nils

Moin, du gibst dem User in der OU das Recht, Objekte vom Typ "contact" zu erzeugen (und vermutlich auch zu bearbeiten). Gruß, Nils

Moin, vorbereitend kannst du eine Abfrage mit OldCmp machen. Das kann auch User abfragen und gibt u.a. das Datum des letzten Kennwortwechsels aus. oldcmp -users -report http://www.joeware.net/freetools/tools/oldcmp/index.htm Norberts Vorschlag ist auch nicht der Holzhammer, sondern der Gummihammer. Man setzt alle Kennwörter einmal auf "abgelaufen" und löscht dann das Flag gleich wieder. Die Kennwörter haben in diesem Moment "jetzt" als Änderungsdatum. Danach gilt für alle User die im AD definierte Kennwortrichtlinie, d.h. du kannst exakt sagen, wann die Kennwörter ablaufen. Die User haben dann auch noch bis zu diesem Zeitpunkt Zeit. Gruß, Nils

Moin, komisch, das Argument kommt immer an der Stelle. :D Und, hat irgend jemand tatsächlich FT im Einsatz? Oder es auch nur mal im Einsatz gesehen? Und wenn: Funktioniert es so, wie man es sich gedacht hat? VMware FT ist superspannende Technik, die bis vSphere 6.x praktisch kein Einsatzgebiet hatte, weil die betreffenden VMs nur eine vCPU haben durften. Jetzt dürfen sie zwar vier vCPUs haben, aber praktische Relevanz hat das Feature immer noch nicht. Viele Kunden missverstehen es und sind dann enttäuscht, wenn man sie aufklärt. FT ist gedacht für einzelne VMs, für die es entweder keine andere HA-Technik gibt oder für die ganz spezielle Anforderungen bestehen. Es ist nicht gedacht für "ich mache mal alle meine VMs fehlertolerant". Ganz abgesehen davon, setzt FT eine ziemlich teure Lizenz voraus (es sei denn, das wurde mittlerweile geändert, würde mich aber wundern). FT braucht fast niemand, die meisten brauchen nicht mal Failover im Minutenbereich. Da stimme ich nahezu vorbehaltlos zu. Gruß, Nils

Moin, ich sag es mal so: Nach den Erfahrungen mit Windows 10 und ausgehend von der Unreife der TP5 würde ich nicht nur kein System von TP5-Basis anheben wollen, sondern ich würde auch nicht zu den ersten Anwendern von Windows Server 2016 gehören wollen. Jedenfalls nicht, solange es keinen ernsthaften Grund außer "naja, 2012 R2 lohnt sich ja irgendwie nicht mehr" gibt. Selbst wenn die Qualität des neuen Servers vom Start weg gut wäre (was zumindest nicht an jeder Stelle zu erwarten ist), kommen dann ja auch noch Drittanbieter ins Spiel: Backup, Virenschutz, Monitoring, Management ... und die brauchen meist auch noch ein paar Wochen. Gruß, Nils

Moin, ganz einfach: Das wird nicht gehen. Sobald sich zwei Domänen im selben Netz befinden (und spätestens, wenn sie Daten austauschen sollen), müssen NetBIOS- und DNS-Namen unterschiedlich sein. Warum soll der NetBIOS-Name übernommen werden? Mir fällt nichts ein, wo das sinnvoll sein könnte. DIe Aussage "das AD ist nicht mehr sauber und muss neu gemacht werden" zweifle ich hiermit an. Ich habe in den vergangenen 17 Jahren nur sehr wenige AD-Umgebungen gesehen, die sich nicht hätten reparieren lassen (und unter denen, die wirklich kaputt waren, waren die meisten absichtlich kaputt, weil Laborsysteme). Was genau haltet ihr denn für "nicht sauber"? Und wie groß ist die Umgebung? Gruß, Nils

Moin, nur damit ihr keine falschen Erwartungen habt: Im "Crash-Fall" gibt es keine Live Migration! Das ist bei allen Virtualisierern so. Bei Ausfall eines Hosts kann die Hochverfügbarkeit (also der Cluster; bei vSphere wäre das extra einzurichten) dafür sorgen, dass die betreffende VM auf einem anderen Host neu gestartet (!) wird. Live Migration (oder vMotion) setzt voraus, dass es allen beteiligten Systemen super geht. Daher ist Live Migration auch keine Technik für Ausfallsicherheit, sondern eine Management-Technik. Gruß, Nils

Moin, bitte keine Threads mit anderen Fragen kapern. Wir können das gern diskutieren, aber eröffne bitte einen neuen Thread dafür. Gruß, Nils

Moin, genau das ist die Lösung, jedenfalls nach Best Practice. DNS für eine AD-Domäne sollte immer (und ausschließlich) über die DCs laufen. Also muss auch ein Client, der die AD-DNS-Daten auflösen will, den AD-DNS nutzen. Die Internet-Namensauflösung erfolgt dann über Forwarder in den AD-DNS-Servern. Sofern das DNS in deinem Router DNS-Delegierung oder so etwas wie Conditional Forwarding beherrscht (was ich mal nicht annehme), könntest du dort eine Weiterleitung für "lab.local" auf die DCs einrichten. Dann ist die Namensauflösung auch über den Router korrekt möglich. Gruß, Nils

Moin, wieso? Waren die mal schlecht? Der "Overhead" ist zu vernachlässigen. Und Abhängigkeit von der Software hat man in jedem Fall. Der entscheidende Vorteil ist, dass man auf diese Weise die Detailkonfiguration per Software vornehmen und bei Bedarf auch im laufenden Betrieb ändern kann. Zudem würde "ein Team über alles" das Partitionierungsproblem vermeiden: Das Team hat (geeignete Datenströme vorausgesetzt, aber das ist bei Virtualisierung i.d.R. gegeben) eine rechnerische Bandbreite von viermal Gigabit, die man recht frei zwischen den verschiedenen Traffic-Arten aufteilen kann. Bewegt eines der "logischen" Netze keine Daten, dann ist auch die zugeordnete Bandbreite frei und kann von den anderen Netzen genutzt werden. Würdest du hingegen einzelne Karten "physisch" für einen bestimmten Zweck zuweisen, dann liegen diese einfach brach, wenn kein Traffic darüber fließt. Ähnlich wie bei der Partitionierung einer Festplatte: Ist auf einer Partition Platz frei, dann nützt das der anderen Partition, die gerade vollläuft, nichts. Richtet man die Platte als eine große Partition ein, dann ist man da flexibler. Gruß, Nils

Moin, das ist nachvollziehbar. Wir wollen hier auch nicht darauf drängen, Interna preiszugeben. Es geht uns um die Richtung, die wir aufzeigen wollen. Gern! Gruß, Nils

Moin, "den Nutzer" wirst du nicht erhalten können, wenn du die Domäne löschst. Die Profile und Daten der User bleiben aber auf den Rechnern erhalten. Von dort könntest du sie in die Profile der neu anzulegenden lokalen User auf den PCs übertragen. Vielleicht kann dir dies dabei helfen - ich habe es in so einem Szenario noch nie probiert, aber es könnte klappen: [benutzerprofile mit EasyTransfer migrieren | faq-o-matic.net] http://www.faq-o-matic.net/2010/02/05/benutzerprofile-mit-easytransfer-migrieren/ Gruß, Nils

Danke. Gruß, Nils

Moin, ein "AD-Admin" hat den einfach. Die Frage wäre höchstens dann relevant, wenn "AD-Admin" bedeutet, dass einzelne delegierte Rechte ausreichen. Genau das ist aber offenbar ungeklärt. @carnivore: auch hier kann ich Norbert nur zustimmen. Dein Ansinnen ist verständlich, aber für Lösungsansätze noch lange nicht weit genug definiert. Du musst also das tun, was in der IT sehr unbeliebt ist: Auf der organisatorischen Seite die Anforderungen klären. (Vielleicht sagte ich das auch schon.) Nur so zur Einordnung: Ich rede hier nicht von fünf Minuten überlegen und dann einen Halbsatz hinschreiben. Ich rede von Klärung - bei den meisten Kunden, die ich kenne, würde ich dafür eine Reihe von Meetings und dazwischenliegenden Arbeitsphasen erwarten. Gruß, Nils

Moin, okay, das heißt: Zunächst die Anforderungen konkretisieren. "Security stetig erhöhen" ist als Ansatz sinnvoll, beschreibt aber weder Anforderungen noch Maßnahmen. "Muss organisatorisch nicht sein" fällt in dieselbe Kategorie. Wenn dann eine Anforderung darin besteht, Kontendaten nur selektiv in den Regionen abzulegen, kommen grundsätzlich RODCs in Frage - oder eben ein völlig anderes AD-Design, das, wie Norbert schon richtig sagt, mit getrennten Forests arbeiten muss. Um das zu entscheiden, müssen die Anforderungen weiter konkretisiert werden. Gruß, Nils

Moin, tendenziell würde ich in deinem Setup ein Team über vier der sechs Karten machen und dann mit vNICs im Management OS (= Host-Ebene) arbeiten. In deiner Konfig hast du nur eine Karte für Cluster und LM, was einen SPoF darstellen kann und die Geschwindigkeit begrenzt, wenn du einen Host mal per LM evakuieren willst. Gruß, Nils

Moin, weil es gerade so schön passt und weil mein Vortrag oben erwähnt wurde: Gruß, Nils

Moin, ja, die AD-Datenbank ist pro Domäne immer vollständig. Die einzige Möglichkeit, die Replikation von Kennwörtern einzuschränken, sind RODCs. Deren Kernszenario sind zwar "kleine, weniger sichere Sites" (nicht Hub-Sites, das würde keinen Sinn ergeben), aber sie lassen sich auch für andere Zwecke einsetzen. Worin besteht denn die genaue Anforderung? Gruß, Nils