NilsK

Moin, du musst nun das Root-Zertifikat neu veröffentlichen und an der passenden Stelle ablegen. Die Daten brauchst du auch für die Root-CA, damit Clients sie überprüfen können. Best Practice ist, eine zentral erreichbare Stelle für all diese Daten auf einem Webserver zu haben (per http erreichbar, nicht per https, damit keine Zertifikatsprüfungsschleife entsteht). Gruß, Nils

Moin, die Einträge sehen OK aus. Hatte der alte DC zufällig denselben Namen wie der neue? Ansonsten gilt weiter: Beobachten. Erst wenn neue Symptome auftreten, kann man dem sinnvoll nachgehen. Gruß, Nils

Moin, die SPN-Ausgabe ist unauffällig. Den Funktionslevel kannst du gefahrlos hochstellen, der betrifft nur die DCs untereinander. Einzige Ausnahme ist möglicherweise Exchange (je nach Version), aber das Problem, das du damit haben könntest, hättest du jetzt auch schon aufgrund des 2016er-DCs. Gruß, Nils

Moin, beobachten. Und noch mal die Eventlogs genau studieren, ggf. auch von ein paar Clients oder weiteren Servern. Solange es keine konkreten Probleme gibt, fehlt die Grundlage für weitere Einschätzungen. Gruß, Nils

Moin, der Fehler mit dem Kerberos-Ticket des Clients hat mit deinem Problem ziemlich sicher nichts zu tun. Zeitprobleme auf dem DC können wir auch ausschließen, denn es gibt ja nur den einen, und der synchronisiert sich per NTP. Wie ist denn der Stand momentan? Gibt es aktuell noch Probleme? Gruß, Nils

Moin, "ein ERP-System" ist gut. Ernst gemeint: Was du als "Anforderungen" auflistest, sind Basics. Das ist, als wenn du ein Auto mit vier Rädern und einem Getriebe suchst. Klärt erst genauer, was ihr wirklich braucht. Sucht euch dafür ggf. einen Partner, der sich auf Anforderungsanalyse für Geschäftsprozesse und ERP-Systeme versteht. Zur Einordnung: Ich rede hier nicht von einem Workshop, den man in wenigen Stunden rechnet, sondern durchaus von einem Prozess mit einer ganzen Reihe intensiver Arbeitstage, der sich meist über einige Wochen hinzieht. Mit dem Ergebnis aus dieser Analyse werdet ihr erstens klarer sehen, was für Produkte und Anbieter überhaupt in Frage kommen. Und ihr könnt es als Basis für eine Angebotsabfrage nehmen. Und falls dir das jetzt groß vorkommt: Ist es. Ein ERP-System für 140 User ist auch schon ziemlich groß. Das ist nichts für eine Liste mit sechs Stichwörtern. Gruß, Nils

Moin, ja, natürlich. :rolleyes: Es ging mir ja auch darum, ein grundlegendes Missverständnis im Zusammenhang dieses Threads aufzuklären. iSCSI ist nun mal nicht für wechselnde Verbindungen von mehreren Zugriffspunkten gedacht, weil es eben LUNs bereitstellt und keine Shares. Gruß, Nils

Moin, aber sowas von! :D Gruß, Nils

Moin, für den Zweck ist eine herkömmliche Freigabe (SMB) geeignet, iSCSI nicht. iSCSI ist eine blockorientierte Punkt-zu-Punkt-Verbindung zwischen genau einem Rechner und genau einem Volume (genauer: einer LUN). Eine solche LUN einem anderen Rechner zuzuweisen, ist ein Ausnahmefall und erfordert genaue Kontrolle des Vorgangs. Gruß, Nils

Moin, die kurze Antwort ist: Geht nicht. Prinzipbedingt. Gruß, Nils

Moin, oh, ich mache gerade ein richtig großes Projekt, das ausschließlich den Wechsel des AD-Domänennamens zum Ziel hat. :D Richtig, nicht öffentlich nutzen halt. Man reserviert den Namen nur, um sicherzustellen, dass ihn niemand anders rechtmäßig hat und daraus evtl. mal Probleme entstehen. Eine Versicherung, die zwischen 10 und 100 Euro im Jahr kostet, je nach TLD. Gruß, Nils

