NilsK

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

Moin, nein, so etwas sieht Outlook nicht vor. Gruß, Nils

Moin, was ist denn der Wunsch dahinter? Wenn man andere zu einem Termin einlädt und diese noch nicht darauf reagiert haben, dann wird die Terminanfrage dort automatisch als "mit Vorbehalt" im Kalender angezeigt. Gruß, Nils

Moin, was sagt denn dcdiag zu dem Thema? was heißt "die Replikation funktioniert zum größten Teil"? Was geht denn nicht? Das heißt genau was? Was hat "etwas geknallt"? Und was heißt "in Ordnung gebracht"? Mit folgender Kommandofolge kannst du einen DC veranlassen, seine DNS-Einträge zu erneuern. Ändert sich dadurch was? ipconfig /registerdns && net stop netlogon && net start netlogon Generell habe ich den Eindruck, dass ihr eure AD-Umgebung nicht ausreichend im Griff habt. Vielleicht wäre es ratsam, jemanden dazuzuholen, der sich damit gut auskennt. Gruß, Nils

Moin, das deutet darauf hin, dass es nicht an der richtigen Stelle verknüpft ist. Gruß, Nils

Moin, man kann die lokale Anmeldung auch per Gruppenrichtlinie steuern. Dort gibt es sowohl das Erlauben als auch das Verweigern (bei den Benutzerrechten auf Computerebene). Vermutlich das, was Norbert meinte. Gruß, Nils

Moin, solche Gehaltsübersichten sind noch weniger aussagekräftig als Langzeitwetterprognosen. Gruß, Nils

Moin, die Frage ist doch völlig uninteressant. Einen Cluster baut man ja nicht für den Normalbetrieb, sondern für den Fall eines begrenzten Ausfalls. Und in dem Fall bietet Round Robin eben nicht genügend Absicherung, weil zu erwarten ist, dass die Hälfte der Clients keine Verbindung mehr bekommt. Gruß, Nils