NilsK

Moin, und damit hast du eine nicht supportete Konfiguration. vSphere/ESXi 5.1 ist nicht Teil des SVVP und damit nicht Teil der Support-Policy von Microsoft. Wollte ich auch nicht glauben. Ist aber leider so. Gruß, Nils

Moin, das ist sehr zu empfehlen. Gruß, Nils

Moin, gut, und was ist deine Antwort auf meine Frage? Vielleicht können wir zur Lösung deines eigentlichen Problems ja auch noch was beitragen. Gruß, Nils

Moin, OK, wieder was dazugelernt. ;) Gruß, Nils

Moin, das bringst du dem IE (und anderen Browsern) gar nicht bei. Ein Einzelwort wird er nie als möglichen Domänennamen akzeptieren. Setze http:// davor, dann geht es. Wenn man DNS nutzt, sollte man sich auch an die DNS-Gepflogenheiten halten. Zonen der ersten Ebene gibt es nicht (bzw. nur als Verweis auf die zweite Ebene, aber nicht für die Pflege von Hostnamen). Gruß, Nils

Moin, oh, tatsächlich. Na sowas. Scheint wohl ein Fehler in der Skriptlogik zu sein, denn manchmal sieht man, dass der Text zunächst "roh" dargestellt wird und dann ins Syntax Highlighing wechselt. Anscheinend erzeugt das Code, den der IE10 nicht richtig interpretiert. Gruß, Nils

Moin, dafür kann er nichts - leider stellt die neue Boardsoftware längere Listings immer so dar. @jpanse: Was genau ist das Ziel deines Codes? Wenn es darum geht, Aktionen abhängig davon auszuführen, ob jemand in einer bestimmten Gruppe ist, geht das viel effizienter. Dafür braucht es keine AD-Abfragen im Logonskript. Gruß, Nils

Moin, ich rate von automatischen Kennwortsperren grundsätzlich ab. Es ist in Umgebungen mit aktivierter Sperrung sehr einfach, Denial-of-Service-Angriffe auszuführen, indem man mutwillig falsche Kennwörter eingibt. Mir juckt es schon seit Jahren in den Fingern, ein sehr simples Batch zu publizieren, das eine ganze Domäne und vor allem alle darin befindlichen Dienstkonten innerhalb von Sekunden oder Minuten lahmlegt. Gruß, Nils

Moin, nein, das heißt es nicht automatisch. Der DNS-Server, der die nslookup-Anfrage beantwortet, kann dies auch aus seinem Cache tun. Es könnte also durchaus eine gültige Antwort kommen, obwohl der DNS-Server keinen Kontakt zu einem übergeordneten Server hat. Gruß, Nils

Moin, och, dazu kann es schon Gründe geben. Exchange beispielsweise oder der Active Directory Connector, den man früher für Exchange brauchte, haben durchaus die DS-ACLs im Configuration-NC manipuliert. Wenn es tatsächlich eine Auswertung dieser Art sein soll, wird man vermutlich an kommerziellen Tools nicht vorbeikommen. Konkrete Empfehlungen dazu kann ich keine nennen, aber eine Handvoll sollte es geben. Man muss dabei abwägen, ob der Aufwand gerechtfertigt ist. Beispiel: Ein gelöschter oder gesperrter Account oder eine Gruppe ohne Mitglieder stellen als Berechtigte in ACLs praktisch kein relevantes Risiko dar. Gruß, Nils

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

Moin, schwierig bei Hyper-V ... Gruß, Nils

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

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

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

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

Moin, mir erschließt sich dabei allerdings auch nicht, wozu so eine Funktion gut sein sollte. Gruß, Nils

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