NilsK

Moin, "don't feed the trolls". Gruß, Nils

Moin, alle detaillierteren Empfehlungen kann man seriös nur aussprechen, wenn man Anforderungen und Gegebenheiten genau betrachtet. Dazu ist ein Forum nicht geeignet. Besser wäre, wenn du dir jemanden ins Haus holst, der dich berät. iSCSI ist ein Protokoll für blockorientierten Zugriff, d.h. die komplette Steuerung des Dateisystems erfolgt durch den Server, der die LUN eingebunden hat. Das Storage-Gerät hat auf der Ebene keinen Zugriff. Vorteile guter NAS-Geräte gegenüber "vollwertigen" Windows-Servern können in einer einfacheren Handhabung oder in zusätzlichen Funktionen liegen (z.B. Redundanzaufbau, Snapshots usw.). Auch das ist dann eine Frage der Detailbetrachtung. Gruß, Nils

Moin, plonk. Gruß, Nils

Moin, ergänzend zu Dunkelmanns weitgehend sinnvollen Anmerkungen: Den physischen DC könnte man ausnahmsweise in der Umgebung durchaus die serielle Anbindung zur Zeiterfassung machen lassen (vorausgesetzt natürlich, die zugehörige Anwendung ist sicherheitstechnisch okay). Falls es über einen Umsetzer geht, würde ich das aber auch vorziehen. Gegen "NAS" ist nicht grundsätzlich etwas einzuwenden - kommt halt auf die Qualität des Systems an, da reden wir ja über eine Bandbreite von 100 bis 100.000 Euro. Auch gegen iSCSI ist nichts einzuwenden, da gilt aber derselbe Vorbehalt. Einen Scale-out Fileserver hingegen würde ich für die Umgebung derzeit eher nicht empfehlen. Damit gibt es noch kaum Erfahrungen im Markt, und dass man damit derzeit wirklich Geld spart gegenüber einem dedizierten Speichersystem, wage ich zu bezweifeln. Mag sein, dass das in 12 Monaten anders ist, aber momentan würde ich in dem geschilderten Netzwerk die Finger davon lassen. Ein Hinweis noch zur "Groupware": Nichts gegen Open-Source-Produkte oder Exchange-Mitbewerber, aber sobald man dort eine Fassung mit definiertem Support nimmt, sind die Kosten meist nicht wesentlich geringer als bei Exchange. Dafür hat Exchange den Vorteil, dass man dort sehr viele kompetente Partner am Markt findet. Gruß, Nils

Moin, "don't feed the trolls". Gruß, Nils

Moin, wenn das so wäre - glaubst du wirklich, dass ich dann nachfragen würde? :rolleyes: Leider hast du deine Beschreibung auch nicht im nötigen Detailgrad abgefasst, schade. Stattdessen hast du die ungenaue und verknappte Beschreibung noch mal verkürzt. Weder hast du die Berechtigungen genau angegeben (oder gibt es bei dir wirklich eine Gruppe "AD-Benutzer"? Wenn ja, wer ist da drin?), noch hast du beschrieben, wer genau was macht und was dann passiert. Wissenswert wäre z.B. mit welchen Applikationen da gearbeitet wird, wer genau angemeldet ist usw. So werde ich dir nicht helfen können. Vielleicht hat ja jemand anders eine Kristallkugel, die besser funktioniert als meine. Gruß, Nils

Moin, kontrollieren solltest du das auf jeden Fall - es ist aber sehr unwahrscheinlich, dass die Bindungsreihenfolge an dem Problem beteiligt ist oder dass sich dadurch was ändert. Diese Einstellung wird meist falsch verstanden. [Hyper-V Network Binding Order] http://www.altaro.com/hyper-v/hyper-v-network-binding-order/ Gruß, Nils

Moin, ich glaube dir, dass die Situation unangenehm und schwer durchschaubar ist, aber aus deiner Beschreibung lässt sich leider nicht mal entnehmen, wer was überhaupt versucht hat. Also bitte noch mal genau beschreiben: Welche Berechtigungen gelten genau auf Freigabeebene? Welche Berechtigungen gelten genau auf NTFS-Ebene? Mit welchem Konto gelingt genau welcher Vorgang? Mit welchem Konto schlägt genau welcher Vorgang fehl? Wie lautet die Fehlermeldung in der Situation genau? Gruß, Nils

Moin, um das Pferd mal von vorn aufzuzäumen: Das AD-Migrationsverfahren, das du hier andeutest, wird mit großer Sicherheit nicht funktionieren. Bitte lass dich von jemandem beraten, der sich in der Materie auskennt. Gruß, Nils

Moin, und wie viel RAM braucht die VM, die da übertragen werden soll? Die Ressourcen klingen so, als wären sie - unabhängig vom akuten Problem - zu knapp. Bedenke, dass jeder Clusterknoten alle VMs ausführen können muss, wenn sein Partner ausfällt. Gruß, Nils

Moin, stehen an der Quelle und am Ziel genügend RAM-Ressourcen für den Vorgang zur Verfügung? Vagen Hinweisen aus dem Web zufolge treten diese Fehlermeldungen dann auf, wenn der Migrationsvorgang länger braucht als erwartet. Gruß, Nils

Moin, aber nur, wenn sie nicht Exchange nutzen, oder? Gruß, Nils

Moin, neben der Bootreihenfolge musst du in der Konfiguration der VM die DVD verbinden. Das kann das Laufwerk des Hostservers sein oder eine ISO-Datei. Die DVD bzw. das ISO muss für den Zweck bootfähig sein. Dann sollte es klappen. Gruß, Nils

