Jump to content

Sebastian R

Members
  • Gesamte Inhalte

    115
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Sebastian R

  1. Wie bereits geschrieben - läuft nicht als Dienst. Nunja, die USV stammt aus einer Zeit bevor SE mitmischte. Die jetzige Eaton ist auch keine Doppelwandler-USV und Neuanschaffung ist nicht drin - leider. Ich baue mal neue Akkus ein und teste mal...
  2. Oder die alte Smart-UPS mit AP9631 drin reaktivieren bzw. neue Akkus einbauen. @Nobbyaushb Wieso hattest Du in einem vorherigen Post davon abgeraten die alte USV wieder einzusetzen? Hat die gravierende Nachteile gegenüber der Eaton?
  3. Die Eaton hat wie schon oben erwähnt leider keine Netzwerkschnittstelle. Der Vorschlag von cj_berlin mit Skript & SSH wäre auch eine ziemliche Bastelei auf pfsense. Zudem wäre es dann nicht möglich irgendwelche Infos von der USV abzufragen. Auf https://networkupstools.org/index.html gibt es eine Beta-Version für Windows aus dem Jahre 2015, wird offensichtlich nicht mehr gepflegt und sowas auf nem Server zu installieren halte ich für problematisch. WinNut wird noch gepflegt, läuft aber nicht als Dienst.
  4. Nein, dort gibt es keine Möglichkeit dazu. HAbe allerdings noch eine alter APC SUA1000I mit Netzwerkkarte. Dei bräuchte erst neue Akkus. Ob sich das lohnt?!
  5. An einem Standort gilt es zwei HP Microserver (Server 2019), ein NAS (OMV), einen pfsense Router und einen RaspberryPi bei Stromausfall herunterzufahren. Alle Geräte hängen an einer Eaton Ellipse Pro. Diese ist derzeit an den pfsense Router angeschlossen auf dem NUT läuft. Bei den Linux Geräten klappt das runterfahren zuverlässig aber das "offizielle" NUT Paket für Windows verdient wirklich den Status "Beta". Diese Bastelei möchte ich eigentlich ungern bei einem Server machen. Es gibt noch "WinNUT" was gut funktioniert aber keinen Dienst mitbringt - also für einen Server unbrauchbar. Hab ihr noch andere Ideen wie man das lösen könnte?
  6. Habe nun einen Testserver mit PRTG aufgesetzt und mich aber auch nochmal mit Zabbix eingehender beschäftigt. Unter der aktuelle Version 5.4 und dem Agent2 klappt z.B. SMART reibungslos auszulesen.
  7. Womit wir wieder einen Schritt Richtung Zabbix gehen
  8. Danke für das Feedback. Ich werde mal PRTG ausprobieren. Aber manche Dinge lassen mich auch nachdenklich werden wie zuverlässig das ist z.B. beim Disk Monitoring: https://kb.paessler.com/en/topic/15553-how-do-i-monitor-hard-drive-smart-events
  9. Zum Überwachen von Windows-Servern und Clients sowie einigen Linux Maschinen und Switches per SNMP habe ich mich mit Zabbix, dass mir dafür als die beste Lösung erschien, auseinandergesetzt. Nach Installation des Zabbix-Servers 5.0 LTS und testweise Installation und Konfiguration des Agents auf einem Windows10 Client kam die Ernüchterung: z.B. CPU-Load Monitoring funktioniert nicht, auch nach stundenlanger Recherche keine Lösung in Sicht. Auch am Versuch die SMART Daten der HDD an Zabbix zu übermitteln bin ich gescheitert. Für Leute die täglich damit umgehen , mag es eine gute Wahl sein die zweifellos auch sehr mächtig ist. Allerdings erweckt das für mich den Eindruck einer Bastellösung und ich habe nicht die Möglichkeit mich da so reinzuarbeiten "nebenbei". Gibt es etwas "anwenderfreundlichere" Alternativen?
  10. OK danke für die Antworten, werde mich dann dran machen einen neuen DC zu installieren die nächsten Tage. Da hab ihr sicher mehr Erfahrung bzw. seid die Experten. Den DC2 habe ich nochmal gestartet (ohne Verbindung zu einem Virtual Switch) da ich noch einige Dateien brauche. Fürs Verständnis wäre es interessant zu wissen welche Probleme beim Restore eines DC auftauchen können? Das letzte Replikat ist deutlich jünger als die Tombstone Lifetime. Was ich erwärten würde ist das ein Reset des Secure Channel notwendig wäre aber ansonsten fällt mir nichts weiter ein was gegen einen Restore sprechen würde?!
  11. Hallo zusammen, habe ein Netzwerk mit zwei Hyper-V Hosts (Server2019 Standard). Aus dem ersten Host läuft u.a. der PDC (DC1). Auf dem zweiten Host u.a. ein zweiter DC (DC2) (AD, DNS, DHCP-Failover). Weitere DCs gibt es nicht. Für alle Gastbetriebssysteme sind jeweils Replikationen auf den anderen Hyper-V Host eingerichtet. Nun hat kurz vor den Feiertagen und unbemerkt die Platte - auf der die VMs gespeichter sind im zweiten Host - begonnen zu zicken. Trotz keiner SMART Fehler fand ich nun im Eventlog die ID7 mehrfach. Das Windows Server Backup hat leider die Sicherung der Hyper-V Hosts auch wegen diesem Problem übersprungen. Das letzte erfolgreiche Replikat des DC2 stammt vom 20.12.2021. Habe nun alle Gasbetriebssysteme auf dem HYper-V Host #2 auf eine neue Platte verschoben oder wo dies nicht funktionierte das Replikat davon auf dem Hyper-V Host #1 exportiert und auf #2 importiert (wiederherstellen). Da es bei einem Restore von DCs, insbesondere wenn sich sich länger "nicht gesehen haben", einige Fallstricke gibt wollte ich fragen was hier die richtige Vorgehensweise ist? Könnte ich hier auch so vorgehen wie bei den anderen VMs: Export des Replikats, Import auf Hyper-V Host #2, starten und erstmal einer Behandlung mit chkdsk und sfc unterziehen?! Grüße Sebastian
  12. Die Reservierung ist gelöscht. Auf dem Client ist ein ipconfig /release nicht möglich, da es sich um ein Android Tablet handelt. Aber ich denke die URsache liegt woanders wie ich eben feststellen musste: Ich nutze DHCP in einer Failoverkonfiguration. Und auf dem "anderen" DHCP sind sind lediglich die LEases identisch mit dem primären DHCP. Die Reservierungen aber nicht! D.h. Änderungen die ich auf dem primären DHCP vornehme (in dem Fall Reservierungen) werden nicht repliziert. Ich hab die Replikation eben nochmal manuell angestoßen allerdings sind die Reservierungen weiterhin nicht identisch. Wie kann ich das beheben? Failoverkonfiguration aufheben und neu einrichten?
  13. Hallo, hsbe ein Problem mit einem Client (Tablet) für den auf dem DHCP Server (Windows server 2016) bisher eine Rservierung bzw. feste IP eingerichtet war. Diese Reservierung habe ich gelöscht. Der Client erhält aber trotzdem immer wieder die gleiche IP. Auf dem DHCP-Server wird auch ein Leaseablaufdatum von "unendlich" angezeigt ebenso wie die damals bei der Reservierung eingegebene Beschreibung. Auch das Löschen des Lease mit Neustart von DHCP-Server und Client brachten keine Änderung. Der Client zieht sich immer wieder die gleiche IP. Wie kann ich diese verkappte Reservierung loswerden?
  14. So nochmal Rückmeldung: die grace period für den Shutdown habe ich verlängert. Dadurch kommt es nicht mehr zu den Fehlermeldungen auf den Gästen wenn der Host neu gestartet wird. Die Ursache warum die Gäste nicht, oder zumindest nicht zuverlässig, starten konnte ich auf die Starverzögerung zurückführen. Sobald dort ein Wert größer als 0 Sekunden eingetragen wird, startet der Gast nach einem Host-Neustart nicht (oder nur manchmal). Hat jemand dafür eine Erklärung?
  15. Danke für Eure Antworten. Ich glaube das geht schon in die Richtung, dass der Host zu schnell herunterfährt. Eben habe ich mal eine virtuelle Maschine gespeichert und anschließen wieder gestartet was ohne Fehler geschah. Ich werde mal dies ausprobieren, ggf. auch das was dort ind en Kommentaren gesagt wurde: https://www.altaro.com/hyper-v/extending-hyper-vs-guest-grace-period-host-shutdown/
  16. Sorry, dass ich mich erst jetzt wieder melden. Ich habe weiter "experimentiert", den Hyper-V Host kann ich nicht nach Belieben einfach neu starten. Es gab einige ältere Einträge in den Hyper-V Anwendungs-und Dienstprotokollen die auf mangelnden Arbeitsspeicher hinwiesen. Dies versuchte ich durch einen zeitversetzten Start der VM's zu beheben. Und scheinbar war genau das die Ursache für den unzuverlässigen Start der Gäste nach einem Reboot des Host! Jetzt sind alle drei VMs auf starten ohne Verzögerung eingestellt und sie werden nach einem Reboot vom Host nun auch alle zuverlässig gestartet. Nur was mir auffällt: meldet man sich dann auf einem der Gäste an, bekommt man einen Hinweis, dass der Computer unerwartet heruntergefahren wurde. Kann ich diesen Fehler getrost ignorieren oder wie kann ich ihne beheben? Wie gesagt, die Stop-Aktion bei den VMs ist auf speichern gestellt und alle Integrationsdienste sind verfügbar.
  17. Das hatte ich schon versucht (je 300 sek verzögert), leider ohne Besserung,
  18. Auf meinem HP Microserver Gen8 (G1610T, 16GB RAM) ist Windows Server 2016 als Host-OS installiert. Darauf laufen drei Gast-Betriebssysteme: zwei Windows Server 2016 VMs und einmal Ubuntu 16.04. Diese sind auch alle gleich konfiguriert: dyn. RAM (startup: 2GB, min: 1GB, max: 4GB), Stopaktion: speichern, Startaktion: immer starten, alle Integrationsdienste verfügbar. Nun ist es so, dass wenn der Host neu startet die Gäste nicht oder nur unzuverlässig gestartet werden. Sie bleiben dann in dem Status "gespeichert" und ich kann Sie auch über den Hyper-V Manager ohne Probleme bzw. Fehlermeldungen manuell starten - das funktoniert. Ich bin ziemlich ratlos wie ich die Ursache für dieses Verhalten herausfinden kann?!
  19. Seltsamerweise ist seit einigen Tagen bei den Clients (bisher nur Win10 getestet) die Netzwerkumgebung leer, es heißt es werden dort keine anderen Rechner, NAS etc angezeigt. Außer der eigene Computer und ein Win7 Client der nicht Mitglied in der Domäne ist. Aber alle anderen Windows-Clients, NAS etc. fehlen. Es handelt sich um eine Domäne mit Win2016 Server die u.a. DHCP, DNS, WINS und AD bereitstellen. Auf den Servern sind komischerweise alle Clients im Netzwerk brav aufgelistet in der Netzwerkumgebung! DNS funktioniert ebenfalls auf den Clients: ping auf hostname und FQDN geht. Ebenfalls per UNC Pfad (sowohl über den Computernamen als auch über die IP) kommt man auf die Freigaben. Per DHCP bekommen die Clients u.a. den WINS server übergeben und den Knotentyp (hybrid). Das ganze lief ja auch problemlos bis vor wenigen Tagen ohne dass etwas an der Konfiguration geändert wurde, lediglich Updates installiert.
  20. Da alle FSMO Rollen, also auch PDCE, auf den neuen Server umgezogen sind (siehe #1). Und nur diesen sollten die Clients als Zeitquelle nehmen.
  21. Und auch alle Clients nehmen als Zeitquelle weiterhin den alten Server. :nene:
  22. Danke für den Hinweis. Die Anleitung habe ich abgearbeitet, trotzdem taucht in der Ereignisanzeige immer wieder Event 144 auf. Das wechselt sich ab mit Event 143 (Der Zeitdienst wird als gute Zeitquelle angekündigt). :confused:
  23. Ich greife das nochmal auf, weil ich im Eventlog des neuen virtuellen DCs noch immer regelmäßig die ID 144 (Time-Service). Bei den Integrationsdiensten habe ich die Zeitsynchronisation schon deaktiviert. Dann auf externe Synchronisation umgestellt: reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t reg_dword /d 0 w32tm /config /manualpeerlist:"0.pool.ntp.org,0x1" /syncfromflags:MANUAL /reliable:yes w32tm /config /update w32tm /resync w32tm /resync /rediscover Danach mit /query /status und /query /source überprüft sieht auch alles gut aus. Nach einem Neustart jedoch habe ich wieder Lokal / CMOS Uhr als Zeitquelle. :confused:
×
×
  • Neu erstellen...