NilsK

Moin, guckstu: [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/ Gruß, Nils

Moin, jaja, das glauben viele ... neulich hatte ich wieder einen Kunden, der stolz erzählt hat, "nun endlich" sein WINS abgeschafft zu haben. Man hätte da nur jetzt ein Problem, weil in anderen Subnets die Computerlisten nicht mehr funktionieren, und die Auflösung kurzer Namen ginge auch nicht mehr ... Ich bin auch nach 15 Jahren, in denen behauptet wird, man brauche WINS nicht mehr, immer noch der Meinung, dass WINS deutlich mehr nützt als es schadet so gut wie keine zusätzliche Last erzeugt praktisch keinen Administrationsaufwand erzeugt viele Fehler umgeht, die sich sonst äußern würden und die man oft eben nicht einfach so wegbekommt Man muss es nur richtig einrichten, und dazu gehört: mindestens zwei, maximal fünf WINS-Server einrichten (ab dem vierten als Stern-Topologie) alle (Windows-) Server und Clients als WINS-Clients einrichten auf allen Rechnern (außer den WINS-Servern selbst) zwei WINS-Server eintragen (bei großer Client-Anzahl die konkreten Server und ihre Reihenfolge variieren, um eine gewisse Lastverteilung zu erreichen) Gruß, Nils

Moin, ich meinte, dass du in nslookup explizit den einen oder den anderen DNS-Server angeben sollst. Deine bisherigen Ausgaben haben immer denselben Server gefragt. Ruf dazu "nslookup" ohne Parameter auf, dann gibt mit "server 1928.168.1.x" den jeweils gewünschten Server an. Dann mach die Abfragen. Die DNS-Zone ist als "Active Directory-integriert" eingerichtet? Die FSMO-Rollen der DCs haben mit der normalen Funktion nichts zu tun und beeinflussen nicht die Redundanz. Ist auf dem zweiten DC evtl. die Windows-Firewall falsch konfiguriert? Verändert sich das Verhalten, wenn du testweise alle Windows-Firewalls abschaltest? Wie ist der vSwitch in Hyper-V konfiguriert? Gruß, Nils

Moin das hat mit "hohl" nichts zu tun. In deinem Szenario gibt es nun mal einige Dinge, die man überprüfen sollte. Verbinde bitte nslookup mal mit dem anderen Server und versuch die Abfragen von dort noch mal. Wenn auch dort die richtigen Antworten kommen, ist es okay. Dann könntest du noch mit der DNS-Konsole prüfen, ob beide DNS-Server die AD-Daten korrekt haben. Wenn das der Fall ist, ist kein Screenshot nötig. Nächster Test: Abschalten des ersten DC, prüfen der Fehlermeldungen. Dann von einem Client aus die nslookup-Überprüfungen wiederholen, Fehler- und Ereignismeldungen prüfen. Danach: Anschalten des ersten DC, Abschalten des zweiten DC. Selbe Tests. Das erwartete Verhalten ist, dass ein DC ausreicht, egal welcher. Warum das bei dir nicht geht, ist eben zu prüfen. Gruß, Nils

Moin, das sieht soweit erst mal OK aus. Was sagt denn folgendes Kommando: nslookup kb.local Da sollten beide DCs zurückkommen (bzw. natürlich deren IP-Adressen). Kann der Client denn beide DCs anpingen? Kann er beide per nslookup ansprechen und erhält dann von jedem die richtigen Daten zurück? Gruß, Nils

Moin, das ist, wie immer, eine Frage der Anforderungen. Oder anders gesagt: Kommt darauf an. ;) "Compliance-Archivierung" ist ja erst mal nur ein Begriff, den man für den konkreten Fall ausdeuten muss. Ich weiß nicht genau, was Simpana da im Einzelnen macht. Meist geht es bei separaten Archivierern um das Journaling-Archiv, d.h. "alles, was rein und raus geht", kommt als Kopie ins Archiv, falls man es mal brauchen könnte. Dafür wird man auch weiter eine externe Lösung brauchen, denn Exchange selbst bietet dafür nur die Schnittstelle, aber keine Speichermöglichkeit. Der Artikel, den du verlinkt hast, ist eine andere Funktion. Hier geht es darum, dass der Anwender innerhalb seiner Mailbox nichts mehr löschen kann, sobald die Funktion individuell aktiv ist. Hier ist das Szenario, dass ein Verdacht vorliegt und man verhindern will, dass Beweise vernichtet werden. Das bezieht sich auf die Mailbox selbst, also nicht (nur) auf das, was über den Server rein- oder rausgesendet wird. Ob Simpana sowas auch bietet, weiß ich nicht. Häufig nachgefrag ist noch eine dritte Variante, die vermutlich dem entspricht, was eure User jetzt manuell machen: Die Verdrängungs-Archivierung. Kurz gesagt, sollen regelbasiert "alte" Mails aus der Mailbox ins Archiv verschoben werden. Da bietet Exchange zwar auch eine Technik (Archiv-Mailboxen), aber die hat den gravierenden Nachteil, dass die Daten eben doch auf dem Exchange-Server bleiben. Externe Systeme haben dafür separate Speicher, was meist eher gewünscht ist. Das kann Simpana meines Wissens sehr gut und effizient. Gruß, Nils

