mwiederkehr

Nach langer Zeit kann ich hier eine Rückmeldung geben, dass das Problem wohl gelöst ist. Die Meldung (und die zugehörigen Suchresultate) haben mich auf eine falsche Fährte geführt. Als dann plötzlich bei einem Host das Clusternetzwerk auf rot war, kam ich dem tatsächlichen Problem auf die Spur. Das Problem ist, dass die NICs nach einem Reboot nach einigen Minuten Last Paketverlust zeigen. Und zwar nur die vom Clusternetzwerk, welche in einem vSwitch mit SET sind. Die nicht geteamten iSCSI-Ports laufen fehlerfrei. Firmware und Treiber sind aktuell und das Problem ist auf mehreren Servern nachvollziehbar vorhanden. Leider wissen weder Microsoft von HPE aktuell weiter, deshalb haben wir jetzt andere Adapter eingebaut. Seither gab es keine Probleme mehr mit der Performance und auch der Fehler ist nicht mehr aufgetaucht im Event Log. Die nicht funktionierenden Adapter waren "HPE Ethernet 10Gb 2-port 530FLR-SFP+". Funktionieren tun die "HPE Ethernet 10/25Gb 2-port 640FLR-SFP28". Vielleicht hilft das ja mal jemanden. Vielen Dank euch für die Hilfe!

Gut, dazu muss man sagen, dass Microsoft eine grosse Firma ist und nicht alles, was ein Mitarbeiter "offiziell" sagt für immer gilt. Silverlight gilt ja auch nicht mehr als zukunftsfähige Technologie.

Ach, man wird älter... Vor zwanzig Jahren habe ich mir noch jede verfügbare Alpha und Beta "geholt" und jetzt beobachte ich aus der Ferne, warte auf die fertige Version, und hoffe, dass nicht zu viel anders ist.

Man könnte .corp, .home oder .mail nehmen. Diese werden nicht wie .local für bestehende Dienste verwendet und werden von der ICANN nicht als TLD vergeben. (Ganz genau genommen wurde nach jahrelanger Diskussion die Registrierung abgelehnt. Es steht aber nirgends in einem RfC, dass die Namen in Zukunft nie als TLD vergeben werden dürfen. Die Chance dafür ist jedoch verschwindend klein, denn die zu erwartenden Probleme werden mit jedem Jahr grösser.) Quellen: https://www.theregister.com/2018/02/12/icann_corp_home_mail_gtlds/ / https://www.icann.org/resources/board-material/resolutions-2018-02-04-en#2.c

Ich bin etwas erstaunt über den Namen "Windows 11" (falls er denn stimmt). Bis jetzt hiess es von Microsoft ja, Windows 10 sei die letzte Version von Windows gewesen (welches natürlich weiter aktualisiert werden würde). Aber vielleicht ist das nur Marketing und aus Windows 10 21H2 wird dann einfach Windows 11 22H1 oder so. Mehr als Screenshots und runde Ecken interessieren mich die inneren Werte, unter anderem der Stand Windows on ARM.

Man kann den Backupserver auch ganz abschotten: er bekommt Zugriff auf die Hosts, aber die Hosts nicht auf ihn. Also separates VLAN oder zweites Interface an der Firewall. (Oder allenfalls Windows Firewall in kleinen Umgebungen.) Zugriff auf den Backupserver nur per RDP, TeamViewer oder Guacamole und nur vom Admin-Netzwerk aus.

Bei dieser Ausgangslage würde ich mich auf die Separierung der Backupinfrastruktur vom produktiven Netzwerk konzentrieren und evtl. SureBackup anschauen. Das hilft, besonders fiese Malware zu entdecken, welche die Daten transparent verschlüsselt und erst später den Schlüssel verwirft. SureBackup kann regelmässig die Backups auf Malware prüfen, Prüfsummen von Dateien in Backups vergleichen und VMs aus dem Backup isoliert starten und prüfen, ob sie funktionieren.

Ich sehe folgende Möglichkeiten für "Schutz vor Elementarereignissen und Malware": Externer Speicher (S3) oder Veeam Cloud Connect. Zur Unveränderbarkeit gibt es bei S3 den Object Lock und bei Cloud Connect die "Insider Protection". Dabei werden gelöschte Sicherungen noch während x Tagen beim Provider aufbewahrt. Es schützt also sogar vor böswilligen Mitarbeitern mit allen Zugangsdaten. S3 habe ich in der Grössenordnung noch nicht verwendet. Cloud Connect würde sicher gehen, auch effizient (WAN Accelerator), aber nicht ganz günstig. Wenn es nicht unbedingt ausserhalb des Gebäudes sein muss, könntest Du den Backupserver und den Speicher auch in ein separates Netzwerk nehmen. Veeam muss die ESXi erreichen können, aber nicht umgekehrt. Evtl. noch in Kombination mit einem Hardened Repository in einem anderen Netzwerk.

