NilsK

Moin, vermutlich an 23 Druckern, zu denen eine Netzwerkverbindung hergestellt werden muss. Klingt nicht unbedingt nach Wunschdesign. Trotzdem gibt es ja offenbar Netzwerkprobleme, jedenfalls deuten deine Logs darauf hin. Das verstärkt das Problem mindestens, anscheinend sorgt es aber auch direkt für Fehler. Gruß, Nils

Moin, dann hab ich ja noch Glück gehabt, dass du mir das gesagt hast, kein Kunde. Gruß, Nils

Moin, Alter, muss sich denn alles ändern? Dafür bin ich mittlerweile zu alt. Also, du hast natürlich auch hier Recht. Offenbar gibt es Windows 10 Enterprise auch ohne SA. Ich bin mir ziemlich sicher, dass früher die Enterprise-Fassung eine SA vorausgesetzt hat. Anscheinend ist das nicht mehr so. Damit ist meine obige Aussage jetzt unvollständig und Zahnis Ergänzung notwendig. Das VDA-Recht hängt an der SA. Wenn man eine Umgebung plant, sollte man mit einem kundigen Berater immer prüfen, ob das konkrete Szenario wirklich abgedeckt ist - bei dem macOS-Szenario bin ich mir gerade nicht mehr so sicher, ob das wirklich drin wäre. Gruß, Nils

Moin, ja, nimm die 015 raus. Das braucht man nicht, und es führt im Zweifel nur zu Problemen - so etwa in deinem Szenario. Gruß, Nils

Moin, hm, ja, stimmt. Bei 2008 war es 1+1 (Host und 1 VM). das ist korrekt, aber Enterprise setzt ohnehin SA voraus. Ohne SA gibt es nur Professional. Nimmt man zu Professional die SA hinzu, hat man Enterprise. Das VDA-Zugriffsrecht ist ein SA-Feature, insofern hast du natürlich Recht. Gruß, Nils

Moin, ich glaube, du hast diese Optionen nicht richtig verstanden. Abgesehen davon, ist ein lokaler Admin eben lokaler Admin. Maßnahmen wie die genannten können evtl. in einem Gesamtkonzept eine Rolle spielen, aber es gibt kein kleines, überschaubares Set von Einstellungen, das Sicherheit "herstellt". Solange nicht klar ist, was denn erreicht werden soll und vor welchen konkreten Gefahren du dich schützen willst, kann man keine passende Lösung entwerfen. Wobei je nach Anforderung eine Lösung durchaus ein größeres Projekt zur Entwicklung erfordern kann. Allgemeine Anregungen findest du im Web zuhauf. Wenn dann konkrete Fragen bestehen, können wir die gern diskutieren. Gruß, Nils

Moin, mit der einen Lizenz ist der Host lizenziert (solanger er nur Host ist) und zwei Windows-Server-VMs. Das ist seit Windows Server 2008 so. https://www.youtube.com/watch?v=6tH3QGSRP00 Gruß, Nils

Moin, lol. Du sprichst wahr. Wenn man mehr darüber wüsste, wie denn die Umstellung geplant ist und wie groß das Netz ist, könnte man mehr Sinnvolles dazu sagen. Vorausgesetzt, das Routing zwischen beiden Netzbereichen ist sichergestellt, dann sollten sich Aufwand und Risiko in Grenzen halten. Du könntest dann DC1 ins neue Netz stellen und DC2 zunächst im alten Netz belassen. Die weiteren Server und die Clients stellst du sukzessive um. Gegen Ende kommt DC2 dann auch ins neue Netz. Parallel mehrere IP-Adressen für die DCs würde ich eher nicht machen. Mit Routing ist das auch nicht nötig. Also im Wesentlichen bei DC1 die neue IP-Adresse eintragen, Anmeldedienste neu starten und nach ein paar Minuten prüfen, ob die DNS-Einträge sich aktualisiert haben. Falls nein, manuell korrigieren. Später dasselbe Spiel mit DC2. Ich sehe da eigentlich kein ernsthaftes Problem. Gruß, Nils