Moin, puh, du machst aber viele Worte. Ist etwas schwierig, deinem hektischen Stil zu folgen, nichts für ungut. Mir scheint, du solltest dich erst mal mit Grundlagen befassen: Erstens dem Grundaufbau eines AD und den Grundlagen der Replikation. Und zweitens mit den Grundprinzipien von Hyper-V. Wenn du ohne Kenntnisse versuchst, mit einem komplexen Szenario zu beginnen, wird es unnötig schwierig und fehlerträchtig. Zu deinem konkreten Problem: DNS hat XP-Fan ja schon genannt. [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/ Gruß, Nils

Moin, ich ergänze: 4. Hyper-V Replica ist eine limitierte DR-Lösung für einen eingeschränkten Satz an Szenarien. 5. Hyper-V Replica ersetzt kein Backup. Ein DC ist für Replica zwar supported, aber in aller Regel nicht sinnvoll. Replica zielt darauf, ein einfaches DR-Konstrukt für solche Applikationen zu schaffen, die einerseits Datenverluste aufgrund des asynchronen Prinzips vertragen und andererseits über eigene Mechanismen keine Redundanz bieten. Ein Replica-Konstrukt muss daher auch gut geplant werden. Der übliche Aufbau sieht eher so aus, dass im Ausweich-RZ ein normaler DC läuft, der mit dem Haupt-RZ auf AD-Ebene repliziert. Per Replica werden dann ausgewählte Server asynchron repliziert. Im Fall des Falles ist das AD also vorhanden, und die replizierten VMs lassen sich manuell starten. Da Exchange mit Replica nicht supported ist, würde man schon dafür eine separate Lösung brauchen. Das trifft auch auf einige andere Applikationen zu. Ach so, und noch eine Ergänzung: Der "erste" DC spielt keine besondere Rolle. Warum dein Szenario nicht geklappt hat, lässt sich so nicht direkt ablesen, es kann auch zahlreiche Gründe außerhalb von Hyper-V geben. Gruß, Nils

Moin, Datenverluste im engeren Sinn sind nicht zu erwarten. "Lingering Objects" sind AD-Objekte, die vor mehr als 60 Tagen gelöscht wurden, von deren Löschung der entfernte DC aber nichts weiß. Man kann sich damit an dem entfernten DC dann anmelden, obwohl es sie ja eigentlich nicht mehr geben dürfte. In deinem Szenario ist das Risiko in dem Sinne einschätzbar. Sobald du den entfernten DC dann entfernst, ist das Problem auch weg. Der Hinweis mit den vorhandenen Konten bezieht sich darauf, dass mit einem neuen DC dann ja der aktuelle Datenbestand in die Niederlassung kommt; Änderungen auf dem entfernten DC sind dann verloren. Und falls es da eben noch Konten gab, die im Zentral-AD nicht mehr vorhanden sind, können sich die natürlich nicht mehr anmelden. Gruß, Nils

Moin, wenn der entfernte DC länger offline ist, als die Tombstone Liftetime dauert, dann wird er beim Wiederherstellen der Netzwerkverbindung nicht mehr replizieren. AD merkt das und beendet die Replikation. Es gibt dann auch Eventlog-Einträge. Nach diesem Zeitpunkt besteht das Risiko von "Lingering Objects" (genau genommen besteht das jetzt auch schon, aber bis zum 11.4. könnte AD das selbst beheben). Wenn du danach den DC deinstallierst und einen neuen einrichtest, werden die User, die als Konten noch vorhanden sind, sich weiter anmelden können. Gruß, Nils

Moin, allgemein ist ein Forum für Grundsatzfragen nur schlecht geeignet. Dafür sind andere Quellen da, du könntest dich auch nach einem Buch umsehen. Ich kenne zufällig eins, das du mit naheliegenden Begriffen beim Händler deiner Wahl finden solltest. ;) Deine VM-Konfiguration solltest du noch mal überarbeiten: Die genannte Kombination von Diensten auf der VM braucht ganz sicher keine 2 GB als Start-RAM, da kannst du auf 1 GB runtergehen. Dass sie sich im Betrieb auf 512 MB absenkt, ist unwahrscheinlich. Dort könntest du auch 1 GB setzen - ist an der Stelle am Ende aber Geschmackssache. Grundsätzlich ist Dynamic Memory für die beschriebene VM nutzbar (alle genannten Dienste können damit umgehen), in deinem Gesamtkonstrukt aber eigentlich völlig unnötig. Du willst ja nur zwei VMs betreiben, und die haben in den 64 GB problemlos Platz, auch wenn keine Dynamik im Spiel ist. Ist auch wieder Geschmackssache, aber ich selbst würde der ersten VM 2 GB in deinem Fall statisch geben. Wenn sie auch Fileserver sein soll (was in einer sehr kleinen Umgebung machbar ist; wenn es perspektivisch mehr als die 15 User werden, würde ich DC und File trennen), dann 4 GB, mehr wird nicht nötig sein. Auf jeden Fall solltest du aber die vCPUs ändern. Ein Domänencontroller braucht nie im Leben 8 vCPUs. Ich würde da eine einzige setzen. Maximal zwei, selbst dann, wenn die VM auch noch Fileserver sein soll. Auf keinen Fall mehr. Sonst erzeugst du dir später Probleme, falls deine Umgebung doch noch mal stärker wächst. Bedenke: Weist du 8 vCPUs zu, dann müssen acht Cores gleichzeitig frei sein, damit deine VM laufen kann. Bei zwei VMs sicher kein Problem, aber wenn es mal mehr wird, kann das sehr wohl problematisch werden. Bitte keine direkte Zuordnung von physischen NICs zu einer VM. Das führt ganz schnell in die Sackgasse, und es geht am Prizip der Virtualisierung vorbei. Gruß, Nils