Ich denke, er will prüfen, ob er über das zweite Gateway ins Internet kommt, ohne das Default Gateway des Rechners umzustellen. Die Konfiguration sieht korrekt aus. Die Route ist drin und hat eine niegrigere Metrik als die Default Route. Ich habe das so auch schon verwendet für Tests und aktuell auf einem Server 2012 R2 im Einsatz. Dort allerdings mit einer Netzwerk- und keiner Hostroute, also mit Mask 255.255.255.0. Evtl. probierst Du es mal so?

Lässt sich leider soweit ich weiss nicht konfigurieren. Das Feature hat seine Vorteile, aber ich finde, sowas sollte konfigurierbar und standardmässig (zumindest für bestehende Konten) deaktiviert sein. Es gab Kunden, die hatten die Änderung nicht mitbekommen und bei denen war das Scan2Mail-Postfach recht voll deswegen. Und ich finde, wenn man auf einem Multifunktionsgerät etwas einscannt und an sich mailt, sollte nicht einfach so eine Kopie davon in einem Postfach liegen, auf das zumindest der Helpdesk Zugriff hat. Aber solche Änderungen motivieren wenigstens die Admins, die "Major Change Notifications" aufmerksam zu lesen, auch wenn es meist nur um ein geändertes Icon in Outlook geht oder so.

In der Tat, sehr geiles Video! Es zeigt wunderbar, wie sich eine Kombination von "ist nicht so schlimm"-Einstellungen auswirken kann. User haben lokale Adminrechte? Nicht schlimm, ist ja nur lokal. Support arbeitet mit Domain-Admin? Nicht schlimm, wissen ja, was sie tun. Zum Thread: muss der Rechner unbedingt in die Domäne/ins interne Netzwerk? Oder gibt es Terminalserver, über die gearbeitet werden kann? Ich kenne das BYOD-Szenario nur von wenigen Kunden, und dort ist es so, dass private Geräte auch intern wie extern behandelt werden. Sie kommen also nur ins Gast-WLAN und arbeiten von dort auf dem Terminalserver.

Zammad lässt sich an Azure AD anbinden und ist auch gehostet verfügbar. Ich würde das mal anschauen. Habe es nur selbst gehostet im Einsatz und ohne Azure AD, aber bin sehr zufrieden damit.

Du kannst die Ordnerstruktur bei einem Benutzer (oder einem dafür erstellten Konto) erstellen und die Ordner dann mit den anderen Benutzern teilen. Diese müssen OneDrive einmalig im Browser öffnen und bei den Ordnern auf "synchronisieren" klicken. Dann werden die Ordner vom OneDrive-Client synchronisiert und können normal verwendet werden. Oder es arbeiten alle Benutzer mit dem gleichen Konto. Solange Du die notwendigen Lizenzen bezahlst, ist es Microsoft egal, mit welchem Konto die Benutzer arbeiten.

Für Veeam gibt es einen CBT-Treiber: https://helpcenter.veeam.com/docs/agentforwindows/userguide/backup_cbt_driver.html?ver=50 Habe den allerdings noch nie installiert. Aber muss es eine Sicherung auf Blockebene sein? Wäre in diesem Fall eine herkömmliche Sicherung, die auf das Archivbit oder das Dateidatum schaut, nicht schneller? Die Differenz kann dann bei als geändert erkannten Fotos ja immer noch gebildet werden, um Speicherplatz zu sparen. Oder allenfalls das Systemlaufwerk als Image sichern und die Daten herkömmlich?

Ich setze bei einem Kunden den Layer2 Cloud Connector ein. Zwar nicht mit JSON, aber die Software macht einen guten und stabilen Eindruck, so dass ich es mal damit versuchen würde. Die Website ist zwar englisch, aber die Firma hat ihren Sitz in Hamburg, so dass ich davon ausgehe, dass der Support deutsch spricht.

Du musst das Dollarzeichen escapen, da dieses bei regulären Ausdrücken für "Zeilenende" steht. Also Suchen nach "__;.*\$" im Modus "regular expression".

Erstmal vielen Dank für Deine Antwort! Ich bin -so fies das tönt- sehr froh, dass ihr das Problem auch habt. So weiss ich zumindest, dass es wohl kein Konfigurationsfehler ist. Das "Normale", also 1809, Build 17763. Habt ihr einen besseren Workaround als die VMs regelmässig zu verschieben? Habt ihr eine Case-Nr. bei Microsoft? Werde auch ein Ticket aufmachen, vielleicht hilft das den Entwicklern ja bei der Fehlersuche.