Moin, da bist du jetzt aber auch schon auf einer sehr hohen Komplexitätsebene ... hast du die Grundlagen von Exchange denn schon ausreichend erarbeitet? Und: Was genau meinst du mit "Einen schnellen und schönen dedizierten Server mit eigener IP"? Ist der Server etwa direkt ans Internet angeschlossen? Das Thema mit den Adressbüchern ist eigentlich im Web sehr gut dokumentiert, daher solltest du dir die Grundlagen erst mal aus den vorhandenen Quellen besorgen (ein Stichwort ist "Address Book Policies"). Wenn du dann konkrete Fragen hast, helfen wir gern. Gruß, Nils

Moin, selbst wenn es ginge, müsstest du die Trennung in Exchange ja ohnehin einrichten. Und das kannst du jetzt auch tun. Gruß, Nils

Moin, ich würde dafür Excel nehmen. [Excel: Admins unbekannter Liebling | faq-o-matic.net] http://www.faq-o-matic.net/2008/01/19/excel-admins-unbekannter-liebling/ Gruß, Nils

Moin, aha. Und das sagt genau was aus in einer virtuellen Umgebung? Und das hat welche Relevanz? Dir ist bekannt, dass Benchmarks immer nur in einer bestimmten Konstellation aussagekräftig sind? Soso. Wie können die User das denn einschätzen? Worauf genau stützt sich die Unzufriedenheit? Oder um es anders zu sagen: Was ist denn nun genau das Problem? Bislang haben wir höchstens "gefühlte Werte" von dir genannt bekommen. Gruß, Nils

Moin, Hyper-V simuliert keine CPU. Vielleicht liegt hier ein Missverständnis wegen der Oberfläche des älteren VMM vor, wo man scheinbar CPU-Typen auswählen konnte. Darüber legt man aber keinen "emulierten Typ" fest, sondern die Auswahl dient der Ressourcenplanung als logischer Wert. Aber vielleicht könnte der TO ja endlich mal beschreiben, was denn nun eigentlich sein Problem ist ...? Gruß, Nils

Moin, sofern das AD nicht deutlich kleiner ist als 20 User, sollte im dauerhaften Betrieb mindestens ein zweiter DC laufen. Ansonsten ist es hier schon richtig gesagt worden: Zweiten DC dazu, korrekt konfigurieren, Replikation abwarten, ersten DC herunterstufen, Windows neu installieren, wieder zum DC hochstufen. Der Witz liegt in dem zweiten Punkt "korrekt konfigurieren". :) Gruß, Nils

Moin, verstehe ich nicht. Ein Problem gibt es also nicht? Sei dir bewusst, dass die Anzeige innerhalb des Management-OS von Hyper-V nicht unbedingt Aufschluss über die tatsächliche Ressourcennutzung durch die VMs gibt. Oft sieht man nur die Ressourcen, die die Parent Partition verwendet. Gruß, Nils

Moin, was genau ist dein Problem? Gruß, Nils

Moin, seh ich was falsch, oder kann das nicht gehen? Wenn keine Vertrauensstellung besteht und das Notebook nicht Mitglied der DomäneB ist, dann kann man sich auch nicht mit einem Konto aus DomäneB dort anmelden. (Schließlich vertraut das Notebook der DomäneB gar nicht.) Korrigiert mich, sollte ich falsch liegen ... Gruß, Nils

Moin, naja, wenn es ohnehin nur um einen Einzelserver geht, wäre das nicht meine oberste Sorge. (In einem größeren Netzwerk würde ich natürlich zustimmen.) Gruß, Nils

Moin, das bestehende NAS weiterzunutzen ist auf jeden Fall die einfachere Lösung. Wahrscheinlich ist sie sogar kostengünstiger. Denn nur weil dein Server "ohnehin" läuft, erledigt er die Speicherarbeit ja nicht kostenlos mit, wenn du einen Schwung Platten einbaust. Die brauchen auch Strom, und zwar nicht zu knapp. Für alles Weitere müsste man eine genaue Betrachtung machen. Berücksichtige halt, dass Appliances (wie ein NAS-Gerät) nicht umsonst deshalb beliebt sind, weil sie eben so wenig Aufwand verursachen. Gruß, Nils PS. Das Thema Datensicherung hast du hoffentlich im Griff.

Moin, OUs sind wie Ordner im Dateisystem. Jede Datei kann in genau einem Ordner liegen, jeder User (bzw. jedes andere AD-Objekt) analog in genau einer OU. Zunächst handelt es sich um eine reine Ordnungsstruktur, die man jederzeit ändern kann, wenn es besser passt. Gruppen hingegen dienen der Vergabe von Berechtigungen. Ein User kann in beliebig vielen Gruppen gleichzeitig Mitglied sein. Eine Gruppe hat eine Security-ID und kann damit Berechtigungen auf Dateien, Datenbanken, Mailboxen, Drucker usw. erhalten. (Eine OU hat keine Security-ID und kann daher keine Berechtigungen erhalten.) Meist ist es effizienter, Berechtigungen an Gruppen zu verteilen als an einzelne User. Sollen etwa zehn Schüler einer Klasse eine Datei nutzen können, dann kann man eine Gruppe definieren und die zehn Schüler dort aufnehmen. Nur die Gruppe erhält Zugriffsrechte auf die Datei - durch ihre Mitgliedschaft erhalten die zehn Schüler die Rechte "durchgereicht". Soll später noch ein weiterer Schüler die Rechte haben, nimmt man ihn einfach in die Gruppe aus. Sollen zwei Schüler das Recht nicht mehr haben, entfernt man sie aus der Gruppe. Gruß, Nils