NilsK

Moin, wie jeder Hypervisor* braucht Hyper-V für seine Arbeit als Host natürlich Arbeitsspeicher. Wieviel das im konkreten Fall ist, hängt von den Details des Hosts ab. Mit 8 GB hätte ich jetzt auch nicht unbedingt gerechnet, aber wenn das so ist, braucht der Host es eben. Leider gibt es in Windows Server 2016 keine einfache Möglichkeit mehr, den benötigten Wert herauszufinden. Warum ist NUMA abgeschaltet? Vielleicht könnte es in deiner Situation helfen. Dass du etwa sagst "ich bekomme nichtmal beide 20GB VMs gestartet" deutet darauf hin, dass die NUMA-Grenzen zum Problem beitragen. Die Host-Reserve fest einzustellen, ist mindestens "not recommended", vielleicht ist es sogar "unsupported". Und selbst wenn, würde man es nicht wollen, denn es nähme dem Host die Reserven, die er ja nun mal braucht. Es gibt also drei Möglichkeiten: Das statische RAM der VMs reduzieren (geht in den allermeisten Fällen - ein DC etwa braucht mit Sicherheit keine 8 GB, in den meisten Umgebungen reichen sogar 2 GB), bei einzelnen VMs auf Dynamic Memory schalten (wäre für den DC etwa gangbar) oder den Host-RAM erweitern. 64 GB ist heute für einen Hypervisor gering. Gruß, Nils * die anderen brauchen ähnlich viel, vertuschen das aber, weil sie Memory Overcommit zulassen. Das macht Hyper-V aus durchaus validen Gründen nicht.

Moin, also nur die Namensauflösung für die Domäne dauert so lange? Und nur bei diesen Clients? Es gibt also Clients, die dort keine Verzögerung haben? In dem Fall kann es ja kein (allgemeines) Netzwerkproblem sein. Dann ist irgendwas an dem Image nicht OK. Es ist nicht unbedingt gesagt, dass der Client während der Zeit nicht aufs Netzwerk zugreift. Vielleicht wirkt ein Netzwerktrace ja erhellend. Eine vage Idee, die ich noch habe, betrifft die AD-Site-Einstellungen der Clients. Ich habe leider keine Zeit, das vorzusortieren, aber vielleicht willst du hier mal gucken. Möglicherweise enthält euer Image Konfigurationen, die genau die Abfrage der DCs betreffen. https://technet.microsoft.com/en-us/library/cc978016.aspx http://www.windowsnetworking.com/kbase/WindowsTips/Windows2003/AdminTips/ActiveDirectory/DynamicSiteNameandSiteNameWhichsiteaclientcomputerbelongsto.html http://www.windowsnetworking.com/kbase/WindowsTips/WindowsServer2012/AdminTips/ActiveDirectory/there-any-way-clear-dc-locator-cache-windows-client-computers.html Gruß, Nils

Moin, da hat der Netzwerkmensch evtl. auch nichts mit zu tun. Die Verzögerung passiert ja anscheinend auf dem Client, bevor er überhaupt aufs Netzwerk zugreift. Ist das bei allen Clients? Wieviele sind das? Sind alle Netzwerkzugriffe so verzögert? Dasselbe Verhalten bei ping auf IP-Adresse und ping auf Name? Oder nur beim ping auf den Domänennamen? Gruß, Nils

Moin, dann solltest du dir aber noch mal Gedanken zum Design machen. Für Testzwecke oder ganz spezielle Szenarien mag das gehen, in Produktion würde ich das nicht machen wollen. Gruß, Nils

Moin, ping hängt 20 Minuten, bevor es überhaupt loslegt? Das hab ich noch nie gesehen. Schieb in den Bindungen mal den (funktionierenden) WLAN-Adapter nach oben, danach den LAN-Adapter. Ändert das was? Gruß, Nils

Moin, was heißt ? Du machst Dauerping, der schlägt 20 Minuten fehl, dann geht es? Was die Netzwerkkarten betrifft: Einen solchen virtuellen WLAN-Adapter legt Windows m.W. nur auf Anforderung an. Da muss es also eine Komponente oder Konfig geben, die das bewirkt, vielleicht ein Haken im Treiber-Setup. Wenn dem so ist, schalte die Funktion mal ab. Das sieht mir zumindest nach einem Verdächtigen aus. Wie ist die Bindungsreihenfolge der Netzwerkadapter? Unter Windows 7 spielt die noch eine Rolle. Vielleicht versucht WIndows erst vergeblich, über nicht funktionierende Adapter zu sprechen. Gruß, Nils

Moin, was meinst du mit ? Willst du eine VM installieren, die DC ist? Dann geht das rein technisch schon, den Host in die Domäne der VM aufzunehmen. Ob es sinnvoll ist, steht auf einem anderen Blatt. Gruß, Nils

Moin, äh - nein. Ein DC mit einem neuen OS hebt immer das Schema an. Ein "Level" der Datenbank gibt es nicht, schon deshalb nicht, weil ja jeder DC seine eigene Datenbank hat. Und natürlich können ältere DCs mit einem neueren Schema arbeiten. Kann es sein, dass du hier den Betriebsmodus und das Schema verwechselst? Gruß, Nils

Moin, wenn ihr sowieso neu installieren wollt, dann baut eine neue VM. Eine vorhandene VM neu zu installieren, ist nicht sinnvoll. Der Eintrag "file" wird bei der Installation des Betriebssystems automatisch gesetzt. Da du Secure Boot aktiviert hast, lässt Hyper-V da auch nichts anderes zu und entfernt die anderen Einträge daher. Grundsätzlich sollte es möglich sein, die Bootreihenfolge nachträglich mit Set-VmFirmware zu definieren - aber wie gesagt, sinnvoller ist es, eine neue VM zu erzeugen. EDIT: Insbesondere wenn die VM repliziert ist, würde ich keine Neuinstallation machen. Das reduziert den Aufwand nun wirklich nicht. Gruß, Nils

