NilsK

Moin, Wie kommst du auf die Idee, dass die Namensauflösung nicht funktioniert? Deine Angaben lassen diesen Schluss nicht zu. nslookup ist kein Werkzeug, um die Funktion der Namensauflösung zu prüfen. Gruß, Nils

Moin, Die Dateien enthalten den "Guest State", also Konfigurationsdaten der Versionen 8.2 und höher, die früher Teil der eigentlichen VM-Dateien waren. Einzeln kannst du damit nichts anfangen. Wenn sie Datensicherung sie übrig lässt, ist die dafür verwendete Software vielleicht zu alt für die aktuelle Hyper-V-Version? Du solltest mal prüfen, ob du VMs richtig wiederherstellen kannst. Alte Backup-Software, die die VMGS-Dateien nicht kennt, scheitert nämlich meist beim Restore. Gruß, Nils

Moin, naja, Quickwins sind das nicht, sondern eher Abschnitte einer sehr umfassenden Aufgabenliste. Man mache sich nichts vor, das ist richtig Aufwand. Gruß, Nils

Moin, ich ergänze mal, dass Monitoring gut und wichtig ist, dass aber der oft kolportierte "proaktive"* Gedanke fast nie hinhaut: Monitoring verhindert so gut wie keine Ausfälle, es kann nur dazu beitragen, diese kurz zu halten. Gruß, Nils * ein unsinniges Wort, das es eigentlich gar nicht gibt.

Moin, normal ist es jedenfalls nicht. Aber vermutlich ein Bedienungsfehler. Siehe Jans Nachfrage. Gruß, Nils

Moin, liebe Leute, von der TO haben wir seit dem Eröffnungspost vor fast zwei Monaten nichts mehr gehört. Lassen wir diesen Thread in Frieden ruhen. Gruß, Nils

Moin, ein Problem des Datentyps? Das SID-Feld ist sehr speziell. Gruß, Nils

Moin, wenn du mit Delegation im AD arbeiten willst oder musst, geht an dsacls ohnehin kein Weg vorbei. Das GUI hilft nicht nur nicht, sondern es verhindert, dass man vorankommt. Hier noch eine Standardquelle, da ist auch ein dsacls-Skriptgerüst dabei: [AD-Adressen im Sekretariat bearbeiten lassen | faq-o-matic.net] https://www.faq-o-matic.net/2008/06/23/ad-adressen-im-sekretariat-bearbeiten-lassen/ Und noch was zum Thema: [ice:2010 AD-Delegation – die Folien und Skripts | faq-o-matic.net] https://www.faq-o-matic.net/2010/08/14/ice2010-ad-delegation-die-folien-und-skripts/ Gruß, Nils

Moin, verstehe, das sind ja bestimmt auch zwei Stunden Zeit, eine Testumgebung mit VMs aufzubauen. Dann wird dir wohl nichts übrig bleiben, als weiter auf eine Produktionsumgebung zu verzichten, wenn du die vorhandene zum Testsystem umfunktionieren musst. </ sarcasm> Dann formuliere ich mal positiv: Wie du jetzt durch das Lahmlegen erfahren hast, ist es sinnvoll, Änderungen dieser Art in einer unkritischen Testumgebung durchzuspielen. Da wir aus deinen Schilderungen auch nicht jedes Detail aus der Ferne einschätzen können, wird dir das mehr Handlungssicherheit geben. Gruß, Nils

Moin, Du kannst das nicht in einer Testumgebung ausprobieren? Gruß, Nils

Moin, Ja, das ergibt Sinn. Dann scheint mir das auch ein angemessenes Verfahren zu sein. Gruß, Nils

Moin, Wie entsteht denn überhaupt der Bedarf? Warum braucht es für "die wichtigsten" Einstellungen 30-40 GPOs, und warum werden so viele Domänen erzeugt? Gruß, Nils

Moin, in dem Szenario könntest du den automatischen Start und die Verzögerung z.B. über einen geplanten Task selbst bauen. Wenn du dann keinen Autostart willst, schaltest du den Task ab. Hab ich so schon bei Kunden gesehen, meine ich. Mit der eingebauten Automatik kriegt man das vielleicht auch hin, aber dazu habe ich mangels Bedarf keinen Tipp. Gruß, Nils

Moin, was genau willst du erreichen? Dass die VM sofort startet? Oder dass sie gar nicht startet? Gruß, Nils

Moin, Jupp, das auch Gruß, Nils

