NilsK

Moin, aha, also geht es um Hyper-V. Warum beantwortest du nicht einfach die Fragen, die man dir stellt? Was meinst du mit "im Hyper-V des gleichen Server"? Ganz einfach, Disk2VHD ist kein P2V-Tool. Gruß, Nils

Moin, das hängt entscheidend davon ab, auf welcher Basis denn dein Host läuft ... Gruß, Nils

Moin, schlechte Idee. Ein Host ist ein Host ist ein Host. Niemals andere Rollen auf einem Hyper-V-Hostserver einrichten. Wenn du File- oder DHCP-Server clustern willst, bau dafür einen separaten Cluster. Das klingt nicht durchdacht. Warum sollte das Ziel sein, den Cluster zu sichern? Das Ziel besteht doch wohl eher darin, nach Ausfällen oder Datenverlusten deine Applikationen und Daten wiederherzustellen, oder? Also solltest du auch vom Ziel her planen. Du machst hier den beliebten Fehler, von einer bekannten oder angenommenen Methode her zu denken. Erfahrungsgemäß kommt man damit bei Recovery-Planungen nicht weit. Neben wbadmin (das ich nur in Ausnahmefällen nutzen würde) und DPM gibt es ja noch eine ganze Reihe weiterer Werkzeuge und Ansätze. Das wäre ganz sicher ein Desaster und gehört selbstverständlich in die Liste der zu berücksichtigen Schadensszenarien. Ein solcher Komplettausfall ist aber ausgesprochen unwahrscheinlich und ebenso selten. Viel häufiger wirst du dich mit anderen Szenarien herumschlagen müssen. Für die brauchst du auch Lösungen. In den meisten Situationen gelingt eine Wiederherstellung auf Basis von "Komplett-Backups" nicht, wenn kein Komplett-Restore erforderlich ist. Die meisten Kunden, die den Restore-Fall wirklich durchplanen, landen bei hybriden Verfahren, in denen Backups auf Applikationsebene und Backups auf VM-Ebene fallweise kombiniert werden. Den Cluster als solchen zu sichern, ist nicht grundsätzlich unsinnig, aber auch nicht immer sinnvoll, denn meist ist ein Cluster bzw. Clusterknoten schneller neu wieder aufgesetzt als restauriert. Gruß, Nils

Moin, die Drucker nutzen ja den Server nicht (sprich sie greifen nicht auf den Server zu), sondern die User. Also brauchst du in dem Fall für die Drucker keine CALs. Für andere Geräteklassen kann das allerdings anders aussehen. Es kommt grob gesagt darauf an, ob das Gerät selbst auf den Server zugreift oder nicht. Gruß, Nils

Moin, mischen kannst du den CAL-Typ nicht, du musst dich bei der Erstzuweisung entscheiden. Gibt es (identische) User, die mit mehr als einem Endgerät (PC, Notebook, Smartphone ...) auf die Server zugreifen, dann sind User-CALs besser. Gibt es eher PCs, die von mehr als einem User verwendet werden, dann sind Device-CALs besser. Installieren musst du die CALs nicht, sie müssen "im Schrank stehen". Gruß, Nils

Moin, die Autorisierung ist ein Konfigurationseintrag, der auf den DNS-Namen des Servers läuft. Du kannst die IP-Adresse also hinterher problemlos ändern. Die Autorisierung ist eigentlich simpel: Wenn ein Windows-DHCP-Server startet, prüft er, ob er Domänenmitglied ist. Falls ja, schaut er in der AD-Konfiguration nach, ob er selbst dort als autorisierter Server drinsteht. Falls ja, startet er. Falls nein, schaltet er den DHCP-Dienst inaktiv. Hier stehen die Einträge, falls jemand mal mit ADSI Edit nachsehen will: CN=NetServices,CN=Services,CN=Configuration,DC=domain,DC=tld Gruß, Nils

