Gerätetunnel unter Windows Pro? Die Editionsmatrix prüfen

Das Profil landet auf dem Laptop, die VPN-Einstellungsseite zeigt es an, und der Gerätetunnel baut am Anmeldebildschirm trotzdem nie eine Verbindung auf. Unter Windows Pro ist das oft kein Konfigurationsfehler. Der native Gerätetunnel wird nach Edition lizenziert, und ein Benutzertunnel, der nach der Anmeldung funktioniert, belegt eine andere Fähigkeit. Lesen Sie die Anforderung, bevor Sie das Zertifikat debuggen.

Das Symptom zeigt sich, bevor sich jemand anmeldet

Ein Benutzertunnel verbindet sich nach der Anmeldung im Kontext des Benutzers, deshalb funktioniert er unter Pro normal. Ein Gerätetunnel soll die Rechnerkonnektivität herstellen, bevor sich ein Benutzer anmeldet, und zwar mit einem Rechnerzertifikat und IKEv2. Das sind verschiedene Phasen des Lebenszyklus, nicht zwei Namen für dasselbe Profil.

Unter einer nicht berechtigten Edition kann das Profil trotzdem bereitgestellt und aufgeführt werden, aber die Verbindung vor der Anmeldung erscheint nicht. Nach der Anmeldung kann der Benutzertunnel einwandfrei funktionieren, wodurch die Bereitstellung bei jeder Prüfung durch den Kontoinhaber gesund aussieht. Der Fehler ist aus einer bereits angemeldeten Sitzung heraus unsichtbar.

Ein Profil für alle Benutzer verfügbar zu machen, ändert, wer es verwenden darf. Es ändert nicht den Authentifizierungskontext von Benutzer zu Rechner, daher kann es einen Benutzertunnel nicht in einen Gerätetunnel verwandeln. Der Unterschied liegt im Authentifizierungskontext, nicht in der Sichtbarkeit des Profils.

Lesen Sie die Matrix, nicht nur den CSP-Knoten

Microsofts Funktionsmatrix für Windows 11 führt den nativen Always On VPN-Gerätetunnel für Enterprise und Education auf. Der Konfigurationsdienstanbieter VPNv2 dokumentiert separat einen DeviceTunnel-Knoten, dessen Anwendbarkeit Pro einschließt, und diese Zeile wird häufig als Beweis dafür zitiert, dass die Funktion funktioniert. Konfigurationsoberfläche und Funktionslizenzierung beantworten unterschiedliche Fragen: Die eine sagt, dass eine Einstellung ausgedrückt werden kann, die andere, dass die Edition auf die Fähigkeit Anspruch hat.

Bestätigen Sie die tatsächliche Edition und den Build, statt dem Kaufeintrag zu vertrauen. Verwaltete Aktivierung, ein laufendes Upgrade oder ein neu erstelltes Image können einen Rechner auf einer anderen Edition belassen, als die Asset-Liste angibt:

winver
DISM /online /get-currentedition
Get-ComputerInfo | Select-Object WindowsProductName, WindowsEditionId, OsBuildNumber

Wenn die Ausgabe Pro sagt, liegt der native Gerätetunnel außerhalb des dokumentierten Funktionsumfangs für diesen Rechner. Diese Schlussfolgerung erfordert keine Profiländerung und wird durch eine solche auch nicht behoben. Halten Sie diesen Befund fest, bevor Sie etwas anderes ändern.

Vier Voraussetzungen hinter dem Funktionsflag

Die Edition ist das Tor, und die übrigen Anforderungen erklären, warum ein Rechner mit berechtigter Edition trotzdem scheitert. Prüfen Sie sie der Reihe nach, denn jede kann dasselbe stille Ergebnis erzeugen. Eine Zeile zu überspringen verschwendet den Aufwand für die darunter liegenden Zeilen. Die Edition steht aus gutem Grund an erster Stelle.

Die Zertifikatsprüfung ist die, die Leute überspringen. Der private Schlüssel muss im Rechnerspeicher vorhanden und vor der Anmeldung für den Systemkontext nutzbar sein, was ein anderer Speicher ist als der, den ein Benutzer in seinem eigenen Zertifikatsdialog sieht:

Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.HasPrivateKey } | Select-Object Subject, NotAfter

Ein Zertifikat, das im Benutzerspeicher korrekt aussieht, kann im Rechnerspeicher völlig fehlen. Der Gerätetunnel scheitert dann an der Authentifizierung, bevor der Anmeldebildschirm erscheint, und kein erneuter Profilimport ändert das. Prüfen Sie den Speicher, den der Dienst verwendet, nicht den, den der Benutzer sieht.

Eine geplante Aufgabe als SYSTEM ist nicht die Funktion

Es kursiert ein Workaround, der ein VPN-Profil aus einer als SYSTEM laufenden geplanten Aufgabe startet, wodurch kurz nach dem Start ein Tunnel erscheint. Das ist nicht der native Gerätetunnel. Die Aufgaben-Engine startet zu einem anderen Zeitpunkt, die Verbindung ist ein Benutzermodusprofil, das von einem Dienstkonto gestartet wird, und der Lebenszyklus entspricht nicht einem maschinenauthentifizierten Tunnel, der am Anmeldebildschirm vorhanden sein muss.

Er kann einen oberflächlichen Test bestehen, weil der Tunnel steht, wenn sich jemand anmeldet und nachsieht. Dieser Erfolg misst die Verzögerung zwischen Start und Aufgabe, nicht die Konnektivität vor der Anmeldung, und er lässt den Rechner während des Zeitfensters ohne Tunnel, das die Funktion abdecken sollte.

Behandeln Sie den Workaround für die Produktion als nicht unterstützt. Wenn ein Entwurf davon abhängt, ist die Anforderung wahrscheinlich eine Verbindung vor der Anmeldung, was die Diskussion zurück zur Editionsberechtigung bringt.

Wählen Sie die Anforderung vor der Technologie

Schreiben Sie die Anforderung als einen Satz: Das Gerät muss eine benannte Ressource erreichen, bevor sich ein Benutzer anmeldet, oder der Benutzer braucht Zugriff nach der Anmeldung. Wenn der zweite Satz zutrifft, ist ein Always On-Benutzertunnel unter Pro ein unterstützter Entwurf und der Gerätetunnel unnötige Komplexität.

Wenn der erste Satz zutrifft, ist die Edition ein hartes Tor. Wählen Sie eine berechtigte Edition oder eine dokumentierte Architektur vor der Anmeldung, die die Organisation unterstützt, und planen Sie die Lizenzänderung, bevor Sie Profile und Zertifikate um eine Fähigkeit herum aufbauen, die der Rechner nicht ausführen kann.

Notieren Sie Edition, Domänenbeitrittsstatus, Zertifikatsspeicherort und Bereitstellungskanal in den Bereitstellungsnotizen. Der nächste Ingenieur kann die Berechtigung dann in Minuten bestätigen, statt dieselbe Profilfehlersuche auf einem Rechner zu wiederholen, der sich nie verbunden hätte.