NilsK

Moin, wieso das denn? Allgemein rät man davon ab, weil es i.d.R. keine Vorteile bringt, aber sich vom Installationsstandard entfernt. Das verkompliziert manchmal Troubleshooting-Prozesse. Das Umbenennen eines DC ist kein Problem, das kann man genauso machen wie bei einem Client. Herunter- und wieder hochstufen ist nicht nötig. Das Verschieben der AD-Datenbank geht nur im Offline-Modus per NTDSUTIL. Ob es dazu reicht, die AD-Dienste zu beenden, weiß ich aus dem Kopf nicht (ich glaube schon); falls nicht, musst du den DC in den DS-Restore-Mode booten. Gruß, Nils

Moin, wie jetzt - meinst du? ... SCNR ... @Sunny: Meinst du nicht, dass eine Quellenangabe angebracht wäre? Gruß, Nils

Moin, ach so, um das noch eben anzuführen: Meine Einschätzung stützt sich auf eine höhere zweistellige Zahl von Hyper-V-Projekten zwischen zwei und 13 Hosts, beginnend mit Hyper-V in 2008 R2. Parallel gab es bei uns etwa dieselbe Zahl von vSphere-Projekten. Ich kann also beide Welten einschätzen. Abseits der Flamewar-Ebene stimme ich Daniels Zusammenfassung zu. Schöne Grüße, Nils

Moin, was du aufführst, lässt sich wohl am besten unter "Vorurteil" zusammenfassen. Der SCVMM bietet unbestritten Vorteile. Er ist aber auch nicht "nötig" in dem Sinne, dass ohne ihn "nichts" oder "recht wenig" ginge. Auch eine Umgebung mit, sagen wir, fünf oder sechs Hosts lässt sich problemlos ohne SCVMM betreiben. Alle Funktionen, die man von der Umgebung erwartet, stehen dann zur Verfügung: Failover, Live Migration, Replica, Cluster-Aware Updating, Client Monitoring, Metering ... Im Gegensatz zu vSphere, wo ich ohne vCenter kein HA und kein vMotion machen kann (und vieles andere auch nicht). Man ist hier also schnell dabei, Äpfel mit Birnen zu vergleichen. Klar, vCenter ist komfortabler als der mitgelieferte Hyper-V-Manager. Ich zahle allein dafür aber auch schon eine hohe vierstellige Summe, muss das also eher mit dem VMM vergleichen - und da hat dann eher der VMM die Nase vorn. "Installation dauert eine Stunde" - wenn du Patches und Konfiguration einrechnest, bist du bei vSphere auch nicht wesentlich schneller. Wir würden uns vielleicht über einen Unterschied von 20 Minuten unterhalten - für die Installation eines Hostservers, was ja nun eher eine einmalige Sache ist. So what? "Man muss den Cluster überwachen" - das muss man bei vSphere auch. Der Rest deiner Einwände bewegt sich meines Erachtens auf ähnlichem Niveau. Bleibt für mich irgendwie nur eine persönliche Abneigung übrig, die man nicht diskutieren kann. Und "Flamewars" brauchen wir hier im Board nicht. Gruß, Nils

Moin, einen RDP-Zugriff kannst du für VMs nur über das Netzwerk einrichten. Der Client, von dem aus du zugreifst, und die jeweilige VM müssen also miteinander per IP kommunizieren können. Als Alternative kannst du dir die Verwaltungstools auf dem Client installieren und dann per vmconnect.exe zugreifen, das ist das "Konsolenfenster", das du auch vom Host aus über den Hyper-V-Manager nutzt. In dem Fall muss der Client nur mit dem Host sprechen können, aber nicht direkt mit der VM. Du brauchst dann aber natürlich auch Zugriffsrechte für vmconnect.exe (entweder weil du Host-Admin bist oder weil dir die Rechte explizit eingeräumt wurden). Ein "interner" Switch ist ein Hyper-V-Switch "ohne Uplink", d.h. nur der Host und die VMs sind daran gebunden, aber nicht das externe LAN. Die jeweiligen virtuellen Netzwerkkarten müssen dann IP-Adressen aus demselben Segment bekommen, wenn sie miteinander kommunizieren sollen. Gruß, Nils

