NilsK

Moin, Dann ist iSCSI die bessere Option. Das Problem dürfte jetzt darin bestehen, dass beide Karten SMB machen. Gruß, Nils

Moin, wie greifst du auf das NAS zu? Per SMB oder per iSCSI? Wozu dient das Konstrukt? Greift nur die eine VM auf das NAS zu oder auch andere Geräte? Gruß, Nils

Moin, naja, dazu muss man ja erst mal durchsteigen, wie die Logik denn nun ist. Für einen Nicht-Insider ist das mittlerweile nicht mehr ganz einfach. Zumal die neue Handhabung mit den erstmals wegfallenden Elementen ja nun auch kaum noch nachzuvollziehen ist. In sofern kann ich die Nachfragen schon verstehen. Trotzdem ist es richtig, dass man ab einem gewissen Punkt die Dinge ausprobieren sollte, weil sie sich in einem Forum nur schlecht erklären lassen. Also: Testlab einrichten (ein DC als VM, je Client-Version eine VM, die wichtigsten Aspekte nachbilden - immer in einem Lab, nie in Produktion) und testen. Gruß, Nils

Moin, dann suchst du ja genau keinen MOC-Kurs. Wie die anderen schon sagten: Such dir einen Schulungsanbieter oder ein Systemhaus und besprich mit denen, was du willst. Das wird dann auf ein Angebot nach Tagessätzen hinauslaufen. Wenn der Anbieter gut ist, kann er mit dir im Vorfeld auch schon besprechen, welche Idee sinnvoll ist und welche weniger (mehrere Domänen etwa macht man heute nicht mehr, mehrere Standorte sind im Lab sehr aufwändig, Troubleshooting ist sehr relativ ... usw.). Dabei kann es helfen, wenn man sich vorher über das Ziel der Maßnahme ausführliche Gedanken macht, sonst artet sowas manchmal in "betreutes Herumspielen" aus. Gruß, Nils

Moin, um es mal etwas ausdrücklicher zu beantworten: Da du "nur" die ADMX für die Systeme benötigst, die du tatsächlich einsetzt, solltest du die Vorlagen auch von diesen Systemen nehmen und nicht separat herunterladen. Leider hatte es in der jüngeren Vergangenheit mehrfach veraltete Downloads bei Microsoft gegeben, die dann zu Anzeigefehlern bei der Administration führten. Offensichtlich fehlt hier die Qualitätskontrolle. Da ja aber jedes Windows-System die zur Version passenden Vorlagen mitbringt, ist es der bessere Weg, diese zu nehmen. Bei Windows 10 muss man, wie Norbert schon sagt, leider etwas genauer hinsehen, weil die laufenden Änderungen dort auch Einstellungsmöglichkeiten entfernen. Auch dort gilt aber, dass die mit dem OS (bzw. ggf. mit Updates) ausgelieferten, also quasi "installierten" Versionen vorzuziehen sind. Die Funktion der Richtlinien selbst wird durch die Vorlagen nicht verändert, sondern nur die Administrierbarkeit. Gruß, Nils

Moin, ja, das siehst du richtig. https://support.microsoft.com/en-us/help/231287/loopback-processing-of-group-policy Und das wurde dir in #7 ausdrücklich und bereits in #2 implizit gesagt. Aber gut, dass es jetzt gefunden ist. Gruß, Nils

Moin, bei solchen Mandantenlösungen rate ich dazu, ausreichend zu analysieren und zu planen. Da das AD von selbst nicht mandantenfähig ist (in dem Sinne, dass die Mandanten tatsächlich voneinander getrennt sind, also Kunde A nichts von Kunde B wissen darf), bedeutet das erheblichen Aufwand oder völlig andere Lösungen. Mit Standardwerkzeugen kommt man da fast nie weiter. Gruß, Nils

Moin, wir können weiter munter irgendwelche Stichworte in den Raum werfen. Ob die dann mit den Anforderungen des TO, mit den juristischen Rahmenbedingungen, die für ihn tatsächlich gelten, oder mit seinem Business irgendwas zu tun haben - oder ob sie überhaupt irgendwie auf irgendwas zutreffen, ist mittlerweile offenbar egal. Genausogut könnten wir jetzt auch aufwerfen, dass E-Mail grundsätzlich kein besonders geeignetes Kommunikationsmedium ist. Oder dass es nachts kälter ist als draußen ... Macht ruhig weiter, ich bin dann raus. Gruß, Nils

