daabm

Wenn Du's per Domain Policy verteilst (und nach Möglichkeit noch die Verarbeitung der lokalen Policy deaktivierst), wäre das nicht passiert Aber ok. Würde mich freuen, wenn Du ne Ursache findest und postest.

Das war mir schon fast klar, aber macht Ihr das echt per lokaler GPO? Greenbone sagt mir grad nichts. Edit: "Lokale GPO" ist ein Widerspruch in sich - muß "lokale Policy" heißen Auch wenn man's per gpedit.msc bearbeitet.

Ich bin jetzt nicht im Code der SACL-Auswertung verbuddelt, aber: Je mehr Einträge die hat, um so mehr Prüfungen müssen bei Änderungen gemacht werden, ob eine davon grad zutrifft. Ist immer ein Trade-Off: Bist Du sehr granular und damit zielgenau, hast Du sehr lange ACLs (S und D), deren Auswertung entsprechend länger dauert. Zielst Du ungenau, bist Du da zwar schneller, erzeugst aber mehr Logeinträge. Ich würde mich im Zweifel für zweiteres entscheiden, weil es im Handling einfacher ist und Event Logging ein erstaunlich lastarmer Mechanismus. Aber probier's einfach aus und überwache die CPU- und Storage-Auslastung der DCs. Unsere haben kaum AD-Auditing, erzeugen aber trotzdem so viele Security Events, daß das 4 GB Security Eventlog in 4 Stunden Rollover macht. Darauf hängt dann natürlich auch noch der Splunk Agent, und trotzdem merkt man das nicht in Perfmon.

Zu wenig Info - was genau meinst Du mit "die lokale Gruppenrichtlinie" und mit "Zugriff per remote steuert"?

Wenn man was verbessern will, muss man was ändern. Weil wenn sich nichts ändert, dann ändert sich nichts. So gesehen ist es egal 😂

Einer der Gründe, warum wir versuchen NTLM los zu werden. Aber das ist eine gaaanz lange Reise... Und wir haben ja alle echt viel Zeit übrig, um uns mit solchen Sahnehäubchen zu beschäftigen. Klar wäre es "nice", aber wer soll es in welcher freien Zeit machen? Dynamische RPC-Openings auf den Firewalls haben unsere Netzer mal versucht, ging schief. Da ich daran aber nicht beteiligt war, weiß ich leider nichts über die Hintergründe.

Nachdem Norbert im Urlaub ist (warum müssen Rentner eigentlich "Urlaub" haben - da ist doch die Zeit immer frei einteilbar ): Kaffee muß sich jeder selber ziehen, Licht geht automatisch und das Feíerabendbier steht wie immer im Kühlschrank - diesmal unten links: 🍻🍺

RPC verträgt sich schlecht mit Infrastruktur-Firewalls. Ich hatte "aus Gründen" kürzlich das Vergnügen, mich mit Subnetzen zu beschäftigen. Dabei ging's um ein Autosite-Skript für ein übergreifendes AD. Ergebnis: Wir haben Subnetze im sechsstelligen Bereich. Im Testlab mit einem Teil davon angelegt (50.000 Subnets, 13.000 Sites, 950 Site Links) waren dann KCC, ISTG, ISMServ und Netlogon "mehr als beschäftigt". Das ergänze ich jetzt noch mit 3 verschiedenen RPC-Ranges, die wir historisch bedingt haben. Wie soll ich da Regeln bauen, daß jeder AD-Client seine DCs (also die für seine Site zuständigen) auf den dafür erforderlichen Ports erreichen kann, alle anderen aber nicht? Und alle anderen RPC-Services ebenso? Und vorher weiß ich nicht, welcher RPC-Service sich welchen Port schnappt. Die Liste der erforderlichen IP-Netze dürfte die Kapazität der Reg-Werte sprengen, die fassen AFAIK nur 64k. 🏳️🏳️🏳️ (Kapitulation...) PS: Ja, ich weiß ein wenig wovon ich rede. Deshalb ist in dem Skript hier auch der RPC-Check von Ryan Ries enthalten - https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1

Wir konnten es nie exakt eingrenzen, aber es gab Hinweise auf Timeouts im Storage. Wenn ein Member Computer sein PW ändert, macht er das erst im AD, und wenn das geklappt hat, lokal. Ein DC macht es AFAIK andersrum, und wenn das AD-Update dann schiefgeht, war's das.

Das ist dann aber kein Multihomed DC mehr - das ist nur noch ein Windows-Server mit mehreren NW-Karten. Machen wir seit Jahren - Du mußt nur auf dem Management-Netz darauf achten, daß die IP nicht im DNS registriert wird (der Haken darf NICHT gesetzt sein.), dann klappt das problemlos. Und um albernen NW-Verkehr zu vermeiden noch den Client für MS-Netzwerke und die Datei- und Druckerfreigabe aus den Bindungen rausnehmen.

Mein Bergfest war gestern, ich hab Freitag frei. Deshalb heißt der ja auch "Frei"-Tag

Man KANN multihomed DCs machen. Aber nicht alles, was man machen kann, ist auch hilfreich oder gut Man KANN auch von einer Brücke springen, das ist kompletter Blödsinn. Vielleicht hilft dieser Vergleichsansatz Deinem Kunden. Wenn man es macht (aus "Gründen"), dann sollte man viel Energie in DNS investieren, damit die AD-relevanten DNS-Einträge für alle Clients aus allen Netzen immer korrekte Antworten liefern. Und auch für die DCs selbst natürlich. Viel Spaß dabei, wenn das Windows-DNS ist - SCNR

