Warum upgraded Windows 10/11 Pro nicht zu Enterprise?

Ein klassischer Stolperstein in modernen Windows-Deployments

Du hast einen neuen Client per Autopilot oder manuell aufgesetzt, Intune ist angebunden, die Microsoft 365 E3/E5 Lizenz ist zugewiesen – und trotzdem bleibt das Gerät stur auf Windows 10/11 Pro.

Dabei sollte es doch automatisch zu Enterprise hochstufen, oder?

👉 Die Ursache liegt häufig nicht bei der Lizenz, sondern ganz woanders:
Der SYSTEM-Kontext hat keinen Zugang zum Internet – wegen fehlender Proxy-Konfiguration.

Hintergrund: Lizenzaktivierung und Hybrid Join brauchen WinHTTP

Viele moderne Windows-Funktionen laufen nicht im Benutzerkontext, sondern im SYSTEM-Kontext. Dazu gehören:

• Windows Enterprise Aktivierung
• Microsoft Entra (Azure AD) Hybrid Join
• Autopilot Deployment
• Intune MDM-Registrierung
• SSO & Device-based Conditional Access

All diese Prozesse benötigen internetzugriff aus dem SYSTEM-Kontext – z. B. auf:

• https://login.microsoftonline.com
• https://device.login.microsoftonline.com
• https://enterpriseregistration.windows.net

Wenn der Proxy nur für Benutzer, aber nicht für SYSTEM greift, schlägt alles fehl – leise und schwer nachvollziehbar.

Symptome

• dsregcmd /status zeigt AzureAdJoined : NO
• Enterprise-Aktivierung bleibt aus
• Fehlercodes wie 0x80072ee2 (WININET_E_TIMEOUT) oder 0x801c03f2 im Eventlog
• netsh winhttp show proxy meldet: Direct access (no proxy server)

Lösung: WinHTTP-Proxy im SYSTEM-Kontext setzen

Der SYSTEM-Kontext verwendet eigene Proxy-Einstellungen – getrennt von denen in Edge oder Internet Explorer. Diese werden über das Tool netsh gesetzt.

Beispielkonfiguration:

netsh winhttp set proxy proxy-server="http=myproxy.domain.tld:8080;https=myproxy.domain.tld:8080" bypass-list="*.domain.tld;10.*;192.168.*"

Deployment per GPO (Startup-Skript)

Da SYSTEM-Kontext betroffen ist, funktioniert nur ein Computerkontext-Skript – kein Benutzer-Logon.

Beispielskript (Set-WinHttpProxy.cmd):

@echo off
SET PROXY=http=myproxy.domain.tld:8080;https=myproxy.domain.tld:8080
SET BYPASS=*.domain.tld;10.*;192.168.*;*.local

echo [%DATE% %TIME%] Setting SYSTEM proxy... >> C:\Windows\Temp\SetWinHttpProxy.log
netsh winhttp set proxy proxy-server="%PROXY%" bypass-list="%BYPASS%" >> C:\Windows\Temp\SetWinHttpProxy.log 2>&1
exit /b 0

GPO-Konfiguration:

1. GPO erstellen
2. Konfigurieren unter: Computerkonfiguration → Richtlinien → Windows-Einstellungen → Skripts (Start)
3. UNC-Pfad zum Skript eintragen (z. B. \\domain.local\netlogon\Set-WinHttpProxy.cmd)
4. OU mit Zielgeräten verknüpfen
5. Neustart durchführen

Validierung

netsh winhttp show proxy

und

dsregcmd /status

Erwartung:

• AzureAdJoined : YES
• Windows Enterprise wird automatisch aktiviert

Rückgängig machen

Falls du später auf WPAD umstellst oder keinen Proxy mehr brauchst:

netsh winhttp reset proxy

Kann ebenfalls per GPO-Skript verteilt werden.

Fazit

Windows-Enterprise-Aktivierung, Hybrid Join, Autopilot und Intune setzen voraus, dass der SYSTEM-Kontext uneingeschränkt mit bestimmten Microsoft-Endpunkten kommunizieren kann.

Das klappt nur, wenn:

• der WinHTTP-Proxy korrekt gesetzt ist
• keine TLS-Inspektion den Datenverkehr unterbricht
• GPO-basiertes Skript den Proxy sauber im Hintergrund setzt

Diese Kleinigkeit kann der entscheidende Unterschied sein zwischen funktionierendem Modern Deployment und stundenlangem Troubleshooting.