peterg

Was wäre hier die Best Practice? NTFS Wie finde ich das raus? Im Gerätemanager steht als Speichercontroller: LSI SAS-3000 Serie, 8-Port mit 1068 Alles aktuell

Hallo mulu, daran habe ich auch schon gedacht - siehe unten Das wäre der nächste Schritt.

Die SAN ist über Fibrechannel an die beiden HP Server angebunden. Im Netzwerk selbst sind die HP Server nur per Gbit (onboard NICs) angebunden.

Die Daten liegen auf einer extra VHDx Partition mit fester Größe. Jede VM hat (wenn benötigt) eine extra Datenplatte. Der Fileserver hat eine Datenplatte mit ca. 4 TB (SAS-Platten der SAN) und eine mit 34 TB (SATA-Platten der SAN). Die 34 TB sind notwendig, da aufgrund von bestimmten Kanal-Berechnungen die temporären Berechnungsdateien mehrere TB groß sein können. Hier wollten wir sehr viel Reserve. Ach ja, die EDV-Firma hat jetzt auch mal jeder VM eine eigene Netzwerkkarte gegeben (jeder Server hat ja 4 Stück 1Gbit onboard). Vorher waren die NICs zusammengefasst (die EDV-Firma meinte so was wie "port provisioning"). Eigentlich würden wir gerne aufgrund der Datensicherung (wegen dem wöchentlichen FullBackup und Stand der Technik) auf 10Gbit umstellen. Aber vorher möchten wir gerne wissen, woher der Fehler kommt. Kann es sein, dass bei 38 Clients Gigabit nicht ausreicht?

Es sind 2 HP Server DL380 Gen9 (1 Jahr alt) mit je 3 VMs und ein HP DL 360 Gen9 als Management Server (z.B. für Veeam, ...). Die anderen VMs haben scheinbar keine Probleme. Hier sind aber auch fast keine Shares angelegt. Über die betroffene VM laufen so gut wie alle produktiven Shares. Ich habe schon überlegt, ob man ein paar Shares zu Test mal auf eine andere VM verschiebt. Wenn wieder ein "Aussetzer" kommt, weiß man dann wenigstens, ob auch eine andere VM betroffen ist. Das könnte man soweit treiben, dass man feststellt, ob beide phsikalischen Server betroffen sind oder nur einer oder dann evtl. auch nur eine VM. Ja, jede VM hat eine eigene VHDx-Systempartition mit fester Größe. Gruß, Peter

Hallo, ich habe nun mal die betroffnene VM bzgl. VMware-Zeitaktualisierungen gemäß dem VMware Artikel https://kb.vmware.com/s/article/1189 "dicht" gemacht. Mal sehen was passiert. Ich schaue mir nun auch jeden Tag die Protokolle an, ob irgendwas "verdächtiges" drin ist. Könnten die "Aussetzer" (Lahmlegen des Fileservers) evtl. auch von einem defekten Gerät (Rechner, Switch, ...), Kabel oder Dose kommen? Gruß, Peter

Deutschlehrer? In der Überschrift habe ich es zum Glück hinbekommen. Ich glaube, dass es trotzdem alle verstanden haben. Vielen Dank!

Die Frage bleibt, ob die unplanmäßige Zeitsynchronisation (die Zeit stimmt aber letztendlich dann doch wieder - siehe meine Beschreibung) der Grund für den Aussetzer ist? Wie beschrieben (siehe PDF-Datei) gibt es im Protokoll nur zwei Hinweise zum Zeitpunkt des Aussetzers. Diese beiden Meldungen sind nach bisher 4 Aussetzern immer gekommen.

Kann ich beim nächsten "Aussetzter" mal probieren!

Hallo, danke für die vielen Hinweise. Nachfolgend meine Antworten. Diese Artikel hatte ich auch schon gefunden. Dort steht aber, dass es die letzte Option sein sollte, da die Logs von einem MS Supportmitarbeiter ausgewertet werden müssen, was natürlich nicht unerhebliche Kosten verursacht. Was gibt es hier für Risiken? Auf dem Fileserver ist auch eine Object Store DB. Wenn ich an der Reparaturmodus von Windows 7 denke, dann funktioniert danach nichts mehr. Aktuell holt der Host die Zeit via CMOS Clock. -> Ändere ich. VMware Tools sind installiert aber nur die "Statistikprotokollierung". Zum Zeitpunkt der Aussetzter sind bisher keine Backups, Snapshots o.ä. gelaufen. Zum Zeitpunkt der Aussetzter sind keine der "bestimmten Vorgänge" durchgeführt worden. Die Aussetzer kommen urplötzlich im laufenden Betreib.

