[English]Ich stelle mal ein Thema hier im Blog ein, welches von einem Leser an mich herangetragen wurde. Es geht um Windows 11, getestet unter Version 22H2. Dem Leser ist aufgefallen, dass Windows 11 22H2 eine längere Startzeit gegenüber Windows 10 aufweist, die bis zu 60 Sekunden betragen kann. Nach längerer Fehlersuche stellte sich heraus, dass der Network Connectivity Status Indicator (NCSI) in Verbindung mit Gruppenrichtlinien für die Netzwerkeinstellung die Ursache ist.
Anzeige
Was ist der NCSI?
Das Kürzel NCSI steht für Network Connectivity Status Indicator, also die Anzeige des Netzwerkstatus im Infobereich der Taskleiste (siehe nachfolgendes Bild). Der Network Connectivity Status Indicator ist ein Feature in Microsoft Betriebssystemen, welcher prüft, ob eine aktive Internet-Verbindung des Computers besteht. Hierbei wird ein Web-Server von Microsoft unter msftconnecttest.com bereitgestellt, welcher erreichbar sein muss. Über obigen Link lassen sich noch einige Details auf der Wikipedia abrufen.
Windows 11 22H2: NCSI verlängert Startzeit
Ein Blog-Leser, der als Administrator in seinem Unternehmen vor dem Rollout von Windows 11 22H2 steht, hat mich vor einigen Tagen per E-Mail kontaktiert, weil er auf eine unschöne Sache gestoßen ist. Dazu schrieb er mir:
Hallo Herr Born,
ich komme gerade von einer langen Windows Fehlersuche wieder und muss an einer Stelle einfach mal meinen Frust loswerden. Und da ich fleißiger Leser ihres Blogs bin und Sie dort bereits mehrfach von ähnlichen Dingen berichteten fielen Sie mir als erstes als digitaler Beichtstuhl für Windows und andere Vergehen an der digitalen Menschheit ein.
Migration auf Windows 11 geplant
In der Mail schreibt der Leser, dass er berufsmäßig als Administrator tätig ist und aktuell mit der Einführung von Windows 11 als Ablösung für Windows 10 beschäftigt sei. Es geht unter anderem um die Migration von ca. 200 Rechner, die bisher noch auf Windows 10 21H2 und 22H2 laufen. Diese Clients sollen auf Windows 11 22H2 umgestellt werden. In der Unternehmensumgebung werden die Clients über Active Directory verwaltet mit den "üblichen" Gruppenrichtlinien versehen.
Problem: Längere Startzeiten
Der Leser führt aus, dass das größte Hindernis beim Rollout des neuen Betriebssystems bis jetzt eine um 60 Sekunden längere Startzeit für Windows 11 22H2 Rechner gegenüber den Windows 10 21H2 / 22H2-Clients gewesen sei. Dies trat in der Umgebung des Lesers ohne erkennbaren Grund, und von Anfang an auf.
Eine Diagnose der Ursache ist fällig
Diese Beobachtung hat den Leser dann doch gewurmt, so dass er sich vor einiger Zeit hingesetzt und getestet hat. Er wollte der Ursache einfach mal auf den Grund gehen. Nach Isolierung der Windows 11 Rechner und dem Zuweisen von GPOs Schritt für Schritt konnte ein Gruppenrichtlinen-Regelwerk als für die Startverzögerung verantwortlich gezeichnet werden, schreibt der Leser.
Konkret seien es im aktuellen Fall hier die Elemente zur "Netzwerkverbindungs-Statusanzeige", dem kleinen Symbol im Statusbereich des Computers, welches auf mögliche Verbindungsprobleme zum Netzwerk bzw. Internet hinweist, für diese Startzeit-Verlängerung verantwortlich gewesen.
In der Unternehmensumgebung des Administrators seien datenschutzfreundlichen Optionen mit eigenen Einstellungen per GPO zugewiesen worden. Windows 10 konnte damit, so der Leser, sehr gut umgehen. Bei Windows 11 war dies nicht der Fall, das Betriebssystem benötigte 60 Sekunden mehr für das Auflösen eines internen DNS-Namens und das Prüfen auf die Erreichbarkeit einer internen Webseite.
Anzeige
Nach erneuten Überprüfung und dem Probieren blieb nur das vollständige Entfernen eigener Werte, die Standardeinstellung läuft nun (aber unter Verzicht auf Datenschutzaspekte die sich um die NCSI ranken) reibungslos. Der Leser hat keine Details zu den GPOs genannt – aber die Richtlinien sind in diesem Artikel grob beschrieben.
Der Leser schreibt dazu: Da bleibt für mich nur noch der Gedanke ob dort ein Bug, ein Feature oder eine Ignoranz aus Redmond mich heimgesucht hat. Und natürlich die Frage, ob der Leserschaft das obige Szenario bereits schon einmal untergekommen ist?
2015
Da ich selbst für sehr viele Maschinen verantwortlich bin, dieses Problem einmal hatte, fand ich die Lösung in diesem Blog. Warum auch immer, hatte ich in der Registry einen falschen Wert stehen. Es wird auch sehr gut beschrieben wie NCSI genau funktioniert.
https://www.der-windows-papst.de/2020/07/19/network-connectivity-status-indicator/
IIRC gibt es einen extra Service, der diesen Zauber veranstaltet.
Wenn sicher ist, dass der Rechner niemals in seinem Leben das große weite Internet sehen wird/darf/kann, kann man, frei nach dem Motto "nur ein toter Service ist ein guter Service und reduziert die Angriffsfläche" den Dienst per sc disablen.
Immerhin erlaubt dieser Dienst der NSA die Überwachung eines jeden Windows-Rechners in der Welt ob er gerade eingeschaltet wurde, und so kann man die Drohne passend starten…
Natürlich ist das Windows Update und die Activation traurig. Aber es versucht trotzdem Updates.
Und inzwischen scheint MS Windows IoT ja auch für andere Zwecke als nur für "Maschinen" zu lizenzieren, so das das Abschalten dieses Schnüffel-Dienstes in gewissen Umgebungen keinen Nachteil hat, im Gegenteil.
Warum MS diesen Dienst nun beim Warten auf die DNS Antwort blockierend gestaltet hat?
Gewiss kein Zufall sondern Nötigung dafür zu sorgen, das der Rechner ind Netz kann, z.B. im die Aktivierung zu prüfen oder im Falle von IoT zu machen?
Achso:
Man fällt auch ganz prima damit auf die Nase, wenn man einen dezidierten Proxy einsetzt und der interne DNS entsprechend nur internes auflöst. Dann klappt zwar die erste Abfrage nach der Text Datei, weil die Namens Auflösung ja der Proxy macht, aber das Addres lookup der 2. Adresse schlägt fehl, weil der lokala DNS den Namen nicht kennen kann.
So spioniert MS einen Teil der Infrastruktur aus um zu sehen, ob ein vollwertiger DNS vorhanden ist.
Es ist nichts Neues dass man über DNS einen Tunnel aufbauen kann…(früher günstige, illegale Möglichkeit im Zug kostenlos ins Internet zukommen. Lange ist es her…)
Ich weiß nicht, wozu sonst MS wissen muss, ob der DNS externe Adressen auflöst, wenn der Proxy funktioniert.
Ist ja nicht das erste mal das die Abfrage oder der Status des Netzwerkes den Bootvorgang von Windows stark verzögert, taucht doch seit XP immer mal wieder auf.
Ich behalte das mal im Kopf wenn wir unsere Win10 Geräte auf Win11 ziehen.
Danke für die Arbeit!
60 Sekunden längere Startzeit? Bei einem Kollegen hier dauerte die Anmeldezeit zuletzt sage und schreibe 1h40m (Win 10, Netzwerkprofil)! Hab ihm gerade ein lokales Profil angelegt (Netzwerkprofil macht in seinem Fall keinen Sinn, da er eh immer am gleichen Rechner sitzt und nicht wie andere KollegInnen auch mal den Arbeitsplatz wechselt), jetzt dauert die ganze Prozedur weniger als 2 Minuten.
Achte darauf, das keine Netzwerk Laufwerke "persistent" gespeichert sind.
U.U. versucht Windows/der Explorer diese alle vorzumounten z.B. um das Icon für dieses Laufwerk durchzustreichen.
Schlecht wenn der Server umbenannt wurde, dann hängt das Windows in der DNS Abfrage resp. dem Broadcast (ja, es soll Consultants geben, die sich nicht die Mühe machen die DHCP Namen in den DNS zu transferieren und stattdessen auf Windows Broadcasts zur Namens Auflösung vertrauen.
Funktioniert doch sahnemäßig und der Kunde merkt davon ja nichts. Auch ist das viel sicherer!)
und da das nicht parallel erfolgt, kann das lange dauern.
Interessante Analyse, das passt zu einer Feststellung, die ich jüngst mit Notebooks machen konnte, die von Win10 auf Win11 migriert worden sind. Obwohl in einem öffentlichen Netzwerk, das über die Funktionalitäten von NCSI sowie NLASVC festgestellt wurde, natürlich keine dynamische DNS-Registrierungen gemacht werden, ist das unter Win11 nicht der Fall. Der aktive Netzwerkadapter, in der Regel der WiFi-Adapter, versucht alle zwei Minuten, die Netzwerkadresse zu registrieren, wie es in Domänen-Netzwerken standardmäßig erfolgt. Durch folgenden Powershell-Befehl wurde dies nun erforderlich manuell zu setzen, dass keine Registrierungsversuche mehr durchgeführt werden:
Get-NetAdapter WiFi| Set-DNSClient –RegisterThisConnectionsAddress $False
Hab auch sehr lange Startzeiten bei unseren Clients (Windows 10 Enterprise 2019/2021 LTSC). Bei uns liegts an einer GPO für die Namensauflösungstabelle (NRPT = Name Resolution Policy Table), die die DNSSEC-Überprüfung für unsere interne Domain erzwingt.
Es liegt auch nicht an der DNSSEC-Überprüfung an sich, sondern einfach nur an der Tatsache, dass sich die entsprechenden Einträge in der registry unter
"HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig" befinden. Ein einfaches Deaktivieren der Überprüfung hilft auch nicht. Man muss den Registry-Schlüssel komplett löschen und dann bootet der Client wieder normal schnell.
Konnte bisher auch nicht rausbekommen, woran das liegt.
Interessanter Beitrag, aber 60 Sekunden längere Startzeit wäre jetzt für mich kein Showstopper für ein Rollout und eigentlich zumindest in den Umgebungen, die ich betreue, nicht Mal ein Grund für weitere Recherche.
Interessanter und was hier ein bisschen untergeht, welche Einstellungen wurden genau verändert um das Verhalten hervorzurufen und betrifft die Verzögerung der internen DNS Abrufe eine bestimmte Adresse oder alle DNS Aufrufe.
Zum zweiten Abschnitt und den Fragen: Da müssen wir leider warten, ob der Leser hier in den Kommentaren Aufklärung bietet. Ich hatte ihn im Vorfeld per Mail angefragt, aber keine Antwort erhalten (vermutlich ein nicht benutztes E-Mail-Konto als SPAM-Falle). Das Thema schien mir interessant – und falls wer betroffen, dürfte ein Test schnell Erkenntnisse liefern. Zudem fragte der Tippgeber ja, ob Dritte ähnliche Erfahrungen gemacht haben.
"Und natürlich die Frage, ob der Leserschaft das obige Szenario bereits schon einmal untergekommen ist?" -> Lieber Einsender, wenn Sie uns Details der Settings genannt hätten, dann könnten da einige sicher darauf antworten. Vor allem die Lösung wäre ja doch auch hilfreich gewesen.
Kann da nur beipflichten, das Thema schlägt immer wieder mal auf. Oft ist die Kerproblematik auf die Feststellung wo sich Windows "befindet" zurückzuführen. Also Domain, Private, Public.
Die Stichworte hierzu sind Active und Passive Probing. Die Einstellungen die man treffen kann sind recht vielfältig. Theoretisch hat man Reg-Flags um alle externen Prüfungen auf interne Quellen umzuleiten. Theoretisch. Den interessanterweise funktioniert das nicht wirklich immer.
Habe in den letzten Jahren schon X-Stunden bzw. Tage mit diesem Problem verbracht weil die Umgebungen die ich betreue, allesamt ein ziemlich hohes Mass an Privacy-Einstellungen haben. Dazu alles ausprobiert was ich finden konnte.
Active Probing generell deaktivieren ist zwar möglich, ist aber seit längerem (also seit vielen Builds) eine sehr schlechte Idee. Dann findet manchmal nichtmal der DC seine eigene Zugehörigkeit. Gängige Workarounds können dann auch fehlschlagen. Ziemlich lächerlich das Ganze. Schlüsseldatei ist wie auch unter Windows Papst beschrieben die Abfrage der Connector Datei des Active Probing. Die kann man z.B. auf einem interen IIS veröffentlichen. Diese ist Bestandteil des Active Probing.
Das Passive Probing hat noch nie so 100% zuverlässig funktioniert bzw. habe ich nie rausgefunden, wie man es zuverlässig triggern kann. Manchmal findet eine Maschine aber nach ein paar Stunden seine Zugehörigkeit. Das wäre dann auf diese zurückzuführen, wie auch immer das Zustande gekommen ist.
Insgesamt ist die ganze Geschichte unglaublich undurchsichtig und die genauen Prozesse dahinter sind nicht öffentlich dokumentiert. Bräuchte man einen MS-Mitarbeier, dann könnte man auch aktiv entsprechende Massnahmen treffen. Meine Anfragen liefen leider ins leere.
Dann könnte ich mir vorstellen, dass das deaktivieren von IPv6 auf das Active Probing einen Einfluss hat. Zumindest für den ersten Trigger beim Systemstart. Wobei ich nicht ganz ausschliessen kann, dass dies darauf zurückzuführen ist, dass die IPv6 Konnektivität nach draussen nicht zuverlässig geblockt wurde. Habe da nicht soviel Zeit investiert da ich es eh immer deaktiviere. Darf aber gerne jemand testen der es ebenso deaktiviert hat, ich habe kein Muse mehr für dieses Problem. ;)
Die Workarounds:
In der Vergangenheit half ein durchstarten des nlasvc. Das ist aber heute essig weil er seit ein paar Monaten speziell gesichert ist und nicht ohne weiteres neu gestartet werden kann. Prozesse bei Systemstart hart abschiessen ist jetzt auch nicht so dolle.
Noch weiter zurück half den nlasvc zu verzögern. Das ist aber ebenfalls seit längerem Geschichte.
Heute gibt es zwei funktionierende, mir bekannte Varianten:
Static Adressen: Netzwerkadapter Deaktivieren/Aktivieren
DHCP Adressen: Netzwerkadapter Deaktivieren/Aktivieren oder ipconfig /renew
Die Netzwerkadapter Aktivieren/Deaktivieren Variante hat schon immer am zuverlässigsten funktioniert. Auf jedem OS. Solange das Active Probing aktiviert bleibt und intern den Kram findet auch auf neueren Builds.
Das kann z.B. per Powershell-Script erschlagen werden. Seit Win 8.1 ist das recht Schmerzfrei da es entsprechende Cmdlets gibt um die Adapter zu manipulieren. Unter Windows 7 war das noch recht gräuslich mit Bordmitteln und man musste eine Helper-Exe zu Hilfe nehmen damit es einigermassen easy ohne die eher anfällige Analyse der Registry war. Der Nachteil ist, dass das Script mit erhöhten Rechten laufen muss.
Es würde ganz bestimmt irgend einen WMI Befehl geben um das ganze zu triggern. So wie für fast alles das auf irgendwas reagiert. Aber in diesem Jungle finde ich mich leider nicht so richtig zurecht. :(
Ein weiterer Übeltäter bezüglich langer Anmeldezeiten:
Das ganze IPv6/IPv4/Teredo Geraffel-Durcheinander kann z.B. massgeblich für lange Anmeldezeiten verantwortlich sein. Weil da kunterbunt hin und hergeschaltet wird und Timeouts abgewartet werden. Bei jeder Abfrage von neuem. Es hilft manchmal massiv z.B. die ganzen Tunneldienste wie Teredo etc. zu deaktivieren. Damit ist Windows klar ist, dass es entweder IPv4 oder IPv6 direkt gibt. Und sich den Rest sparen kann. Noch schneller teilweise wenn IPv6 ganz deaktiviert wird *hust*
(Aber ausschliesslich wenn man es richtig macht. Die meisten machen es leider falsch, dann hat man das gleiche Problem. Stichworte: Routingtabelle, Deaktivieren Protokoll auf Adapter, Deaktivieren der Funktionen)
Kleine Ergänzung: Eigentlich ist die Prio eher anders rum, das Theater mit den Tunnels macht bezüglich Anmeldelänge eher Ärger. Das Nichtfinden der Domain macht für den Anmeldevorgang eigentlich noch nicht viel Ärger sondern eher danach.
Hallo zusammen,
ich hatte im Juni/Juli 2023 mich mit dem Thema NCSI und Windows 10 22H2 und Outlook 2019 Konnektivitätsproblemen befasst. Outlook, und nur Outlook zeigte den Status „getrennt" an. Exchange OnPrem erreichbar. DNS ets. alles ok. Auch die Anzeige „Kein Internet" wurde unten rechts angezeigt. NCSI Settings (Registry) durchprobiert. Egal was man gesetzt hat, ein Problem war verschwunden, ein anderes ist gekommen. Als ich dann nochmal im Netz gegraben habe, fand ich tatsächlich einen Artikel von Microsoft zu genau diesem „Outlook getrennt" Problem.
Die Lösung seitens Microsoft, äusserst lustig:
1. Deaktivieren von IPv6 am Netzwerkadapter (einfach mal komplett gegen die eigene Empfehlung…)
Meine Lösung war letztendlich „Prefer IPv4 over IPv6" – einen Reboot später und die Konnektivität war wieder gegeben.
https://learn.microsoft.com/en-us/outlook/troubleshoot/connectivity/outlook-shows-disconnected-if-ipv6-is-enabled
„Prefer IPv4 over IPv6"
Das aktivier ich auch immer in reinen IPv4 Netzen und lasse in den Adaptern IPv6 in den Netzwerkadaptern aktiv. Außer bei Nutzung der obig erwähnten "Name Resolution Policy Table" (NRPT) gibt auch keine langwierigen Bootprozesse. Klar, in Domänennetzwerken dauerts mitm Booten immer etwas länger, aber da reden wir von vlt. 10-15sek. Bei meinem Problem mit der NRPT sinds aber eher 1-1,5min. Bisschen nervig isses schon.
Der wichtigste Satz ist folgender: "Es wird empfohlen, IPv4 gegenüber IPv6 in Präfixrichtlinien zu bevorzugen, anstatt IPV6 zu deaktivieren." Ohne diesen Punkt schiesst man sich immer ins Bein wenn man Komponenten von IPv6 deaktiviert. Weil es Windows teilweise eben dennoch erst mit IPv6 versucht.
Also entweder ist alles was IPv6 ist vor IPv4 (inkl. ULA's) oder eben anders rum. Sobald man anfängt Teile von IPv6 zu deaktivieren immer IPv4 mit höchster Prio. Ausser der 6to4 Schrott mit allem was dazugehört, der kann und imho sollte eigentlich immer aus. Der ist eh nicht so richtig kontrollierbar.
Die älteren 6to4 Protokolle sollten ohnehin aus Sicherheitsgründen deaktiviert werden, da gibt's einige Hardening Empfehlungen in die Richtung.