Wir haben ein paar mehr Domains als gemeinhin üblich - bei uns einige Male pro Jahr.

Dann räume ich am WE den Kühlschrank aus und ziehe den Stecker der Kaffeemaschine Hier war es deutlich wärmer, knapp 15°.

Als Tip für die Zukunft: Get-Content brauchst Du nur einmal am Anfang, und Set-Content nur einmal am Ende Der -replace Operator ist Regex, der kann also in der Suchfolge einen Capture machen, den Du im Replace-Teil wiederverwenden kannst. Deine 4 Zeilen könntest Du damit reduzieren auf Get-Content C:\VMware_vCenter_Uebersicht.html | ForEach-Object {$_ -replace '^(https://(vcenter_\d).+/ui/)$', '<a href="$1">$2</a>'} | Set-Content C:\VMware_vCenter_Uebersicht.html Die Klammern sind Capture Groups und werden anhand der öffnenden Klammer durchnumeriert. Der erste Match enthält die komplette URL, der zweite Match nur noch vcenter_ und eine Zahl. Edit: -replace interpretiert das nur dann als Regex, wenn Du einfache Hochkommas verwendest. Und statt '^(https://(vcenter_\d).+/ui/)$' könntest Du auch '^(https://([^/]+)/.+/ui/)$' verwenden, damit würde in $2 alles landen bis zum ersten Slash ('/').

Mein erster Gedanke: Ooops - nur 3 Nutzer? Müssen Chefs sein. Mein zweiter Gedanke: Ok, sind Chefs - was willste machen...

Kann man schon machen - mache sogar ich ab und zu, um schnell mal was auszuprobieren. Wenn es aber reproduzier- und nachvollziehbar sein soll (oder wie bei uns meistens sogar MUSS), dann ist ein Skript oder Befehlszeilenaufruf die bessere Variante. Die kann man irgendwo (revisionssicher) speichern und beliebig oft wiederholen. Und mit kleinen Anpassungen dann für ähnliche Aufgaben super schnell modifizieren - "code reuse"

Security by obscurity... Macht's nur unkomfortabler, verhindert aber nichts. Abfotografieren geht immer. Oder um's mal allgemeiner zu formulieren: "If you don't trust your admins, don't make them admins". Läßt sich auf jede andere Funktion im Unternehmen übertragen.

Jupp, so langsam wird es "rund". @RealUnreal Zeitverteilung ist ein hierarchischer Vorgang. Und für Kerberos ist Zeit essentiell, weil die Timestamps für die Preauthentication verwendet werden. Es kann nur einen "Chef im Ring" geben, und jeder, der teilnimmt, darf nur einen "Uplink" haben. Dem virtuellen Computer ist es grundsätzlich egal, ob er seine Zeit vom Host bekommt, der in der gleichen Domäne ist (ist er das?) oder ob er sie direkt aus der Domäne holt. Allerdings macht ein fehlkonfigurierter Host in dem Fall die Authentifizierung für alle VMs gleich mit kaputt. Also entscheidet man sich, alle Zeit-Integrationen der Virtualisierungsplattform abzuschalten und bei Domänenmitgliedern ausschließlich NT5DS zu verwenden.

Deine Quelle beim PDC ist der VM IC Provider, das ist falsch. Der muß auf ntp stehen -> Time Sync in VMWare abschalten. Und die Quelle beim Host ist Local CMOS, das ist auch falsch. Mit den 2 GPOs alleine kannst das nicht lösen, Du mußt die dämliche Zeitsynchronisation der VMWare Tools abschalten.

Shell Folders war möglicherweise schon deprecated, bevor Du geboren wurdest... https://devblogs.microsoft.com/oldnewthing/20031103-00/?p=41973 Also lass den Kram da einfach, wie er ist. Oder wenn's glücklich macht, dann patche es.

Kann leider nicht folgen. Wie kann das auf nem einzelnen DC passieren bzw. Auswirkungen haben? Er hat doch immer auf sich selber Zugriff und kennt sein aktuelles Maschinen-PW. Oder meinst was ganz anderes? Falls ja, was genau und wie kann ich es provozieren zur Test-Behebung? Wenn er der einzige ist, was hindert mich am Image-Restore/CopyPaste des DC vom Stand Tag davor. Ein DC verhält sich da genau wie ein Client - er kennt lokal (Registry) sein Kennwort, und es steht auch im Computerkonto im AD. Paßt das nicht mehr, hast das gleiche wie bei nem Member - entweder rejoin (also de-/promote) oder nltest /screset. Zweiteres geht aber nicht gegen ihn selber, sondern muß auf ihm selbst gegen einen anderen ausgeführt werden - hast Du nur einen, ist hier Ende. Und rejoin aus offensichtlichen Gründen das gleichen Problem.

Auch schon wieder 11 Jahre her... https://evilgpo.blogspot.com/2012/03/how-to-save-my-screen.html

Die gleiche Diskussion hatten wir doch grad schon mal Du kannst die Verzeichnisse problemlos umbenennen und dann in der Registry den Profilpfad korrigieren. Der User darf da nur grad nicht angemeldet sein - Shutdown-Skript z.B. Danach noch ntuser.dat laden und Environment/Volatile Environment überprüfen und ggf. korrigieren (wobei das bei Volatile Environment unnötig sein sollte). Ob das ein Domänen- oder lokaler Account ist, ist dabei wurscht. In eurer Automation habt Ihr halt leider die falschen Variablen ausgesucht.

Syspro verwende ich selbst auch, kann ich nur empfehlen. Und da das eine Ein-Mann-Firma ist, ist das auch gut angelegtes Geld.