NilsK

Moin, leider ist das Thema Verschlüsselung deutlich komplexer, wie du ja auch schon an unseren Fragen merkst. Ihr solltet euch mit jemandem, der das Thema einschätzen kann, ausführlich beraten, um eure Anforderungen zu klären. Stellt euch darauf ein, dass es vielleicht nicht "die eine" Lösung gibt. Unterschätzt das bitte nicht - ich habe das schon so oft mit Kunden durch, dass man meint, das sei doch alles ganz einfach, und am Ende hat man entweder viel Geld für eine Lösung ausgegeben, die irgendwas verschlüsselt, aber nicht so, wie man es braucht - oder aber man bricht das Projekt ab, weil sich niemand die Mühe machen will, die Einsatzzwecke wirklich im Detail zu beleuchten. Gruß, Nils

Moin, schau an, danke für den Hinweis. Wobei sich der Wikipedia-Artikel redliche Mühe gibt, das Thema möglichst umständlich zu erklären ... Gruß, Nils

Moin, oha, da hab ich dir mit meiner flapsigen Anmerkung wohl auf den Fuß getreten. Das war nicht die Absicht. Entschuldige. Das allerdings halte ich für einen der großen Vorzüge einer Community - oder sogar für deren eigentlichen Sinn. Sicher, nicht jede Diskussion trägt direkt zur Lösung bei. Und manchmal schweift man ab. Aber es hat seinen Grund, warum wir in Diskussionen oft weitergehende Fragen stellen, den Hintergrund beleuchten oder den Zusammenhang kritisch betrachten wollen: Allzu oft hat ein Fragesteller nur die Details seines Problems vor Augen und ist darin gefangen. Er sucht dann Lösungen für diese Details, auch wenn diese das eigentliche Problem gar nicht lösen. Ein vollständiges Sicherheitskonzept kann dir in einem Forum niemand bieten. Der Hinweis, dass das Vorgehen, nach dem du ursprünglich gefragt hast, heute nicht mehr zielführend ist (in den Neunzigern hat man oft so gedacht und konnte das auch tun, weil die Sicherheitslage eine ganz andere war), ist aus meiner Sicht aber sinnvoll. Und grundlegende andere Hinweise hast du ja bekommen. Darum ging es. Und, zugegeben, den Spruch mit dem Sakko wollte ich einfach anbringen. Gruß, Nils

Moin, abgesehen davon ... wer verbietet denn heute noch den Internetzugriff? Das ist so Neunziger, da könnte man ja auch übergroße bunte Sakkos anziehen. Aber ernsthaft: Statt antike Vorgaben zu machen, die auf einem ebenso antiken Sicherheitsverständnis beruhen, wäre es sinnvoller, eine zeitgemäße Umgebung aufzubauen, die den Anwendern eine Umgebung gibt, mit der sie sinnvoll arbeiten können und die heutigen Sicherheitsansätzen entspricht. Gruß, Nils

Moin, wie wird denn in dem ersten, proplematischen Fall auf die Daten zugegriffen? Direkt aus dem Home Office per VPN? Dann läge die Ursache auf der Hand: natürlich dauern solche Netzwerkzugriffe über ein langsames Netzwerk erheblich länger, als wenn der Client das LAN verwenden kann. Gruß, Nils

Moin, das wäre erläuterungsbedürftig. So, wie es da steht, glaube ich es nicht. Gruß, Nils

Moin, Fassen wir zusammen: - du installierst den neuen Server mit einem Medium, das zu den vorhandenen Lizenzen passt - du machst den Server zum DC in der vorhandenen Domäne -du kopierst die Daten und ggf. Funktionen vom alten auf den neuen Server - du nimmst den alten Server außer Betrieb und entfernst ihn aus dem AD - du wechselst den Dienstleister, weil der aktuelle nicht die nötige Sachkenntnis hat Und wenn das Netzwerk größer ist als, sagen wir, 10 user, dann installierst du mindestens einen weiteren DC mit ordentlicher Lizenz. Gruß, Nils

