NilsK

Moin, Windows fragt dann, wenn der aktuelle User keine Berechtigung hat (auch keine Verweigerung, sondern einfach kein zutreffender Eintrag), es aber Berechtigung für andere User oder Gruppen gibt. Das muss dann kein Admin sein. Gruß, Nils

Moin, von mir aus nicht. Aber ich glaube eigentlich nicht, dass eure Umgebung so hohe Replikationslatenz hat. Gruß, Nils

Moin, technisch ist das egal. Nur in einer großen, geografisch verteilten Struktur mit großen Replikationslatenzen würde man dafür den PDC-Emulator vorziehen, weil man dann (in manchen Topologien) evtl. Replikations-Hops spart und so die Wartezeit zwischen den beiden Kennwortwechseln verzögert. Das dürfte allerdings heutzutage in fast allen Umgebungen keine ernsthafte Rolle spielen. In einer Multi-Site-Umgebung könnte man sich die konfigurierten Latenzen ansehen und ein wenig Puffer draufrechnen. Oder einfach zwischen den beiden Wechseln zu Mittag gehen. Gruß, Nils

Moin, im Prinzip profitiert ein SQL Server durchaus von mehreren CPUs bzw. vCPUs. "Je mehr desto besser" ist aber nicht ohne Weiteres richtig - wie viele er nutzt, hängt von der Version und Edition ab. Und "viel hilft viel" ist bei vCPUs kein guter Weg. Vier oder acht vCPUs sieht man bei SQL Servern oft, das kann okay sein (wie gesagt, je nach Edition). Alles Weitere müsste man dann schon genauer analysieren. Nur im Ausnahmefall (also eigentlich: auf keinen Fall) sollte man einer VM so viele vCPUs geben wie der Host Cores hat. Und wenn man sowas tut, dann nicht für mehrere VMs gleichzeitig. Das wäre ein prima Weg, den Host in die Knie zu zwingen. Gruß, Nils

Moin, also, richtig ist: in einem AD ohne RODCs macht man das einmalig für die Domäne, nicht pro DC. in einem AD mit RODCs gibt es den "echten" krbtgt und je einen pro RODC. Falls das so ist, muss man die Kennwörter von allen diesen Accounts ändern. Man tut dies auf einem normalen DC. zum Ändern setzt man ein neues Kennwort, das zunächst den Kennwortrichtlinien genügen muss, wie bei jedem anderen Account auch. ABER: Das Kennwort bleibt nicht, sondern das AD setzt dann automatisch einen neuen, geheimen Wert. einmal ändern reicht nicht. Man muss die Replikation abwarten und dann das Kennwort ein zweites Mal ändern. Das liegt daran, dass das AD sowohl das aktuelle als auch das vorhergehende Kennwort akzeptiert. Das ist nur bei diesem Account so. Das TechNet-Skript macht all dies von selbst und prüft vorher genau, was es tun muss. Dass das Skript manchmal abbricht, liegt i.d.R. daran, dass Jorge die Lokalisierung nicht richtig hinbekommen hat. Man braucht das Skript aber nicht, sondern kann das wie beschrieben einfach manuell machen. Wichtig ist nur, dass man zwischendurch die Replikation abwartet, was bei einer weltweit verteilten Umgebung schon mal Stunden dauern kann. Gruß, Nils PS. sorry für die Verwirrung durch meine vorherige, nicht ganz korrekte Antwort.

Moin, fragen wir so: Wozu würdest du eine autorun.inf brauchen? Gruß, Nils

Moin, das macht man einmalig für die Domäne, nicht pro DC. Und auf den RODCs sowieso nicht, die sind Read-only und können keine Daten ändern. Im übrigen hilft eine Websuche nach "krbtgt change password" durchaus weiter. Gruß, Nils

Moin, mit "krudes Szenario" meine ich den Ansatz, das Teilen von Accounts durch den Kennwortwechsel eindämmen zu wollen. Käme mir nicht in den Sinn. Gruß, Nils

