NLA Dienst Fehler - Firewall öffentlich - automatischer Neustart vom NLA per Skript wird benötigt
Moin,
wir haben aktuell das Problem, dass wir auf mehreren AD Servern (alle alleine in der Domäne - kleine Kunden) regelmäßig, aber relativ selten nach dem Neustart die Firewall Einstellungen öffentlich haben. Ein manueller Restart des NLA SVC löst das Problem sofort. Aber dies ist lästig. NLA ist schon auf verzögert starten gesetzt, löst das Problem aber nicht.
Das ganze passiert ja, weil der Dom.Server beim Starten seinen eigenen Service nicht erkennt und mit 2 oder mehreren AD Servern wäre das Problem weg. Aber das geht nicht. Es wird nur ein AD bei kleinen Kunden bleiben.
Jetzt die Frage bzw. zwei:
- Kann ich das nachhaltig und dauerhaft lösen?
- Wenn nicht, wie kann ich per Skript den NLASVC beim Neustart um 10 Sekunden verzögert neustarten?
Hier geht es darum, dass ein Skript die Möglichkeit bietet, den Dienst als Admin ohne Eingabe der Credentials den Dienst neustartet.
Wäre super, wenn da jemand eine Lösung hätte...
gruß tobias
wir haben aktuell das Problem, dass wir auf mehreren AD Servern (alle alleine in der Domäne - kleine Kunden) regelmäßig, aber relativ selten nach dem Neustart die Firewall Einstellungen öffentlich haben. Ein manueller Restart des NLA SVC löst das Problem sofort. Aber dies ist lästig. NLA ist schon auf verzögert starten gesetzt, löst das Problem aber nicht.
Das ganze passiert ja, weil der Dom.Server beim Starten seinen eigenen Service nicht erkennt und mit 2 oder mehreren AD Servern wäre das Problem weg. Aber das geht nicht. Es wird nur ein AD bei kleinen Kunden bleiben.
Jetzt die Frage bzw. zwei:
- Kann ich das nachhaltig und dauerhaft lösen?
- Wenn nicht, wie kann ich per Skript den NLASVC beim Neustart um 10 Sekunden verzögert neustarten?
Hier geht es darum, dass ein Skript die Möglichkeit bietet, den Dienst als Admin ohne Eingabe der Credentials den Dienst neustartet.
Wäre super, wenn da jemand eine Lösung hätte...
gruß tobias
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 579486
Url: https://administrator.de/forum/nla-dienst-fehler-firewall-oeffentlich-automatischer-neustart-vom-nla-per-skript-wird-benoetigt-579486.html
Ausgedruckt am: 26.12.2024 um 01:12 Uhr
6 Kommentare
Neuester Kommentar
Moin.
Ohne zweiten DC bzw. DNS? Nein.
Cheers,
jsysde
Ohne zweiten DC bzw. DNS? Nein.
- Wenn nicht, wie kann ich per Skript den NLASVC beim Neustart um 10 Sekunden verzögert neustarten?
Per Taskplaner mit entsprechendem Trigger, dann:net stop nlasvc && net start nlasvc
Cheers,
jsysde
Moin,
Gruß,
Dani
Das ganze passiert ja, weil der Dom.Server beim Starten seinen eigenen Service nicht erkennt und mit 2 oder mehreren AD Servern wäre das Problem weg. Aber das geht nicht. Es wird nur ein AD bei kleinen Kunden bleiben.
reden wir jetzt von Servern, die Mitglied in einer Domäne sind oder von einem Server der als Domain Controller agiert? Bei letzterem darf das Problem eigentlich gar nicht auftreten. Bei Ersterem kenn ich das Problem ausschließlich bei physikalischen Servern. Bei VMs ist mir die Thematik noch nie untergekommen.Gruß,
Dani
Moin.
Cheers,
jsysde
Zitat von @Dani:
[...]Bei Ersterem kenn ich das Problem ausschließlich bei physikalischen Servern. Bei VMs ist mir die Thematik noch nie untergekommen.
Ich hab' hier einige Kleinstkunden, bei denen ein HyperV-Host (non-Domain) mit nur einem virtuellen DC für die AD-Domain drauf läuft. In dieser Konstellation seh' ich das Phänomen auch hin und wieder, also dass der DC erst nach Neustart des NLA-Dienstes wieder "Domänennetzwerk" anzeigt. Tritt aber auch nicht bei jedem Reboot auf, was es noch merkwürdiger macht...[...]Bei Ersterem kenn ich das Problem ausschließlich bei physikalischen Servern. Bei VMs ist mir die Thematik noch nie untergekommen.
Cheers,
jsysde
Moin @jsysde,
es liegt wohl am Netzwerk Stack von Microsoft Hyper-V.
Unter VMware ESXi ist mir das Problem noch nie untergekommen.
Gruß,
Dani
es liegt wohl am Netzwerk Stack von Microsoft Hyper-V.
Unter VMware ESXi ist mir das Problem noch nie untergekommen.
Gruß,
Dani
Moin.
Doch, hatte ich hier auch schon - war aber ein (fürchterbar kaputt konfiguriertes) Alt-System, dass wir bei einem Kunden vom vorherigen IT-Betreuer übernommen haben. Auch da gab es nur einen DC, nämlich als VM auf ESXi 6.5, und der hat dieses Verhalten auch gezeigt.
Rein der Logik folgend kann das auch wenig mit der Virtualisierungsplattform zu tun haben, es liegt wohl eher am Windows Server himself. Zumal ich das von 2012R2 aufwärts schon auf allen Servern, meist auf DCs, aber auch schon auf Memberservern, gesehen habe.
Cheers,
jsysde
Doch, hatte ich hier auch schon - war aber ein (fürchterbar kaputt konfiguriertes) Alt-System, dass wir bei einem Kunden vom vorherigen IT-Betreuer übernommen haben. Auch da gab es nur einen DC, nämlich als VM auf ESXi 6.5, und der hat dieses Verhalten auch gezeigt.
Rein der Logik folgend kann das auch wenig mit der Virtualisierungsplattform zu tun haben, es liegt wohl eher am Windows Server himself. Zumal ich das von 2012R2 aufwärts schon auf allen Servern, meist auf DCs, aber auch schon auf Memberservern, gesehen habe.
Cheers,
jsysde