Moin, du brauchst 1 Lizenz Windows Server 2016 Standard, 1 Lizenz Windows 10 Enterprise (für die Client-VM) und pro Client 1 2016-CAL (egal welches OS). Enterprise deshalb, weil dort m.W. die Lizenz auch den Zugriff auf die Client-VM enthält. Du lizenzierst bei Server-VMs immer den Host, nie die VMs. Die Standard-Lizenz umfasst 2 VMs mit Windows Server. Gruß, Nils

Moin, ja, im Wesentlichen musst du sicherstellen, dass alle Clients alle Namen richtig auflösen können. In der Koexistenzphase bedeutet das ohnehin alle Namen aus der alten und der neuen Domäne. Ob man das per Forwarding macht, per Stub-Zone, per Secondary oder wie auch immer, ist aus der Sicht nebensächlich. Natürlich müssen auch die IP-Grundinformationen stimmen, das Gateway etwa. Dann ist es während der Migration egal, welchen DNS-Server die Clients fragen, das könnte durchaus der "alte" sein. Irgendwann ändert man das im DHCP und gut. Mit "Sonderlocken" meinte ich sowas wie WINS-Server, Domänennamen oder so, halt die (wenigen) Sachen, die man Windows per DHCP so mitgeben kann. Das müsste man dann rausnehmen, falls es bisher vorhanden war. Alles Weitere kann man nur beurteilen, wenn man sich genau mit der Umgebung beschäftigt. Das kann gar nichts sein oder eine ganze Menge ... Gruß, Nils

Moin, dann klingt das nach Routingproblem. Das würde auch die Logmeldungen erklären. Gruß, Nils

Moin, auf deinem Screenshot von dem Client ist ein aktives VPN zu sehen, parallel zur LAN-Verbindung. Solche Konstrukte führen regelmäßig zu dem von dir beobachteten Problem. Gruß, Nils

Moin, ja, das ist richtig. Das Thema wird auch schon eine Weile in der Microsoft Product Group diskutiert, aber die bekannten Fälle scheinen im Detail so unterschiedlich zu sein, dass es dort nicht vorangeht. Daher wäre ein Supportcall weiterhin empfehlenswert - vielleicht löst der das Problem, aber wenn nicht, dann ist das wenigstens ein zusätzlicher offizieller Problemhinweis an den Hersteller. Gruß, Nils

Moin, ich tippe mal auf das VPN, das dem Client da in die Quere kommt. Gruß, Nils

Moin, man testet nicht in einer Produktionsumgebung. Auch nicht auf "unkritischen" Servern. Punkt. Die Veeam-Checkpoints funktionieren aber? Das wäre schon mal gut. Trotzdem oder gerade deswegen: Supportcall. (Falls ich es noch nicht empfahl.) Gruß, Nils

Moin, ja, DHCP kann ein Grund für eine Trennung sein. Die muss dann aber physisch sein (eigenes Netz, mindestens eigenes VLAN), ein separater IP-Kreis reicht dann nicht. (Ich sehe gerade, dass DHCP schon in der Eröffnung erwähnt wurde, das hatte ich erst übersehen.) Ein zwingender Grund ist das allerdings auch nicht. Durch passendes Design bekommt man auch das hin, solange man per DHCP keine Sonderlocken verteilt. Gruß, Nils

Moin, naja ... das würde ich differenziert sehen. Solange es sich um eine kleine bis mittelgroße Umgebung handelt und "selbes IP-Netz" einfach nur das IP-Segment bezeichnet, sehe ich überhaupt kein Problem. Etwas Sorgfalt muss natürlich sein, aber sonst interessiert sich das AD nicht besonders für andere Systeme im selben Subnet. In einer größeren Umgebung mag das etwas anders aussehen, aber da sehe ich auch nur operative Gründe für eine Subnet-Trennung, keine technischen. DNS und alle anderen Infrastrukturdienste kann und muss man natürlich sorgfältig planen, einrichten und betreiben. Aber das gilt für getrennte Subnets genauso wie für ein gemeinsames. Besonders die DNS-Auflösung muss während der Koexistenz ja auch domänenübergreifend funktionieren, das ist in der Praxis eher der Knackpunkt. Da man bei einer Domänenmigration für eine funktionierende Netzwerkkommunikation sorgen muss, kann eine zusätzliche IP- und VLAN-Aufteilung erheblichen Zusatzaufwand bedeuten, das würde ich schon gegeneinander abwägen. Gruß, Nils

