cj_berlin

Netzwerkcontroller is vermutlich Bluetooth, brauchst Du für Server nicht.

Das könnte halt erklären, warum es nicht automatisch installiert wird, nicht wahr?

Dann nutze halt ein anderes Modell, bis es klappt. Der Hersteller hat es nicht vorgesehen, ein Server-OS auf diesem Board zu fahren, das heißt, alles nur Best Effort ohne Erfolgsgarantie. Du kannst aber auch eine andere Netzwerkkarte in den PCI-Slot stecken Das ist das Gute an Desktop-Boards, mit einem NUC nicht immer gut "Dein Ethernet-Controller" *ist* doch die Netzwerkkarte, die Du suchst.

Du kannst in die Dateien reingucken, INF ist reiner Text. Oder Du installierst sie einfach, das macht nichts kaputt.

Moin, einige Intel-Karten wie beispielsweise die i219V sind von Intel als Desktop-NICs deklariert und werden auf einem Server-OS nicht automatisch installiert. Das ist auch irgendwo in den Tiefen von deren Webseite ersichtlich, wenn Du auf das Modell der Karte gehst und dann auf Treiberunterstützung. Desktop-Betriebssysteme sind gelistet, Server nicht. Du kannst Dir trotzdem behelfen, indem Du das Treiber-Paket auspackst, dort die INF-Dateien suchst, die mit der rechten Maustaste anklickst und auf "Installieren" klickst. Anschließend gehst Du zurück in den Geräte-Manager, auf die Netzwerkkarte, sagst "Treiber aktualisieren", wählst "Manuell angeben", dann "Intel" als Hersteller und beispielsweise die i218V als Modell.

Ich habe das mit force-graph mal für Replikationsbeziehungen im AD gehackt. Eigentlich ganz einfach, wenn man es erst durchstiegen hat.

Moin, zuerst deaktivieren, dann rückgängig machen.

VM und Computer-Objekt reicht nicht, Du musst einen Metadata Cleanup durchführen.

Moin, VPN-Zugänge *sind* ein hohes Risiko, und da ist es nur am Rande wichtig, in welches Netz sie führen, daher dürfen am entfernten Ende eines VPN-Tunnels selbstverständlich nur verwaltete Endgeräte sein. Gateway-basierte Zugänge wie Netscaler oder UAG kann man aus Sicherheitssicht durchaus weit weniger kritisch sehen. Die Sache hat aber noch ein paar andere Aspekte: Lizenzierung: Wer sein Office (nur ein Beispiel) immer noch über Retail oder VL bezieht, lizenziert das physikalische Endgerät, vor dem der User sitzt. Wenn jeder Mitarbeiter zwei PCs, drei Tablets, vier Smart-TVs und einen Smart-Fridge hat, wieviele Office-Lizenzen müsste man da vorhalten? Downtime in Bezug auf Arbeitszeit: Fällt ein Firmengerät aus und der MA kann nicht arbeiten, ist es das Risiko der Firma, und sie kann sowohl vorbeugend tätig werden (bessere Hardware, kürzere Lebenszyklen) als auch selbst bestimmen, wie aufwendig die Wiederherstellung der Arbeitsfähigkeit werden darf. Bei einem Endgerät, auf das die Firma keinen Einfluss hat, ist es schwierig. Ressourcenverbrauch: Weil der Mitarbeiter es geil findet, die CRM-Anwendung auf seinem Gaming Rig mit zwei 5K-Bildschirmen zu bedienen, hat seine VDI-Maschine viel mehr zu tun als im Sizing vorgesehen. Sind diese Mehrkosten einfach durch die Firma zu tragen, weil "ist so"? Standardisierung im Client-Park hat oft ihre Gründe. Ich habe mehrere Versuche miterlebt, BYOD bewusst und geregelt einzuführen, und musste feststellen, dass das Konzept vorn und hinten nicht funktioniert, sobald man eine Sekunde länger darüber nachdenkt.

Moin, Du hast CAP and RAP auf dem Gateway erstellt - aber wie lauten die? Die Fehlermeldung sagt ja, CAP ist nicht erfüllt. Intern funktioniert es vermutlich deshalb, weil intern eine direkte Verbindung zum RDS möglich ist.

Moin, https://learn.microsoft.com/de-de/sql/database-engine/install-windows/rename-a-computer-that-hosts-a-stand-alone-instance-of-sql-server?view=sql-server-ver16

