NilsK

Moin, standardmäßig sind es 20 Sekunden - über alle verfügbaren Pfade. Dabei nutzt der Client die Hälfte der Zeit für den ersten Pfad und versucht erst dann den zweiten. Nach der Hälfte der verbleibenden Zeit den dritten usw. Wenn also erst am Ende ein erreichbarer Pfad steht, kann es sein, dass die Zeit nicht mehr für den Download reicht. Die CRL-Pfade sind also auch eine wichtige Designfrage. Der erste sollte immer verfügbar sein. Gruß, Nils

Moin, ich nehme mal an, dass die Software einen Treiber oder etwas in der Art einbindet, um das zu erreichen. Mit Bordmitteln ist es m.W. nicht möglich. Gruß, Nils

Moin, ich tute ja ungern in das Horn - aber besonders Vertriebler erzählen einem schon mal Dinge, die nicht ganz zutreffen und die von der "offiziellen" Linie des Unternehmens abweichen. Wenn ein Mitarbeiter von Unternehmen X erzählt, die Erde sei eine Scheibe, dann ist das ja auch noch lange keine Aussage des Unternehmens. Diese Erkenntnis bringt uns bei dem Thema hier aber auch nur bedingt weiter. Sie hat ja noch nicht mal was mit dem RAM-Thema zu tun. Kommst du gleich auch noch mit Dingen, die bei der Xbox schlechter sind als bei der PS4? Gruß, Nils

Moin, jaja. Auch wenn das immer behauptet wird, hat "Microsoft" das nie erzählt. Das Feature stand von Anfang an auf der Liste, ist nur eben sehr spät fertig geworden. Man kann das zu Recht kritisieren, aber nicht mit Märchen. :D Da wir über Hyper-V reden: Dynamic Memory ist eine hübsche und einfache Möglichkeit, den tatsächlichen RAM-Bedarf herauszufinden. Man beobachtet, wieviel Speicher verwendet wird und weist diesen Wert dann statisch zu (wenn man mit statischem Arbeitsspeicher arbeiten will). Ich denke aber, dass in diesem Thread alles Nötige gesagt wurde, anscheinend auch mittlerweile von jedem. :D Gruß, Nils

Moin, schön, dass das mal jemand mit konkreten Werten bestätigt. Ich predige das ja seit Jahren. :D Gruß, Nils

Moin, dazu hab ich ja nun schon eine Menge geschrieben. Wenn die Situation also so ist, wie du beschreibst, dann probier das eine oder andere davon aus, statt dich zu verweigern und weiter zu meckern. Gruß, Nils

Moin, jeder DC ist in DNS nur der Site zugeordnet, an der er sich wirklich befindet. Bring das AD und die Clients nicht durcheinander, indem du willkürlich weitere EInträge vornimmst! Das Failover auf einen anderen Standort geschieht automatisch, wenn am eigenen Standort kein DC antwortet. Wenn du willst, kannst du dieses Verfahren anmelden, um den Failover auf einen anderen DC zu steuern. Das setzt aber voraus, dass die Site-Konfiguration minutiös aufgebaut und korrekt ist. [Enabling Clients to Locate the Next Closest Domain Controller] https://technet.microsoft.com/en-us/library/cc733142(v=ws.10).aspx Gruß, Nils

Moin, Glückwunsch! Und danke für die Rückmeldung. Gruß, Nils

Moin, wie geil! :) Danke für die Aufklärung! Wenn man mit dem Wissen googelt, findet man auch andere mit demselben Problem. Darunter auch Hinweise, wie man den Dienst deaktiviert, ohne ihn umbenennen zu müssen. Gruß, Nils

Moin, hm, OK, dann kann man das schon so machen. Korrigiere mal deine SET-Anweisungen, vermutlich geht es dann schon. Einen Schönheitspreis bekommt das Skript nicht, aber das ist ja auch nicht das Ziel. ;) Gruß, Nils

Moin, bevor wir an den Problemen deiner Lösung herumdoktorn, sollten wir versuchen, eine Lösung für dein Problem zu finden. Also: Was ist das, was am Ende dabei herauskommen soll? Wer soll das Skript einsetzen, um damit was zu tun? Allgemein: Batch ist für solche Zwecke sehr umständlich, und die Fehlersuche ist oft unnötig schwer. Wenn du ins Scripting einsteigst, dann wäre PowerShell die bessere Empfehlung. Und: Wenn du ganz am Anfang einmal @echo off schreibst, brauchst du nicht jedes einzelne echo mit @ zu unterdrücken. Deine Variablenzuweisung scheitert wahrscheinlich an dem /P. Das setzt du nur, wenn der Anwender etwas gefragt werden soll. Gruß, Nils