Habe den Diesnt gestartet und auf "automatisch" gestellt. War aktiviert, obwohl E-Modus auf Höchstleistung steht. Habe ich nun deaktiviert. Frage mich immer noch was diese Zeitumstellung verursacht bzw. die Zeit aber dann trotzdem stimmt?

Nein! Dienst ist installiert, steht aber auf "manuell". Soll ich den Dienst starten und auf "automatisch" stellen? Es läuft alles unter VMware 6.0 (siehe Beschreibung). Zeitdienst für Gast ist am Host deaktiviert.

Danke für die Hinweise. Werde darüber nachdenken. Zertifikat, etc. ist alles vorhanden und funktioniert (auch der microsoft connectivity analyzer). Gruß, Peter

Hallo, der DC holt sich die Zeit über einen manuell eingestellten Zeitserver (0.pool.ntp.org,0x1 1.pool.ntp.org,0x1 2.pool.ntp.org,0x1 3.pool.ntp.org,0x1). Das funktioniert auch (habe es gerade nochmal kontrolliert). Aber der DC ist nicht das Problem. Ich schaue mir den Beitrag von Dir an. Danke. Wie kann man die Anwendung/Systemkomponente herausfinden, welche die Zeitumstellung verursacht?

Irgendwie möchte man es selbst hinbekommen.... bzw. mit "Unterstützung". Macht mehr Spaß...

OK, dann muss ich aber auch am DNS bei Domainfactory und wohl am DNS unserer Domäne rumfummeln. Da muss ich mal googeln

Ist ein POPConnector (bei uns POPcon) wirklich so schlecht? Es erfolgt so eine Viren- und Spamprüfung bei Domainfactory (und natürlich am Exchange), beim Serverausfall gehen keine Mails verloren.

Hallo, wir haben hier ein langsam doch ernsthaftes Problem mit unserem Fileserver (ist eine VM). In ganz unregelmäßigen Abständen werden plötzlich und gleichzeitig alle Netzlaufwerke getrennt. Kurz danach sind die Freigaben wieder da, aber alle total langsam. Arbeiten ist dann nicht möglich. Nach einem Reboot (nur der einen VM) passt wieder alles. System: Windows 2016 Std. als VM unter VMware 6.0. Zusätzlich gibt es noch weitere 5 VMs mit Server 2016 Std. Je 3 VMs sind auf einem HP DL380 Gen9. Als Datenspeicher bzw. für die VMs hängt noch eine HPE MSA 2042 SAN und ein HPE MSA 2040-LFF dran. Was fällt auf: Am Fileserver kommen zum Zeitpunkt des Ausfalls immer folgende Meldungen im Ereignisprotokoll: Quelle:Microsoft-Windows-Kernel-General Datum: 07.08.2018 12:14:18 Ereignis-ID: 1 Aufgabenkategorie:(5) Ebene: Informationen Die Systemzeit wurde von 2018-08-07T10:09:53.004867100Z in 2018-08-07T10:14:18.202000000Z geändert. Änderungsgrund: Die Uhrzeit wurde von einer Anwendung oder von einer Systemkomponente geändert. Und: Der USB-Dongle-Server zeigt eine Warnung und einen Fehler im Ereignisprotokoll -> siehe Anlage! Nach Prüfung mit w32tm /query /status wird die Zeit aber einwandfrei mit dem DC synchronisiert. Komisch ist auch, dass die Systemzeit von 10:09:53 auf 10:14:18 geändert wurde, aber im Protokoll dies erst um 12:14 angezeigt wird. Die Zeit ist aber doch synchron mit dem DC. Ich habe keine Ahnung warum und vor allem was auf dem Fileserver diese Zeitumstellung veranlasst. In den VMware-Einstellungen ist die Zeitsynchronisation mit dem HOST deaktiviert! Ich habe nun mal den Dienst "Windows-Zeitgeber" am Fileserver deaktiviert. Ausführliches "loggen" des Zeit-Dienstes wäre auch noch möglich. Ich habe den Zeit-Dienst auch schon mal zurückgesetzt. Habt Ihr irgendwelche Tipps? Bin ich evtl. auf der falschen Spur? Gruß, Peter Serveraussetzer.pdf