Moin, Gut: 1. Gar nicht, weil es eine maximale Zahl nicht gibt. Du kannst dir am Ende nur anschauen, wie eine konkrete Umgebung läuft und das ggf. per Monitoring untermauern. Der Task Manager hilft dabei nicht, er führt normalerweise eher in die Irre. Als Faustregel: zwischen 2:1 und 20:1 trifft man alles an, das kann auch alles in der jeweiligen Situation passen. 20:1 passt aber längst nicht überall, und 2:1 ist meist übertrieben konservativ. Allerdings gibt es Software, die nur mit 2:1 von deren Hersteller Support kriegt. In gemischten Umgebungen würde ich mir bei 4:1 oder 8:1 keine größeren Sorgen machen. 2: das geben die Applikationen in den VMs vor, nicht die Host-Umgebung. Auch hier ist also keine pauschale Aussage möglich. In der Praxis sehe ich eher zu "dicke" als zu "dünne" Konfigurationen. Einem DC würde ich kaum jemals mehr als 2 vCPUs geben, ein SQL Server kann damit auch gut laufen, wird aber oft auch in kleineren Umgebungen mit 4 besser laufen, manchmal auch 8. Auch dies muss man sich konkret ansehen. Ja, auch ich stimme also den anderen zu. Und nein, eine VM, die nichts zu tun hat, läuft mit mehr CPU nicht besser. Sie langweilt sich nur schneller. Gruß, Nils

Moin, Ich habe deine Frage überhaupt nicht verstanden. Kannst du bitte noch mal knapp beschreiben, was du wissen möchtest? Gruß, Nils

Moin, ergänzend dazu: Die GUI-Funktionen sind manchmal nicht direkt auf einzelne AD-Attribute gemappt, sondern es kann auch sein, dass sie z.B. Funktionen aufrufen. Daher müsstest du zunächst mal rausfinden, welche Berechtigungen denn tatsächlich benötigt werden. Andersrum kann es aber auch sein, dass das GUI mehr zu ändern versucht, als du eigentlich vorhast. Manche Registerkarten mit z.B. fünf Einträgen versuchen alle zu ändern, auch wenn man nur den Eintrag in einem der Felder verändert hat. Hier wäre also im Zweifel zu prüfen, ob es mit einer anderen Art des Zugriffs geht. Gruß, Nils

Moin, da, wo du den Code herhast, steht doch sicher dabei, wie der genutzt werden soll. Gruß, Nils

Moin, wenn wir dich hier sinnvoll unterstützen sollten, wäre es sinnvoll, dass du a) den Aufbau und b) das beobachtete Verhalten noch mal genau beschreibst. Das scheint mir hier etwas durcheinander zu gehen. Gruß, Nils

Moin, Ach so, dann hatte ich das missverstanden. Aber dann scheint mir der Client einen Hau zu haben. Gruß, Nils

Moin, typischerweise passiert dabei Folgendes: Windows merkt, dass seine (virtuelle) Netzwerkkarte nicht mehr funktioniert, weil diese ja auf die Hyper-V-Integrationsdienste zugreift. Es findet aber eine neue Netzwerkkarte, die vom neuen Hypervisor bereitgestellt ist. Windows überträgt die Konfig der alten Karte auf die neue und deaktiviert die alte Karte. Allerdings verschluckt sich das Betreibssystem dabei an der alten IP-Kofiguration, die noch an die alte, deaktivierte Karte gebunden ist. Das kann unterschiedliche Effekte hervorrufen - beispielsweise den, den du gerade siehst. Typische Abhilfe: [Migration von Hyper-V VMs zu anderem Hypervisor (V2V) – Wichtige Nacharbeit! | faq-o-matic.net] https://www.faq-o-matic.net/2016/07/06/migration-von-hyper-v-vms-zu-anderem-hypervisor-v2v-wichtige-nacharbeit/ Gruß, Nils

Moin, SetACL oder mit GUI SetACL Studio. https://helgeklein.com/setacl/ https://helgeklein.com/setacl-studio/ Gruß, Nils

Moin, Evgenij, was mich jetzt noch interessieren würde: was würdest du unter einer langen Ausführung verstehen? SCNR, Nils PS.

Moin, um das noch mal näher zu beschreiben: vereinfacht gesagt, würde ich da überhaupt nichts mit den Profilen machen. Wenn überhaupt, dann mit bestimmten Nutzdaten - schon das ist im Detail hakelig genug, aber zumindest ist es ein viel geringerer Umfang. Meiner Beobachtung nach gibt es in den meisten "Fat-Client-Umgebungen" den Anwendungsfall "derselbe User meldet sich dauernd an unterschiedlichen Geräten an" in Wirklichkeit sehr selten oder sogar überhaupt nicht. Also muss man Profile auch nicht übertragen. In den Fällen, wo bei Teilen der Anwenderschaft so eine Nutzung vorkam, habe ich dann oft in der Beratung festgestellt, dass die Grundidee von Roaming Profiles zwar hübsch ist, dass es in Wirklichkeit aber meist ohne geht. Bleibt also oft nur ein kleiner Rest, für den man das lösen muss. Wohlgemerkt: Nur meine Wahrnehmung. Das kann im konkreten Fall anders sein. Aber das ist der Grund, warum ich dazu neige, komplett davon abzuraten, statt Workarounds zu finden oder teure Spezialprodukte zu kaufen. Gruß, Nils