NilsK

Moin, danke, lesen kann ich. Was du aber nicht geschrieben hast, ist der Grund dafür. Was willst du damit erreichen? Du musst uns dazu auch nichts sagen, aber dann können wir Fragen nach der Sinnhaftigkeit auch nicht beantworten. Gruß, Nils

Moin, auch hier rate ich, die Umgebung im Blick zu behalten. Vier VMs plus ein Host für fünf User? Das ist doch nicht angemessen. @LinderA gerade in so einer kleinen, oder nennen wir es: kompakten Umgebung kann man viel falsch oder sehr ungünstig machen. Ich an deiner Stelle würde jemanden beauftragen, der sich mit der Technik und mit solchen Kleinstumgebungen auskennt. Gruß, Nils

Moin, nein, das ist nur ausgesprochen selten deaktiviert. Das moderne Web funktioniert nicht ohne Javascript. Ob es gescheit ist, können wir nicht sagen - du hast ja nicht gesagt, was du vorhast und warum du dieses Verhalten haben möchtest. Gruß, Nils

Moin, naja, ein geeignetes Abschlussprojekt musst du dir schon selbst suchen. Und einen Ansprechpartner dafür im Ausbildungsbetrieb auch. Viel Erfolg! Gruß, Nils

Moin, FISI-Abschlussprojekt? Also, dafür scheint mir das Szenario erheblich zu komplex zu sein. Überleg dir das, ob du dich bei den ganzen möglichen Stolperfallen nicht verhakst. Gruß, Nils

Moin, solche Subnet-Betrachtungen kann man deutlich vereinfachen, wenn man die bitweisen Operationen weglässt und einfach "nach Optik" vergleicht. Subnet-Masken haben (in binärer Schreibweise) immer zusammenhängende 1-Ketten, die ganz links beginnen immer, wenn in der Subnet-Maske eine 1 steht, gehört die entsprechende Stelle in der IP-Adresse (in binärer Schreibweise) zur Netzwerk-Adresse. Immer, wenn in der Subnet-Maske eine 0 steht, gehört die entsprechende Stelle in der IP-Adresse (in binärer Schreibweise) zur Host-Adresse. Man schreibt beides untereinander und vergleicht optisch. Kein Bedarf, im Kopf oder per Tool AND, XOR oder sonstwas durchzugehen, was für Menschen wenig intuitiv ist. Hier mal verdeutlicht mit "x" für 1 und "-" für 0: IP 192.168.56.1 /20 1100 0000 1010 1000 0011 1000 0000 0001 xxxx xxxx xxxx xxxx xxxx ---- ---- ---- IP 192.168.50.1 /22 1100 0000 1010 1000 0011 0010 0000 0001 xxxx xxxx xxxx xxxx xxxx xx-- ---- ---- Aus Sicht des ersten Hosts (mit der IP-Adresse 192.168.56.1 /20) ist der zweite Host also im selben Netz. Er wird versuchen, ihn direkt ohne Router anzusprechen. Aus Sicht des zweiten Hosts (mit der IP-Adresse 192.168.50.1 /22) ist der erste Host nicht im selben Netz. Er kann diesen also nicht direkt ansprechen, sondern müsste seinen Router dafür ansprechen. Je nachdem, wie dieser konfiguriert ist, klappt das dann oder auch nicht. (Dieses Ergebnis kam oben in diesem Thread bereits vor.) Deine XOR-Betrachtung verstehe ich nicht - sie ist, soweit ich sehe, fehlerhaft. Das liegt nach meinem Dafürhalten daran, dass Menschen nun mal mit XOR nicht intuitiv umgehen können. Mach es dir einfacher. Gruß, Nils

Moin, möglich ist vieles. Die Frage ist dann eher, was dieses Szenario eigentlich abbilden soll. Mehrere Domains in einem Forest, die alle dieselbe Struktur haben ... eher ungewöhnlich. Ist das eine Hosting-Umgebung? Gruß, Nils

