Sprachpakete… Man kann nicht mit ihnen, aber ohne sie geht halt auch nicht. Vor allem, wenn man Mitarbeiter im Unternehmen hat, die kein englisch oder deutsch verstehen. Ich halte das noch immer für eine dreiste Lüge, aber was soll ich machen. Dann halt mit Sprachpaketen.

Also erst einmal das aktuelle Sprachpaket laden. Wo gab es das noch einmal? Ach was solls, wir haben doch den uupdump. Datei „microsoft-windows-client-languagepack-package_<lang>-<processor>-<lang>.esd“ laden und im SCCM einbinden. Zum Schluss noch in der aktuellen Windows 10 Task Sequenz die Sprachpakete einbinden und fertig.

Das funktioniert auch soweit, nur dass nach dem ersten Boot und dem Wechsel von der Sprache die man installieren wollte – bzw. installiert hat – in die Sprache, die auf der ISO installiert war ein „Fehler“ auftritt. Dieser ist als solches beim ersten Hinschauen nicht erkennbar, da die Meldung in den „Nein, nicht abmelden“-Dialog gestopft wird.

Kurz gesagt ist ein Fehler aufgetreten und ein paar Sprach-Funktionen konnten nicht korrekt geladen werden („you can try again later… Error code: 0x%1!X!“). Unter der Sprachauswahl steht ein ähnlicher lokalisierter Text: „Sorry, we’re having some trouble on our end. Retry?“

In diesem konkreten Fall, reicht es aus, das Windows Update anzuschmeisen und damit das letzte CU neu installieren zu lassen. Anschließend haben die installierten Sprachpakete eine andere Version, nämlich die des aktuellen Builds (beispielsweise 18363.476).

Als kleinen Nachtrag (ich bin faul): LXP sind keine vollständigen Language Packs (siehe MS TechNet, „[…] however, for full languages (aka SKU languages), we have not yet retired the legacy language packs (lp.cab) […]“). Daher sind LXPs nichts für unsere Umgebung. Sollte Microsoft hier mal etwas ändern um es den Admins „leichter“ zu machen, werde ich mich dessen annehmen… Vielleicht…