Jump to content

NilsK

Expert Member
  • Gesamte Inhalte

    17.573
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von NilsK

  1. Moin, schön, aber das beantwortet ja noch nicht, warum, das gut sein sollte. Welches Problem würde man damit lösen oder vermindern wollen? Gruß, Nils
  2. Moin, schwierig bei Hyper-V ... Gruß, Nils
  3. Moin, du suchst LIZA. Das beantwortet dir deine Fragen (soweit ich sie richtig verstehe) ohne Export. [LIZA - Active Directory Security, Permission and ACL Analysis] http://www.ldapexplorer.com/en/liza.htm Gruß, Nils
  4. Moin, sicher, wenn man das nötige Kleingeld hat ... da man für P2V aber vermutlich nicht höhere vierstellige (oder sogar fünfstellige) Beträge ausgeben will, gibt es durchaus Alternativen am Markt. Am besten ist aber: Kein P2V. (Wie Dukel schon zutreffend betont.) Gruß, Nils
  5. Moin, nslookup hat noch nie anders gearbeitet. Es fängt, genau anders als der Client-Resolver, immer beim maximal mit Suffizes ausgestatteten Namen an und arbeitet sich dann bei Misserfolg "nach unten". Das ist auch dokumentiert, ich habe nur gerade die Links nicht bei der Hand. Eine Web-Recherche sollte dir das aber schnell bestätigen. Was sich hingegen geändert haben könnte, ist das Verhalten des DNS-Servers, der zu der externen Domain gehört, deren Namen ihr intern verwendet. Wie in dem von mir geschilderten Beispiel könnte es sein, dass dieser DNS-Server für jeden Host, den er nicht kennt, dieselbe IP-Adresse zurückgibt. (Es könnte sein, dass der Domain-Inhaber damit auch Besucher auf seine Webseite bekommen will, die sich beim Hostnamen vertippen.) Damit ist die DNS-Antwort für nslookup gültig, wenn sie natürlich eben auch unsinnig ist. Eine Möglichkeit, das "von innen" zu ändern, ist mir nicht bekannt. Naja, abgesehen von: DNS-Namen des AD ändern ... Du kannst aber nslookup zwingen, genau den von dir gewünschten Eintrag abzufragen, ohne Suffizes anzufügen: Hänge einen Punkt hinten an, also z.B. nslookup www.heise.de. Gruß, Nils
  6. Moin, nslookup verhält sich immer so. Das Verhalten ist völlig normal. Das Problem liegt in eurer ungünstigen DNS-Konfiguration. nslookup ist, anders als viele glauben, NICHT geeignet, um die Namensauflösung eines Clients zu überprüfen. Dazu ist ping besser geeignet (oder ein Browser). nslookup ist das richtige Tool, um in die DNS-Datenbank zu sehen. Ich hatte einen sehr ähnlichen Fall vor ein paar Monaten bei einem Kunden. Dort kam noch hinzu, dass dessen Domainname im Internet von einem falsch konfigurierten DNS-Server bedient wurde, was wir aber erst nach einiger Zeit herausgefunden haben. Hier ein Zitat unserer damaligen Ergebnisse: Schöne Grüße, Nils
  7. Moin, mir erschließt sich dabei allerdings auch nicht, wozu so eine Funktion gut sein sollte. Gruß, Nils
  8. 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
  9. Moin, das hängt entscheidend davon ab, auf welcher Basis denn dein Host läuft ... Gruß, Nils
  10. 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
  11. 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
  12. 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
  13. 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
  14. Moin, ja, die Autorisierung kann man unabhängig vom Betrieb vornehmen. Gruß, Nils
  15. NilsK

    CSVDE import

    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
  16. 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
  17. 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
  18. NilsK

    CSVDE import

    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
  19. NilsK

    CSVDE import

    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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
×
×
  • Neu erstellen...