Moin, so alt?! Gruß, Ni"Methusalem"ls

Moin, sehe ich auch so. Warum spekulieren, wenn man für 10 Euro oder so im Jahr Eindeutigkeit schaffen kann? Gruß, Nils

Moin, die AD-Domäne hat mit der Internetseite (im Sinn der Außendarstellung einer Organisation) nichts zu tun. Ob du das als technischen Grund ansiehst, musst du dir überlegen. Ansonsten stimme ich Norbert zu: Die Argumente sind hier alle genannt. Ob du sie übernimmst oder nicht, musst du dir überlegen (oder wer halt die Entscheidung dazu trifft). Gruß, Nils PS. um noch mal eine Zahl zu nennen: Eine AD-Migration geht selten günstiger vonstatten als "empfindlich fünfstellig", auch bei recht kleinen Umgebungen. Das kann auch locker sechs- oder siebenstellig werden. Ärgerlich für das Unternehmen und erfreulich für den Dienstleister, wenn der einzige Grund dafür der Name ist.

Moin, ich finde, wie sollten uns an diesem sehr halbseidenen Kram, der juristisch mindestens "grau" ist (oder woher haben die die Lizenz, dieses ISO zu verbreiten?) nicht beteiligen. Der Informationsgehalt dieser Artikel ist von Null kaum zu unterscheiden. Gruß, Nils

Moin, was ist denn überhaupt das Ziel des Ganzen? Ich sehe solche Konstrukte öfter, höre aber selten Gründe, die dafür sprechen. Gruß, Nils

Moin, da Microsoft schon mehrfach gezeigt hat, dass sie große Projekte geheim halten können, wenn sie wollen: Geh davon aus, dass solche "Leaks" und die damit zusammenhängenden Spekulationen Absicht sind. Das hat direkten Nutzen (im Gespräch bleiben) und versorgt auch die Medienpartner (die was "Neues" zu berichten haben - immer wieder "die 10 besten Tricks zu Windows" macht denen ja auch keinen Spaß). Gruß, Nils

Moin, aber um es noch mal ausdrücklich zu sagen: nenn die AD-Domäne nicht firma.de. Gib ihr überhaupt keinen Namen, der mit dem Namen der Firma zu tun hat. (Nein, du bist nicht der erste, der annimmt, dass sich der Name der Firma nie ändert. Und ja, sowas passiert viel häufiger, als Admins so denken. Die Firma, in der ich jetzt bin, hat das mehrfach hinter sich.) AD-Name = abstrakter Name, den man als Domain registriert hat, aber nicht "im Internet" verwendet. Gruß, Nils PS. zuletzt habe ich hier mit gebotenem Nachdruck darüber gesprochen: https://youtu.be/cTjYMeoN1QI (Minute 5:50 für die ungeduldige Zuschauerin).

Moin, naja, zunächst ist das erst mal Clickbait. Gruß, Nils

Moin, ich glaube, er will sagen, dass das Thema hier nicht hingehört. Gruß, Nils

Moin, wichtige Regel in der Softwarelizenzierung: Es gibt kein "so ist das immer". Besonders Oracle ist da schon sehr speziell. Microsoft und andere können sich auch gut absurde Regeln ausdenken, aber Ora schießt regelmäßig den Vogel ab. Gruß, Nils PS. meiner Interpretation nach gibt es in diesem Thread keine Frage mehr zu klären.

Moin, warum kümmerst du dich überhaupt um diese Ebene? Für die Praxis dürfte das in nahezu allen Szenarien völlig irrelevant sein, das wird eher so eine Geschichte à la "wir machen es, weil es geht" sein. Oder hast du eine bestimmte Anforderung, die du lösen musst? Gruß, Nils

