cj_berlin

Moin, in diesem Fall kannst Du den Exchange nach Anleitung deinstallieren. Allerdings wird dabei der Installer auch das mail-Attribut bei den Usern löschen, so dass Outlook-Autokonfiguration nicht mehr funktioniert. Daher am besten das mail-Attribut bei allen Usern vor der Deinstallation exportieren und danach wieder auf den vorherigen Wert setzen.

Ich habe das bei Microsoft eingekippt, jemand untersucht das Thema, aber ohne irgendwelche Zusagen. Sie sind doch wirklich jedes mal überrascht, dass Leute den Kram, den sie sich ausgedacht haben, wirklich benutzen

https://developers.redhat.com/blog/2020/11/19/transitioning-from-docker-to-podman#about_podman

Wenn das die Lösung bringt, gerne auch das. Und ich wette, es gibt garantiert ein Video, wo das beschrieben wird. Das Thema hat sich ja seit 12 Jahren Null geändert.

2022 Essentials gibt es nur als OEM, also quasi von den Hardware-Herstellern. Wenn Du ein laufendes DynDNS von einem anderen Provider hast, sollte das Zertifikatsthema leicht lösbar sein. Wenn Dein Wissen dazu nicht ausreicht, mach das gleiche, was ich machen würde, wenn ich in Deinem Fach was erledigt haben möchte, mir aber das handwerkliche Geschick oder das notwendige Werkzeug dazu fehlt

Dann überschneidet sich Dein Blickfeld anscheinend nicht mit meinem. Ich habe naturgemäß mit Leuten zu tun, die sich vorrangig um solche Projekte kümmern, und ich glaube nicht, dass irgend jemand dort über lange Weile oder Zukunftsangst geklagt hat Was ich (wiederum naturgemäß) in der Cloud sehe, ist, dass langsam aber sicher Kunden aus der "die Cloud wird's schon richten"-Fraktion auf die Schnauze fallen, sich der wahren Natur der "Shared Responsibility Matrix" bewusst werden und anfangen, am lebendigen Objekt Governance einzuführen. Infrastrukturseitig ist - für mich völlig unbegreiflich - ein leichter Trend zu erkennen, die on-prem-VDI oder sogar Terminaldienste (egal ob nativ oder Citrix) in die Cloud zu verschieben, unabhängig davon, ob die Anwendungen, die dort genutzt werden sollen, vorrangig in der Cloud sind oder nicht. Virtualisierungs-Consultants bereiten sich darauf vor, dem Mittelstand gangbare Alternativen zu VMware zu bieten.

Ja, scheinbar bist Du nicht alleine mit dem Phänomen Keine Ahnung, ob es in Essentials irgendwelche Sonderlocken gibt, aber im Grunde ist es ja normales RDS-Gedöns, und da gibt es im Server-Manager einen Assistenten, mit dem man das Zertifiklat durchtauschen kann. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn781533(v=ws.11) CSR kannst Du mit certlm.msc auf dem Server erstellen oder auch online auf https://csrgenerator.com/ (aber dann hat der Anbieter Deinen privaten Schlüssel). Für den Wizard im Server-Manager brauchst Du so oder so eine PFX-Datei.

Moin, das ist eine Funktion von Essentials und hat mit dem Router nichts zu tun. Theoretisch sollte es sie auch unter Server 2016 noch geben, aber nicht dass Microsoft sie abgeschaltet hat, weil Server 2012R2 aus dem Support ist. Das ist offensichtlich seit Anfang April schon so. Deine IP-Adresse ändert sich also vermutlich nicht jeden Tag

LinOTP funktioniert sehr gut mit NetScalern und ist eine ganze Ecke günstiger als RSA.

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.