[English]Ein neuer Rechner mit Windows 11 24H2 Home lässt sich zwar mit einer entsprechenden Lizenz auf die Pro-Version upgraden. Das System lässt sich danach aber nicht in die Cloud-Lösung Microsoft Defender for Endpoint integrieren. Ähnliches gilt für OEM-Systeme mit Windows 11 24H2 Pro, die nicht entsprechend vorbereitet sind. Microsoft hat dieses Problem als bekannt bestätigt und einen Workaround gepostet.
Upgrade von Home auf Pro bringt Probleme
Windows kann in der Home-Edition nicht in Domänen aufgenommen und durch die Cloud-Lösung Microsoft Defender for Endpoint geschützt werden. Besitzt man einen Produkt-Key für Windows 11 24H2 Pro, kann man ein entsprechendes System mit Windows 11 24H2 Home aber upgraden, um Domain-tauglich zu werden. In Firmen könnte man dann den Windows-Rechner zusätzlich mit der Cloud-Lösung Microsoft Defender for Endpoint schützen. Bei Windows 11 24H2 scheitert dieser Vorgang bei einem so von Windows 11 Home hochgestuften Rechner aber, so dass der Microsoft Defender for Endpoint nicht aktivierbar ist.
Microsoft hat das Problem im Supportbeitrag KB5043950: Microsoft Defender for Endpoint known issue bestätigt (den Kollegen hier ist das aufgefallen). Das Problem tritt auf, wenn neue (von Home auf Pro aktualisierte) Geräte mit Windows 11 Version 24H2 in Microsoft Defender für Endpunkte integriert werden sollen.
Administratoren in Unternehmen stellen dann fest, dass die betreffenden Geräte sich nicht in den Cloud-Dienst Defender for Endpoint einbinden lassen. Die Systeme erhalten nicht den erwarteten Schutz, selbst wenn Intune die Einbindungssequenz durch Anwendung einer EDR-Richtlinie (Endpoint Detection and Response) ausführen soll.
Intune zeigt dann eine Fehlermeldung an, da es die Richtlinie nicht erfolgreich anwenden kann. Benutzer können möglicherweise auch keine Verbindung zu Unternehmensressourcen herstellen, wenn eine Richtlinie für den bedingten Zugriff so konfiguriert ist, dass Defender for Endpoint aktiviert sein und sich aktiv melden muss. Der Konformitätsstatus ist im Microsoft Intune-Dashboard zur Gerätekonformität sichtbar.
Problem tritt in diesen Szenarien auf
Dieser Fehler kann laut Microsoft in einem der folgenden zwei genannten Szenarien auftreten.
Upgrade von Home auf Pro
Hat ein Benutzer ein neues Gerät mit Windows 11 24H2 Home gekauft, wird der Defender for Endpoint nicht unterstützt. Der Benutzer kann aber mit einem Pro-Produktschlüssel ein Upgrade auf Pro durchführen.
Bei diesem Upgrade wird aber der Defender for Endpoint nicht installiert – was aber beabsichtigt ist. Der Defender for Endpoint-Agent wird nicht korrekt im Defender for Endpoint-Dienst registriert, und das Gerät ist nicht geschützt.
OEM-Gerät mit fehlerhafter OEM-Vorbereitung
Der zweite Fall, in dem es Probleme gibt, tritt bei OEM-Geräten auf. Kauft ein Benutzer ein neues Gerät mit der Windows 11 24H2 Pro SKU, muss der OEM reagieren und die entsprechende Funktion installieren. Hat der OEM gepennt und die erforderliche Funktion nicht installiert, gibt es die oben skizzierten Probleme.
Workarounds aus dem Problem
Der Administrator muss das DISM-Befehlszeilentool (Deployment Image Servicing and Management) verwenden, um den Windows Sense-Client aus einer Eingabeaufforderung mit administrativen Berechtigungen mit folgendem Befehl zu installieren.
DISM /online /Add-Capability /CapabilityName:Microsoft.Windows.Sense.Client ~~~~
Microsoft gibt im KB-Artikel noch „~~~~“ hinter dem obigen Befehl an – um die erwarteten Parameter zu füllen. Weitere Informationen finden sich unter WindowsAdvancedThreatProtection CSP.
Text etwas korrigiert, um klarzustellen, dass die Einbindung des Systems in Microsoft Defender for Endpoint (Cloud-Dienst) in dem beschriebenen Szenario scheitert.
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-8.1-and-8/hh824952(v=win.10)?redirectedfrom=MSDN#eicfg-format
Dann muss man halt die MS empfohlenen Pfade verwenden. Besonders, wenn eine im UEFI hinterlegte Lizenz das Upgrade blockiert.
Das ganze System wie eine Aktivierung gespeichert wird ist Müll seit Version 8.x
Zitat:
„Microsoft gibt im KB-Artikel noch „~~~~“ hinter dem obigen Befehl an – ich gehe aber davon aus, dass dies ein Fehler ist.“
–
Nein, das ist kein Fehler.
Die vier Tilden müssen mit hinzu, um die hinteren 4 unwichtigen Namensbestandteile zu eliminieren.
Diese Tilden funktionieren wie Trenner oder Auf-Splitter.
Erklärung:
Ein Paket oder eine Fähig enthält im String:
1. den Namen
2. die sha1-Checksumme
3. die Plattform (zum Beispiel „amd64“ oder „x86“)
4. die Sprache (zum Beispiel „de-de“ oder „en-US“)
5. die Versionsnummer
Alle diese 5 Komponenten werden mit je einer Tilde als Verbindungsstück zusammengekettet zu einem String.
Wenn man jetzt an dism die Parameter übergibt, dann interessiert im Grunde nur der Name, aber nicht die übrigen Bestandteile, also splittet man die mit 4 Tilden vom Gesamtstring wie mit einer Axt einfach ab. Die Versionsnummer und Checksummen etc sind dem User in diesem Fall unwichtig und oft auch gar nicht bekannt
Beispiel:
ursprünglicher kompletter String eines Paketes:
„Microsoft-Windows-Client-LanguagePack-Package~31bf3856ad364e35~amd64~en-US~10.0.19041.746“
einzelne Bestandteile:
1. Microsoft-Windows-Client-LanguagePack-Package
2. 31bf3856ad364e35
3. amd64
4. en-US
5. 10.0.19041.746
Durch die 4 Tilden am Ende hinter dem Namen werden die Bestandteile 2 bis 5 wie mit einem Beil einfach entfernt.
Dism bekommt dann also nur den Namen und sucht sich Sprache, Plattform, Versionsnummer und Checksumme automatisch passend heraus.
Man kann es auch so sehen, dass man mit den 4 Tilden das dism-Tool anweist, diese 4 fehlenden Namensbestandteile zu jeder Tilde selber rauszusuchen.
Wenn man die 4 Tilden weg lässt, dann sind Sprache, Plattform, Version und Checksumme für das Paket nicht definiert und dism weiß dann nicht, welche der vielen Varianten es benutzen soll.
Interessanter Artikel, aber mal ehrlich:
Welche echter verantwortungsbewusste Admin nimmt ein vorinstalliertes W11 Home, upgraded es auf Pro und nimmt es dann in eine Domäne auf … 🤔 Echt jetzt?
Ich hätte eigentlich einen Aufschrei erwartet, schon seltsam. 🙃
Eigentlich sollte jeder Admin der bis 3 zählen kann das System passend neu zu seiner Umgebung aufsetzen, schon alleine um die ganze vorinstallierte Bloatware loszuwerden und nicht in irgendeine Installationsfalle tappt. Wie man oben lesen kann, passiert der Fehler leider auch auch wenn der OEM gepennt hat.
Unter diesem Link – noch besser beschrieben von MS:
https://support.microsoft.com/en-au/topic/kb5043950-microsoft-defender-for-endpoint-known-issue-2fd719b6-8c26-469f-99fe-832eb1b702d7
Witzig, das AntiVir Updates eines BS verhindert ist mir das erste mal 1994/95 passiert als ich ein Win 3.11 auf Win95(Disketten) updaten wollte. F-Prot hatte verhindert das die von der Installation erzeugte Startdiskette(frag nicht) ihren Job machen konnte. Das ich da im zarten Alter von 14 einem Riesenproblem auf der Spur war wusste ich natürlich nicht ;)
Wer macht sowas? PCs und Notebooks, die mit Windows Home ausgestattet sind, sind eigentlich nicht für den Unternehmenseinsatz gedacht. Für die Dinger gibts vom Hersteller keinen Vorortsupport. Will man den Büro-PC bei einem Defekt zum Hersteller einschicken und wochenlang darauf warten, dass er repariert zurück kommt? Soll die Buchhaltung dann derweil Pullover stricken, bis der PC wieder da ist? Leute, kauft für den proffessionellen Einsatz konzipierte Hardware mit Vorortsupport (max 24 bis die Kiste wieder geht) und dann bekommt ihr auch geich eine Pro-Lizenz, die übrigens auch billiger ist, als eine Home mit Pro-Heraufstufung!