Moin, wenn es Dir um die Leistung von Echtzeit-Anwendungen geht, brauchst Du QoS, VLANs helfen da kaum. Allerdings ist es bei Softphones immer schwer zu sagen, ob Aussetzer auf Netzwerk oder doch auf die CPU/Interrupts/andere lokale Ressourcen zurückzuführen sind. Da hilft eigentlich nur ein Hardphone derselben Marke und schauen, wie sich das verhält. In puncto Performance helfen VLANs eigentlich nur dann, wenn Du Anwendungen hast, die mit Broadcasts arbeiten, und diese das Netz mit den Broadcasts fluten. Doch auch da kann es passieren, dass diese Anwendung überall benötigt wird

Kenne den Heise-Artikel nicht, aber von dem, was ich sonst gelesen habe (die wichtigsten wurden hier schon verlinkt), war der Aufwand im Sinne von insgesamt aufgewendeten Stunden ja nicht so wahnsinnig hoch. Es sind die Jahre, die es insgesamt gedauert hat, die mir hier großen Respekt einflößen - vor allem, da man nicht weiß, an welchen anderen überlasteten "Random Guys from Nebraska" bereits seit Jahren gebaggert wird. Aber rein ressourcentechnisch könnte es auch eine One-Man-Show gewesen sein. Spannend fand ich auch die Hinweise, dass es Ungereimtheiten in dem vermeintlich chinesischen Namen gibt. Aber da müssen wir wohl noch abwarten. Die ganze Diskussion nach "mehr Geld für Open Source-Entwickler", die wie immer sofort ausgebrochen ist, greift natürlich auch zu kurz. Es war ja nicht der Geldmangel, der Lasse Collin in die Arme des vermeintlichen Jia Tan trieb. Wenn wir etwas schaffen wollen, das dieses Szenario in Zukunft verhindern soll, muss es mit Maßnahmen einhergehen, die gerade in der Open Source-Community auf wenig Gegenliebe stoßen werden. Sowas wie eine Clearing- und Matchmaking-Plattfrom, auf der Klarnamenpflicht herrscht. Was Hersteller von kommerziellen Produkten allerdings machen könnten, und die Plattformen geben es heute schon her, ist an die Maintainer der Projekte, die sie nutzen, herantreten und sagen: wir geben Dir X Geld jedes Jahr dafür wird ein Account von uns "kommerzieller Co-Maintainer" jeder PR wird bis 48h (können auch 72h sein) zurückgehalten, before er ge-merge-t wird. In dieser Zeit können alle kommerzielen Co-Maintainer einen Code Review vornehmen und mit Begründung rejecten. Wer das Recht innerhalb dieser Zeit nicht wahrgenommen hat, hat es für diesen PR verwirkt bei Übertragung der Maintainerschaft des Projektes hat jeder zahlende kommerziele Co-Maintainer ein Vetorecht Oder sowas in der Art. Dadurch wird die Freiheit in der Software-Entwicklung nicht eingeschränkt, die Supply Chain aber geschützt. Und die Software-Firmen werden in die Pflicht genommen, nicht bloss einen finanziellen Beitrag zu leisten, sondern auch bei der Qualitätssicherung mitzuwirken. Schließlich bauen sie Produkte daraus, wo deren Name draufsteht

...aber immerhin haben wir seit 1967 auf dem europäischen Kontinent keinen Linksverkehr mehr In den USA gibt es sogar verschiedene Zeitzonen innerhalb eines Bundestaates (z.B. die "Redneck Riviera" in Florida). Was mich allerdings in Bezug auf "geht also, wenn man will" am meisten fasziniert, ist Indien. Die arbeiten ständig mit der ganzen Welt zusammen und haben die Zeit nicht nur um N Stunden, sondern auch noch zusätzlich um eine halbe Stunde verschoben. Auch das funktioniert...

...und hier ist "hauptsächlich" der Punkt, an dem sich alle Wege gabeln werden: wenn Du zu 100% Windows-Rechner hast, die alle im selben AD-Forest Mitglied sind, behaupte ich mal, dass der Aufwand, die Inventur eines Endpunkts zu skripten, bei zwei Stunden liegt, und der Aufwand, diese auf alle Endpunkte auszurollen, bei einer Minute (File Copy per GPP + Scheduled Task in GPP) wenn Du zu 100% Windows-Rechner hast, sie aber NICHT alle AD-Mitglieder sind, ist der Inventur-Aufwand identisch, der Deployment-Aufwand erhöht sich etwas, weil Du die Workgroup-Rechner einzeln betreuen musst hast Du neben Windows noch Linux oder Unix, wo Du aber Root-Zugriff hast, verdoppelt sich der Aufwand, die Inventur zu skripten, Deployment kommt natürlich sehr darauf an hast Du aber neben Windows, Linux und Unix noch irgendwelche Netzwerk-Geräte, musst Du anfangen, mit SNMP zu hantieren, und das will erst mal gelernt sein Hast Du mal geschaut, ob Dein (evtl. vorhandenes) Monitoring oder Deine (evtl. vorhandene) Software-Verteilung hier helfen können?