Moin, ja, die Autorisierung kann man unabhängig vom Betrieb vornehmen. Gruß, Nils

Moin, danke für die Rückmeldung! Ja, das mit Unicode/ANSI war mir auch schon mal aufgefallen, hatte ich hier vergessen. Dasselbe Problem gibt es an anderen Stellen auch, z.B. bei Logonskripts. Gruß, Nils

Moin, wieso geht es um die Frage? Desktop-User können das auch weiterhin ignorieren. (So, wie ich es am Desktop auch mache.) Um damit was auszusagen? Gruß, Nils

Moin, [Warum der Hyper-V-Host keine (!) weiteren Dienste ausführen sollte | faq-o-matic.net] http://www.faq-o-matic.net/2010/05/03/warum-der-hyper-v-host-keine-weiteren-dienste-ausfhren-sollte/ Gruß, Nils

Moin, für die Prüfung musst du grob wissen, was csvde macht und ggf. noch die wichtigsten Schalter identifizieren können. Ich würde mich an deiner Stelle mit dem Import nicht weiter aufhalten. Gruß, Nils

Moin, es ist ganz einfach: csvde eignet sich so gut wie nie zum Import von Objekten. Spätestens beim Kennwort wirst du scheitern. In der Praxis nutzt man das auch praktisch überhaupt nicht für Importzwecke. Es kann gut sein, dass csvde zwingend den DN als erstes Attribut erwartet. Stell deine Felder mal um. Es kann allerdings auch sein, dass du Gruppen gar nicht auf die Art gefüllt kriegst, wie du es versuchst. Ich habe das nie so versucht, daher keine konkrete Erfahrung an dieser Stelle. Gruß, Nils

Moin, wie kommst du darauf? Was dort gezeigt wird, entspricht dem, was Windows 8 jetzt auch schon hat. Ein paar Verbesserungen im Kachel-Handling, aber nicht "mehr Touch". Auf dem Desktop braucht und nutzt man es nicht. Auf einem Touch-Gerät ist es praktisch. So einfach ist das. Das geht jetzt auch schon. Neu ist nur das Seitenverhältnis 50:50, derzeit geht nur 30:70. Gruß, Nils

Moin, meine Ansicht generell: Da du in der DMZ nur wenige Einträge brauchst, die üblicherweise noch dazu nahezu statisch sind, würde ich gar keine Replikation vornehmen. Gruß, Nils

Moin, ... und erzeugst erst danach die virtuellen Switches. Niemals nachträglich Teaming einrichten für NICs, für die schon vSwitches existieren. Es wäre allerdings auch möglich, die NICs am Host einzeln zu belassen und dann innerhalb der VM ein Team zu erzeugen. Alles eine Frage des Designs. (Und das sollte man vorher in Ruhe machen.) Und nur zur Sicherheit: Die Empfehlung, einen physischen DC zu betreiben, heißt, dass es eine separate Hardware sein muss. Nicht auf einem der Hyper-V-Server einen DC einrichten. Gruß, Nils

Moin, bitte eröffne beim nächsten Mal einen neuen Thread. Es ist nicht erwünscht, Threads mit neuen Fragen zu übernehmen. Schon gar nicht nach vier Jahren. Ein grundsätzliches Sicherheitproblem entsteht nicht, wenn eine interne DNS-Zone in die DMZ repliziert wird. Das tatsächliche Sicherheitserfordernis ergibt sich aus den Einträgen selbst. Wenn die schützenswert sind, haben sie nichts in einer DMZ zu suchen. Ist es denn überhaupt erforderlich, die ganze Zone in die DMZ zu übertragen? Und weitergehend: Braucht es überhaupt eine Replikation? Meist reichen in der DMZ doch sehr wenige Einzeleinträge aus, die sich üblicherweise auch selten ändern. Gruß, Nils