Moin, wie gesagt: Supportcall. So eine Situation sollte man nicht länger bestehen lassen, wer weiß, was im Hintergrund das Problem ist. Nur so ein zusätzlicher Schuss: Sind die Spectre-/Meltdown-Patches auf den Hosts und in den VMs eingerichtet? Wenn die uneinheitlich sind, lassen sich diverse Probleme beobachten. Wozu setzt du die Checkpoints denn ein? Eigentlich rät man in Produktionsumgebungen davon ab. Gruß, Nils

Moin, nein, das geht nicht. Entweder er ist angemeldet, dann hat er ein Kerberos-Ticket und ein Access Token, mit dem er auf alle Ressourcen zugreifen kann, auf die er Berechtigungen hat. Oder er ist nicht angemeldet. Was ist denn das Ziel? Gruß, Nils

Moin, warum nutzt du nicht GPP? Da gibt es fertige Komponenten für sowas. Oder verstehe ich was miss? Gruß, Nils

Moin, eben. Und da steht ausdrücklich drin, dass die Software nur für Unterrichtszwecke benutzt werden darf. Windows darf sogar nur auf Rechnern der Institution genutzt werden. Jede produktive Nutzung scheidet damit aus. Dass Studierende die Software für Eigengebrauch für lau bekämen, war schon immer ein Mythos, der durch Wiederholung nicht wahrer wird. Gruß, Nils

Moin, die Studenten- und Schulprogramme erlauben den kostenlosen Zugriff auf die Software nur für Unterrichtszwecke und natürlich nicht für einen produktiven Einsatz. Das interpretieren zwar sehr viele Studierende anders, aber die begehen dann schlicht Lizenzverstöße und könnten genausogut direkt Raubkopien verwenden. Gruß, Nils

Moin, ihr habt hier gerade sehr schön die Gründe diskutiert, warum sich Mailverschlüsselung nicht durchsetzt ... ... und tatsächlich stimme ich Norbert zu, dass wahrscheinlich die einzig praktikable Lösung eine Gateway-Verschlüsselung ist. Das ist dann nicht Ende-zu-Ende, aber immerhin Unternehmen-zu-Unternehmen. Gruß, Nils

Moin, das dürfte eine Browsereinstellung sein. Man müsste das automatische Ausfüllen von Formularfeldern abschalten. Gruß, Nils

Moin, ich widerspreche. Das Scavenging muss man an mehreren Stellen aktivieren, und das muss gezielt geschehen: In den Eigenschaften der Zone gibt man die Grundkonfiguration vor mit zwei Intervallen. Genau verstehen, was diese Intervalle bedeuten! Das macht man einmal, weil es in den Eigenschaften der Zone hinterlegt und mit ihr repliziert wird. In den Eigenschaften des DNS-Servers gibt man an, ob dieser das Scavenging auch durchführen soll. Hier gibt es ein weiteres Intervall. Es gilt die (dringende) Empfehlung, dass nur ein DNS-Server in der Umgebung den Prozess ausführt, weil man nur dann die Intervalle wirklich einschätzen kann und weil dann ausgeschlossen ist, dass sich Löschvorgänge mehrerer Server überlagern. Ganz wichtig: Sobald man das Scavenging aktiviert hat, muss man - mindestens in der Anfangszeit - die Umgebung genau beobachten. Die neu aktivierte Option neigt dazu, zunächst zu viele Einträge zu löschen, die man dann ggf. manuell wiederherstellen muss. Hier muss man also zügig reagieren können und den Hintergrund kennen. Gruß, Nils