NilsK

Moin, ich war auch schon ganz erstaunt. Hilft jetzt bei der Lösung nur eingeschränkt, aber ein "typisches" Verhalten scheint mir das nicht zu sein. Gruß, Nils

Moin, liest du auch, was man dir schreibt? Ein letztes Mal versuch ich es jetzt noch. Diese Zeile ist fehlerhaft: Und: Aber das erste Exit ist immer noch drin. Da Exit sich eben nicht so verhält, wie du das vermutest, kann es immer noch sein, dass es das Skript beendet, wenn der Parser die Zeile liest. Sollte er nicht, weil die Bedingung nicht zutrifft. Der CMD-Interpreter arbeitet aber nun mal anders als eine echte Programmiersprache. Solange das Exit also drinsteht - und zwar genau an der Stelle, wo der Abbruch stattfindet -, brauchen wir an dem Rest nicht rumzumachen. Noch besser (und mittlerweile eine Frage der Höflichkeit) wäre es, wenn du uns endlich mal sagst, was du da eigentlich insgesamt vorhast. Warum machen wir ewig an dieser IF-Konstruktion in einem Batch rum? In der Zeit hätte man die Aufgabe vermutlich manuell längst erledigt. Oder man lässt das mit dem IF einfach und erzeugt den Task in jedem Fall neu, ist ja am Ende egal. Gibt es Gründe, das anders zu machen? Dann wäre es nett, wenn du uns das wenigstens mal skizzierst, denn dann können wir vielleicht sinnvoll zu einer Lösung beitragen, statt einfach nur rumzustochern. Gruß, Nils

Moin, Puh, du bist aber ne echt harte Nuss. Wie dein Code jetzt aussieht, soll ich raten, oder wie? Kann es sein, dass das Skript in dem umständlichen Befehl am Ende über den Versuch stolpert, die Variable AF aufzulösen, die du in der dritten Zeile fehlerhaft definiert hast? Gruß, Nils

Moin, Also du willst nicht erklären, was du machst. Gut, musst du auch nicht, ist ja ein freies Land hier. Das Problem ist mit Sicherheit das Exit. Das beendet dein Skript und den ganzen CMD-Prozess. Möglicherweise habe ich die Vermutung schon mal geäußert. Du könntest jetzt mal versuchen, das Skript ohne Exit zu bauen. Musst du aber auch nicht, da sind wir liberal. Übrigens ist die einzige Zeile in dem Skript, die was machen soll, völlig unnötig kompliziert. Die FOR-Schleife braucht es dort nicht. Gruß, Nils

Moin, also gibt "er" auch nicht das ECHO aus? Dann ist es das EXIT. Das führt eigentlich immer zu unerwünschten Folgen. Faustregel: EXIT gehört nicht in ein Batch. Was du jetzt noch nicht beantwortet hast, ist, was du da eigentlich machst. Ich sehe irgendwas von Scheduled Task und Systemkonto, kann mir aber keinen Reim drauf machen. Typischerweise kann man Probleme vom Typ "Geht nicht" besser lösen, wenn man weiß, worum es insgesamt geht. Gruß, Nils

Moin, was auch immer heißt - ich verstehe die Fehlerbeschreibung nicht. Ferner verstehe ich nicht, was du da eigentlich machst. Es wäre hilfreich, gäbest du an, was du denn eigentlich erreichen willst. Was mir auffällt: EXIT beendet nicht das Skript, sondern die ganze CMD-Instanz. Das ist fast nie gewollt. Wenn du nur das Skript verlassen willst: GOTO :eof Gruß, Nils

Moin. Was in dem Heft steht, ist völlig richtig, aber eben nicht vollständig. Die Anmeldung an der Domäne ist Voraussetzung dafür, dass man überhaupt Berechtigungen bekommen kann. Ohne Berechtigungen auf die Ressourcen nützt einem die reine Anmeldung aber nicht. Und eine Domäne kann man nicht nachträglich aus einem Forest entfernen. Auch umgekehrt kann man eine Domäne nicht nachträglich einem Forest (genauer: einem anderen Forest) hinzufügen. Du lernst Theorie? Gut, dann gehört das dazu, aber für Umsetzungen braucht man das Wissen nicht. Man muss das nur als Berater wissen, um Kunden zu sagen, dass sie das nicht tun sollen. Gruß, Nils