Moin, [Welcher Name ist der beste für eine AD-Domäne? | faq-o-matic.net] https://www.faq-o-matic.net/2007/06/08/welcher-name-ist-der-beste-fuer-eine-ad-domaene/ [Wie nenne ich mein Active Directory? | faq-o-matic.net] https://www.faq-o-matic.net/2013/06/24/wie-nenne-ich-mein-active-directory/ Meine Empfehlung: abstrakter Name, der nicht mit dem Firmennamen zusammenhängt auf diesen Namen eine Domain mit "einigermaßen" passender TLD registrieren, aber öffentlich nicht nutzen Damit hat man getran, was man vorsorgend gegen Namenskonflikte und Probleme aus einer Umfirmierung tun kann. Gruß, Nils

Moin, in der Tat - "das DNS löst nicht mehr auf" ist schon sehr unspezifisch. Wie genau äußert sich das Problem? Was wurde schon getestet und versucht? DNS neu zu installieren, ist bei AD-integrierten Zonen tendenziell problemarm, würde aber evtl. gar nichts lösen. Gruß, Nils

Moin, Dazu wird man öffentlich wohl nichts finden. Auch die c't ergeht sich zu dem Thema nur in allgemeinen Vermutungen, und die haben sicher ausführlich recherchiert. Der einzige Weg wäre, Microsoft zu fragen. Gruß, Nils

Moin, das kommt drauf an, wie der VPN-Client arbeitet. Ohne den einzubeziehen, wird man das meiner Vermutung nach nicht lösen können. Gruß, Nils

Moin, nicht alle Einwände sind begründet, nur weil sie von Datenschützern stammen. Es gibt da bei manchen eine gewisse Neigung, sich etwas zusammenzureimen und eigene Vorlieben zu Vorgaben umzudeuten. Die BSI-Standards der 200-Serie nutzen jedenfalls Formulierungen, die Bitlocker zulassen (z.B. Maßnahme M 4.29). Gruß, Nils

Moin, wie Jan schon richtig sagt - der einzige sinnvolle Ansatz ist eine Vollverschlüsselung des Notebooks. Einzelne Dateien rauszugreifen, ist ja keine Lösung. Gruß, Nils

Moin Franz, danke für den guten Hinweis! Der "Kundendienst" kann sich nur auf den erweiterten Support beziehen, denn der ist ja Teil des definierten Supports (siehe ersten Spiegelstrich: "zehn Jahre Support" unter https://support.microsoft.com/de-de/help/14085/microsoft-business-developer-and-desktop-operating-systems-policy).Auch rückwärts-logisch muss das so sein, denn sonst wäre Windows 7 in dem Punkt der Lizenzbedingungen (was dort ja ausdrücklich genannt wird) gar nicht mehr verfügbar (Mainstream-Support ist 2015 abgelaufen). Gruß, Nils

Moin, aha, das ist dann ja eine andere Situation. Ich interpretiere mal: Die Anwender nutzen den VPN-Client, um sich in das Netz des Kunden/Partners einzuwählen. Der VPN-Client sorgt dann dafür, dass das dort nötige DNS-Suffix hinzugefügt wird, damit kurze Namen im Zielnetzwerk korrekt aufgelöst werden. Daher würde ich die Suche beim VPN-Client fortsetzen. Gruß, Nils

Moin, wieso können die User das überhaupt eintragen? Dafür müssen sie lokale Admins sein. Dann hast du ganz andere Probleme. Die Lösung lautet also: Nimm den Usern die Adminrechte. Gruß, Nils

Moin, das ist sogar üblich. Viele VDI-Umgebungen laufen aufgrund der Lizenzbedingungen in Wirklichkeit mit einem Server-OS. Da es hier noch nicht mal um die Desktop-Nutzung geht, würde ich mir den Umstand mit der Client-Lizenzierung (und den möglichen Implikationen, dass das vielleicht nicht mal ein zulässiges Szenario ist) gar nicht erst antun. Gruß, Nils

Moin, ja, mit den GPO-Berechtigungen hast du Recht, das geht nur lokal. Da hatte ich Tomaten auf den Augen. Gruß, Nils

Moin, warum schaltest du die DNS-Suffix-Suchliste ab? Dein eigentliches Problem habe ich noch nicht verstanden. Kannst du das bitte noch mal genauer erklären? Gruß, Nils

Moin, ob du das per Berechtigungsvererbung in einem Schritt hinbekommst, weiß ich nicht und habe auch keine Zeit, das auszuprobieren. Aber zwei Anregungen: man kann per GPO auch Berechtigungen setzen man könnte den Prozess nicht über GPP, sondern über ein Skript laufen lassen, das dann z.B. mit SetACL die Rechte so setzt, wie es erforderlich ist Gruß, Nils

Moin, wenn die VMs quasi wie Server verwendet werden, ist es evtl. günstiger, sie gleich als Server-VMs zu installieren und auf dem Host eine Datacenter Edition einzusetzen. Gruß, Nils