Moin, Frankfurt ist ja richtig, aber Leipzig nicht. Gut, aus hiesiger Sicht ist das beides genauso "im Osten" wie alles südlich von Kassel "im Süden" ist, aber ... Gruß, Nils

Moin, dazu müsstet ihr definieren, was denn "relativ befreit administrieren" heißt. Wenn jemand Software bzw. Updates installieren können soll, dann muss er Administrator sein. Ein Administrator ist ein Administrator und kann das ganze System und alle seine Komponenten manipulieren. Viele Kunden sind der Ansicht, dass es sich als Domänen-Admin durchaus "relativ befreit administrieren" lässt. Wenn ihr euch darunter anderes vorstellt, werdet ihr das definieren und dann ggf. ein bisschen mehr Arbeit aufwenden müssen. Man könnte sich ja z.B. die Frage stellen, warum sich denn jemand lokal anmelden muss, um Updates zu installieren. Es gibt da andere Möglichkeiten, wenn man sie braucht. Gruß, Nils

Moin, warum sollte er? Und wenn er es würde - die Gründe, die er dafür anführen könnte, würden auch auf lokalen Exchange-Betrieb zutreffen. Beim Datenschutz geht es nur um personenbezogene Daten, die man nur unter bestimmten Bedingungen speichern darf. Diese Bedingungen unterscheiden nicht zwischen Cloud und On-prem. Darfst du die Daten nicht in der Cloud speichern (weil du z.B. keine Einwilligung der Personen zum Speichern hast), dann darfst du es lokal auch nicht. Wenn du es hingegen lokal darfst, dann spricht fast nie etwas dagegen, die Daten bei einem vertrauenswürdigen Dritten zu speichern, der seinerseits ein paar Bedingungen erfüllt (was Microsoft sowohl in der "normalen" als auch in der "deutschen" Cloud tut). Ich verstehe die eine oder andere Skepsis, aber auf die Fakten sollte man schon achten. Nennen wir es Magdeburg. Gruß, Nils

Moin, wer administrative Rechte auf einem DC hat, hat diese auf jedem DC. Er ist dann nicht Domänen-Admin, kann sich aber zum Domänen-Admin machen. Ergo: Faktisch nicht umsetzbar. Gruß, Nils

Moin, wie Norbert schon richtig sagt, sollte man das nicht (nur) an den Kosten orientieren, sondern an den Anforderungen und den Nutzungsszenarien. Und dabei sollte man auch in den Blick nehmen, dass Office 365 ja viel mehr ist als Exchange. Ein Sharepoint etwa, der "einfach so" funktioniert, kann auch sehr interessant sein. Auch der Umstand, dass man keine eigene Infrastruktur für OWA und ActiveSync vorhalten muss, ist für manchen reizvoll. Von den zahlreichen Zusatztools, die nicht nur immer mehr, sondern auch immer besser werden, mal ganz abgesehen. Bei der Kostenkalkulation sollte man auch die Varianten mit Office-Lizenz durchrechnen. Auch das kann interessant sein - sofern man nicht "ich nutze mein Office 2000 weiter, bis es quietscht" als Vergleich heranzieht. Gruß, Nils

Moin, das ist erfreulich für euch, aber nach den Berichten, die ich dazu gelesen habe, würde ich der Technik nicht mehr vertrauen. Gruß, Nils

Moin, wieviele DCs gibt es denn? "An einem DC angemeldet" ist niemand von den Usern, daher gibt es da auch keine Übersicht. Die Anmeldung hat der DC bearbeitet, aber damit ist das für ihn abgeschlossen. Eine einfache Variante, an diese Information zu kommen, wäre ein Logonskript, das den Usernamen und den Logonserver irgendwohin schreibt, etwa auf ein zentrales Share. So hast du einen Anhaltspunkt, wessen Eventlog ggf. zu prüfen wäre. Vorsicht aber, das kann als Überwachung aufgefasst werden, ggf. den Betriebsrat einbinden. Fraglich ist aber, ob das hilft. Für mich klingt das Phänomen eher, als wäre bei der Datenübergabe an die Sophos-Software etwas nicht in Ordnung. Gruß, Nils