Drü däzi. Gruß, Nils

Moin, Ja, wir in der IT mögen eins wirklich nicht: Anforderungen. SCNR, Nils

Moin, in dem Fall braucht es keine weitere Lizenz, wenn ihr ein Server-OS als Client bereitstellt. Funktioniert meist super. Wenn es doch ein Client-OS sein soll, braucht es dazu eine eigene Zugriffslizenz, weil man Client-OS nicht einfach so virtualisieren darf und weil Client-OS nicht in der DC-Lizenz des Hosts enthalten sind. Eine normale Windows-10-Lizenz reicht nicht aus. Früher hieß diese Lizenz VDA, ist evtl. immer noch so. Gruß, Nils

Moin, zielführend ist es daher, wenn wir mal schauen, was der TO denn eigentlich erreichen will. @info@vision4d.de, wozu brauchst du denn die Liste? Welches Problem oder welche Anforderung willst du lösen? Gruß, Nils

Moin, vergiss einfach die Netzwerkumgebung. Die hat noch nie so funktioniert, wie es dir vorschwebt. Ob ein Rechner dort angezeigt wird oder nicht, hat auch nichts damit zu tun, ob er erreichbar ist. Gruß, Nils

Moin, lizenzrechtlich ist es meist günstiger, dafür kein Client-OS bereitzustellen, sondern ein Server-OS. Je nachdem, wie die Host-Umgebung lizenziert ist, braucht man dann gar keine zusätzlichen Lizenzen. Gruß, Nils

Moin, ah, OK, jetzt verstehe ich den Zusammenhang. Hätte er damals gleich Datacenter genommen, entstünde das Problem gar nicht erst. Ja, schwierige Situation. Meine Vermutung: Dazu ("deaktivierte Cores") wird man keine wirklich exakte, verlässliche Antwort bekommen. Tendenz: Lizenzier das, was physisch drin ist, dann bist du auf der sicheren Seite. Alles andere wird immer ein Fragezeichen haben. Gruß, Nils

Moin, bei 10 VMs 4000 Euro Unterschied? Das würde mich sehr erstaunen. Gruß, Nils

Moin, Dazu sei auch angemerkt, dass man eine Gesamtstruktur mit mehreren Domänen heute (= seit über 15 Jahren) nicht mehr "absichtlich" entwirft. Sie ist technisch möglich, aber es gibt keine Gründe, sie einzurichten (etwas vereinfacht gesagt, aber darauf läuft es hinaus). Solche Fragen sind also tatsächlich sehr theoretisch. Zu Frage 1 wäre also mindestens zu klären, wo denn die Anforderungen herkommen und was denn eigentlich erreicht werden soll. Dann kann man eine Lösung entwerfen. In der IT wird allzu oft von der Technik her gedacht, das führt aber oft in die Irre. Rein technisch hat Evgenij den richtigen Hinweis gegeben: das steuert man dann - wenn es denn so sein soll - über Berechtigungen. Auch bei Frage 2 wäre zu klären, was denn hinter der Anforderung steht. So, wir es da steht, ist es nicht zu lösen. Entweder man richtet das Schema (und die Exchange-Organisation) im bestehenden Forest ein oder in einem separaten Forest, was dann zusätzliche Konfigurationen erfordert. Beides hat Vor- und Nachteile. Gruß, Nils

Moin, sagen wir es so: Wenn man sich eine Windows-PKI mal genauer ansieht, spricht einiges dafür, das nicht selbst an der Backe zu haben. Gruß, Nils

