The case unfolds with a customer at a corporation contacting me to report that starting with Windows 10, version 1803, users across their company were complaining of missing language packs which were automatically selected via CustomSettings.ini prior to layering down the operating system. The fact that all new Windows 10 installations were experiencing the problem pointed at a Microsoft Deployment Toolkit issue.

I asked the customer to collect MDT related logs. When I reviewed the ZTIPatches.log, two patterns became clear: first (as expected), MDT injected the base language into the offline OS, and second, it then failed to add the Basic Windows language feature package:

Adding language pack entries to unattend.xml
Add package {8f4fc5c6-8701-482c-9c35-1538d14f7029}
Package {8f4fc5c6-8701-482c-9c35-1538d14f7029} added.
Add package {0c2585bb-7431-4f47-ab49-62ba7b4e5e93}
ZTIPatches Package path not found: \\wds04mdt0001.corp.contoso.local\MDT_Win10$\Packages\OnDemandPack\amd64_Microsoft-Windows-LanguageFeatures-Basic-de-de-Package_10.0.17134.1_neutral_31bf3856ad364e35_\Microsoft-Windows-LanguageFeatures-Basic-de-de-Package~31bf3856ad364e35~amd64~~.cab
ZTIPatches processing completed successfully.

Unfortunately, the message, "ZTIPatches Package path not found", provided no clue as to the underlying cause and the default behavior is to continue with the rest of the installation despite the issue. Together with the customer, I quickly verified that the features on demand CAB files existed at the specified location. I knew, that in the Windows API (with some exceptions), the maximum length for a path is MAX_PATH, which is defined as 260 characters. With the anecdotal evidence seeming to hint at a path length issue, we then compared Windows 10, version 1709 and Windows 10, version 1803 features on-demand packages, which pointed at the underlying cause: MDT appends a version specific guid to packages folder names. Starting with Windows 10, version 1803, the Windows product group started adding the same guid to the CAB file names. This was not the case in the older releases of Windows 10 features on-demand packages, hence the MAX_PATH limitation had not been triggered.

Armed with this knowledge, I quickly put together a PowerShell script to shorten features on-demand file names prior to importing them into the Deployment Workbench: for example Microsoft-Windows-LanguageFeatures-Basic-de-de-Package~31bf3856ad364e35~amd64~~.cab -> FoD-Basic-de-de.cab prior to importing them into the deployment workbench. The IT department proceeded to implement the suggestion and a few days later confirmed that the users were no longer experiencing issues with language packs installation they had reported.

I’d have considered this case closed. However, just a few weeks later, the same customer contacted me again to report that the workaround did not fly on Windows 10, version 1809 - OS deployments now failed with a generic error message during language pack injection step in Windows PE. Given the interesting nature of the case, I immediately sat down to investigate, verified the issue, checked MDT logs and latency to the deployment server, but could not find any clues that would explain the problem. From my past experience, I knew that aside from MDT logs, the DISM log might hold important clues that might help to pinpoint the problem. So, I opened the DISM.log file located on the temporary drive and sure enough, quickly came across errors related to features on demand (most notably: Failed to extract file update.mum from cabinet). Based on the log entries, I assumed that starting with Windows 10, version 1809, DISM now validates CAB file names and throws a critical error if the file name was altered.

Armed with this clue, I set to work. The key to working around the MAX_PATH issue as well as DISM validation was to bypass MDT functionality by putting together two PowerShell scripts to perform the following tasks:

• Generate zip archive including language pack and features on demand per language
• Unzip the contents of an archive to the system drive as part of the MDT task sequence and then use DISM to apply language bits in the correct order (either offline or online)

I tested this approach, written up my analysis and recommendations and sent them back to the customer, which - to my satisfaction - in turn confirmed that the fix (a workaround to be precise) functioned as intended. The customer also escalated this case with the Microsoft support, which - after a brief investigation - confirmed our suspicions of what we observed in the DISM log as well as the supportability of the implemented workaround.

If you wish to try this approach, follow the steps outlined below:

• Download sample scripts from my GitHub repository
• Copy language packs plus features on demand (either x86 or x64) into the same folder. Place CreateLangPackPkgs.ps1 script in the same folder and execute it to create zip files for individual language bits.
  Note: the default behavior is to create zip archives only for the languages specified in the $lan_lis variable.
• Now, copy language zips you wish to apply plus either ApplyLangPkgsOffline.ps1 or ApplyLangPkgsOnline.ps1 (depending on whenever you wish to inject language packs in WinPE or FullOS) to your deployment share (you could, for example, use following folder structure: %SCRIPTROOT%\LangPacks\1809).
• Add a Run PowerShell action to your Windows 10, Version 1809 task sequence.

Happy deploying.