6
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 579486
Url: https://administrator.de/contentid/579486
Printed on: April 24, 2024 at 23:04 o'clock
6 Comments
Latest comment
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 nlasvcCheers,
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
Tatsächlich sind es Server, die alleine der AD einer Domäne sind. Und es apssiert tatsächlich nur sporadisch - nach jedem 5-8 Reboot, aber nicht zuverlässig. Und es sind auch nur manche Server. Bei anderen Kunden (deutlich mehr) passiert es nicht. Gleiche Hardware, gleiches Windows 2019, gleiche Switche und Firewalls.
Wirklich seltsam...
Wirklich seltsam...
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