Das habe ich mich schon immer gefragt - wer denn bitte hat gleichzeitig das Know-How, einen C-Code gegenzulesen die Zeit, ein Projekt, das quasi jedes andere Projekt nutzt, nach jedem Release zu analysieren, und die Nerven, einen von anderen verfassten Code zu lesen? Merken wir hier ja auch: *entdeckt* wurde die Lücke mit "normalen" Mitteln - jemandem ist ein anormales Verhalten aufgefallen, er hat den kompilierten Prozess profiliert und seine Findings dokumentiert. Der Umstand, dass es sich hier um Open Source handelt, führte lediglich im letzten Schritt dazu, dass Andres Freund selbst die endgültige Diagnose stellen konnte.

Select-Object -ExpandProperty primaryGroupToken oder (Get-ADGroup $targetGroup -Properties PrimaryGroupToken ).PrimaryGroupToken

Es ist nicht "eine höhere Version", sondern ein anderes Produkt. Windows PowerShell und PowerShell sind zwar verwandt, aber das eine folgt nicht auf das andere oder löst es gar ab

Moin, das entscheidende Stichwort in Deiner Schilderung ist "warum auch immer", und da gabelt sich der Weg. Als ich vor 25 Jahren die ersten AD-Trainings gemacht habe, war das Disaster, das wir betrachtet haben, eine Naturkatastrophe, d.h. die Daten sind an sich gut und vertrauenswürdig, es geht also nur darum, sie technisch konsistent wieder auf die Straße zu bekommen. In diesem Szenario ist Deine Lösung komplett valide, sie kann aber auch durch einen Backup ersetzt werden, da muss man nichts neu erfinden. Heute geht ein AD in der Regel durch einen Cyber-Vorfall hops, und da sind die Daten inklusive Betriebssystem eben NICHT gut und vertrauenswürdig. Mit Komplett-Backups bist Du also schnell bei der Diskussion "welches Backup ist noch nicht infiziert", und diese Frage kann im Breach Response nie schnell genug beantwortet werden. In diesem Szenario sind alle Recovery-Verfahren, die auf Komplettbackups oder -kopien basieren, problematisch. Es gibt Anbieter für Tools, die auch "Cyber-geschädigte" ADs recovern können. Da einer davon mein Arbeitgeber ist, werde ich hier keine Namen nennen.

Moin, die Alternative unter Windows PowerShell ist, ping zu benutzen. Oder halt, wenn es in Deinem Fall möglich ist, PowerShell 7. ODER Du bedienst Dich des .NET Frameworks und machst: $ping = New-Object System.Net.NetworkInformation.Ping $ping.Send('192.168.5.105',10000) # zweiter Parameter ist Timeout in MILLIsekunden, also in diesem Fall 10s

Moin, Du siehst es teilweise richtig. Die VM hat durchaus ein Chipset, eine Grafikkarte und manchmal auch eine Soundkarte. Aber die Treiber und Tools, die von der Physik kommen, müssen natürlich runter. Initialisierungsversuch bei jedem Boot plus halt Dienste, die keine Treiber sind und sich nicht automatisch beenden, wenn das Gerät nicht gefunden wird.

Da Du keinen vCenter hast, wirst Du es über VMM nicht machen können. MVMC wäre eine Alternative, ansonsten Disk2VHD oder Bare Metal-Backup / Restore. Es gibt auch kommerzielle Tools dafür wie z.B. von Paragon.

Moin, das "g" in gMSA steht für "group". Da ist es eine 1:N-Beziehung, und Du kannst es für Service und Backup nutzen, dafür ist es da.

Das *ist* der Ansatz mit <div>s

...und bedenke dabei, dass Du die Häufigkeit des Kennwortwechsels für das gMSA nur einmal festlegen kannst, nämlich bei dessen Erzeugung Alles, was @toao und die Vorredner geschrieben haben, ist richtig und wichtig. Ein technisch deutlich komplexeres Problem als das Aufspüren von hochprivilegierten Service-Accounts ist die Frage, welche von ihnen wie stark überprivilegiert sind, d.h. auf welches Berechtigungsniveau Du das zukünftige Service-Account, ob nun Legacy oder gMSA, heben musst, damit die jeweilige Anwendung funktioniert. Insbesondere dann, wenn ihr die Default-Konstruktion nicht geändert habt, die Domain Admins zu lokalen Admins auf Member-Maschinen macht.