NilsK

Moin, lass den ersten DC mal die Namenseinträge neu generieren: ipconfig /registerdns && net stop netlogon && net start netlogon Stehen nun die erwarteten Einträge im DNS? Wichtig natürlich, dass der DC auch bei sich selbst im DNS nachsieht, ebenso auch der zweite. Geändert hat sich mit 2016 natürlich nichts, der Fehler muss also woanders liegen. Gruß, Nils

Moin, sorry, aber mit so einer Problembeschreibung kommen wir nicht recht weiter. Gruß, Nils

Moin, kannst du bitte noch angeben, von was für einem "Load" du sprichst? Was für ein Zähler ist das genau, und wie beobachtest du den? Und wie wirkt sich das aus? Ist die Arbeit mit dem System eingeschränkt? Gruß, Nils

Moin, das heißt was und wurde wie gemessen? Wie wirkt sich das aus? Dass ein Rechner was zu tun hat, wenn man eine Applikation startet, ist ja erst mal normal. Hier fehlt eine nachvollziehbare Problembeschreibung. Gruß, Nils

Moin, zunächst einmal ist so eine Liste unter Umständen mitbestimmungspflichtig. Falls es also einen Betriebsrat gibt, ist der einzubinden. Falls nicht, kann trotzdem eine rechtliche Absicherung ratsam sein. Der übliche Weg, so eine Anforderung umzusetzen, besteht in einem Logonskript, das bei der Anmeldung den Benutzer- und den Computernamen an eine zentrale Stelle schreibt. Alternativ könnte man auch die Security-Eventlogs der Domänencontroller auswerten, aber das ist sehr aufwändig und fehlerträchtig. Erschwerend kommt in allen Fällen hinzu, dass diverse Mechanismen im Betriebssystem die Aussagekraft so einer Liste einschränken. So gibt es keine zuverlässige Möglichkeit, auf so einem Weg festzustellen, ob der User noch angemeldet ist. Außerdem erschwert z.B. der Ruhezustand die Übersicht, weil beim Erwachen keine neue Anmeldung erfolgt - ist ein User z.B. an mehreren Rechnern angemeldet, ist kaum noch festzustellen, wo er zuletzt war. Gruß, Nils

Moin, und nächstes Mal bitte in einem neuen Thread und nicht in einem, der siebeneinhalb Jahre alt ist und eine andere Frage behandelte. Gruß, Nils

Moin, ja, dann ändert sich aber durch Berechtigungen nichts daran. Dann ist die WMI-Abfrage als solche das Problem. Und tatsächlich ist die Menge der Daten, die das MAP sammelt, in der Hinsicht kritisch, auch wenn das Tool die meisten dieser Daten gar nicht auswertet. Du kannst dir ja mal die Testdatenbank herunterladen und da reinsehen - das ist schon sehr umfassend, was darin steht. Aus der Perspektive werdet ihr also mit dem Betriebsrat sprechen und eine Vereinbarung treffen müssen. Berechtigungen lösen das organisatorische Problem nicht. Gruß, Nils

Moin, ja, aber so ist das nun mal. Mit einem Polo kannst du auch nicht 250 auf der Autobahn fahren. Dass die Begrenzung gerade beim Explorer ärgerlich ist, ist richtig, aber nicht neu. Wie in der Beschreibung der Policy, die du vermutlich meinst, ja auch verklausuliert geschrieben steht, muss die Applikation das eben auch unterstützen. Tut sie es nicht, dann wirkt sich die Policy nicht aus. Im Wesentlichen verändert die Policy das Verhalten des .NET-Frameworks ab 4.6.2, mehr nicht. https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/ https://www.ghacks.net/2016/05/27/microsoft-260-long-path-limit/ Gruß, Nils

Moin, Remote-Abfragen per WMI brauchen Adminrechte. Möglicherweise kann man das ändern, aber das wird auch Adminrechte brauchen. Gruß, Nils

Moin, Was jetzt? Gruß, Nils

Moin, wovon redest du genau? Allgemein hängt die Einsetzbarkeit "langer Pfade" immer davon ab, welche Bibliotheken und welche Funktionen der Entwickler einer Software verwendet hat. Da kann man von außen praktisch nichts dran drehen. Windows kann schon seit Urzeiten mit sehr langen Pfaden umgehen, aber konkret geht das eben nur, wenn auch die Applikation mitmacht, die man einsetzt. Gruß, Nils

Moin, nein, den abgesicherten Modus (genauer: DSRM) braucht man nur bei einem Authoritative Restore. Das ist hier ja gar nicht gegeben. Mein Tipp wäre tatsächlich die neue Netzwerkkarte bzw. eigentlich eher die alte, die bei solchen Aktionen bisweilen noch in der Konfig "rumspukt". Die mal entfernen mit dem Geräte-Manager im Modus "show nonpresent devices". Gruß, Nils

