MSEndpointMgr
Home » Microsoft Endpoint Manager » ConfigMgr » WIM Witch v1.4.0 – Language Packs, Features on Demand, and Local Experience Packs

WIM Witch v1.4.0 – Language Packs, Features on Demand, and Local Experience Packs

Starting with version 1.4.0, WIM Witch can now import and apply Language Packs, Features on Demand, and Local Experience Packs. This feature set has been a constant request from the original release of WIM Witch, and I am really happy to have finally delivered it.

There are known bugs, which are listed at the end of the post. There are also unknown bugs, which are not. Consider the new feature set as “Preview” for a little while. This release also has some minor UI tweaks, which will be detailed later in the post.

Importing

Start WIM Witch and select the “Import LP+FOD” tab. Select the type of import (Language Pack, Local Experience Pack, or Features On Demand), the Windows OS, and the corresponding version that you wish to import. At this time, WIM Witch is unable to determine the corresponding version of Windows from these binaries alone, so an accurate selection of the intended version is required.

Once the required data points have been entered, click the “Select” button to browse to the source.

  • LP,LXP, and FOD importation does not import directly from a ISO file like the WIM importation process does. The ISO file will need to be mounted or extracted for WIM Witch to import.

Importing Language Packs

Select Language Packs in the Object Type drop down, then select the version of Windows. Then, click the “Select” button.

Browse to the \x64\langpacks folder in the Language Pack media and select this path. WIM Witch does not support x86 images, so ensure x64 is selected.

Once the folder has been selected, the path will be queried for content and the result will be displayed in a Grid View window.

Did someone call a cab?

Select the Language Packs that will be needed for image creation, then click OK.

The selected files will be displayed in the “Selected Items” window on the “Import LP+FOD” tab. Ensure the files have a CAB file extension. Click the Import button to begin the importation process.

Importing Local Experience Packs

To import Local Experience Packs, select Local Experience Pack in the Object Type drop-down, along with the corresponding OS and Version number. Once configured, click the “Select” button and browse to the LocalExperiencePack source folder. Ensure the LocalExpereincePack folder is selected and not one of its many subfolders.

That’s the one you want.

Once the source path has been selected, a Grid View will be displays a list of the Local Experience Packs that can be imported from the source. Select the needed packs and click OK. The LXP’s will be displayed in the Selected Items window in the Import “LP+FOD” tab.

Click the “Import” button to start the importation process.

Importing Features On Demand

To import Features on Demand, change the Object Type to Features on Demand and select the corresponding OS and Version. Click the “Select” button to select the import source folder.

Select the root of the mounted ISO or source folder.

Unlike the Language Packs and Local Experience Pack, WIM Witch does not provide the user with an option to select packages. Instead it copies the entire contents of the Features On Demand source to its import folder.

Yes, that is an extra “\”. It isn’t hurting anything so I’ve just left it alone for now.

Click Import to start the importation process. There are a lot of files that will be copied, so this process will take longer than the other types.

Don’t you love it when you screen shot a typo?

Applying LPs, LXPs, and FODs

To determine the correctly corresponding version of these objects, WIM Witch requires a WIM file to have been already selected on the Source WIM tab. This allows WIM Witch to autodetect which version and operating system to use, and modifies the options presented accordingly.

Click on the Customizations tab. This pane contains the LP, LXP, and FOD controls, and is now the home for the .Net 3.5 package option, OneDrive Client update, as well as Updates enablement.

I am really proud of how well this pane turned out. Darn near looks professional!

Check the box next to the item type to be included. The Language Packs and the Local Experience Packs will prompt with the familiar Grid View windows, allowing the user to select which of the previously imported packages will be used.

Go get it!

The Features On Demand selection button provides a list of the Windows Capabilities for the given Window Version. Select the Demanded Features needed.

With all of the options selected for, it should look something like this:

Ready to be made so.

From this point, the selected LPs, LXPs, and FODs are ready and will be injected during the build process. They are now the first packages to be processed by WIM Witch, with Software Updates coming later in the process.

How cool is this?

The .Net, OneDrive, and Updates check boxes on the Customization tabs provide the same functionality as they did when the resided in their previous locations.

Known Bugs and FYIs

-I haven’t yet incorporated the new variables into the Save/Load functions, so any configurations created with LP, LXP, or FOD cannot be saved. This also impacts command line users as CLI functionality uses save files to generate WIMs. This missing functionality will be coming soon.

-The importation process for all three object types has very little error correction, and none regarding the files and folders it is importing. Ensure the correct folders are referenced during this process.