Moin, deine Standort- und Subnetz-Zuordnung sieht schon ganz passend aus. Damit die Clients wissen, wo sie sich anmelden müssen, ist zweierlei nötig: die Clients müssen sich in dem Subnet befinden, das im AD ihrem Standort zugewiesen ist der jeweilige DC muss auch im DNS seinem Standort zugeordnet sein Der zweite Punkt ist manchmal nicht gegeben. Das kann passieren, wenn ein neuer DC zunächst am Hauptstandort installiert und dann nachträglich in die Ziel-Site verschoben wurde. In dem Fall passen meist die DNS-Einträge nicht, und man muss sie manuell nachtragen. Dann ist natürlich allgemein die DNS-Client-Konfiguration zu beachten: [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/ Und schließlich solte die Replikationstopologie der tatsächlichen Netztopologie entsprechen. Du gibst an, dass das Routing bei euch eingeschränkt ist und kein vollvermaschtes WAN vorliegt. Dann solltest du die Standorte auch nicht über den Default-Link verbinden, sondern die tatsächlichen Verbindungen mit Sitelinks abbilden. Sofern das Routing tatsächlich durch Firewalls oder technische Maßnahmen eingeschränkt ist, musst du außerdem das "Automatic Site Link Bridging" abschalten, damit die AD-Replikation sich nicht über die Wunsch-Topologie hinwegsetzt. Gruß, Nils

Moin, ich denke, es ist einfach die UAC. Über den Explorer bist du auch als Admin eingeschränkt. [Windows-Berechtigungen mit UAC verwalten | faq-o-matic.net] http://www.faq-o-matic.net/2015/12/23/windows-berechtigungen-mit-uac-verwalten/ Ich rate allerdings davon ab, aufs Geratewohl an den Berechtigungen rumzumachen. Dabei geht sehr schnell etwas kaputt. Und es hat auch seinen Grund, dass der Zugriff auf den Root-Ordner beschränkt ist. Da will man keine Datenmengen haben. Gruß, Nils

Moin, ganz ehrlich - dein Design ist nicht sinnvoll. Weder für den Host noch für die VMs. Gruß, Nils

Moin, nein, daran ist Hyper-V Schuld. Hat er doch oben schon gesagt. :D Gruß, Nils

Moin, ah, okay. Ja, dann hat vermutlich die Zeit nicht ausgereicht. Gruß, Nils

Moin, wie Norbert schon sagt: seit Windows 2012 führt Hyper-V gelöschte Snapshots automatisch zusammen. Ein Shutdown der VM ist nicht nötig. Das Phänomen, das du beobachtest, wird also einen anderen Grund haben. Was gibt denn Get-VMSnapshot -VMName <Name der VM> in der PowerShell zurück? Gruß, Nils

Moin, wenn der Client bootet, versucht er seine Lease zu erneuern oder, falls er keine hat, eine neue zu bekommen. Läuft er durch, dann versucht er nach 50% der Lease-Zeit die Lease zu erneuern (per Unicast). Klappt das nicht, dann versucht er es nach 87,5% der Lease-Zeit erneut, diesmal per Broadcast (aber mit der bestehenden Adresse). Kann er auch dann nicht verlängern, dann verwirft er am Ende der Lease-Zeit seine Konfiguration und beginnt ein komplett neues DHCP Discover (per Broadcast, Adresse 0.0.0.0). Bleibt auch dies erfolglos, dann macht er APIPA. Ist die Erneuerung erfolgreich, dann beginnt die neue Lease-Zeit zum Zeitpunkt der Erneuerung. https://technet.microsoft.com/en-us/library/cc780760(v=ws.10).aspx#w2k3tr_dhcp_how_jxgw Gruß, Nils

Moin, spannend. Wenn man Zeit hat, das forensisch zu untersuchen, wäre es sicher interessant, den Grund dafür zu suchen. Sonst würde ich abwägen, ob man damit leben kann oder ob man die Clients neu installiert. Gruß, Nils

Moin, ... und fallen damit böse auf die Nase, wenn es interessant wird. Wir müssen das hier nicht wiederholen. Es gibt Gründe, warum Hyper-V sowas nicht macht. Damit ist es nicht pauschal besser, aber nach meinem Dafürhalten deutlich besser vorhersagbar. Das Problem ist nicht, wie Memory Overcommit umgesetzt ist. Das Problem ist, dass man es braucht - und das hat der Admin in der Hand. Gruß, Nils

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