Moin, hilft Marks Artikel? [KMS – Key Management Service – Installation und Konfiguration | faq-o-matic.net] http://www.faq-o-matic.net/2013/04/29/kms-key-management-service-installation-und-konfiguration/ Gruß, Nils

Moin, ja, das stimmt. Ich habe das gerade mal ausdrücklich hingeschrieben. Gruß, Nils

Moin, korrekt, wobei du dich mit 10 GB dann schon hart am unteren Rande der Empfehlung befindest. Gruß, Nils

Moin, das wäre die einzige sinnvolle Variante. (Ist ja oben auch schon mal genannt worden.) Gruß, Nils

Moin, "technisch fehlerfrei" geht das natürlich auch heute noch, genau wie seit Windows 2000. Es ist genau wie damals aber nicht nur "nicht Best-Practice", sondern es ist aus vielen sattsam bekannten Gründen entschieden davon abzuraten. Gruß, Nils

Moin, ja. Steht in dem Artikel. Nein, es geht die ganze Zeit um den internen Namensraum. Meine Empfehlung lautet einfach: Der interne Namensraum sollte einen "offiziellen" Namen verwenden, der dem Unternehmen gehört, der aber idealerweise nicht für externe Zwecke verwendet wird. Gruß, Nils

Moin, äh - ich verstehe die Rückfragen zu meinem Artikel nicht recht. Dort spreche ich doch eine ausgesprochen deutliche Empfehlung aus: Was alles passieren kann, wenn der interne Namensraum im Internet jemand anderem gehört, haben wir in diesem Board auch erst kürzlich gehabt: http://www.mcseboard.de/topic/192507-nslookup-hängt-immer-dns-suffix-an/#entry1192179 Gruß, Nils Moin, dann registrier ihn doch selbst ... kostet etwa 10 EUR pro Jahr und ist damit ein Quentchen günstiger als jedes Troubleshooting. Gruß, Nils Ja, viele Unternehmen machen das so.

Moin, da wird IPv6 nicht die Ursache sein, das klingt eher nach einem zufälligen Zusammentreffen. Was sagt das Eventlog? Was ist noch an dem Server geändert worden? Gruß, Nils

Moin, von .local rate ich nach wie vor ab. Ansonsten ist alles Nötige zum Thema DNS-Namensraum für AD ja in meinem oben verlinkten Artikel schon gesagt. (Naja, gut, zumindest alles, was ich selbst als nötig erachte.) Es gibt bei einer neu aufgebauten Struktur normalerweise überhaupt keinen Grund, dass interner und externer DNS-Namensraum gleich heißen. Dafür gibt es gleich mehrere Gründe dagegen. Gruß, Nils

Moin, wie viele Netzwerkkarten haben die Hosts? Wie sind diese konfiguriert? Gruß, Nils

Moin, das AD sollte immer einen rein internen Namensraum haben. Interne Namen und Adressen haben im öffentlichen DNS nichts zu suchen. Macht also zwei "getrennte" DNS-Systeme, eins nur mit den externen Adressen (Webserver, MX und so), von außen zugänglich, und eins nur mit den internen Adressen, nur intern zugänglich. [Welcher Name ist der beste für eine AD-Domäne? | faq-o-matic.net] http://www.faq-o-matic.net/2007/06/08/welcher-name-ist-der-beste-fuer-eine-ad-domaene/ [Welches Domänenmodell ist das Beste für Active Directory? | faq-o-matic.net] http://www.faq-o-matic.net/2007/06/09/welches-domaenenmodell-ist-das-beste-fuer-active-directory/ [Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net] http://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/ Die Fragen klingen nach einer größeren Struktur - ich hoffe für euch, dass ihr jemanden habt, der euch bei einem solchen Migrationsvorhaben kompetent unterstützt. Kriegt man alles hin, ist aber nicht ohne. Gruß, Nils

