Zitat von @PeterGyger: Generell: Die LTSCWindows Versionen sollten diesen Anspruch erfüllen.
Generell sind die LTSC-Versionen aber nicht für den Office-Einsatz empfohlen, sondern sollen z.B. auf POS-Systemen, für Prozess-/Industriesteuerung etc. zum Einsatz kommen. Daran hat sich leider seit der ersten Windows 10 LTSC (bzw. damals noch LTSB) nix geändert.
In der Praxis bedeutete das mit der 1607: Kein vernünftiger Betrieb von Thinkpads an Dockingstations möglich. Somit als "Daily Driver" ungeeignet.
also ... die Synology DS216se stellen jetzt nicht unbedingt die absolute Hochleistungsklasse dar. Es wird durchaus wahrscheinlich sein, dass es am leistungsschwachen NAS / dessen Prozessor liegt.
mir fehlen Ideen in welche Richtung ich suchen muss. Bislang finde ich nur Lösungsansätze, wo man die ManagementShell nutzt.
Umgebung: Server 2012R2, Exchange 2013 - (läuft nur im Intranet mit einer handvoll Clients, ein lokaler Connector speist ihn mit Mails).
Vor ca 2 Wochen habe ich ein abgelaufenes Zertifkat manuell erneuert - ohne Zertifizierungsstelle, da der Server nur intern läuft - lief danach einwandfrei (Clients mussten das Cert einmal speichern). Vorgestern hab ich ihn dann das erste Mal seitdem neu gestartet - danach war Exchange nicht mehr erreichbar.
neben den Clients, die sich natürlich nicht mehr verbinden können gibt es lokal schon folgende Phänomene: - Exchange Administrative Center gibt nach Login einen 503 - Toolbox gibt nach Start einen Snapin-Fehler - Exchange Management Shell gibt nach Verbindungsversuch einen leeren Fehler
Einen ersten Fehler konnte ich lösen indem ich im IIS-Manager im Verwaltungsdienst ein aktuelles Zertifikat zugerodnet habe. Damit ließ sich der Webverwaltungsdienst wieder starten.
Fehlermeldungen gibt es natürlich viele, ich denke die beruhen natürlich auf einem Grundproblem - ich hatte den Ansatz folgende damit ursächlich zu verknüpfen - Lösungen setzen allerdings die Shell vorraus:
Ereignis 36874, Schannel
Eine TLS 1.2-Verbindungsanforderung wurde von einer Remoteclientanwendung übermittelt, jedoch werden keine der Verschlüsselungssammlungen, die von der Clientanwendung unterstützt werden, vom Server unterstützt. Fehler bei der SSL-Verbindungsanforderung.
oder diese:
Ereignis 2005 MSExchange Certificate Deployment
Verbund- oder Authentifizierungszertifikat nicht gefunden: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. Das Zertifikat wurde am lokalen sowie an benachbarten Standorten nicht gefunden. Bestätigen Sie, dass das Zertifikat in Ihrer Topologie vorhanden ist, und setzen Sie das Zertifikat bei Bedarf bei der Verbundvertrauensstellung mithilfe von 'Set-FederationTrust' oder 'Set-AuthConfig' auf ein gültiges Zertifikat zurück. Die Übermittlung des Zertifikats an den lokalen oder die benachbarten Standorte benötigt möglicherweise etwas Zeit.
Im IIS sehe ich 3 aktuelle Zertifikate, die am entsprechenden Tag erstellt worden sind - allerdings hat keines den Hashwert, der oben drin stand. Zudem heißt es dort:
Dieses Zertifizierungsstellen-Stammzertifikat ist nicht vertrauenswürdig. Installieren Sie das Zertifikat in dem Speicher vertrauenswürdiger Stammzertifizierungsstellen, um die Vertrauensstellung zu aktivieren.
Hat er irgendwo noch das alte abgelaufende Cert drin gehabt und mit Neustart reingeschrieben? Oder fehlt ihm irgendwo, wie das neue heißt? Oder wo kann ich neue Zertifkate erstellen und neu einbinden? (ohne Management Shell etc)
das deaktivieren des Updates ist natürlich auch eine Möglichkeit. Leider weiß man nie ob einem das irgendwann mal auf die Füße fällt.
Bei allen Clients mit diesem Problem habe ich bis jetzt erfolgreich eine Lösung mit "mde-free-portable" jetzt in der Version 8.16 hinbekommen (auch VMs). Dauert mit Änderung der Partition und Neustart keine 10 Minuten.
Bis auf ein DELL NB, hier blieb mir nichts anderes übrig aus es zu deaktivieren.
Jedenfalls verdient sich MS hier keine Lorbeeren. Erst den Fehler in Umlauf bringen und die Lösung den Usern zu überlassen ist nicht nett (einen persönlichen Kommentar verkneife ich mir mal)
Wie soll den der Angreifer die IP-Adresse des Netzwerkes wissen, was er vielleicht infiltrieren will? Ja, es gibt die Bereiche, die man für die Netzwerke nutzen darf. Aber auch das VPN-Netzwerk wird doch Datenpakete verwerfen, wenn diese nicht dem passenden Netzwerk übereinstimmen.
es steht und fällt mit Schreibgeschwindigkeit der Festplatten im NAS und dem Speicher Ausbau. @kreuzberger Deine DS-920 ist sehr schnell, weil Du den Schreibcache mit den NVMSSD aufgebohrt hast. Früher hatte Synology mal schöne Bilder wie gut der Down- oder Upload ist. Somit kann das Schreiben auf dem NAS langsamer sein als das Schreiben auf dem Rechner. Zumal heute die Arbeitsrechner viel Arbeitsspeicher haben und die Festplatten SSD oder SSD NVM verbaut sind. Somit könnte Dein WLAN zwar mehr aber dann ist Dein NAS Dein Flaschenhals.
wenn Windows 11 nicht installiert werden möchte, dann versuch es doch mal mit einem vernünftigen telemetriefreiem Betriebssystem. Davon gibt es viele und auch damit kann man privat so gut wie alles machen was man möchte.
Tschüss und noch einen schönen Männertag aus Ostthüringen
Oder begeht jede Firma die M365 nutzt per se einen Datenschutzverstoß?
Die praktisch relevantere Frage für Unternehmen ist, ob ihre zuständige Aufsichtsbehörde einen Datenschutzverstoß feststellen würde. Das kann bei richtigem Vorgehen praktisch ausgeschlossen werden, da Microsoft bislang ein zu bewegliches Ziel ist. Der dem Beschluss der DSK von 2022 zugrundeliegendeSachverhalt hat keine zwei Monate gehalten. Es ist auch keine Motivation der Datenschutzbehörden erkennbar, Anwender zu sanktionieren, sondern man möchte offensichtlich die besagte Bewegung vorantreiben und steuern.
Neben der Vereinbarung des aktuellsten AVV ist nach der derzeitigen Beschlusslage bzgl. des Cloud-Act auch eine TFA bzw. ein Äquivalent vorzuhnehmen. In dem steckt die eigentliche Arbeit für den Verantwortlichen, weil Microsoft als Zuständiger für eine solche TFA wenig trasparent ist. Angesichts des von der DSK geforderten Prüfungsmaßstabs spielt das formell zwar keine Rolle - der Verantwortliche führt de facto eine TFA durch. Aber die Ergebnisse lesen sich aufgrund der nötigen Annahmen und Spekulationen meist nicht allzu überzeugend.
für Backup Export aus Acronis Cyberbackup mittels acrocmd hol ich mir die arcuids und führe folgendes aus. Letzte Zeile des Return des Exports als Success-Indication.
WSUS wegen 3 TB soll raus. Bleibt es auch. Es sollten dann 41 von 42 Exportiert werden. Ich bekomm aber nur 40 heraus! Es gibt keine *.ERROR Datei oder Log Eintrag dazu.
Ginge vlt. noch schöner aber es läuft. Wenn es um 4 Uhr nachts startet wird parallel gut 1 TB in 2,5 Std. geschrieben. Auch OK soweit.
Nur es fehlt mir immer eine VM - das Archiv01. Ist aber so im Array mit drin. Wenn ich als Trockenübung nur ein "Out-File" jetzt mache und parallel statt des Exportes einfach eine TXT schreiben lassen, ist Archiv01 mit drin. Auch im Array is die arc_uid enthalten.
$_ | Out-File -FilePath "d:\temp\test\$($_).txt"
Es schlägt immer nur der Lauf in der Nacht via Taskplaner fehl.
Bei mehreren Blöcken kann man ja -Begin und -End auf $null setzen. Ich hab aber nur diesen einen Block. Es verhält sich nur nun fast so, als wenn das 1. Object in $null reinläuft. Hab es aber unten nicht so aufgebaut.
In VScode ist alles schön. Man bekommt jedes mal die 41 Dateien (sortiert nach letzten Backup/ Archiv Erstelldatum vor x-Monaten). Liege also nun immer beim 08. Mai. Wollte eh noch Log einbauen.
Hat jemand spontan eine Idee wieso es in VScode läuft, aber via pwsh.exe + Taskplaner das 1. Objekt immer raushaut?
Gute Tag, ich habe ein Problem, aktuell habe ich Windows 11 auf meinem recht neuen PC. Durch diverse Probleme will ich es neu installieren. Das Problem ist, dass dies nicht funktioniert. Ich vermute es hat etwas mit dem SecureBoot zu tun, dieser ist deaktiviert. Warum? Wenn ich im Bios den CMS Support deaktiviere, erst dann wir die Secure Boot Option überhaupt aufgeführt. Aktiviere ich diese und stelle sie auf standart, erkennt er werder meine M2 SSD oder den Installations-Stick. Aktiviere ich den CMS Support, ist die Sercure Boot Option im Bios entfern, aber es werden die SSDs oder Sticks erkannt.
Möchte ohne Secure Boot Windows 11 installieren, geht er bis zum auswähle der W11 Veriosn und sagt mir dann, dass W11 nicht installiert werden kann.
Wie im Bild zu sehen ist.
- GIGABYTE Z790 AERO G, Mainboard - WD Black M2
Ich habe schon 2,3 Thema dazu gesehen, jedoch ohne Lösung.
was hast du denn da eigentlich für ein Synology NAS?
Ich selbst habe da auch schon erstaunlich Unterschiede bei der Performance von Synology NAS je nach Typ und Plattenausstattung erlebt. Ich hab hier zB. ein DS218 mit 2x10TB WD HDD, bei dem ich ähnlich schlechte Transferraten habe wie du. Wenn ich das vergleiche mit meinem DS920+ (2x256GB NVME Cache, 4x6TB HDD) sieht die Welt eben völlig anders aus. Da raaaaaast alles ratz-fatz.
Vielleicht hast du ja die Möglichkeit, über die selbe WLAN-Strecke eine andere SMB-Freigabe zu erreichen und vergleichst das mal. (Freigabe auf einem anderen PC/Server/Notebook, was auch immer....)
ich bin etwas ratlos, daher hoffe ich dass hier der/die eine oder andere ggf. eine Idee hat, woran es liegen könnte.
Ausgangssituation:
Glasfaser mit 1.000 up/down Fritzbox Fibre
in 4 Meter Entfernung (2 dünne Holztüren) Fritz Repeater 6000 daran angeschlossen Synology NAS
gleicher Raum, 2 Meter Entfernung, keine Hindernisse Fritz Repeater 3000 per LAN angeschlossen ein Mini PC mit ner SSD
Ein Speedtest ergibt eine Geschwindigkeit von ca. 170 - 200 mbit/s
Downloads von z.B. Ubuntu laufen mit ca. 80, beim jdownloader bis zu 100....
wenn ich auf WLAN gehe, bekomme ich ähnliche Werte was den Speedtest angeht, Downloads pendeln sich aber bei ca. 40 mbit/s ein
Wenn ich eine Datei aufs NAS verschiebe, ist die Geschwindigkeit (ob WLAN oder LAN) immer so bei 40 mbit/s.
Das erklärt sich mir nicht so wirklich, normal müsste die Geschwindigkeit doch mindestens auf WLAN Speed sein, oder?
wenn ich z.b. einen usb festplattenadapter mit einer ssd bestücke und per usb 3.0 an den mini pc anschließe erreicht der ne geschwindigkeit von knapp 500 mbit/s...
jemand ne Idee wo der Flaschenhalt bzw. die Bremse sein könnte?
Die Verschlüsselung wird seit Ende 2023 ja nicht mehr empfohlen
Der ganze Server 2012 wird schon seit zig Jahren nicht mehr empfohlen Dann kannst du auch die Verschlüsselung einsetzen, macht es nicht besser oder schlechter
Aber was noch zu erwähnen wäre. Mit der Verschlüsselung TripleDES-SHA1 kann auch für einen Server 2016 eine Umgehung genutzt werden. Der Server ist noch unter Support. Das kommt vom Hersteller MS. Artikel vom 24.03.2024
Aber das eigene interne Netz stellt mE sowieso nicht das Problem dar, da selbst dann, wenn per einem "illegalen" DHCP-Server ein weiteres Gateway verteilt würde es nicht wirklich viel brächte, außer der Angreifer hätte sowieso schon einen Empfänger im internen Netz dafür platziert. Daten aus dem internen in externe Netze dürfte in der Regel scheitern in gut konfigurierten Netzen.
Das Hauptproblem besteht also in der Tat bei unbekannten Netzen über die dann ein VPN oder andere Verbindungen aufgebaut werden sollen.
Danke, aber für unvertraute Netze finde ich die Lösung von MayBeSec nicht schlecht. Ich hatte auch nur daran gedacht irgendwie die fehlerhaften DHCP-Infos zu filtern, aber ausgehend den Traffic zu regulieren ist auch eine gute Lösung. Geht allerdings nur, wenn man kein Split-Tunneling vorhat, wobei man dann die Firewallregeln notfalls auch auf die im VPN verwendeten Netze eingrenzen könnte.
liest sich für mich ja eher so als wollte das itacom-Tool einen Lizenzserver (vermutlich bei itacom) konsultieren und dabei wird diese Meldung zurückgegeben.
Habt ihr eventuell eine Firewall oder andere Schutzmechanismen die SSL prüfen im Einsatz?
Wie @MysticFoxDE wegen dem Strahlungswinkel sagt, soll dass mind. für die OG besser werden. Die Höhe ist dann nicht 2,5m sondern 5m. Dann kommt noch der Vorteil von Holzdielen gegen Ziegelstein, denke ich. Ich werde es später ausprobieren.
Das klingt plausibel. Viel Erfolg!
(bin gespannt auf die Unterschiede der Messergebnisse
Fehlermeldung lesen hilft ... Bringt eure Zertifikatsstruktur i. Ordnung. Also der CA die das Zertifikat ausgestellt hat in die vertrauenswürdigen Root-Zertifikate importieren und sicherstellen das das Serverzertifikat alle nötigen Erweiterungen für den jeweilige Zweck aufweist, der Common Name bzw. Die Subject Alternative Names auf den Host passen auf den zugegriffen wird und die Gültigkeit des Zertifikats noch gegeben ist. Korrektes Datum/Uhrzeit der beteiligten Hosts nicht zu vergessen.
Das vom Kollegen @LordGurke vorgeschlagene DHCP Snooping ist aber die deutlich sinnvollere Lösung und üblicherweise auch "Best Practise" in allen gut konfigurierten Netzen!
bei der Firma Itacom haben wir ein Migrationstool erworben, das die Migration von Tobit David nach Exchange ermöglicht. Beim Lizenzieren der Benutzer tritt jedoch eine Fehlermeldung auf (siehe Bild). Obwohl wir bereits TLS 1.3 deaktiviert haben und einen erneuten Versuch unternommen haben, blieb der Erfolg aus. Hat jemand eine Lösung?
Du kannst bei den jeweiligen Clients unabhängig des OS mit den dort verfügbaren Firewall eine Regel anlegen mit "blocke alles" und dann eine mit den zugelassenen Gateways für das Tunnelinterface.
Dann bliebe nur noch iOS zu klären, bei Android wird Option 121 sowieso ignoriert.
...und "Zeichnung2" bzw. der Zielzustand ist jetzt aktiv?? Das was du da aufgezeichnet hast ist einmal das klassische Layer 2 Design mit einem externen Router und einmal das klassische Layer 3 Design mit einem routingfähigen VLAN Switch.
ob ich den Zielzustand mit den gegebenen Mitteln überhaupt erreichen kann.
Ja, völlig problemlos!! Alle ToDos sind in diesem Tutorial dafür explizit und Schritt für Schritt erklärt!! Wurde dir aber auch schon mehrfach gesagt. Jetzt musst DU das nur noch umsetzen!
Zitat von @MayBeSec: Solange das EU-U.S. Data Privacy Framework aus 2023 durch ein neues "Schrems-Urteil" nicht als unzureichend aufgehoben wird, solange besteht für die Unternehmen Rechtssicherheit und „Arbeitsruhe“ (passende Implementierungen vorausgesetzt).
Für die reine Datenübermittlung (sozusagen "Storageort"=USA) kann das in Betracht kommen, für eine komplexe Anwendung wie MS365 nicht, denn der sog. Anwendungserlass und das Privacy Framework regeln Fragen der reinen Datenübermittlung, also die Frage, ob überhaupt Daten dahin fließen dürften (und solange der EuGH nicht wieder eine Kehrtwendung macht, wie gerade bei der Speicherung von IP-Adressen, ist eigentlich absehbar, dass ein Schrems III-Urteil folgen wird...). Es regelt nicht, ob eine Grundlage für den Inhalt und die Art der Erhebung der Daten gegeben ist, und gibt in diesen Bereichen auch keine Rechtssicherheit.
Sprich: Tracking durch den Hersteller, Auswerten der in die USA übermittelten Daten in den USA durch Dritte - solche "Anwendungsfälle" sind datenschutzrechtlich mit den USA nicht machbar, auch nicht mit Privacy Framework.
Aber genau das Privacy Framework ist halt ein wunderbares Beispiel dafür, warum wir im Alltag bei "kleinen" Datenschutzverstößen von Strafen hören, bei den wirklich großen Anbietern und deren Kunden aber nicht: denn die Kommission will auf Biegen und Brechen mit Blick auf das Ergebnis den vollen Datenaustausch mit den USA. Und daher gibt es auch keine flächendeckenden Sanktionen.
Man könnte ja noch diskutieren, ob man das will, oder eine Mehrheit entscheidet sich dafür (Kommission+Parlament) und die Minderheit hat das hinzunehmen. Aber es ist halt paradox, in der EU eine gesetzliche Regelung zu schaffen, die im transatlantischen Bereich einfach ignoriert wird.
Zum Thema Tracking ergänzend: da würden auch keine Einwilligungen aller Mitarbeitenden und Geschäftspartner helfen. Denn eines der großen Fragezeichen bei Microsoft sind Art und Umfang der Telemetriedaten, die nicht dokumentiert und veröffentlicht sind. Selbst die europäischen Staaten erhalten darauf keine vollständige Antwort (jedenfalls, soweit man das in der Presse lesen kann). Damit ist auch keine geeignete Einwilligung denkbar.
"Der" Port muss niemals den Radius erreichen sondern nur die Management IP des Switches. Der Port selber hat ja auch keine IP Adresse, zumindestens nicht als Switchport. Das war vermutlich dein Denkfehler im Eifer des Gefechts.
Wie ich das 99/Mgmnt untagged auf der OPNsense definiere, habe ich glaube ich hier gerade gefunden:
Dafür musst du gar nicht in die Ferne schweifen sondern das steht auch HIER im LAG Tutorial! Bzw. ist so oder so grundlegender Standard bei allen OPNsense / pfSense Interfaces. Wurde dir aber auch schon mehrfach gesagt und ist eigentlich mit einer kinderleichten Logik hinterlegt:
Als alter OPNsense Hase weisst du ja auch schon seit langem das das IP Netz was direkt auf einem Interface wie z.B. dem LAG Interface bei dir liegt (hier dein Parent Interface für deine VLAN Interfaces!) automatisch immer das PVID VLAN ist und so dessen Traffic immer UNgetagged gesendet wird. Die physischen Interfaces oder Parent Interfaces sind also damit immer das PVID VLAN Netz. Sprich wenn du bei dir das VLAN 99 direkt auf dem LAG Interface konfigurierst wird es untagged von der OPNsense gesendet. Sollte der Switch am LAG/Bonding Port dann ebenfalls PVID 99 gesetzt haben wird dieser Traffic dann erwartungsgemäß ins VLAN 99 geforwardet. Ggf. noch einem die VLAN Schnellschulung lesen die das alles noch einmal explizit sogar mit bunten Bildern erklärt! 😉
Fazit: Es kommt also IMMER darauf an WIE du das Parent Interface der OPNsense behandelst.
Hast du da gar keine IP Adresse konfiguriert wird es nicht benutzt und ist inaktiv
Mit IP Adressierung wird dieser Netztraffic untagged gesendet und empfangen = PVID VLAN
Auf dem Gegenüber (Switch etc.) bestimmt dann das PVID Setting (native VLAN) in welches VLAN dieser Traffic geforwardet wird. Bei dir würde man den Bonding Port auf PVID 99 setzen wenn du dem LAG eine VLAN 99 IP vergeben hast.
Wie du das handhabst ist dann persönliche Gescmackssache...
Decken sind grundsätzlich ein Problem (Beton/Metallgitter)
Die Decke im EG ist Stahlbeton, aber im OG sind es Holzdielen. Wie @MysticFoxDE wegen dem Strahlungswinkel sagt, soll dass mind. für die OG besser werden. Die Höhe ist dann nicht 2,5m sondern 5m. Dann kommt noch der Vorteil von Holzdielen gegen Ziegelstein, denke ich. Ich werde es später ausprobieren.
Anschließend bekommt er dann den Wifi-Dokotortitel und die Frau reicht die Scheidung ein. face-wink
Sowas macht man normalerweise direkt auf dem Switch. Da wird festgelegt an welchen physischen Switchports DHCP-Server betrieben werden dürfen, an unerlaubten Ports verwirft der Switch dann die Pakete. Bei der Gelegenheit sollte man sowas dann auch für IPv6-RA konfigurieren, da hast du ein ähnliches Problem.
Das hilft nicht nur gegen böswillige Angreifer sondern auch gegen versehentliches Einbringen von ungewollten DHCP- und RA-Servern.
Am Client kannst du da wenig machen, da du (in öffentlichen Netzen) überhaupt nicht weißt welche IP- und MAC-Adresse der autoritative DHCP-Server dort hat.
Und für Hotel-WLANs gilt: Wenn ich dem Netz nicht vertraue, aber eine halbwegs vertrauenswürdige Umgebung brauche, dann nutze ich das WLAN nicht sondern nehme eine Verbindung über Mobilfunk. Wem das zu viel Datenvolumen ist, hat dann halt nicht den richtigen Tarif für sein Business.
Das solltest du m.E. niemals machen, denn dann wäre der Port ja per Default im Management VLAN 99 was du im Normalfall an Nutzerports keinesfalls willst! Das Management VLAN gehört doch niemals auf Enduserports!
Ja, diese Gedanken hatte ich eben auch. Deshalb hatte ich nachgefragt. Ich glaube, dass ist mir im Rahmen meiner missglückten "Fehlersuche" passiert, weil ich mich irgendwann fragte, ob der Port überhaupt den Radius erreichen könne, bzw. warum ich keine Zuweisung erhalte.
Danke Euch. Dann bin ich schon mal vom Verständnis ein Stückchen weiter.
Es gibt noch eine entscheidende Korrektur die das Setup noch einmal deutlich vereinfacht!!! Durch diese Änderung sind DDNS Adressen für die Peers der remoten Mikrotiks überflüssig. Man erspart sich so lästige Fragerei nach IP Adressen, DDNS in den Zielnetzen der Kollegen. Zur einfachen Lösung gibt man dafür dann wie generell üblich die 0.0.0.0 als Peer IP Adresse auf der Responderseite der Fritzbox ein im Parameter remoteip = 0.0.0.0; Mit dem IP Setup akzeptiert die Fritzbox generell eingehenden VPN Verbindungen egal von welcher Absender IP Adresse. Damit kann man den Home Office Kollegen den Mikrotik fertig konfiguriert als "Plug and Play Box" mitgeben die sie nur noch ins heimische Netzwerk klemmen müssen für den Bürozugang!
Hier muss unbedingt in den Policies unter Action der Level auf Unique gesetzt sein!! Danach kommen die Peers sofort hoch im Status "Established" und auch die Fritzbox VPN Indikatoren werden grün!
Ping Check Mikrotik
Hier ist beim Pingen der Fritzbox über den VPN Tunnel zwingend darauf zu achten in den Advanced Settings die Absender IP auf die lokale LAN IP zu setzen!! Andernfalls verwendet der Mikrotik eine andere Absender IP und der VPN Ping geht ins Nirwana!
Solange das EU-U.S. Data Privacy Framework aus 2023 durch ein neues "Schrems-Urteil" nicht als unzureichend aufgehoben wird, solange besteht für die Unternehmen Rechtssicherheit und „Arbeitsruhe“ (passende Implementierungen vorausgesetzt).
Das bedeutet natürlich nicht, dass ggf. SVK, TIAs und weitere Risikoabwägungen obsolet sind.
Es macht wahrscheinlich Sinn den ganz nach oben in 2. OG zu bringen, damit der Leistungsunterschied größer wird und die Clients nicht bei einem AP kleben bleiben
Nee, das würde ich nicht machen. Decken sind grundsätzlich ein Problem (Beton/Metallgitter). Im Giebel ist der AP "Perlen vor die Säue". Die Netze können bzw. sollen sich ja durchaus überschneiden. Und bei der Decke ist die "Trennschicht" so stark, dass der Client auf jeden Fall zum stärkeren Signal wechseln wird (gerade innerhalb des 5 Ghz-Netzes). Und mit Hilfe eines Controllers kann dieser Wechsel schneller erfolgen, bzw. die Wechselzeit reduziert werden. Im Idealfall so schnell, dass Du das z.B. in einem Livestream/Telefonat nicht merkst.
Das verstehe ich nicht. Du behauptest, die Stabantennen seien in diesem Setup besser. Ursprünglich behauptest Du sogar, es ginge nur damit. Ich behaupte, dass für dieses Setup die Decken-APs auch genügen. Ich zeige Dir Pattern eines 08/15 Decken-APs kontra Stabantenne vom gleichen Hersteller. Und Du versuchst mich zu widerlegen: Nein, nicht indem Du einen besseren AP mit Stabantenne präsentierst – sondern einen schlechteren Decken-AP? Der imho vom Pattern her immer noch besser aussieht als die obigen Stabantennen?
Und genau das wäre noch schlimmer, weil du damit schlichtweg noch weiter über das Ziel hinaus schiessen würdest.
Deswegen mache ich solche Tests ja auch nicht.
Alle getesteten Geräte verfügen über "dynamische" Antennenanpassungen (Beamform und Beamflex). Und speziell um diesen Vergleich geht es. Und natürlich sind die dbm-Werte tendenziell höher und je nach Technik unterschiedlich ausgeprägt, weil man den Strahl mit Hilfe dieser beiden Techniken ja fokussieren will. Und die Fähigkeiten der Techniken sollten verglichen werden. Gibt es irgendwas handfestes, was die Messergebnisse widerlegt oder muss ich das auf Grund von "Fraunhofer", "Institut" und "Chef" einfach ehrfürchtig auf die Knie gehen?
Reichen theoretisch schon, zufriedener währe er aber definitiv mit einem guten AP mit Stabantennen oder ähnlicher Antennencharakteristik.
Das mag sein – viel Erfolg auf der Suche nach dem Optimum. Die bisherige Erkenntnis ist ja, dass es auch der 08/15 Unifi im Hausfrauen-Budget hinbekommt. Ganz nach Pareto: 80% sind erreichbar mit 20% des Gesamtaufwands ... danach wirds anstrengend 😉
Bintec W1002n
Klar. Und den schraubt er sich dann an die Decke. Oder er kauft anschließend zusätzlich ein ganz anderes Modell mit Stabantenne. Anschließend bekommt er dann den Wifi-Dokotortitel und die Frau reicht die Scheidung ein.😉
Vielleicht können wir uns abschließend und fernab der theoretischen Rechthaberei um das goldene Kalb einfach dem Problem des TEs widmen. Denn das Angebot an optisch attraktiven, leistungsstarken APs mit Stabantennen und aktueller Technik im gesteckten Preisrahmen scheint mir doch eher übersichtlich.
Generell: Die LTSCWindows Versionen sollten diesen Anspruch erfüllen.
Diese Frage ist Teil eines komplexes Projektes (Betrieb von Win 10 auf Win 11 umstellen). Die Lizenzfragebzw. Telemetrie / Apps etc. sollte mit einem Systemhaus vorgenommen werden.
Dann ist auch die Verantwortlichkeit und die Haftung (Schadensersatz) sicher geregelt.
Ein anderer Aspekt ist, dass der Admin der MS 365 "betreibt" für die Rechtsverstösse von MS "haftet". Auch wenn der Mitarbeiter nicht in der IT arbeitet. D.h. als Fachmann bestimmte Aufgaben in MS 365 übernommen hat. Wir haben das Anfang Jahr in einer Firma mit gegen 10'000 Ma mit der Rechtsabteilung diskutiert. Bis jetzt ist IMO noch kein solcher Fall bekannt. Aber die Rechtsabteilung hatte diese Möglichkeit nicht ausgeschlossen.
Wenn das in der Praxis geschehen sollte, ohne das der Mitarbeiter bewusst / nicht geschult / etc. gegen den Datenschutz verstossen hat, dann hat MS in Europa ein Problem...
Das Problem ist nicht neu, aber wohl nicht nur auf VPNs beschränkt. Wenn es einem Angreifer gelingt in einem Netz dhcp Pakete zu verschicken, dann kann er wohl jedweden Verkehr, welcher das Netz in dem er sich befindet verlässt, umleiten..
Gibt es eures Wissens in Windows die Möglichkeit die Clients so einzustellen, dass dhcp-Pakete oder zumindest bestimmte Optionen, nur von einer bestimmten Quelle akzeptiert werden? Wäre eine Windows-Firewall Regel eine Möglichkeit?
Moin, ich habe bei uns nachgefragt, wie das läuft.
Die Rahmenbedingungen sind bei uns ein wenig anders. Wir nutzen einen Ruckus WLAN Controller + APs. Als Radius kommt Microsoft NPS zum Einsatz. Die Zertifikate unserer PKI werden auf den iPhones, iPads via MDM (Mobile Iron) ausgespielt.
Im Zertifikat für den NPS stehen als CN der FQDN des NPS Cluster drin. Im SAN ist neben den FQDN des Clusters auch alle FQDN der Nodes zu sehen.
genau das habe ich mit den Zertifikaten von LetsEncrypt und eigenen CAs sichergestellt (die eigenen CAs habe ich natürlich auf dem Client installiert und auch aktiviert (aktivieren ist beim iPhone leider nötig!).
Hast du eine zweistufige PKI? Hast du beide Zertifikate auf dem iPhone installiert?
nein, ich glaube nicht, dass wir da durcheinander gekommen sind.
GB und G(bit) sind aber nach wie vor zwei paar Schuhe. Und zwei Maßeinheiten zu vergleichen kann man machen, muss aber höllisch aufpassen. Sonst geht das irgendwann verloren...
Es geht um die Erfahrungswert bzgl. IOPS wenn es zum starten der VMs zu den Hochzeiten kommt.
Kann man meiner Meinung nach nicht allgemein beantworten. Es hängt schon vom OS ab und dann spielt die installierte Software auch noch eine Rolle. Daher bildet man in der Regel Gruppen der verschiedenen Anforderungen (Low, Normal, High) und schaut über den Mittelwert.
Wenn das LAN mit ca. 30k IOPS belastet wird, sagt mir das im TS-Betrieb ja nicht, wieviel IOPS ich bei einzelnen Virtuellen Desktops zu verarbeiten habe.
Hat man dafür nicht ein Monitoring, die solche Daten erfasst. Damit man diese jederzeit auswerten kann. Wie stellst du rechtzeitig fest, dass die IOPS nicht mehr ausreichen werden? Du wirst kaum warten wollen, bis sich die User beschweren.
Nein, wenn die IT immer nur ihren Schuh anzieht und so das Unternehmen beeinflusst, ist das ebenso falsch.
Das habe ich nicht gesagt. Aber den Nutzer geht es nichts an welche Technik und Hersteller zu Einsatz kommt. Er definiert Anforderungen und Wünsche. Was dann entsprechend evtl. einen Mehrwert bietet und Priorität einnimmt, ist Sache des Management.
Innerhalb der IT bzw. des verantwortlichen Teams kann man sich zu Techniken und Lösungen rege austauschen. Aber am Ende hat die Person, welche die Entscheidung tragen muss und dafür unterschreibt, das letzte Wort. Witzigerweise sobald es um Beschaffungen geht, welche eine Unterschrift von Management benötigen, werden die jungen Kollegen still...
Das Ganze per iSCSI 25G im Storage Network.
Welche Gründe gab es um sich für iSCSI zu entscheiden?
Kann ich so nicht nachvollziehen, ich habe jahrelang Adobe Reader und co. per GPO verteilt.
Richtig, nutze ich heute noch für Adobe, KeepassXC, PDFsam Basic, pdf24 und weitere. Easy und zuverlässig, sofern man sich an ein paar Spielregeln hält und die Hersteller die Verteilung am Schirm haben.
wenn die Antennen so ausgerichtet sind dann macht das wohl wenig Sinn.
Ich nennen das immer sorry das Hausfrauenproblem bei WLAN - es gibt ja auch Desktop-APs oder Router mit solchen Stabantennen, Hausfrauen neigen dazu das immer optisch schön auszurichten, d.h. alle gleich ;=)
Auch auf der Baustelle, erst Gestern wieder:
Die AP können Sie doch an der Wand montieren - weil wir haben eine Wasserdeckenheizung. Können schon will ich aber nicht. Oder wir legen die APs in die Abgehängte Decke hinter die Heizung (mit Wasser) - Ne will ich nicht, noch viel weniger.
Ich sag dann immer soll es schön aussehen oder soll es auch funktionieren?
Und die Notausgangsbeleuchtung und der Rauchmelder wird ja auch nicht hinter der Wandvertäfelung versteckt obwohl die grottig aussehen.