Moin, mit den Berechtigungen von NTFS ist vieles theoretisch möglich, was praktisch nicht funktioniert. Oft sind es Applikationen, die mit sehr speziellen Rechten nicht klarkommen. Das "Mailbox"-Beispiel ist da ein Klassiker. Solche Spezialitäten können funktionieren, wenn man einen ganz genau umrissenen Anwendungsfall hat und eine Applikation, die genau dafür gemacht ist. Als allgemeine Lösung sind sie meist untauglich. Als Leitlinie sollte gelten: Berechtigungen so einfach wie möglich und mit so wenigen Ausnahmen wie möglich. Gruß, Nils

Moin, Hyper-V ist keine Sache des Mainboards, sondern des Prozessors. Die CPU muss Virtualisierung (Intel-VT oder AMD-V) und (im Fall von Client-Hyper-V, also unter Windows 8/8.1) auch SLAT unterstützen. Ob das der Fall ist, siehst du in den Spezifikationen der CPU-Hersteller. Die meisten CPUs für Desktops und Server können das. Die nächste Version von Hyper-V braucht SLAT auch für den Server, die aktuelle noch nicht. Gruß, Nils

Moin, "suspend" ist eine Aktion, die für Pipelines gedacht ist, also wenn du mehrere Cmdlets miteinander verkettest. Du kannst damit bei einer Rückfrage die Pipeline anhalten und etwas anderes machen, z.B. dir manuell Zwischenergebnisse ansehen. Mit "exit" kannst du die Unterbrechung beenden und die Pipeline fortsetzen. Bei einem einzelnen Cmdlet ist das wirkungslos, und in deinem Beispiel ist es eigentlich auch sinnlos. Es ist halt eine Standardabfrage, die diese drei Möglichkeiten vorsieht. Gruß, Nils