Moin, warum sich die Anwendung ins AD eingetragen hat, kann ich dir nicht sagen, das müsstest du deren Hersteller fragen. Wenn du das Server-Objekt löschst, werden alle untergeordneten Objekte mit gelöscht. Objekte an anderen Stellen im Verzeichnisbaum sind davon nicht betroffen. Gruß, Nils

Moin, meist sind das freigegebene Drucker oder alte Message-Queue-Einstellungen. Die werden im AD als Unterobjekte des Servers publiziert. Schau dir das Objekt mal mit ADSI Edit an, dann siehst du auch, was da drunter hängt. Gruß, Nils

Moin, gut, dass wir drüber gesprochen haben. ;) Viel Erfolg dabei! Gruß, Nils

Moin, ihr werdet das sicher schon geprüft haben, aber: Der Dongle selbst ist ja sicher nicht von dem Softwarehersteller gebaut worden. Existiert die Firma noch, von der der Dongle ist? Gruß, Nils

Moin, hat er. Du befindest dich hier in einem professionell orientierten Forum. Da musst du damit rechnen, dass dich jemand auf größere Zusammenhänge hinweist. Darum geht es hier nicht. Es geht um das erhebliche Risiko eines USN Rollback. Das willst du nicht eingehen. Ja, genau: Offline. Nicht online. Wegen des Risikos eines USN Rollback. Und: Es wird unterstützt, aber nicht empfohlen. Bei der Empfehlung geht es nicht um die Ausfallsicherheit des DCs, sondern um die Erreichbarkeit des DCs, wenn es Probleme mit der VM-Umgebung gibt. Das ist schnell erzählt: "Hot Clone" führt zu USN Rollback. Allenfalls könntest du, bevor du den P2V-Vorgang anstößt, die AD-Dienste beenden. Bei 2008 R2 geht das. Dann konvertierst du, nimmst die VM in Betrieb und schaltest den physischen DC nie wieder online. Das ist aber ausdrücklich keine Empfehlung. Aus meiner Sicht ist P2V für einen DC ein No-Go. Dazu sei noch ergänzt: Windows 2012 für den DC ist dabei eine notwendige, aber keine hinreichende Voraussetzung. Die VM-Umgebung muss das Verfahren ebenfalls unterstützen, und das ist derzeit nur bei Hyper-V 2012 und bei vSphere 5.x gegeben. Hier noch mein Senf-Konzentrat zum Thema: [faq-o-matic.net » Darf man einen Domänencontroller virtualisieren?] http://www.faq-o-matic.net/2011/02/28/darf-man-einen-domnencontroller-virtualisieren/ Gruß, Nils

Moin, nslookup zeigt den Servernamen immer als "unknown" an, wenn es keine Reverse-Lookup-Zone gibt. Das ist normal und deutet nicht auf einen Fehler hin. Gruß, Nils

Moin, wenn du aus dem ADUC-Kontextmenü ein Skript aufrufst, bekommt dies zwei Argumente übergeben, durch Blank getrennt: Den aDSPath und die objectClass. Der aDSPath ist im Prinzip der DN, nur erweitert um das Zugriffsprotokoll. Gruß, Nils

Moin, die Information, dass mehrere Versionen auf dem Rechner sind, wäre schon im ersten Post hilfreich gewesen. Das macht einen erheblichen Unterschied! Es funktionierte bei mir "besser" nach einer Reparaturinstallation von Office. Richtig rund ging es erst, als ich nur noch ein Office auf dem Rechner hatte. Offiziell wird es mit Office 2013 zwar unterstützt, parallel noch ein "altes" Office zu haben, aber wirklich gut geht das nicht. Gruß, Nils

Moin, per LDAP wirst du das nicht hinbekommen. Die Zugriffsberechtigungen sind dort nicht (bzw. nicht ohne Weiteres) zugänglich. Wenn ich nicht ganz falsch liege, sollte LIZA dir aber deine Frage beantworten können. [LIZA - Active Directory Security, Permission and ACL Analysis] http://www.ldapexplorer.com/en/liza.htm Gruß, Nils