-I didn’t test with the 1809 and 1903 LP and FOD files as I didn’t have access to them. While I have made every effort to ensure proper functionality, I haven’t tested with the specific files myself. Please let me know if something goes sideways.

-Windows Server 2019 should work with this process, but I have not tested any of these functions with Server sources. Windows Server 2016 will not be made available as an option because the LXP changes were made with 1809 (see the next point).

-With the introduction of LXPs in 1809, I will not be supporting 1803 or earlier builds of Windows 10 and Server as I don’t have the time to build support for a deprecated process.

-The Grid View windows need to have titles added to them. For the time being, enjoy reading the code that generated the query that created the display you are selecting objects from. 😊

-The “Updates” tab has been renamed “Updates Store”. This tab still contains the OSDUpdate and OSDSUS module controls, as well as the Updates downloading functionality, but it no longer contains the “Enable Updates” check box. This all behaves like previous versions. I am really looking forward to overhauling the “Updates Store” tab in the future.

-The bug that caused some users issues with importing from ISO may be finally been rectified. I stumbled across the error while developing the new feature set and derived a solution. If you have had issues with this problem in the past, see if this build resolves it.

Let me know what  you think!

(2949)

Donna Ryan

Donna Ryan is a Principal Consulting Engineer with CDW Corporation's Integrated Technology Services Mobility practice. She began her formal IT career in 2011 as an Associate Engineer with CDW. Her primary skills are around System Center Configuration Manager, specifically operating system deployment, software update delivery, and application packaging. Having consulted hundreds of clients in a variety of industries, she has also delivered projects in multiple other Microsoft technologies such as Hyper-V and Remote Desktop Services. In 2016, she was awarded CDW’s Coworker of the Month for her leadership and dedication to a large and highly visible Windows 10 deployment project for a school district in the Pacific North West.  In 2018, Donna was invited to participate in Microsoft's Mini Enterprise Mobility MVP Summit, as well as the Microsoft CLIP event for the Windows 10 1809 rollout. Her passion for technology and the tech community is a driving force that keeps her exploring the latest and greatest.