Moin, also ... in Kürze dazu: Du bist auf dem falschen Dampfer. So einfach ist die Performancebetrachtung nicht. Du nutzt die falschen Werkzeuge und du ordnest Dinge falsch zu. Mir scheinen hier auch Host und VM durcheinanderzugehen. Mit KVM kenne ich mich nicht aus, was "anpinnen" ist, weiß ich nicht. Das Konzept gibt es bei Hyper-V nicht (und meines Wissens auch nicht bei VMware, jedenfalls nicht als ich mich zuletzt damit beschäftigt habe). Ich denke mal, dass es im Wesentlichen andere Bezeichnungen sind; vielleicht macht KVM hier auch was anders als andere Hypervisoren. Ist aber am Ende egal. Wichtig ist in der Praxis, dass man die VMs richtig einstellt. Und dafür sind die meisten Grundsätze übergreifend gültig und nicht besonders kompliziert. Gruß, Nils

Moin, für mich klingt das auch nach grundsätzlichen Missverständnissen. Um die eigentliche Frage zu beantworten: Unabhängig vom Hypervisor weist man die vCPU-Anzahl für VMs so zu, wie es die Anwendungen erfordern. Also so, wie man es bei den anderen Ressourcen auch tun würde. Einem virtuellen DC würde ich weder unter Hyper-V noch unter VMware und auch nicht unter KVM mehr als eine bis zwei CPUs zuweisen. Bei einem Datenbank- oder Terminalserver mehr, je nach den tatsächlichen Anforderungen. CPU-Overcommit ist in aller Regel kein Problem, da gehöre ich zu der Fraktion, die andere Erfahrungen hat als Evgenij . "In aller Regel" heißt dabei: Es kann natürlich auch Konstellationen geben, in denen man das bleiben lässt und nicht mehr als 1:2 oder gar 1:1 zuweist. Meine Erfahrung sagt aber, das ist die große Ausnahme. Gruß, Nils PS. wenn du es für Hyper-V genauer wissen willst - in dem Rheinwerk-Buch habe ich ein ganzes Kapitel über die Ressourcenzuweisung geschrieben. Das gilt, weil es um prinzipielle Fragen geht, ähnlich auch für andere Hypervisoren.

Moin, fein. Ist zu dem Thema des Threads noch was offen? Sonst sind wir ja fertig. Gruß, Nils

Moin, vermutlich deshalb, weil SQL Server beim Insert die 10 für den Monat und die 6 für den Tag hält. Gruß, Nils

Moin, das ist gut. Dann hat sich unser dezentes Drängeln ja gelohnt. Danke für die Rückmeldung, Nils

Moin, warum beides nicht ausgeführt wird, kann ich auch nicht nachvollziehen. Wie führst du das Skript denn aus? Läuft es evtl. in einem Host, der nur dann die Ausgaben anzeigt, wenn es keine Fehler im gesamten Ablauf gibt? Wenn es unbedingt die antike Technik sein soll und du nicht sagen willst, was damit geschehen soll, damit man es vielleicht insgesamt anders angehen kann, hier der klassische Artikel, der beschreibt, wie man genau diese Daten mit VBS abfragt: https://devblogs.microsoft.com/scripting/dandelions-vcr-clocks-and-last-logon-times-these-are-a-few-of-our-least-favorite-things/ Deinem Skriptcode nach zu urteilen, baust du aber nicht auf bestehendem Wissen auf, und dann ist es wirklich nicht zukunftsweisend, auf eine Technik zu setzen, die seit 15 Jahren nicht mehr entwickelt wird. Aber das sagten wir vielleicht schon. Gruß, Nils

Moin, ich mutmaße mal: Das Skript bricht wegen des Fehlers ab und gibt deshalb auch den Rest nicht mehr aus. @Nero2021 wir haben jetzt den klassischen Fall, dass du dich auf dein Detailproblem fokussierst, statt das übergeordnete Ergebnis in den Blick zu nehmen. Was soll denn mit den Daten geschehen? Wäre es vielleicht schlauer, sie zentral auszulesen statt vom Client aus? Gruß, Nils