Wednesday, 20 February 2019 09:43

MDT: Language Packs and MAX_PATH Limitations

Written by
Rate this item
(0 votes)


This case is my favorite kind of case, one where I use PowerShell to solve an issue affecting a customer. The problem at the root of it is also one you might run into if you are using Microsoft Deployment Toolkit (MDT) to apply language packs and features on demand during OSD, making it an ideal troubleshooting example to document and share.

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_\
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 -> 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.

Read 9054 times Last modified on Friday, 22 February 2019 08:08

Recent Posts

  • Windows 10 21H2 Built-In Apps: What to Keep
    The development of the Windows 10, version 21H2 is finished and the update will soon be available for download from…
    Written on Wednesday, 20 October 2021 11:41
  • Group Policy Changes in Windows 10 21H2
    As Windows 10, version 21H2 update development winds down, Microsoft is now preparing for the final release of the Windows…
    Written on Wednesday, 20 October 2021 07:20
  • Group Policy Changes in Windows 10 20H1 Preview
    As Windows 10 Vibranium Update (20H1) development winds down, Microsoft is now beginning the phase of checking in the final…
    Written on Tuesday, 14 January 2020 04:51
  • An alternative ESU MAK Activation Solution
    This blog post was shared with me by a colleague of mine, Daniel Dorner, a Microsoft Premier Field Engineer. It’s…
    Written on Wednesday, 04 December 2019 21:04
  • The Case of Missing UE-V Templates
    My customers often deal with unexpected Windows behavior and this case is no different. This particular one is especially interesting…
    Written on Tuesday, 03 September 2019 12:20
  • The Case of Changing Default Printer
    While I sometimes long for the day when I no longer have to deal with unexpected Windows 10 behavior, there’s…
    Written on Wednesday, 14 August 2019 20:36