NilsK

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

Moin, die bislang genannten Wünsche erfüllt OTRS. Gruß, Nils

Moin, VM ausschalten, exportieren, vom neuen Pfad importieren. Gruß, Nils

Moin, freut mich! :) Gruß, Nils

Moin, sind die Integrationsdienste in dem Client installiert? Gruß, Nils

Moin, anscheinend ist die AD-Datenbank wirklich kaputt. In der gegebenen Situation ist daher ein Restore oder das Neueinrichten fällig, weil es ja nur einen Server gibt. Sofern ein Restore klappt (autorisierend ist nicht nötig, es gibt ja nur einen Server), ist es gut. Falls nicht: Domäne neu einrichten, die beiden User neu einrichten, PCs aufnehmen, Daten vom Backup wiederherstellen, Berechtigungen neu setzen. Prüf aber erst, ob die Hardware einen Schaden davongetragen hat. Gruß, Nils

Moin, wobei wir bei SCVMM von vier- bis fünfstelligen Kosten reden ... Es ist ziemlich einfach: Wenn es eine zuverlässige P2V-Lösung sein soll, die auch für den Produktionseinsatz supported ist und Spezialitäten wie SQL Server sinnvoll unterstützt, wird es Geld kosten. Sehr wahrscheinlich mehr Geld als eine ordentliche Migration. Disk2VHD ist kein P2V-Tool (sondern ein Konvertierer für Festplatten ohne Support). Und egal mit welchem Tool: ein P2V-konvertierter Server wird prinzipiell nie besser als das Original, sondern fast zwangsläufig schlechter. Gruß, Nils

Moin, wenn du "alles" wiederherstellen konntest, war der Papierkorb aktiv. Du willst dir dies hier mal ansehen: [Video-Tutorial: Active Directory Object Recovery | faq-o-matic.net] http://www.faq-o-matic.net/2009/09/07/video-tutorial-active-directory-object-recovery/ Gruß, Nils

Moin, ein Bekannter von mir lebt in Thailand und hat auch eine sehr differenzierte Meinung zu Bändern in Tresoren ... ich sag nur "tropische Luftfeuchte". Gruß, Nils

Moin, ah, da hab ich neulich einen Trailer für gesehen, aber ohne Bing komm ich nicht auf den Titel, und das gildet ja nicht. Gruß, Nils

Moin, damit verlassen wir aber den sachlichen Bereich. Wir könnten hier jetzt auch Beispiele aufzählen, in denen VMwares Marketing sich unsympathisch aufgeführt hat. Zur Erkenntnis trägt das nichts bei. Gruß, Nils

Moin, na, jetzt suchst du aber verzweifelt nach Argumenten, oder? Wie oft kommt ein Release-Wechsel vor? Eben. Ja, von 2008 R2 auf 2012 kommt man nicht ohne Downtime, das muss man einplanen. In der Folgeversion wird das dank Shared-Nothing Live Migration wahrscheinlich nicht der Fall sein. (Übrigens gab es das Feature zuerst bei Hyper-V.) Und ja, bei vSphere geht das ohne Downtime. Ist damit ausgeschlossen, dass in Folgeversionen VMware Funktionen integrieren könnte, die dann eben doch eine Downtime bei der Migration erfordern? Also mal bitte auf dem Teppich bleiben. Wenn wir lang genug suchen, werden wir für jedes System Nachteile finden. Die Frage ist doch, was ich als Kunde in einer bestimmten Situation brauche, und da fallen viele prinzipiell vorhandene Nachteile (oder auch Vorteile) dann vielleicht gar nicht ins Gewicht. Hm, das klingt jetzt aber, als hättest du da was missverstanden. Live Migration ist kein Prozessorfeature. Hast du das jetzt mit AMD Pacifica verwechselt? Wobei gerade Linuxer traditionell eher auf Xen setzen. (Oder auf KVM und Konsorten.) Wenn wir mal eins der größten RZ weltweit außer Acht lassen. :D Sonst ist der Hinweis durchaus korrekt. Und es ist auch unbestritten: An vielen Stellen hat VMware immer noch technisch die Nase vorn, gerade an solchen Stellen, die man in richtig komplexen Umgebungen braucht. Ist ja auch richtig prima Software. Die Frage, die wir hier ja leider gebetsmühlenartig wiederholen müssen, ist aber immer die nach den konkreten Anforderungen. Und da stellt man eben durchaus häufig fest, dass der Kunde die Features der Enterprise-Plus-Fassung echt geil findet, aber schlicht nicht braucht - und dass das, was er braucht, problemlos mit den Bordmitteln von Hyper-V erreichbar ist. Wenn er trotzdem mehrere tausend Euro für vSphere ausgeben will, bin ich der Letzte, der ihn daran hindert. ;) Gruß, Nils