Moin, eine direkte Einbindung der Virtual FC kann natürlich performanter sein. In geschätzt 99 Prozent aller Umgebungen kommt es auf diesen kaum messbaren Unterschied aber gar nicht an. Dafür ist eine vFC-Anbindung dann auch sehr komplex und erfordert spezielle Features in der FC-Infrastruktur. Das ist prinzipiell in vSphere und Hyper-V identisch. Leg die virtuellen Disks auf das CSV, dann macht der Cluster alles, was du brauchst. Die Performance reicht aus, sofern das Storage leistungsfähig genug ist. Sollte es das nicht sein, dann würde es auch mit vFC nicht reichen. Gruß, Nils

Moin, naja, ebensogut hättest du jetzt auch www.microsoft.com angeben können ... Also: Vom Grundsatz her würdest du dem Cluster eine "große" LUN zuweisen, die du nach dem Einbinden im Cluster als CSV einrichtest. Auf dieses CSV legst du dann die VHDX-Dateien der VMs. Ob in denen das VM-Betriebssystem oder die Applikationsdaten liegen, ist auf dieser Ebene egal. Gruß, Nils

Moin, wenn du dir endlich mal SetACL ansiehst, wirst du feststellen, dass du damit ACLs bereinigen kannst, um sie danach gezielt neu zu befüllen. Das Tool ist nicht umsonst Industriestandard. Gruß, Nils

Moin, Anonymisierst du bitte den Hersteller? Die Angabe tut nichts zur Sache und macht uns nur angreifbar. Gruß, Nils

Moin, dann solltet ihr euch nach einem geeigneten Werkzeug umschauen. Der Server-Manager ist für sowas ja nicht gerade geeignet, selbst wenn man das mit den Profilen hinbekäme. Gruß, Nils

Moin, oder kürzer gesagt: Ich würde den wesentlichen Teil des Skripts von SetACL erledigen lassen (praktisch Industriestandard für Berechtigungen). Die einzige echte Variable in deinem Skript scheint der Username zu sein, den könnte man bei 1800 Einträgen ja sicher besser aus einer Datei entnehmen. Gruß, Nils

Moin, warum dies? Nur während des Tests oder auch in Produktion? In beiden Fällen: Wozu soll das gut sein? Was ist das Ziel eurer Testreihe? Was wollt ihr rausfinden? Die Symptomatik klingt nach Netzwerkproblemen, dazu passt auch, dass es nach kurzer Zeit verschwindet. Um Näheres zu sagen, müsste man sich das alles mal in Ruhe ansehen. Möglicherweise provoziert ihr die Probleme auch durch euer Testverfahren. Gruß, Nils

Moin, was heißt Startet ihr laufend direkt hintereinander neu? Und bei 40 Neustarts kommt einmal der Fehler? Oder wie? Bleibt der Fehler dann bestehen, oder behebt er sich von selbst? Gibt es um das Event herum weitere Meldungen? Gruß, Nils

Moin, an Logik und Verhalten der UAC hat sich nichts geändert. Nur an der Abschaltbarkeit. <erhobener Zeigefinger> Und damit haben wir wieder den klassischen Fall: Wer UAC bislang routinemäßig abgeschaltet hat, kommt damit nicht klar. Wer stattdessen damit umgegangen ist, sieht kein Problem. Genauso wie wir es von Betriebssystem-Firewalls kennen: Die stellen auch nur dann ein Problem dar, wenn man sie abschaltet. </erhobener Zeigefinger> Gruß, Nils

Moin, wieso genau? War es dir zu umständlich, einen Dropbox-Account anzulegen? Gruß, Nils

Moin, Microsoft hat nichts geändert, das ist normales UAC-Verhalten. Statt die UAC abzuschalten, sollte man lieber richtig damit umgehen. Genau wie man eine Firewall auch nicht abschaltet, sondern konfiguriert. [Windows-Berechtigungen mit UAC verwalten | faq-o-matic.net] https://www.faq-o-matic.net/2015/12/23/windows-berechtigungen-mit-uac-verwalten/ [benutzerkontensteuerung (UAC) richtig einsetzen | faq-o-matic.net] https://www.faq-o-matic.net/2008/02/22/benutzerkontensteuerung-uac-richtig-einsetzen/ Gruß, Nils

Moin, da ein Mac nicht mit der Windows-Gruppenlogik arbeitest, wirst du dich mit dem Gruppenprinzip in macOS auseinandersetzen müssen. Gruß, Nils

Moin, hast du dich mit dem Account neu angemeldet, nachdem du ihn der neuen Gruppe hinzugefügt bzw. ihn aus anderen entfernt hast? Nur dann werden die Gruppenmitgliedschaften wirksam. Ich tippe auch auf UAC. Gruß, Nils