I'm experimenting very much ATM. - I had several problems with the permissions... but as I only want to extract some sort of files I don't care for my proof of concept. (took ownership and so on). One Change that has to be made is that the uncompressed Manifest files get included in the cab files. Not the encrypted ones like in the current situation. I checked on Win81 updates they are provided uncompressed. With uncompressed manifest files it is also possible to look into the packages like with CBS package inspector - compressed manifest cabed files will fail.
Ta for this insight. I did it the current way because moderate mentioned that the package handler itself works just fine with compressed files - oh, and because I'm lazy. Bonus edit: I'd never heard of CBS Package Inspector - brilliant! Thanks!
This path thing is so annoying... There are some bugs with cabarc and -p parameter. Without -p the cab files can fail if dism looks in the wrong folder (missing subfolders). But with the parameter the cabs always fail. I tried makecab with dff's but they also fail. Now I use expanded, plain folders... with nummeric names - Otherwise some packages fail. Thoose damn long folder/file names freaking me out... Will write more after a nap... 8:30 in the morning, haven't slept yet.
Yes, CABARC.EXE is pretty buggy, and probably uses ANSI file APIs (and is therefore prone to failure on long paths) as well. SUBST should help in those cases. All CBS packages need to use the -p switch, as we need to preserve the full folder structure. The package handler expects it, and goes postal if it isn't. The .CAB file handler built into Explorer actually lies about the structure of a cabinet, presenting all the files on one level - i.e. 'flat' view. It's not like that internally at all, hence why I use 7-Zip myself for viewing cabinets. Note that the -p and -P switches are two separate things, and I've never been able to convince -P to work properly. It would be nice if it did: I could make the script a bit simpler. Bonus new version: OP updated with new version (2013/10/22), which has a long, juicy changelog.
I will try to rename mainifest as packages as their assembly names and will see if this works. Than it should be an easy task for you to replace the names and do some fileoperations within your script. It should simplifie it a lot. EDIT: does not work.
Path not found was my fault.. But who can know that this cabarc has such silly parameters. It's really one of the worst syntax I've seen so far. -P works for me. I will share the details to you if needed. I wrote scripts for the extracted Folders (by your tool - no *.cab at the end) to decrypt manifest/replace and afterwards cab them. If the script running in some upper folder and subfolders contain the extracted packages than the path within the CAB contains also the path from the script which will cause dism to faul as the packages have unnecessary folder structure.
There is some 'problem' if updating MUM packages. e.g. Only Enterprise: Code: Microsoft-Windows-TerminalServices-Publishing-WMIProvider-Package~31bf3856ad364e35~x86~~6.3.9600.16384.mum Microsoft-Windows-TerminalServices-RemoteApplications-Client-Package~31bf3856ad364e35~x86~~6.3.9600.16384.mum Microsoft-Windows-TerminalServices-UsbRedirector-Package~31bf3856ad364e35~x86~~6.3.9600.16384.mum They all contain the resourcefolder (in all SKU editions) Code: x86_microsoft-windows-t..-deployment-package_31bf3856ad364e35_6.3.9600.16384_none_f36d64389f290e75 but this is just the "parent" or what it's called and shouldn't be in the packagefolder/cab. Some kind of check would be helpfull but I guess it would be too much work....
There are several Problems with MUMs that contain drivers. e.g. (Enterprise only): Code: Microsoft-Windows-RemoteFX-VM-Setup-Package.mum The content of the Package Microsoft-Windows-RemoteFX-VM-Setup-Package.mum: Code: <?xml version='1.0' encoding='utf-8' standalone='yes'?> <assembly xmlns="urn:schemas-microsoft-com:asm.v3" copyright="Copyright (c) Microsoft Corporation. All Rights Reserved." description="Windows Server RemoteFX VM Components" displayName="Windows Server RemoteFX VM Components" manifestVersion="1.0" supportInformation="http://support.microsoft.com"> <assemblyIdentity buildType="release" language="neutral" name="Microsoft-Windows-RemoteFX-VM-Setup-Package" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" version="6.3.9600.16384" versionScope="nonSxS"/> <package identifier="RDVGGuest" releaseType="Update" restart="required"> <update name="INF_rdvgwddm"> <driver inf="rdvgwddmdx11.inf" ranking="force"> <assemblyIdentity buildType="release" language="neutral" name="rdvgwddmdx11.inf" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" type="driverUpdate" version="6.3.9600.16384" versionScope="nonSxS"/> </driver> </update> <update description="Microsoft-Windows-RemoteFX-Synth3dVsc-IC-Package" displayName="Microsoft-Windows-RemoteFX-Synth3dVsc-IC-Package" name="Microsoft-Windows-RemoteFX-Synth3dVsc-IC-Package"> <package contained="false" integrate="hidden"> <assemblyIdentity buildType="release" language="neutral" name="Microsoft-Windows-RemoteFX-Synth3dVsc-IC-Package" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" version="6.3.9600.16384"/> </package> </update> <update name="RemoteFX clientVM and UMTS files and regkeys"> <component> <assemblyIdentity buildType="release" language="neutral" name="microsoft-windows-RemoteFX-clientVM-files-regkeys-deployment" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" version="6.3.9600.16384" versionScope="nonSxS"/> </component> </update> <update name="INF_RDLSBusCBS"> <driver inf="rdlsbuscbs.inf" ranking="force"> <assemblyIdentity buildType="release" language="neutral" name="rdlsbuscbs.inf" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" type="driverUpdate" version="6.3.9600.16384" versionScope="nonSxS"/> </driver> </update> </package> </assembly> The manifest relates to rdvgwddmdx11.inf and rdlsbuscbs.inf. They aren't included in the extraction process of the script. - But they should, otherwise the package will fail while import. The searched manual (by hand) found some matching manifests and folders. Code: x86_rdvgwddmdx11.inf.resources_31bf3856ad364e35_6.3.9600.16384_en-us_177e726ce975284c x86_rdvgwddmdx11.inf-languagepack_31bf3856ad364e35_6.3.9600.16384_en-us_b0f9fd8323c337c1 x86_rdvgwddmdx11.inf_31bf3856ad364e35_6.3.9600.16384_none_67e956b5e67052e4 x86_rdlsbuscbs.inf_31bf3856ad364e35_6.3.9600.16384_none_aca4bf0cbea8d624 ... in this paricular example the two manifests Code: x86_rdvgwddmdx11.inf_31bf3856ad364e35_6.3.9600.16384_none_67e956b5e67052e4 x86_rdlsbuscbs.inf_31bf3856ad364e35_6.3.9600.16384_none_aca4bf0cbea8d624 should be included in this neutral (~none~) package. I other 2 language-related files should go into Code: Microsoft-Windows-RemoteFX-VM-LanguagePack I haven't foundt matching language files for rdlsbuscbs.inf ... language resources are optional and so I guess they don't exisits.
Cool. will test it within the next days. Damn I love your script. No whoopsie at all Thanks for adding the function!
you may should update the title with new date. known bug: resources from post #47 is not fixed (yet?)
Maybe it's ready for a GUI now, are all the command line switches documented. Seems easy enough to filter for .mum files in my file select dialog (and Open dialog to this folder C:\Windows\servicing\Packages for easy Mum picking) Code: Aunty Mel's Cheap And Nasty SxS Package Extractor, 2013/10/22 Copyright (C) 2012-2013 Melinda Bellemore. All rights reserved. CSCRIPT.EXE SXSEXTRACT.VBS [/?,/H,/HELP] [/DEBUG,/V] </ONLINE|/IMAGE:<folder>> [/INCLUDERES] [/VICIOUSHACKS] <source>.mum [<target>[.cab]] Parses a Windows Side-by-Side package manifest file, chases up all the references, and copies all the files associated with the package. /?,/H,/HELP Display this help text. /DEBUG,/V Enable verbose debug output. /ONLINE Uses %SYSTEMROOT% (usually C:\Windows) as the root folder to search for associated files. /IMAGE:<folder> Uses <folder> as the root folder to search for associated files instead. /INCLUDERES Extract MUI resources as well, for packages that don't have associated language packs. /VICIOUSHACKS Activates a couple of hacks to the script, for extracting 'difficult' packages, such as the TFTP client. <source>.mum Specifies a package manifest file. Wildcards are not permitted. <target>[.cab] Specifies the target folder for extracted files. If the extension '.cab' is specified, the script will call CABARC.EXE to create a cabinet of the extracted files. This script requires both SXSEXTRACT.EXE and CABARC.EXE, either in the current folder or on the system PATH, for full functionality. Confirm SXSEXTRACT.EXE is typo of SXSEXPAND.EXE and not another file I need to track down. Confirm /vicioushacks controls all the syntax of sxsexpand.exe and I only need to front-end the VBS.
Here is a beta-release. Supports only '/VICIOUSHACKS /ONLINE' but it seemed to create me an ADOBE.cab package on the first try from a 2012 R2 VM. FYI, it also copies the command to your clipboard in case you want to edit via notepad (add debug or other options) instead of using the 'Run' button. Package is created in same directory as .exe. Second textbox defaults to mum renamed as cab. Edits to the second textbox aka cab field are updated in the command / clipboard immediately.
Sorry peeps, had (another!) busy week! Yes, it is. Since it's referenced in the .manifest file tree, it's extracted. It would be too much work to write a parser to sort these sorts of files out - too much risk of deleting other files that might be needed. I recommend the human touch: delete files you're sure won't be needed yourself. Bonus query: Was this extraction done with or without the /VICIOUSHACKS switch? If it was, try again without it. It may be matching an assembly with the -Package suffix that it shouldn't. I tried! Up until the latest update of the OP, the thread title changed along with the OP title, but not this time, no matter how many times I edit it and save it. Confirmed - all command-line switches are documented. Confirmed, and whoopsie - I'll have to fix that in the next version. Sort-of confirmed: SxS File Expander's syntax is very simple (basically just SXSEXPAND <source> <dest>), and it's the script that selects files for expansion, not SXSEXPAND.EXE. So yes, you only need to wrap the script.
After certain time (1 month I think), its impossible for normal user to change the thread name. Only moderator/admin can do it. So its better to give a generic name.
When I get chance, next version should offer choice image vs online, have a button to mount/dismount images and will modify mount path / packages folder on fly. Spoiler Need to impersonate 'system' for certain packages apparently. Will use either PSRussinovich or devxexec to spawn the cscript process. Also add Radio buttons for debug, imageres and vicioushacks.
With similar named files, how do I tell the program to pick the correct one, for instance I show 8 mum's for SRT. Should it grab the one with the shortest name thinking it will be the highest in the hierarchy. WinPE-SRT-Package~31bf3856ad364e35~x86~~6.3.9600.16384.mum Code: WinPE-SRT-Package-shell~31bf3856ad364e35~amd64~en-US~6.3.9600.16384.mum WinPE-SRT-Package-shell~31bf3856ad364e35~amd64~~6.3.9600.16384.mum WinPE-SRT-Package-TouchKeyboard~31bf3856ad364e35~amd64~en-US~6.3.9600.16384.mum WinPE-SRT-Package-TouchKeyboard~31bf3856ad364e35~amd64~~6.3.9600.16384.mum WinPE-SRT-Package-windows~31bf3856ad364e35~amd64~en-US~6.3.9600.16384.mum WinPE-SRT-Package-windows~31bf3856ad364e35~amd64~~6.3.9600.16384.mum WinPE-SRT-Package~31bf3856ad364e35~amd64~en-US~6.3.9600.16384.mum Does shortest name = master package ??? WinPE-SRT-Package~31bf3856ad364e35~amd64~~6.3.9600.16384.mum
Little note: i tried devxexec with /user:system, but that doesn't allow me to execute sxsextract.vbs successfully i tried it with /user:TrustedInstaller, but it gives me error and doesn't start. so i prefer and i actually use (RunasSystem.exe + RunFromToken.exe): Code: net start trustedinstaller %windir%\system32\runassystem.exe "%windir%\system32\runfromtoken.exe trustedinstaller.exe 1 cmd" this gives me Full Unrestricted Access