Moin, sicher sogar. Ich verstehe auch, dass man das nutzen können will. Nur will Microsoft es offenkundig nicht mehr pflegen. Das ist eben eine übriggebliebene Komponente, hinter der sie eigentlich nicht mehr stehen, die sie aber auch nicht entfernen. So wie WINS. Gruß, Nils

Moin, wenn sie es wollten, hätten sie es schon getan. Ich gehe davon aus, dass von deren wichtigen Kunden niemand mehr diese Seite benutzt. Gruß, Nils

Moin, das glauben viele, ist aber falsch. Es ist so, wie Norbert und Evgenij sagen. Der Witz am Private Key ist, dass er privat, also geheim ist. Nicht nur in einer idealen Welt darf der nie den Rechner verlassen, auf dem er erzeugt wurde (höchstens als Backup). daher kann die CA den auch nicht erzeugen, denn dann kennte sie ihn ja und er wäre nicht privat. Die Aufgabe der CA besteht ausschließlich darin, den zugehörigen Public Key zu zertifizieren (also zu bestätigen, dass sie davon ausgeht, dass er zu der beantragenden Einheit gehört). Leider gab es in der Vergangenheit CAs, die das anders gesehen und ein Schlüsselpaar für Kunden erzeugt haben. Und leider haben das auch manche "Security-Komponenten" getan, die bei Enterprise-Kunden im Einsatz sind. Das ist ganz großer Käse und geht gar nicht. Aus demselben Grund sind auch Zertifikate, die auf mehreren Servern eingesetzt werden, M*st. Gruß, Nils

Moin, ich erwähne es ungern, aber nslookup ist immer noch das falsche Tool. Die ganzen "no such name" sind dort normal bzw. Absicht. Gruß, Nils

Moin, dieses Argument habe ich schon oft als wirklich ernst gemeinte Aussage gehört. Gruß, Nils

Moin, korrekt. [Never change a running system? Bullshit! | faq-o-matic.net] https://www.faq-o-matic.net/2008/02/20/never-change-a-running-system-bullshit/ Hier ja sogar ein besonders krasser Fall. Ach, und weil es bei jemand anderem vor Jahren so war, ist das bei dir auch so? Also, ich probierte jetzt erst mal Updates aus - der Aufwand ist doch deutlich geringer, als ein Board zu tauschen. Gruß, Nils

Moin, ja, der Artikel ist sehr laienhaft und überspielt mangelnde Sachkenntnis mit reißerischer Darstellung. Auch dies klingt ja kompetenter als es ist. Wie sollte man so einen Nachweis denn bringen? Ist ja nicht so, dass Mimikatz ins Eventlog schreibt, wenn es läuft. Und den Angriff erkennt man i.d.R. deshalb nicht, weil Mimikatz ja nun mal Lücken ausnutzt und die Kommunikation technisch betrachtet valide ist. Das Ändern des krbtgt-Kennworts wiederum ist eigentlich nur dann sinnvoll, wenn man während des Vorgangs sicher sein kann, dass der Angreifer nicht im Netz ist. Das ist nach einem Angriff in einer Offline-Phase der Fall - bei einem regemläßigen, prophylaktischen Wechsel aber eben nicht. Wenn ein Angreifer in der Situation drin bleiben will, lässt er sich vom ersten Wechsel benachrichtigen und hat dann genügend Zeit, vor dem zweiten Wechsel zu reagieren. Gruß, Nils

Moin, abgesehen davon, ist nslookup auch kein Tool, um die Namensauflösung zu prüfen. Damit fragt man die DNS-Datenbank ab. Das ist etwas ganz anderes. Und es arbeitet auch anders als der Client Resolver. Daher ist es manchmal interessant, aber meistens ohne Aussage für konkrete Probleme. [Wenn (und warum) nslookup unerwartete Ergebnisse zeigt | faq-o-matic.net] https://www.faq-o-matic.net/2014/02/12/wenn-und-warum-nslookup-unerwartete-ergebnisse-zeigt/ Gruß, Ni"ich erwähnte das vielleicht schon mal"ls