Hi, vielen Dank! ISP hat den PTR gemacht und nun zickt auch GMX nicht mehr

Hi, SPAM/ Viren werden über ein G-Data Exchange Plug-In gescannt. Zugem läuft der Posteingang auch über G-Data Mail Gateway. Hier sehe ich gar keine Probleme. Frage nebenbei: Was muss ich tun, damit der ausgehende Mailverkehr über TLS läuft oder ist das Standard? (Eingehend wird wia POPcon SSL/TLS abgeholt.) @Norbert TNX Gruß, Peter

Was heißt der Host? -> remote.domäne.de ? Also dann feste Internet IP (90.130.xx.xx) zeigt auf remote.domäne.de Gruß, Peter

Hallo, ich würde gerne das Senden der Mails beim Exchange 2016 von Smarthost auf "Mit der Empfängerdomäne verbundenen M-Eintrag" umstellen. Ich habe nun einen neuen Sendeconnector erstell – Typ "Internet" - (Smarthost deaktiviert), den Bereich mit "*" definiert, den Quellserver und den FQDN eingetragen. Der FQDN-Eintrag ist auch im Zertifikat eingetragen. E-Mails werden grundsätzlich versendet. Nur GMX zickt und im SMTP-Log steht: n554-Bad DNS PTR resource record Muss ich am lokalen DNS noch was eintragen oder beim E-Mail Provider Domainfactory oder muss der Internetprovider (siehe weiter unten) was machen? Beim lokalen DNS gibt es: In der Forward Lookupzone zwei Host-A Einträge: - autodiscover.domäne.de -> interne IP-Adresse des Exchange 192.168.16.8 - remote.domäne.de ->interne IP-Adresse des Exchange 192.168.16.8 In der Reverse-Lookupzone einen PTR-Eintrag: IP-Adresse des internen Exchange-Server 192.168.16.8-> PTR auf den internen Servernamen des Exchange "srv-exch.domäne.local" Bei Domainfactory gibt es zwei Typ-A Einträge: - autodiscover.domäne.de -> feste Internet-IP-Adresse 90.130.xx.xx - remote.domäne.de -> feste Internet-IP-Adresse (hierüber ist der Exchange für OWA erreichbar) 90.130.xx.xx Bei Domainfactory gibt es dann noch zwei MX Einträge: - domäne.de -> Domainfactoy - *.domäne.de -> Domainfactory Beim Sendeconnector remote.domäne.de ist der FQDN-Eintrag beim Sendeconnector (Antwort auf HELO oder EHLO) OWA funktioniert damit auch einwandfrei. Mit dem Internet-Tool "Reverse DNS lookup and PTR Query" wird bei Eingabe der festen Internet-IP Adresse der Internetprovider angezeigt (...glasfaser-ostbayern.de) Muss der Internetprovider einen PTR setzen? Ach ja, der Mailempfang erfolgt noch über POPcon, was sehr gut funktioniert und wenn möglich so bleiben soll. Evtl. kann mir jemand sagen, was ich noch anpassen muss. Gruß, Peter

Hi, wenn dann zweite Karte rein (die erste Karte bleibt ja drin) und die Ports im Team neu zuordnen. Bei über 600 € für die Karte frage ich lieber möglichst genau nach. Testen kommt dann an zweiter Stelle. Verständlich oder? Aber danke für die Infos. Gruß, Peter

Hi, kann ich das vorhandene Team einfach über die PowerShell erweitern (wenn ich die zweite Karte einbaue) oder muss ich den virtuellen Switch und das Team erst löschen und neu erstellen? Die VMs sind schon fertig installiert! Kann/soll ich alle Ports der beiden Karten (auch wenn dann je Karte nur ein Port benutzt wird) in das Team einbinden? Gruß, Peter

Nein