Moin, ob es tatsächlich so ist, wie du es beschreibst, lässt sich ohne exakte Analyse des Codes und der tatsächlichen Vorgänge nicht beurteilen. Allgemein sollten natürlich Transaktionen so kurz wie möglich gehalten werden. Neben Abbrüchen könnte es sonst auch zu Sperrkonflikten usw. kommen. Es wäre allerdings sehr ungewöhnlich, wenn das Programm sich tatsächlich so verhalten würde, wie du beschreibst. Daher gebe ich hier keine Bewertung ab. Nur so viel: In komplexen Situationen wie der beschriebenen liegen die Dinge oftmals anders, als man denkt. Dass du selbst allerdings einräumst, dass es "Wackler" im Netzwerk gibt, sollte dich zu einer gewissen Kooperationsbereitschaft bringen. Gruß, Nils

Moin, gut, und jetzt plustern wir uns alle mal wieder ab. Danke. Gruß, Nils

Moin, MS-DOS Mobile "funktioniert" sogar. Da haben die sich wirklich Mühe gegeben. ;) Wer ein Windows Phone hat, findet es im Store. Tipp: In den GAMES-Ordner wechseln und versuchen, RPS zu Laufen zu bekommen. :D Gruß, Nils

Moin, sowas bekommt man durchaus auch mit Bordmitteln hin. Es braucht dazu nur die nötigen Berechtigungen auf den Objekten und ein Tool, mit dem man die Verwaltung dann vornehmen kann. Vielleicht eignet sich schon ADAC ab Windows Server 2012 dazu (hab ich mit delegierten Berechtigungen noch nicht probiert). Grundsätzlich dürfte es auch mit ADUC gehen. Hier ein Ansatz, das mit einem kleinen skriptbasierten Werkzeug zu machen: [AD-Adressen im Sekretariat bearbeiten lassen | faq-o-matic.net] http://www.faq-o-matic.net/2008/06/23/ad-adressen-im-sekretariat-bearbeiten-lassen/ Gruß, Nils

Moin, MS-DOS Mobile ist auch hübsch: https://youtu.be/irJQDGw8Ptk Vor allem der britische Akzent. :) Gruß, Nils

Moin, das kriegt man ja nun auch in Excel hin. Wenn man in Scripting nicht fit ist, ist das meist die bessere Wahl. Gruß, Nils

Moin, das wird nur mit hohem manuellem Aufwand gehen, denn bei "historischen" Daten wird ja jemand entscheiden müssen, was Sache ist. Du kannst dir höchstens mit den Mitteln von Excel (oder, wenn du das umsetzen kannst, vielleicht mit Skripten) den Prozess etwas erleichtern, aber was du dazu genau tun musst, dürfte sehr individuell sein, daher kann man dir da kaum eine Anleitung geben. Gibt es denn ein Feld, das in allen Welten die Konten eindeutig identifiziert? Sowas wie Mailadresse, Personalnummer oder so? Wenn ja, dann wäre das der Anker, auf dessen Basis du den Vergleich bauen könntest. Gruß, Nils

Moin, eine herkömmliche GP-Einstellung gibt es dafür nicht, aber per GPP solltest du das lösen können. Gruß, Nils

Moin, ich meine: Das ganze Verfahren ist "error-prone", d.h. es kann sehr leicht was schiefgehen. Wenn es keinen zwingenden Grund gibt, würde ich das in einer produktiven Umgebung immer vermeiden. Und "es ist so aufwändig, meine Applikationen neu einzurichten" würde ich zumindest nicht direkt auf der Liste zwingender Gründe sehen. Du kannst ja mal nach "rendom problem" oder ähnlich googeln. Ja, Domain Rename kann klappen. Aber es muss nicht. Gruß, Nils

Moin, ganz falsche Baustelle. Da geht es um die Verwaltung von Konten im AD, nicht um das Zuweisen von Rechten an AD-Konten auf einem lokalen Rechner. Und selbst wenn: Die Konten-Operatoren verwendet man bitte nicht. Schon seit NT nicht mehr. Die vorgeschlagenen Wege, den Account in die lokale Admin-Gruppe aufzunehmen, sind die Lösung dazu. Also hat Microsoft sehr wohl was dafür ... man muss eben nur von Anfang an sagen, was man eigentlich will. Sonst doktorn alle an den Problemen der Lösung herum, statt eine Lösung für das Problem zu finden (wie ich oft und gern sage). Gruß, Nils

Moin, fragen wir erst mal anders: Warum soll der Remote-User überhaupt per vmconnect zugreifen? Reicht eine RDP-Verbindung nicht aus? Ich habe leider gerade keine Zeit, die Schritte zu verifizieren, die ggf. noch nötig sind. Gruß, Nils