Moin, in Windows Server 2012 lässt sich die Rolle "Druckserver" nicht mehr clustern. Empfohlen ist, den Druckserver als VM einzurichten und diese VM auf Hypervisor-Ebene zu clustern. Das wäre auch per Replica denkbar (dann aber nur manuelles Failover möglich). Je nach den Anforderungen an das Drucken kommt man manchmal auch ohne Cluster aus, beispielsweise könnte man alle Queues auf mehr als einem Server einrichten und bei Ausfall eines der Server die Clients auf den anderen verbinden. Gruß, Nils

Moin, nein, diese Deutung der Lizenzbedingungen wurde bislang nicht bestätigt. Es ist also davon auszugehen, dass das "Mischen" erlaubt ist, solange die jeweiligen Lizenzbedingungen eingehalten werden. Grundsätzlich ist das Downgrade erlaubt, auch für einzelne Instanzen. Details dazu musst du in dem für dich gültigen Lizenzvertrag nachlesen. Zu jeder Zeit müssen auf jedem Host eines solchen Konstrukts ausreichend Lizenzen zugewiesen sein, um alle Windows-Instanzen auszuführen, die technisch darauf laufen könnten. In deinem oben skizzierten Fall muss jeder Host also vier 2008-R2-VMs und zwei 2012-VMs lizenziert haben, egal, ob sie gerade dort laufen oder nicht. Gruß, Nils

Moin, definiere "reicht". Wenn du Virtualisierung der Datacenter-Klasse willst und parallel VMs mit Exchange, SQL und anderen I/O-Knallern betreibst, "reicht" es natürlich nicht. Wenn es um Test-VMs usw. geht und dir sonst 7200 rpm reichen, "reicht" es natürlich allemal. Gruß, Nils

Moin, es handelt sich einfach um zwei getrennte Felder. Das eine ist sAMAccountName mit max. 20 Zeichen. Das andere ist userPrincipalName, das aus dem Teil vor dem @ und dem Teil dahinter besteht - gemeinsam, nicht einzeln. Dass du im GUI für den UPN nur den vorderen Teil eingibst und den hinteren auswählst, ist eine reine Komfortfunktion des GUI. Im Feld ist der komplette UPN hinterlegt. Per ADSI oder Skript kannst du das UPN-Suffix auch völlig frei wählen, ohne dass es zentral vorbelegt ist. [sAM-Account-Name attribute (Windows)] http://msdn.microsoft.com/en-us/library/windows/desktop/ms679635(v=vs.85).aspx [user-Principal-Name attribute (Windows)] http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx Gru0, Nils

Moin, nein, das ist nicht erforderlich. Hyper-V-Switches arbeiten auf Layer 2, blockieren also keine Broadcasts. Wenn deine VM keine DHCP-Adresse bekommt, muss das Problem woanders liegen. Gruß, Nils

Moin, ich stimme Robert zu und ergänze: Exchange wird sehr häufig virtuell betrieben, und es spricht im Grundsatz auch nichts dagegen. Für alles Weitere ist Planung und Konzeption nötig. Gruß, Nils

Moin, das ist der Bildschirmschoner. Gruß, Nils

Moin, wieso? VMware hat doch gar kein Dynamic Memory. Wenn es dir darum geht, von vornherein das "Überbuchen" von Arbeitsspeicher einzukalkulieren: Davon rät VMware (zu Recht) auch ab. Du solltest in jedem Fall so viel RAM in den Hosts einplanen, dass alle VMs damit ordentlich laufen können. RAM ist ja heutzutage auch nicht mehr wirklich der Kostenfaktor. Gruß, Nils

Moin, das ist richtig. Aus dem Grund sollte man gut überlegen, ob man wirklich mehr als zwei physische CPUs (="Sockel") braucht. Im Zeitalter von Hexa- und Octa-Core dürften zwei Sockel auch für anspruchsvolle Aufgaben ausreichen. Gruß, Nils