Moin, owei, die Tabelle stammt aus einem uralten Artikel von Holger Schwichtenberg, würde ich sagen ... vergiss die lieber, damit schadest du dir mehr als du verstehst. Das geht weit am Thema vorbei. Also, versuch besser, vorne anzufangen statt irgendwo mittendrin. Schaff dir PowerShell-Grundlagen drauf, schau dir die Basics des AD und von LDAP an. Dann leg erst mal ganz simpel einzelne Objekte in einer einzigen Domäne an. Versuch zu verstehen, was dabei passiert. Wenn du das kannst, dann nimm dir die Multi-Domänen-Struktur vor. Ein wesentliches Ziel solcher Aufgaben liegt darin, dass du dir ein sinnvolles Herangehen erarbeitest. EDIT: Die LDAP-Grundlagen für das AD habe ich hier mal im Überblick zusammengefasst: [LDAP-Grundlagen für Active Directory | faq-o-matic.net] https://www.faq-o-matic.net/2008/01/13/ldap-grundlagen-fuer-active-directory/ Gruß. Nils

Moin, ja, du hast ja Recht ... ich will auch gar nicht in Zweifel ziehen, was du sagst, oder mich mit dir um Details kabbeln. Hör ich jetzt mal auf mit. Worum es mir geht: Der TO hat sich von Klassen, Subnetting usw. auf unwegsames Gelände locken lassen. Das macht die Sache für ihn unnötig kompliziert. Zugegebenermaßen hilft es allerdings auch nicht, wenn man (wie ich) an der Stelle versucht, die Details technisch aufzudröseln. (Lass ich jetzt auch bleiben.) Für das Verständnis ist es nach meiner Erfahrung hilfreicher, wenn man erst mal von dem "wie es gehen sollte" her kommt und sich nicht zu früh mit Grenzen oder Fehlern beschäftigt. Dass zwei Netze sich überlappen, wenn man die Subnetzmasken unpassend setzt (wie es in den Beiträgen des TO ja teils dargestellt ist), ist technisch in IP möglich. Dabei kann die Kommunikation, wie auch schon angemerkt wurde, teilweise auch funktionieren - nur eben nicht mehr zuverlässig oder "immer". Am Ende sind solche Dinge dann meist Fehlkonfigurationen. Gruß, Nils

Moin, auch auf die Gefahr hin, mich als Erbsenzähler zu betätigen, aber ... nein. "Subnetting" gab es zu der Zeit, als die Klassenbereiche definiert wurden, noch nicht. Damals gab es eine statische Aufteilung des gesamten IP-Adressbereichs. Subnetzmasken brauchte man damals noch nicht. Für private Adressierung vorgesehen ist unterhalb von 192.168. nicht ein 16-Bit-Netz, sondern es sind 256 8-Bit-Netze, die jeweils direkt aneinandergrenzen. Je nach Perspektive mag das ähnlich aussehen, es ist aber ein grundlegender Unterschied. In der Zeit vor CIDR war damit das Netz 192.168.1.x ein in sich abgeschlossenes Netz mit 256 Adressen, das von dem Netz 192.168.2.x abgetrennt war. Die ganze Betrachtung mit /16, /24, Subnetting und sogar Subnetzmasken ist "jünger" und hat mit den damaligen Klassen eben nichts zu tun. Ein Klasse-C-Netz hat zwar 8 Bit zur Host-Adressierung, aber ein 8-Bit-Netz ist nicht einfach ein Klasse-C-Netz. Dass diese Begriffe auch 27 Jahre nach der Einführung von CIDR noch immer munter durcheinander geworfen werden, trägt eben zur Verwirrung bei. Und, wie gesagt, die Grafik, die der TO gefunden hat, verstärkt die Unklarheit noch. Sie ist zwar - aus einer Perspektive - sachlich korrekt, stellt die Zusammenhänge aber irreführend dar. Gruß, Nils