Moin, warum hast du einen "Microsoft Virtual WiFi Miniport Adapter" mit derselben MAC-Adresse wie der WLAN-Adapter? Ist der Rechner als virtueller Hotspot eingerichtet? Verschwindet das Problem, wenn du das abschaltest? Ich bin mir nicht sicher, meine mich aber zu erinnern, dass das mal eine experimentelle Funktion war, die oft nicht ordentlich arbeitet. Gruß, Nils

Moin, der Teil "Supported Active Directory environments" in der Supportability Matrix (https://technet.microsoft.com/en-us/library/ff728623(v=exchg.150).aspx) bezieht sich darauf, dass Exchange einen solchen DC erreichen können muss. Es dürfen andere DCs in der Umgebung existieren. Analog gilt das ja auch für RODCs, die in der Einleitung erwähnt werden: Exchange kann mit denen nicht sprechen, aber es darf welche geben. Die Schemaerweiterung ist in keinem Fall ein Problem (sonst gäbe es auch eine Tabelle dazu), denn praktisch alle Änderungen dort erweitern das Schema nur (nur in wenigen Fällen ändern sich Eigenschaften bestehender Objekte, die dann aber nicht zu Problemen führen sollten). Es geht eher um Funktionen, die die neueren DCs nicht oder in anderer Weise bereitstellen, sodass Exchange sie nicht versteht. Es sollte also gehen. Ob man in Exchange tatsächlich in dem Fall einen DC direkt eintragen muss, kann ich nicht sagen. Gruß, Nils

Moin, vielleicht irgendeine Extension im Explorer, die beim Zugriff von selbst etwas macht? Gruß, Nils

Moin, das klingt, als fehle der Private Key. Gruß, Nils

Moin, nur Nano unterliegt der CBB-Politik (Current Branch for Business), muss also alle paar Monate aktualisiert werden. Das geschieht im Unterschied zum Client aber nicht automatisch. Nano eignet sich also nur für kurzlebige Systeme. Gruß, Nils

Moin, in Beitrag #8 war ein Artikel verlinkt, der die Hintergründe gut darstellt. War mir in dem Detailgrad auch nicht bekannt. Da ich aber kaum noch NetApp-Kunden betreue, kommen mir NFS-Datastores auch nur noch selten unter. http://www.mcseboard.de/topic/208895-exchange-2010-iscsi-vs-nfs/?do=findComment&comment=1318413 Gruß, Nils

Moin, eine saubere Lösung wirst du nicht ohne die IT der Organisation hinbekommen. Sprich mit denen, um zu einem funktionierenden Konstrukt zu kommen. Jeder Workaround, der die vorgegebenen Strukturen irgendwie umgeht, fällt dir schnell auf die Füße - so auch der Domainsuffix per GPO, das ist immer wieder eine Fehlerquelle. Gruß, Nils

Moin, warum dieser Ton? Und: Das ist doch in diesem Thread bereits diskutiert und belegt worden. Wir müssen das ja nicht wiederholen - nachlesen reicht. :D Gruß, Nils

Moin, vielleicht eine falsche bzw. ungünstige Bindungsreihenfolge bei den Win-7-Clients? Ich meine, dass Windows 7 da noch mehr Abhängigkeiten hat als die jüngeren Systeme. Gruß, Nils

Moin, naja, eben nicht. Es ist für Exchange dann ja nun mal nicht supportet. Das habe ich in diesem Thread ja auch gelernt. ;) Gruß, Nils

Moin, zeigt sich die Verzögerung auch bei interner Namensauflösung? Kannst du mal ein ipconfig -all von einem "schnellen" und von einem "langsamen" Client posten? Gruß, Nils

Moin, da hast du natürlich Recht. Sehr sozial gedacht. Gruß, Nils

Moin, ja, ziemlich genau so verlaufen die Diskussionen üblicherweise. Da ich allerdings gar nichts beweisen muss, müssen wir das auch nicht fortführen. Ich weise nur auf meine Erfahrung mit "sowas" hin - ist ja weder mein "Backup" noch mein System. Gruß, Nils

Moin, wie - und so ein Satz von dir? :D Ein Kennwort gehört nicht in ein Skript. Auch nicht verschleiert. Und auch nicht, wenn der User aufs AD "nur" Leserechte hat. Wenn ein CSV-Export erzeugt wird, klingt das für mich nach einer einmaligen Sache. Auch wenn dafür ein Remotezugriff nötig ist, braucht das Kennwort für sowas nicht im Skript zu stehen - man könnte es bei der Skriptausführung anfordern und gesichert übergeben. Gruß, Nils

Moin, kann man so machen - aber wenn ihr sowieso mit einem CSV arbeitet, warum exportiert ihr die Daten nicht einfach an der Quelle? Das ist viel einfacher, und ihr braucht keinen Useraccount, dessen Kennwort ihr in einem Skript im Klartext hinterlegt. Gruß, Nils

Moin, der TO berichtet von Problemen. Und sowas höre ich immer wieder, dabei erstaunlich oft in NetApp-Umgebungen. Ich glaube auch, dass die Tolles können. Möglicherweise ist es auch der Umgang der Admins damit. Jedenfalls erlebe ich zu oft Probleme mit solchen Sicherungsmethoden, als dass ich ihnen einfach so vertrauen würde. Daher meine Predigt. ;) Gruß, Nils