Moin, man kann jetzt nur raten, was du da eigentlich machst. Künftig wäre es sinnvoll, wenn du den Zusammenhang erläuterst. Aus dem Bauch: Wenn der Server am RAM-Limit lief und nun Updates einspielt, dann wird er vermutlich sehr viel auslagern müssen (Paging). Da so ein alter Server wohl keine SSDs hat, kann das durchaus dazu beitragen, dass ein Updatevorgang viele Stunden dauert. Zumal Windows-Updates ohnehin sehr Disk-I/O-intensiv sind. Gruß, Nils

Moin, genau das meine ich: Ein gutes Kennwort ist zum Weitergeben zu wenig attraktiv. Die Erschwernis ist deinem (etwas kruden) Szenario eher überlegen, das Kennwort als solches ist es mit Sicherheit. Gruß, Nils

Moin, das tut ein gutes Kennwort aber noch besser. Gruß, Nils

Moin, unabhängig vom Coding: Das sieht nach schlechtem Design aus. Man sollte die Vererbung von Berechtigungen nicht ohne Not unterbrechen. Noch dazu sehen die Berechtigungen, die du angibst, nicht praktikabel aus. Für alles, was mit Berechtigungen zu tun hat, empfehle ich SecACL und (falls es grafisch sein soll) SetACL Studio von Helge Klein, beides kostenlos. SetACL ist Industriestandard und wird viel für Skripte eingesetzt. Die PowerShell ist da ... etwas eigen. Gruß, Nils

Moin, sorry, das kam etwas rüde rüber. Ich wollte dich gar nicht kritisieren. Gruß, Nils

Moin, woran man wieder schön sieht, dass eine Statistik immer einen Zusammenhang braucht. Sonst ist sie wie eine Bibelstelle, mit der man alles begründen kann. Gruß, Nils

Moin, dazu solltet ihr euch evtl. eine Software ansehen, die sowas kann und dann auch gleich geeignet ist, sowas zu überarbeiten. Mir fiele da etwa tenfold ein. Spätestens dann, wenn das keine einmalige Sache ist, wird man mit Skripten schnell überfordert sein. Gruß, Nils

Moin, dann sollte der Rest ja auch klappen. Bedenke, dass du in der PowerShell immer mit Objekten arbeitest. Gruß, Nils

Moin, wie siehst du dir denn $table an? Bei mir gibt beides dasselbe Ergebnis aus. Kommt bei dir was anderes zurück, wenn du $table | fl abschickst? Gruß, Nils

Moin, ich hab ihn mal angeschrieben. Gruß, Nils

Moin, ich zweifle weder an Evgenij noch an seiner Absicht. Aber die Seite ist so, dass sie zu wenig seriös wirkt. Gruß, Nils

Moin, ich würde auch auf faq-o-matic.net auf die Umfrage hinweisen, aber es sind so gar keine Informationen dazu zu finden. Was wird denn mit den gesammelten Daten gemacht? Und wie verlässlich ist "Stand heute sieht es so aus"? Ist das Evgenijs Vermutung oder steckt etwas dahinter, worauf man sich beziehen kann? Im Übrigen dürfte der Betreiber der Webseite mit seinen Aussagen zur DSGVO ziemlich danebenliegen. Sorry, aber so macht das Ganze für mich einen halbseidenen Eindruck ... Gruß, Nils

Moin, dein Vorhaben wird so, wie du es dir vorstellst, technisch nicht funktionieren. Den "XP-Mode" gab es nur unter Windows 7, der lässt sich mit Hyper-V nicht nachbilden. Wenn es ein virtuelles XP sein soll (wovon ich dringend abrate - es bleibt ein XP, auch wenn "drumrum" ein modernes OS läuft), könntest du dir einen Desktop-Virtualisierer wie VirtualBox oder VMware Workstation ansehen. Die sind anders ausgerichtet als Hyper-V, vielleicht bekommst du damit etwas hin, was deinen Anforderungen entspricht. Grundsätzlich stimme ich den anderen aber zu - XP setzt man nicht mehr ein. Du bist ja wegen des Supports von Windows 7 weg, der Support für XP ist schon vor vielen Jahren ausgelaufen. Auch in einer VM ist es unwahrscheinlich, dass du dein Nutzungsszenario ausreichend sicher umgesetzt bekommst. Da ist die Zeit für den sauren Apfel jetzt wirklich da. Gruß, Nils