Moin, das ist jetzt eine Frage der Betrachtung. Dein Zitat sagt was anderes. Demnach sind es 256-mal /24. Wenn man es denn so schreiben will. Die 16 Bit beziehen sich auf den gesamten Bereich privater Netze, aber der unterteilt sich nun mal in 256 Blöcke zu je 8 Bit. Führt aber irgendwie nicht weiter. Außer dass es die Verwirrung zwischen "Classes" und CIDR fortsetzt. Zu der Zeit, als die "Klassen" festgelegt wurden, gab es aber nun mal CIDR und die Subnetzmasken noch nicht. Und seit mit CIDR gearbeitet wird (über 25 Jahre!), sind die Klassen faktisch obsolet. Gruß, Nils

Moin, du wirfst da Dinge durcheinander. Die Zeile mit 192.168.0.0 meint, dass alle Subnets, die mit 192.168. beginnen, zur "Class C" gehören - bzw. gehörten, denn die Class-Aufteilung ist seit vielen, vielen Jahren obsolet. Jedes einzelne Netz in diesem Bereich nutzt typischerweise (bzw. nutzte eben zur damaligen Class-Zeit) 24 Bits als Subnetzmaske. Von diesen Netzen gab es aber 256 Stück, die eben alle unterhalb von 192.168. lagen. Die Grafik beschreibt nicht die einzeln verwendbaren Subnets der "Klassen", sondern die Bereiche, die die Klassen zur Verfügung standen. Deine Interpretation dieser Grafik ist ein Missverständnis, das aber durch die (irreführende) Grafik provoziert ist. Da du offenbar gerade dabei bist, dir Grundlagen anzueignen: Verabschiede dich von dem "Klassen"-Konzept. Das ist Stand der Achtzigerjahre. "Klassen" waren festgelegte Netzwerkbereiche, in denen man eben keine Subnetzmasken hatte bzw. brauchte - weil die Größe des Subnets eindeutig durch die Klasse vorgegeben war. Gruß, Nils

Moin, die Frage ist doch, warum das überhaupt geschehen soll. Meine Vermutung: Auf dem Server, um den es geht, besteht kein Bedarf mehr an einem "echten" SQL Server und die Lizenz soll frei werden, um sie woanders zu nutzen. Also, unabhängig davon, ob es einen technischen Weg gibt, der theoretisch ein direktes Downgrade ermöglicht (was ich immer noch bezweifle) - die Versionen unterscheiden sich so stark, dass ich keine Experimente vornehmen würde. Ich würde die Datenbank(en), um die es geht, sichern, dann den SQL Standard deinstallieren und dann den SQL Express installieren. Backup wiederherstellen, fertig. Das dauert vielleicht zwei Stunden. Ein Downgrade-Versuch würde nicht viel schneller gehen, dafür aber ein (aus meiner Sicht erhebliches) Risiko des Scheiterns enthalten, und dann dauert es viel länger. Gruß, Nils

Moin, Geht es denn mit dem SID eines Users? Wenn nein, arbeitet die Methode nicht mit SID. Wenn ja, muss es ja doch an der Gruppe liegen. Was sind denn die Eigenschaften der Gruppe? Gruß, Nils

Moin, Hab ich doch schon mehrfach gesagt. Ich würde einfach direkt den Gruppen die Berechtigungen auf die vorhandenen Views geben. In dem kleinen Umfang, den du beschreibst, reicht das doch völlig aus. Dazu dient das Kommando GRANT, wie auch schon gesagt. Gruß, Nils

Moin, Und wenn du das Skript als User aus der Zieldomäne ausführst? Gruß, Nils

Moin, Falscher Gruppentyp? Gruß, Nils

Moin, ich stolpere darüber, dass du die NetBIOS-Schreibweise für den Namen mit dem DNS-Domänennamen verwendest. Das funktioniert manchmal, aber manchmal auch nicht. Ich nehme mal nicht an, dass der NetBIOS-Name "DomB.local" ist, sondern eher "DOMB", oder? Ansonsten würde ich persönlich Berechtigungen per Skript nur mit SetACL setzen. Vielleicht wäre man da aber auf dasselbe Problem gestoßen. Gruß, Nils