Moin, und immer noch vergleichst du Äpfel mit Birnen. Das ist aber auch ganz was anderes als die Ausgangsfrage. Also hier irrelevant. Naja, wie du selbst sagst, bin ich in den meisten Szenarien sogar dann noch günstiger, wenn ich den VMM nutze. Und in Mittelstandsszenarien bis fünf oder sechs Hosts geht es prima ohne, und da spare ich dann mal eben 40.000 Euro verglichen mit vSphere. Schauen sie zu Recht, weil die Aussage so ja nicht richtig ist. Dass Templates meistens sehr unsinnig eingesetzt werden und dann zu unguten Konfigurationen führen, steht jetzt mal auf einem anderen Blatt. "Die" Third-Party-Hersteller? Dann hast du dich auf dem Hyper-V-Markt aber noch nicht so gut umgesehen. Ich sehe da mittlerweile einige, die sehr interessante Zusatzprodukte bieten. Natürlich ist es vergleichbar. Es ist nicht dasselbe, aber es ist vergleichbar. Je nach Szenario kommt man, wie ja auch Daniel oben sagte, manchmal zu dem Schluss: Hier ist VMware besser geeignet. Dort ist Xen interessant. Und in anderen Situationen ist eben Hyper-V die bessere Wahl. Genau diese Differenzierung lässt du leider bislang vermissen. Das finde ich ein wenig schade. Nee, schon klar. Das Netzwerk, die Storage-Anbindung und das "bisschen Haushalt" macht sich bei VMware bekanntlich von selbst. <Zynismus>Glücklicherweise sehen das viele VMware-Verfechter so, daher haben wir eine Menge Aufträge, um sowas wieder geradezuziehen.</Zynismus> Kosten. Performance. Eignung. Je nach Situation. Wo es besser passt, empfehlen wir auch VMware. Und wo der Kunde eine Vorprägung hat, liefern wir ihm, was er gern möchte. Wir sind Dienstleister, keine Missionare. Gruß, Nils

Moin, vereinfacht gesagt: Ja. Gruß, Nils

Moin, wenn deine IP-Adressen 16-Bit-Subnetzmasken haben, befinden sie sich effektiv im selben Subnet. Entweder hast du das hier falsch wiedergegeben, oder es ist nicht günstig geplant. Oben hattest du noch "Cluster Network: Momentan je 1 Adapter pro Node" erwähnt - wo finde ich das in deiner Aufstellung wieder? Ansonsten würde ich vermuten, dass die Storage-Anbindung nicht korrekt ist. Darauf scheint mir auch die Fehlermeldung hinzudeuten, die du gepostet hast. Gruß, Nils

Moin, du bleibst auf dem Äpfel-und-Birnen-Niveau. Auch bei vSphere musst du selbstverständlich einen Cluster einrichten und konfigurieren, bevor HA funktioniert. Das ist, sobald man es einmal gemacht hat, auf beiden Seiten sehr beherrschbar. Und die Treiber-Installation - meine Güte ... entweder hast du von deinem Hardware-Hersteller ein Medium, das dir die Arbeit abnimmt. Oder du integrierst die Treiber in deine Installationswerkzeuge, wenn du wirklich viele Hosts installieren willst. Oder du hast eben 20 Minuten Aufwand. Dafür musst du bei neuer Hardware eben auch nicht warten, bis die vom Hersteller des Hypervisor durchzertifiziert ist und er die Treiber in seinen Kernel einkompiliert hat. Sorry, hier verlässt du mich. Seit wann ist XenDesktop zwingend erforderlich, um eine Hypervisor-Umgebung zu betreiben? Kommen jetzt auch noch mal Argumente? Gruß, Nils

Moin, ADFS ist zwar schon das richtige für das Szenario, aber dafür müsste natürlich auch die Web-Applikation angepasst werden. Für den Fall einer bestehenden Anwendung, die ihr nicht ändern könnt, wäre dann ein clientseitiges SSO-Tool geeignet. Gruß, Nils

Moin, sagen wir es so: Wenn es bei euch problemlos ist, den DC für ein paar Stunden länger außer Betrieb zu nehmen, dann ist evtl. das Herunter- und Heraufstufen in deinem Fall die einfachere Methode: DC herunterstufen Server umbenennen Server hochstufen und dabei gleich die richtigen Pfade wählen Gruß, Nils

Moin, weil es mir gerade auffällt, hier noch eine Korrektur für ein Missverständnis. Ein Switch hat keine IP-Adresse, weder in Hyper-V noch sonstwo. Es handelt sich bei physischen Switches um die IP-Adresse des jeweiligen Management-Moduls. Sowas gibt es bei virtuellen Switches nicht, weil dort eine andere Schnittstelle für das Management bereitsteht. Die Netzwerkkarte, die du "im Host" (richtiger: im Management OS) siehst, ist nicht "der Switch", sondern eine virtuelle Netzwerkkarte im Management OS, die an den jeweiligen Switch gebunden ist. Falls das Management OS nicht an den Switch gebunden sein soll, entfernt man das Häkchen "Gemeinsame Verwendung ... zulassen" in der Konfiguration des virtuellen Switches - dann verschwindet auch die virtuelle Netzwerkkarte, aber der Switch selbst bleibt natürlich erhalten. [Hyper-V und Netzwerke | faq-o-matic.net] http://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ Gruß, Nils