Hallo zusammen Ein Hyper-V-Cluster mit vier Hosts (Windows Server 2019) gibt es immer wieder Probleme durch extrem hohe Storage-Latenzen. Diese gehen zeitweise auf mehrere Sekunden hoch, so dass sich die Benutzer über mangelnde Performance auf den Terminalserver beschweren. Auf dem Host sind dann in kurzem Abstand mehrere dieser Meldungen zu finden: Event-ID: 8 Source: Hyper-V-StorageVSP Text: Failed to map guest I/O buffer for write access with status 0xC0000044. Device name = C:\ClusterStorage\VolumeX\VM\Disk.vhdx In der VM sind zur gleichen Zeit Meldungen über wiederholte oder verzögerte Schreibzugriffe zu finden. Ich habe einige Meldungen zu dem Problem gefunden, aber leider keine Lösung. Am nähesten kommt diese Beschreibung: https://forums.veeam.com/microsoft-hyper-v-f25/windows-server-2019-hyper-v-vm-i-o-performance-problem-t62112.html Veeam ist im Einsatz, aber die Probleme treten nicht auf, wenn Backups laufen. Die VHDX liegen auf einem MSA2052 und einem OceanStor Dorado. Die machen fast nichts (unter 1000 IOPS), alles SSD. Die Probleme treten zufällig verteilt bei einzelnen VMs auf. Nicht bei mehreren gleichzeitig und auch nicht zu Zeiten hoher Last. Das Problem tritt täglich ein bis zwei Mal für wenige Minuten auf. Ansonsten ist die Performance super. Und auch wenn eine VM das Problem gerade hat, sind andere VMs auf der gleichen LUN nicht betroffen. Die Hosts sind HPE ProLiant DL360 Gen10. Ich habe alle Windows Updates sowie das aktuelle ProLiant Support Pack installiert. Der im Thread beschriebene Workaround (Verschieben der VMs alle paar Tage) scheint zu funktionieren. Es deutet alles auf einen Fehler in Windows hin. Die bisher verfügbaren (Private) Patches scheinen nicht zu helfen. So weit, so klar. Was mich aber stutzig macht: wieso sehe ich das Problem nur auf einem Cluster? ProLiant, WS2019 und Veeam ist ja keine exotische Konfiguration... Habt ihr das bei euren Clustern auch schon beobachtet?

Vielen Dank für die Antworten. Offline-Dateien sind deaktiviert und ausser dem Defender läuft kein AV. Der Kunde hat mich diese Woche aber noch darauf angesprochen, dass er bei dem Server vom Datenlaufwerk keine einzelnen Dateien mit Veeam restoren kann. Das Laufwerk wird nicht angezeigt. Komischerweise meldet der Server selbst keine Probleme. Anscheinend war die VHDX mal bei einem Problem mit dem SAN auf der "abgestürzten" LUN. Habe eine neue VHDX angehängt und die Daten kopiert. Seither ist die Disk im Veeam Restore wieder sichtbar. Zudem wurde das Netzlaufwerk mittels GPO unter Verwendung des Namens des alten Fileservers (welcher jetzt per CNAME auf den neuen Server zeigt) verbunden. Ich habe das angepasst auf den neuen Namen. Bis jetzt scheint es zu funktionieren, aber das kann auch Zufall sein.

Ja, wenn man die Kameras hat, ist das natürlich praktisch. Ich verwende für einfachere Überwachungen gerne Synology oder -wenn es die Cloud sein darf- Arlo. Die lokale Verwaltung ist generell ein Vorteil von UniFi. Bei Aruba ist fertig lustig, wenn der Hersteller irgendwann mal keine Lust mehr hat, die Server dafür zu betreiben. Wobei ich da bei HPE nicht so Bedenken habe. Falls Du mal einen kleineren Server brauchen solltest: auf den NUCs läuft Hyper-V tadellos. Setze die noch gerne bei kleineren Kunden ein für zweiten DC und Backup. Jetzt erscheint dann die neue Generation mit Intel vPro, also einer Art iLO.

Ich war jahrelang zufriedener Anwender von UniFi, sowohl geschäftlich als auch privat. Der einzige Nachteil war der Bedarf eines Controllers. Auf einem PC oder Server installieren oder den CloudKey kaufen, finde ich alles nicht ideal. Deshalb bin ich bei der recht neuen Produktlinie "Instant On" von HPE Aruba gelandet. Hier setze ich meist die AP-22 ein. Die sind recht günstig und funktionieren problemlos. Auch der Wireless Uplink ist sehr gut. Die Geräte unterstützen ohne Aufpreis auch erweiterte Features wie eigene Subnets inkl. NAT in bestimmten SSIDs oder einen Inhaltsfilter. Ich weiss nicht wie gut der ist, aber zumindest für privat ist er eine zusätzliche Schutzschicht.

Ja, ganz genau. Man kann aber bisher noch kein eigenes Root-Zertifikat verwenden. Wäre praktisch, wenn man schon eines verteilt hat auf den Geräten. In diesem Fall könnte man das der Sophos nehmen.

Das schon, aber man kann kein eigenes Root-Zertifikat verwenden, mit dem er die selbst erstellten Zertifikate signiert. Dieses Feature steht seit einigen Jahren auf der Wunschliste. Und soweit ich weiss erstellt er für alle angefragten Hosts immer ein eigenes Zertifikat und verwendet nicht ein im Windows vorhandenes. Was aber geht, ist das Ignorieren von ungültigen Zertifikaten auf Serverseite.

Bei Fiddler kann man leider noch keine eigenen Zertifikate verwenden. Dafür müsstest Du noch einen Proxy davor schalten.

Ich verwende für solche Sachen Fiddler. Wenn die App die Proxy-Einstellungen berücksichtigt, geht das ohne "Tricks". Das Zertifikat muss jedoch installiert werden: https://www.telerik.com/blogs/how-to-capture-ios-traffic-with-fiddler