Moin, technisch hat sich da seit über 20 Jahren nichts mehr geändert. Im Wesentlichen sogar seit der "Urversion" von Windows NT nicht. Was immer mal wieder neu gemacht wurde, sind die Benutzeroberflächen dafür, und die können in der Tat verwirrend sein, wenn man das nicht "hauptberuflich" macht. Netzlaufwerke sind immer an das Benutzerkonto gebunden. Wenn ich mich als "Horst" an PC1 anmelde und ein Netzlaufwerk mit dem Buchstaben X: auf eine Freigabe verbinde, die auf PC2 liegt, dann steht es nur mir als Horst auf PC1 zur Verfügung. Meldet sich Ute an PC1 an, dann hat sie kein X:. Sie kann bzw, müsste es sich dann selbst einrichten. Ebenso sehe ich kein X:, wenn ich mich auf PC3 mit dem Konto "Horst" anmelde. Auf PC2 hingegen (also dem Rechner, der die Freigabe anbietet) muss niemand angemeldet sein - wenn dort eine Freigabe eingerichtet ist, dann besteht sie sozusagen als "Angebot" dauerhaft. Dadurch wird PC2 zum Dateiserver, wenn man so will. Eine dauerhafte Verbindung von Computer zu Computer - unabhängig von angemeldeten Benutzerkonten - gibt es auf diese Weise aber nicht. Du kannst also einem Computer kein Laufwerk X: einpflanzen, das mit einer Freigabe im Netzwerk verbunden ist. Zu den Berechtigungen hier ein wenig Stoff - Vorsicht, sehr technisch, aber in der Systematik zutreffend. [Datei- und Freigabeberechtigungen in Windows | faq-o-matic.net] https://www.faq-o-matic.net/2015/12/28/datei-und-freigabeberechtigungen-in-windows/ Gruß, Nils

Moin, Das kann man, solange die Software benutzerspezifische Daten und Einstellungen auch benutzerspezifisch an den dafür vorgesehenen Stellen speichert. Das dürfte der wesentliche Punkt sein. Natürlich muss die Software auch geeignet sein, um in mehreren Prozessen in unterschiedlichen Sessions auf demselben System zu laufen. Raketenwissenschaft ist das aber nicht. Gruß, Nils

Moin, das eine noch: Sich mit anderen zu vergleichen, sollte man sich abgewöhnen. Das führt zu gar nichts außer Frust. Und damit meine ich nicht nur solche persönlichen Vergleiche. Ich beobachte in Unternehmen immer wieder, dass jedes Team meint, die Arbeit des anderen Teams bewerten zu müssen. Und dann beschwert man sich regelmäßig bei den Vorgesetzten, dass das Betriebsklima so schlecht sei ... Gruß, Nils

Moin, die genannten Beispiele illustrieren sehr gut einen meiner Haupteinwände: In Wirklichkeit geht es bei solchen Bonus-Systemen darum, dass der Arbeitgeber einen Teil des kaufmännischen Risikos auf die Arbeitnehmer abwälzen will. Wenn das Geschäft nicht gut läuft, will er so die Kosten drücken. Da man das aber schlecht so sagen kann, erfindet man irgendwelche pseudo-messbaren Ziele, an denen man dann den Bonus festmacht. Tatsächlich habe ich noch nie ein Modell gesehen, das nicht in der Praxis zum größten Teil auf "Nasenfaktor" hinauslief. Ausnahmen mögen Großbanken sein. Da bekommt man den Riesenbonus auch dann, wenn der Laden an die Wand fährt. Dafür überlebt man da auch nur bis Anfang 40, daher ist das nichts für mich. Gruß zum Wochenende, Nils