Moin, das ist für den Betrieb als Host ja auch nicht nötig. Seine VMs startet er dann trotzdem. Nach ein paar Minuten gibt es dann also wieder AD und DNS. Und dafür hat man den Vorteil, dass man den Host über das AD konfigurieren und verwalten kann. Um aber vielleicht noch mal auf den Ursprung des Threads zurückzukommen: Man darf hier durchaus mal die Größe des Netzwerks in den Blick nehmen. Es sind weniger als 10 User. Zwischendurch wurde hier ein Vorschlag diskutiert, der von mindestens fünf zu verwaltenden Servern ausgeht. Nicht so richtig angemessen ... Gruß, Nils

Moin, vermutlich kann man technisch Nano auch für Nicht-Container verwenden, es wird eher eine Supportfrage sein. Microsoft entwickelt das einfach nicht mehr für andere Zwecke weiter. Gruß, Nils

Moin, soweit ich weiß, ist für Nano die Software Assurance nötig. Das liegt daran, dass Nano eben keine normale Installation ist, sondern immer auf dem aktuellen Service-Release neu installiert werden soll. Und das braucht SA. Der Rest ist "normal", d.h. eine Standard-Lizenz gilt für einmal physisch oder zweimal virtuell. Edit: Was hast du denn vor? Nano ist ja vor allem als OS-Basis für Container gedacht. Für "normale" Server ist das ausgesprochen nutzlos. Gruß, Nils

Moin, eine Anleitung kann ich dir nicht geben. Konkrete Umsetzungserfahrung habe ich mit Schemas im SQL Server nicht - weil, wie ich vielleicht schon andeutete, nur selten Bedarf daran besteht. Als nächstes müsstest du jedenfalls deine Views in das Schema verschieben (mit ALTER SCHEMA sollte das gehen) oder diese dort anlegen, falls sie noch gar nicht existieren. Erst danach kannst du Berechtigungen vergeben. Oder, wie gesagt, du lässt den Umweg mit dem Schema einfach bleiben ... Gruß, Nils

Moin, das sind ja nicht nur verschiedene Editionen, sondern verschiedene Produkte. Das wird ohne Neuinstallation ziemlich sicher nicht gehen. Gruß, Nils

Moin, also, zunächst einmal ist das Papier ausdrücklich eine "Orientierunngshilfe" und keine Vorgabe. Ganz vorne steht ausdrücklich, dass man die konkreten Umstände in Betracht ziehen muss. Daraus folgt, dass es gerade nicht auf ganz konkrete Umsetzungen (wie etwa DNSSEC) ankommt. Oder einfacher: Anders als vermutet bzw. hier in dem Thread dargestellt, gibt es eben keine Verpflichtung, DNSSEC einzusetzen. In dem Kapitel, in dem es um DNSSEC geht, sind Voraussetzungen genannt, unter denen die Transportverschlüsselung ausreicht - die Formulierung ist aber (ziemlich sicher absichtlich) so, dass sie eben auch andere Lösungen zulässt. Damit will ich das nicht weg- oder kleinreden. Sollte sich aber im konkreten Fall zeigen, dass DNSSEC nicht geht, dann sind eben auch andere Maßnahmen möglich. Es ist kein Schwarz/Weiß (ist es bei der DSGVO auch nur selten). - Ob mögliche Alternativen praktikabler sind, steht auf einem anderen Blatt. Gruß, Nils

Moin, man wird das nur organisatorisch lösen können, aber eigentlich ist es ja einfach: Es gibt eine "endgültige" Datensicherung der VM. Die liegt im Tresor. Es gibt eine lauffähige Kopie der VM. Dort richtet man für die relevanten Applikationen Benutzer ein, die nur Leserechte haben. Falls es die "originalen" Benutzer sein müssen, ändert man deren Berechtigungen. Nur diese User können sich anmelden. Im wesentlichen war's das. Wenn jemand die VM kaputtgespielt hat, erzeugt man sie aus dem Backup neu. Optional könnte man, wie ich oben skizzierte, mit einem Snapshot-Verfahren arbeiten. Gruß, Nils