22 comments

  • Hi Donna,
    I’m trying to add a language pack (en-US) and I received this :

    03/06/2020 11:41:42 Information – Applying lp.cab
    WARNING: Failed to add package C:\Users\girouma0\Desktop\WIM Witch\imports\Lang\Windows 10\1909\LanguagePacks\lp.cab
    WARNING: Add-WindowsPackage failed. Error code = 0x800f081e
    Add-WindowsPackage : Add-WindowsPackage failed. Error code = 0x800f081e
    At C:\Users\girouma0\Desktop\WIM Witch\WIMWitch.ps1:3806 char:5
    + Add-WindowsPackage -PackagePath $source -Path $mountdir | out-nul …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [Add-WindowsPackage], COMException
    + FullyQualifiedErrorId : Microsoft.Dism.Commands.AddWindowsPackageCommand

    Thus, when I add the the Windows 10 updates, I received the error : (I think this is because the architecture is WIM Witch\updates\Windows 10\1909\SSU\

    Get-ChildItem : Cannot find path ‘C:\Users\girouma0\Desktop\WIM Witch\updates\1909\SSU\’ because it does not exist.
    At C:\Users\girouma0\Desktop\WIM Witch\WIMWitch.ps1:1310 char:17
    + $Children = Get-ChildItem -Path $path

    Thank you!

    • I have a few questions, if you don’t mind.

      Language pack-

      Did you import your language packs using the import function in WIM Witch? I don’t recognize the file name “lp.cab”, so I am not sure how you obtained it or what it is. I would use the import mechanism and retrieve the LPs, LXPs, and FODs from the ISO you can get from the VLSC, then try again.

      Updates.

      That error occurs when the folder for that particular class of update doesn’t exist. Did you download updates prior to Making it So? WIM Witch doesn’t yet download updates during the build process, so its essential one downloads the updates prior.

  • Thank you very much for fixing the bug. I don’t get the error while selecting “Inject features on demand” for windows server 2019. It shows the list of options to choose from but it doesn’t show “ServerCore.AppCompatibility~~~~0.0.1.0” in the options. Except that, all the other options are visible.

    After “Rsat.WSUS.Tools~~~~0.0.1.0 “‘, it should display “ServerCore.AppCompatibility~~~~0.0.1.0” but it does not.

    Rsat.NetworkLoadBalancing.Tools~~~~0.0.1.0
    Rsat.RemoteAccess.Management.Tools~~~~0.0.1.0
    Rsat.RemoteDesktop.Services.Tools~~~~0.0.1.0
    Rsat.ServerManager.Tools~~~~0.0.1.0
    Rsat.Shielded.VM.Tools~~~~0.0.1.0
    Rsat.StorageMigrationService.Management.Tools~~~~0.0.1.0
    Rsat.StorageReplica.Tools~~~~0.0.1.0
    Rsat.SystemInsights.Management.Tools~~~~0.0.1.0
    Rsat.VolumeActivation.Tools~~~~0.0.1.0
    Rsat.WSUS.Tools~~~~0.0.1.0
    SNMP.Client~~~~0.0.1.0
    Tools.DeveloperMode.Core~~~~0.0.1.0
    Tools.DTrace.Platform~~~~0.0.1.0
    Tools.Graphics.DirectX~~~~0.0.1.0
    WMI-SNMP-Provider.Client~~~~0.0.1.0
    XPS.Viewer~~~~0.0.1.0

    • Thank you for finding this. I don’t have the Server specific FOD ISOs, so I used the Win10 set. I’ll update this and push out the fix tomorrow.

    • I put the fix in and released version 1.5.2

      You should get prompted to update on your next run. Thanks for point this out. It’s much appreciated!

      • Thank you for fixing this very very. It is very now perfectly. Thanks again.

  • Hi. Just wanted to throw this out there, that while trying to use this on Server 2016, I kept running into an error when trying to Import a wim from an ISO. Kept bugging out on line 2069.

    For some reason, when the ISO would get mounted, the devicepath property would be blank. On my Windows 10 and Server 2019 machines, it would have a value.

    Ended up having to change the line to:

    $iso = (Get-DiskImage -DevicePath ($isomount | Get-Volume).Path.trimend(‘\’)).DevicePath

    It’s ugly, but I couldn’t find another way to get the device path.

    Don’t know if this issue is just specific to Server 2016 or something that’s being caused by one of the lovely undocumented gpo’s my predecessor left behind. But for some reason it just seems to mount it in an unattached state on Server 2016. Figured I’d just throw up an fyi incase someone else ran into this on v 1.5.1

    • This bug has been haunting me since release. My guess is some policy is set that prevents mounting of images without drive letters.

      Thanks for submitting your workaround. 🙂

  • Thanks for this beautiful tool. I am trying to inject FoD for 2019 but getting the below error. I have already imported FOD ISO and mapped the Source WIM file. Could you advise? Thanks

    02/17/2020 10:43:13 Information – Edition selected: Windows Server 2019 SERVERDATACENTERCORE
    02/17/2020 10:43:17 Error – Source not found. Please import some Demanding Features and try again
    02/17/2020 10:43:19 Error – Source not found. Please import some Demanding Features and try again

    • I haven’t tested this on Windows Server, so there could be a bug.

      Do you have a path for the FOD’s at [WIM Witch Install Path]\imports\FODs\Windows Server\1809\

      And if so, are your FOD’s in there?

      • Yes the path exists and the FODs are imported.

        \imports\fods\Windows Server\2019

      • A fix for this bug has been added to version 1.5.1, which has now been released. Update WIM Witch and let me know if this solves it for you. Thank you so much for letting me know about the bug. 🙂

  • Trying to add a language experience pack, PS throws this error:
    Add-ProvisionedAppxPackage : A license file path was not specified.
    A license file must be specified when installing app packages (.appx). If a license file is not required, use the
    /SkipLicense option. For more information, see the help.
    At G:\wimwitch\WIMWitch.ps1:3443 char:5
    + Add-ProvisionedAppxPackage -PackagePath $file -LicensePath $licen …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [Add-AppxProvisionedPackage], COMException
    + FullyQualifiedErrorId : Microsoft.Dism.Commands.AddAppxProvisionedPackageCommand

    • If I were to guess, the importation of the LXP’s was not correct. IF you check the \wimwitch\imports\lang\Windows 10\[ver]\localexperiencepack folder, it should have subfolders. Each subfolder should be the language code (af-za am-et ar-sa, etc etc). Each subfolder should contain two files, an APPX and a License.xml.

      Let me know what you find out.

  • Fantastic work! everything worked intuitively on the first try. Even some of the bugs you describe were obvious to work around. I just used this last night after a full day of failing to get language packs in for China offices using OSDBuilder. I was able to do it manually ,but it takes a ton of time to organize the files and folders. Your tool was RIGHT on time! I have never been able to do language packs before this.

    • I am really happy WIM Witch worked for you. It’s a passion driven project, and comments like yours make all the effort worthwhile 🙂

Sponsors

Subscribe

Do you want to be notified of new posts on our site?

Please enter your email address below:

Categories

MSEndpointMgr.com use cookies to ensure that we give you the best experience on our website.