Moin, du hast den Vorgang noch nicht verstanden. Genau das, was du suchst, ist bereits implementiert. Ordne die Computer passend in OUs an oder erzeuge passende Computergruppen. Verknpüfe (und ggf. berechtige) ein GPO, in dem du unter "Benutzerrechte" festlegst, wer sich a.) ausdrücklich anmelden darf oder b.) ausdrücklich nicht anmelden darf. Alternative: Du definierst pro Computer oder pro Computer-Typ eine Gruppe, die diejenigen Benutzer enthält, die sich anmelden dürfen. Diese Gruppe (und nur diese) definierst du dann per GPO und "Eingeschränkte Gruppen" als Mitglied der lokalen Gruppe "Benutzer". Wobei ich den ersten Weg praktischer finde. Kein Bedarf, an den Computern rumzumachen. Gruß, Nils

Moin, Löschen und neu anlegen? Wenn es dann noch nciht geht, müsste man sich das vermutlich mal direkt ansehen. Gruß, Nils

Moin, Shared VHDX funktioniert auf 2008 R2 noch nicht. Und in 2012 würde ich es nicht machen, weil es nicht ausreichend stabil ist. Aus dem Grund hat Microsoft in 2016 die Technik ja auch geändert. Viele (naja) Kunden sind von Shared VHXD auf iSCSI oder sogar vFC umgestiegen, weil es sonst nicht zuverlässig ist. Gruß, Nils

Moin, ja, das ist immer so das Problem ... die Leute beim Hersteller kennen es nur mit "Gott-Modus", daher ist das das einzige, was sie supporten. Muss man sich dann überlegen, wie man damit umgeht. Gruß, Nils

Moin, die IP-Adressen des Hosts haben mit den VMs nichts zu tun. Wenn der Host selbst nicht auf das iSCSI-Storage zugreifen soll, braucht er an dem vSwitch auch keine vNICs - dann schaltest du das Häkchen "Gemeinsame Nutzung ... zulassen" beim vSwitch ab. Damit verschwinden dann die vNICS im Host. Die VM bekommt dann eine vNIC, die an den iSCSI-vSwitch gebunden ist. Die konfigurierst du dann in der VM. Das hat, wie gesagt, mit der Netzwerkkonfiguration des Hosts nichts zu tun. [Hyper-V und Netzwerke | faq-o-matic.net] https://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ Wenn du die Redundanz auf diesem Weg herstellen willst (kann man machen, wäre konzeptionell aber evtl. noch mal zu prüfen), dann legst du pro Host zwei vSwitches an, einen für Port1 und einen für Port2. Die "gleichen" vSwitches (also die, die auf denselben Port im Storage zeigen) müssen auf beiden Hosts denselben Namen haben, also etwa "vSwitchSAN1" (auf beiden Hosts) und "vSwitchSAN2" (auf beiden Hosts). In dem Fall bekommt deine VM zwei neue vNICs, eine mit Switch1 und eine mit Switch2 verbunden. In der VM musst du über beide NICs dann MPIO einrichten. Hyper-V 2008 R2 ist technisch noch sehr eingeschränkt. Einen Cluster würde ich damit heute nicht mehr betreiben. Gruß, Nils

Moin, ohne die Software zu kennen: Es wird technisch mit Sicherheit ausreichen, die Berechtigungen gezielt zu vergeben. Müsste man nur wissen, welche ... Gruß, Nils

Moin, dann wäre zu erwarten, dass dazu etwas im Eventlog steht. Gruß, Nils

Moin, konzeptionell funktioniert das anders. Du würdest für die iSCSI-NICs jeweils einen virtuellen Switch erzeugen, also einen pro Host. Die Switches müssen bei beiden Hosts gleich heißen. Dann legst du für deine VM eine dedizierte virtuelle Netzwerkkarte an, die du innerhalb der VM konfigurierst. Das Failover funktioniert dann genauso wie bei normalen Netzwerkverbindungen. Wesentlich ist, dass die vSwitches auf allen Hosts gleich heißen (und dass darüber natürlich dieselben Ziele erreichbar sind). Ob dein Hardwarekonzept so passend ist, steht auf einem anderen Blatt. Und warum setzt du so eine uralte Hyper-V-Version ein? Gruß, Nils

Moin, beides wäre denkbar, ich habe da nichts Konkretes im Kopf. Wenn die Anforderung wichtig ist, würde ich sie als nächstes mit den Beteiligten näher zu klären versuchen und dann einen Lösungsansatz suchen. Gruß, Nils

Moin, wobei vermutlich ein externes Tool sinnvoller ist, weil bei solchen Anforderungen immer noch Spezialitäten zu erwarten sind. Gruß, Nils