cj_berlin

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.

Wie waren denn meine angehängt? Einfach in den Post einfügen. Aber Word-Dateien aus dem Internet aufmachen ist wie in einer Bar aus einem zufälligen Glas trinken - nur einer weiß wirklich, was da drin ist, und das bist nicht Du

OK, aber Du hast ja sicher auch schon bemerkt, dass Deine Maus noch gar nicht als Maus erkannt wird, sondern in der Vorstufe "Human Interface Device" stehen bleibt. Dann ist vermutlich Deine Datei "C:\Windows\INF\input.inf" versaut. Vielleicht hast Du die Möglichkeit, jemanden zu finden, der physisch greifbar ist und sich "mit sowas auskennt". Dein Problem ist lösbar, aber nicht in einem Forum. Der Hinweis von @Nobbyaushb ist übrigens mehr als berechtigt - das Forum hat exzellente Einbindung von Bildern, inklusive Copy/Paste direkt in den Beitrag, poste bitte in Zukunft keine Office-Dateien oder ausführbare Dateien verkürzte Links, wo unklar ist, welche echte URL sich dahinter verbirgt Monster-Dateien wie Logs mit 10.000 Einträgen

Moin, bei Tabellen in e-Mails bin ich immer zwiegespalten, spätestens auf kleinen Bildschirmen werden sie gern gequetscht. Ich würde das "modern", das heißt, mit <div>s machen - dann werden die sich beim Quetschen automatisch umsortieren und untereinander angezeigt werden. Aber auch einige der "Großen" wie PayPal verwenden Tabellen, sogar mehrfach verschachtelte, so dass, wie so oft, YMMV...

Moin, die Linux-Gemeinde empfiehlt für diese Karte die folgende Einstellung: Die wirkt sich natürlich auf alle PCIe-Geräte aus

Moin, Code 39 ist "Dateien fehlen oder sind beschädigt". Die meisten Mäuse heutzutage arbeiten mit dem Microsoft-Treiber, Du kannst es aber verifizieren, wenn Du im Geräte-Manager auf die "Problemmaus" doppelklickst und dann auf den Reiter "Treiber" gehst: Dann klickst Du auf "Treiberdetails" und siehst eine Liste von Dateien: Prüfe mal, ob jede von ihnen am angegebenen Ort vorhanden ist. Ist das der Fall, prüfe, ob die Signatur intakt ist: Sofern die erforderlichen Dateien von Microsoft sind (das sind mouclass.sys und mouhid.sys), kannst Du schauen, ob Du mit sfc /scannow eine intakte Version wiederherstellen kannst. Nächste Stufe wäre dann DISM.exe /Online /Cleanup-Image /Restorehealth

Hallo zusammen, folgende Herausforderung: ich möchte auf einem Windows Server prüfen, ob die Installation eines bestimmten Satzes an Rollen und Features scheitern wird, aber ohne die Installation zu versuchen. wenn ein Feature bereits installiert ist, ist der Fall klar wenn ein Feature ordnungsgemäß mit -Remove entfernt wurde, ist der Fall auch klar leider gibt es immer wieder den Fall, dass die Admins einfach CAB-Dateien aus WinSxS löschen, um "zufällige" Installaiton gewisser Features zu unterbinden. Das Feature wird von WMI dann immer noch als "Available" reportet, die Installation scheitert aber verständlicherweise. Wie kann ich diesen letzten Fall untersuchen? Gibt es eine WMI-Klasse, eine Liste oder eine Datenbank in Windows, welche die benötigten SxS-Dateien für jedes Feature auflistet? Danke vorab an alle und einen schönen Sonntag! EDIT: Ach ja, und so etwas wie DISM /CheckHealth und dann den CBS-Log parsen würde ich gerne vermeiden wollen

Moin, wie die Software ihre Client -Komponente an IP bindet, ist ihr überlassen. Der Clusterdienst sorgt dafür, dass die Rollen-IP am gleichen Host präsent ist wie anderen Teile der Rolle, nicht mehr. Du könntest versuchen, bei den Hostadressen mit dem skipassource Flag zu versehen, aber das wird vermutlich irgendwas anderes stören.

Klar, Microsoft ist schuld. Ich weiß nicht, woher Du Deine Erkenntnisse beziehst, bei mir kann ich auch noch unter Server 2008R2 die Spalte "User Logon Name" einblenden, die den UPN enthält. Das AD macht hier keine Vorgaben, Du kannst per LDAP oder PowerShell den CN auf jeden beliebigen Wert setzen, der die Eindeutigkeit des DN gewährleistet. Dass die MMC-Tools nicht das Gelbe vom Ei sind, war auch schon 1999 klar.