This is looking more and more like a file system permission issue to me. VBScript, born in the days on Windows 9x, really has no idea what an ACL is, and therefore just stops with 'File not found' or 'Path not found' if it can't read (or write) something. I further suspect that's the underlying issue abbodi1406 is having here, too. The first person to say 'but I'm an administrator!' will be glowered at comprehensively. Administrator is not a particularly powerful or interesting account - LocalSystem, on the other hand... Anyway, here's a test version where I've wrapped the Source.Copy call in an extremely simple exception handler, and /DEBUG shows the error code after each copy. If it provides something sensible - I've found the VBScript Err object to be extremely unreliable, often saying success when the call didn't work (or worse) - I can convert that into a fatal error for the next version.
Same command, better result. Now the folder contains additional 2 manifest files. No Errors, but I guess there are missing files (empty subfolder) Debug: Code: Microsoft (R) Windows Script Host, Version 5.8 Copyright (C) Microsoft Corporation 1996-2001. Alle Rechte vorbehalten. Aunty Mel's Cheap And Nasty SxS Package Extractor, 2013/09/29.TEST Copyright (C) 2012-2013 "SuperBubble". All rights reserved. [ Error ] SxS File Expander not available - can't access compressed files. [ Error ] MS Cabinet Tool not available - can't create cabinet files. [ Error ] Output path not specified, assuming: Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Package~31bf3856ad364e35~amd64~~6.1.7601.17514 [Information] Loading manifest: C:\Windows\servicing\Packages\Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Package~31bf3856ad364e35~amd64~~6.1.7601.17514.mum Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Package ------------------------------------------------------------------------------- Version: 6.1.7601.17514 Architecture: amd64 Language: neutral Public key token: 31bf3856ad364e35 [Information] Finding possible associated assembly folders. [ Debug ] Matching wildcard: C:\Windows\WinSxS\amd64_Microsoft-Windows-S..KU-Ultimate-Package_31bf3856ad364e35_6.1.7601.17514_none_???????????????? [ Debug ] Executing: CMD.EXE /C DIR /A /B "C:\Windows\WinSxS\amd64_Microsoft-Windows-S..KU-Ultimate-Package_31bf3856ad364e35_6.1.7601.17514_none_????????????????" > "C:\Users\ADMINI~1\AppData\Local\Temp\rad729E5.tmp" [ Debug ] Vicious hack: add '-Package' to assembly name. [ Debug ] Matching wildcard: C:\Windows\WinSxS\amd64_Microsoft-Windows-S..ate-Package-Package_31bf3856ad364e35_6.1.7601.17514_none_???????????????? [ Debug ] Executing: CMD.EXE /C DIR /A /B "C:\Windows\WinSxS\amd64_Microsoft-Windows-S..ate-Package-Package_31bf3856ad364e35_6.1.7601.17514_none_????????????????" > "C:\Users\ADMINI~1\AppData\Local\Temp\rad9A293.tmp" [ Debug ] Really vicious hack: remove '-Package' from assembly name. [ Debug ] Matching wildcard: C:\Windows\WinSxS\amd64_Microsoft-Windows-S..ponent-SKU-Ultimate_31bf3856ad364e35_6.1.7601.17514_none_???????????????? [ Debug ] Executing: CMD.EXE /C DIR /A /B "C:\Windows\WinSxS\amd64_Microsoft-Windows-S..ponent-SKU-Ultimate_31bf3856ad364e35_6.1.7601.17514_none_????????????????" > "C:\Users\ADMINI~1\AppData\Local\Temp\rad6D453.tmp" [ Debug ] Wildcard match: C:\Windows\WinSxS\amd64_microsoft-windows-s..ponent-sku-ultimate_31bf3856ad364e35_6.1.7601.17514_none_f7e6a2aa970662b7 [Information] Found associated assembly folder: amd64_microsoft-windows-s..ponent-sku-ultimate_31bf3856ad364e35_6.1.7601.17514_none_f7e6a2aa970662b7 [ Debug ] Checking XML path for assembly references: //assembly/dependency/dependentAssembly/assemblyIdentity [ Debug ] Checking XML path for assembly references: //assembly/package/update/package/assemblyIdentity [ Debug ] Checking XML path for assembly references: //assembly/package/update/component/assemblyIdentity [Information] Finding matching manifest for assembly reference: Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Deployment,31bf3856ad364e35,amd64,neutral,6.1.7601.17514 [ Debug ] Trying file name: C:\Windows\Servicing\Packages\Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Deployment~31bf3856ad364e35~amd64~~6.1.7601.17514.mum [ Debug ] Trying wildcard: C:\Windows\WinSxS\Manifests\amd64_Microsoft-Windows-S..Ultimate-Deployment_31bf3856ad364e35_6.1.7601.17514_none_????????????????.manifest [ Debug ] Matching wildcard: C:\Windows\WinSxS\Manifests\amd64_Microsoft-Windows-S..Ultimate-Deployment_31bf3856ad364e35_6.1.7601.17514_none_????????????????.manifest [ Debug ] Executing: CMD.EXE /C DIR /A /B "C:\Windows\WinSxS\Manifests\amd64_Microsoft-Windows-S..Ultimate-Deployment_31bf3856ad364e35_6.1.7601.17514_none_????????????????.manifest" > "C:\Users\ADMINI~1\AppData\Local\Temp\rad635A8.tmp" [ Debug ] Wildcard match: C:\Windows\WinSxS\Manifests\amd64_microsoft-windows-s..ultimate-deployment_31bf3856ad364e35_6.1.7601.17514_none_c12df7b201462ce1.manifest [Information] Loading manifest: C:\Windows\WinSxS\Manifests\amd64_microsoft-windows-s..ultimate-deployment_31bf3856ad364e35_6.1.7601.17514_none_c12df7b201462ce1.manifest [ Debug ] Manifest matches parent assembly reference. Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Deployment ------------------------------------------------------------------------------- Version: 6.1.7601.17514 Architecture: amd64 Language: neutral Public key token: 31bf3856ad364e35 [Information] Finding possible associated assembly folders. [ Debug ] Matching wildcard: C:\Windows\WinSxS\amd64_Microsoft-Windows-S..Ultimate-Deployment_31bf3856ad364e35_6.1.7601.17514_none_???????????????? [ Debug ] Executing: CMD.EXE /C DIR /A /B "C:\Windows\WinSxS\amd64_Microsoft-Windows-S..Ultimate-Deployment_31bf3856ad364e35_6.1.7601.17514_none_????????????????" > "C:\Users\ADMINI~1\AppData\Local\Temp\radECC16.tmp" [ Debug ] Vicious hack: add '-Package' to assembly name. [ Debug ] Matching wildcard: C:\Windows\WinSxS\amd64_Microsoft-Windows-S..-Deployment-Package_31bf3856ad364e35_6.1.7601.17514_none_???????????????? [ Debug ] Executing: CMD.EXE /C DIR /A /B "C:\Windows\WinSxS\amd64_Microsoft-Windows-S..-Deployment-Package_31bf3856ad364e35_6.1.7601.17514_none_????????????????" > "C:\Users\ADMINI~1\AppData\Local\Temp\rad30594.tmp" [Information] Couldn't find any associated assembly folders. [ Debug ] Checking XML path for assembly references: //assembly/dependency/dependentAssembly/assemblyIdentity [Information] Finding matching manifest for assembly reference: Microsoft-Windows-Security-SPP-Component-SKU-Ultimate,31bf3856ad364e35,amd64,neutral,6.1.7601.17514 [ Debug ] Trying file name: C:\Windows\Servicing\Packages\Microsoft-Windows-Security-SPP-Component-SKU-Ultimate~31bf3856ad364e35~amd64~~6.1.7601.17514.mum [ Debug ] Trying wildcard: C:\Windows\WinSxS\Manifests\amd64_Microsoft-Windows-S..ponent-SKU-Ultimate_31bf3856ad364e35_6.1.7601.17514_none_????????????????.manifest [ Debug ] Matching wildcard: C:\Windows\WinSxS\Manifests\amd64_Microsoft-Windows-S..ponent-SKU-Ultimate_31bf3856ad364e35_6.1.7601.17514_none_????????????????.manifest [ Debug ] Executing: CMD.EXE /C DIR /A /B "C:\Windows\WinSxS\Manifests\amd64_Microsoft-Windows-S..ponent-SKU-Ultimate_31bf3856ad364e35_6.1.7601.17514_none_????????????????.manifest" > "C:\Users\ADMINI~1\AppData\Local\Temp\radAD7F2.tmp" [ Debug ] Wildcard match: C:\Windows\WinSxS\Manifests\amd64_microsoft-windows-s..ponent-sku-ultimate_31bf3856ad364e35_6.1.7601.17514_none_f7e6a2aa970662b7.manifest [Information] Loading manifest: C:\Windows\WinSxS\Manifests\amd64_microsoft-windows-s..ponent-sku-ultimate_31bf3856ad364e35_6.1.7601.17514_none_f7e6a2aa970662b7.manifest [ Debug ] Manifest matches parent assembly reference. Microsoft-Windows-Security-SPP-Component-SKU-Ultimate ------------------------------------------------------------------------------- Version: 6.1.7601.17514 Architecture: amd64 Language: neutral Public key token: 31bf3856ad364e35 [Information] Finding possible associated assembly folders. [ Debug ] Matching wildcard: C:\Windows\WinSxS\amd64_Microsoft-Windows-S..ponent-SKU-Ultimate_31bf3856ad364e35_6.1.7601.17514_none_???????????????? [ Debug ] Executing: CMD.EXE /C DIR /A /B "C:\Windows\WinSxS\amd64_Microsoft-Windows-S..ponent-SKU-Ultimate_31bf3856ad364e35_6.1.7601.17514_none_????????????????" > "C:\Users\ADMINI~1\AppData\Local\Temp\rad10AD2.tmp" [ Debug ] Wildcard match: C:\Windows\WinSxS\amd64_microsoft-windows-s..ponent-sku-ultimate_31bf3856ad364e35_6.1.7601.17514_none_f7e6a2aa970662b7 [Information] Found associated assembly folder: amd64_microsoft-windows-s..ponent-sku-ultimate_31bf3856ad364e35_6.1.7601.17514_none_f7e6a2aa970662b7 [ Debug ] CopyList key already exists: C:\Windows\WinSxS\amd64_microsoft-windows-s..ponent-sku-ultimate_31bf3856ad364e35_6.1.7601.17514_none_f7e6a2aa970662b7 [ Debug ] Vicious hack: add '-Package' to assembly name. [ Debug ] Matching wildcard: C:\Windows\WinSxS\amd64_Microsoft-Windows-S..KU-Ultimate-Package_31bf3856ad364e35_6.1.7601.17514_none_???????????????? [ Debug ] Executing: CMD.EXE /C DIR /A /B "C:\Windows\WinSxS\amd64_Microsoft-Windows-S..KU-Ultimate-Package_31bf3856ad364e35_6.1.7601.17514_none_????????????????" > "C:\Users\ADMINI~1\AppData\Local\Temp\rad19EB2.tmp" [Information] Couldn't find any associated assembly folders. [ Debug ] Checking XML path for assembly references: //assembly/dependency/dependentAssembly/assemblyIdentity [ Debug ] Checking XML path for assembly references: //assembly/package/update/package/assemblyIdentity [ Debug ] Checking XML path for assembly references: //assembly/package/update/component/assemblyIdentity [ Debug ] Checking XML path for assembly references: //assembly/package/update/package/assemblyIdentity [ Debug ] Checking XML path for assembly references: //assembly/package/update/component/assemblyIdentity [Information] Starting package creation. Number of files/folders: 5 [Information] Created output folder: C:\Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Package~31bf3856ad364e35~amd64~~6.1.7601.17514 [Information] Copying file: C:\Windows\servicing\Packages\Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Package~31bf3856ad364e35~amd64~~6.1.7601.17514.cat --> C:\Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Package~31bf3856ad364e35~amd64~~6.1.7601.17514\update.cat [ Debug ] Obj.Copy returned: 0 [Information] Copying file: C:\Windows\servicing\Packages\Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Package~31bf3856ad364e35~amd64~~6.1.7601.17514.mum --> C:\Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Package~31bf3856ad364e35~amd64~~6.1.7601.17514\update.mum [ Debug ] Obj.Copy returned: 0 [Information] Copying folder: C:\Windows\WinSxS\amd64_microsoft-windows-s..ponent-sku-ultimate_31bf3856ad364e35_6.1.7601.17514_none_f7e6a2aa970662b7 --> C:\Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Package~31bf3856ad364e35~amd64~~6.1.7601.17514\amd64_microsoft-windows-s..ponent-sku-ultimate_31bf3856ad364e35_6.1.7601.17514_none_f7e6a2aa970662b7 [ Debug ] Obj.Copy returned: 0 [Information] Copying file: C:\Windows\WinSxS\Manifests\amd64_microsoft-windows-s..ultimate-deployment_31bf3856ad364e35_6.1.7601.17514_none_c12df7b201462ce1.manifest --> C:\Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Package~31bf3856ad364e35~amd64~~6.1.7601.17514\amd64_microsoft-windows-s..ultimate-deployment_31bf3856ad364e35_6.1.7601.17514_none_c12df7b201462ce1.manifest [ Debug ] Obj.Copy returned: 0 [Information] Copying file: C:\Windows\WinSxS\Manifests\amd64_microsoft-windows-s..ponent-sku-ultimate_31bf3856ad364e35_6.1.7601.17514_none_f7e6a2aa970662b7.manifest --> C:\Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Package~31bf3856ad364e35~amd64~~6.1.7601.17514\amd64_microsoft-windows-s..ponent-sku-ultimate_31bf3856ad364e35_6.1.7601.17514_none_f7e6a2aa970662b7.manifest [ Debug ] Obj.Copy returned: 0
OK, the only idea I have left is that all On Error statements clear the Err object; the VBScript references clearly state that On Error Resume Next clears the Err object, but it leaves ambiguous whether On Error Goto 0 does the same. Let's test that. Load sxsextract_test.vbs into your favourite text editor, and scroll down to line 681. You'll find these four statements: Code: On Error Resume Next Source.Copy FSO.BuildPath(Folder.Path, CopyItems(Loop1)) On Error GoTo 0 Call LogDebug("Obj.Copy returned: " & CStr(Err.Number)) Swap the third and fourth lines (lines 683 and 684), so it reads: Code: On Error Resume Next Source.Copy FSO.BuildPath(Folder.Path, CopyItems(Loop1)) Call LogDebug("Obj.Copy returned: " & CStr(Err.Number)) On Error GoTo 0 Save the file, re-run with debug output. If it still says Obj.Copy returned: 0 for the folder copy, it's (essentially) a bug in VBScript that can be worked around, but probably isn't worth the bother.
Same result. No errors, missing files. I tested with other package and it works. I don't understand why the subfolder is empty. It get's created but without any files. I searched in WinSXS the subfolder and found it with a few files. Why isn't it working? I don't get it... copying the folder within cmd was no problem. with my regular admin account. i also tried system account but with the same result.
OP updated with new version. The error handler around Source.Copy is in to stay, but I've made no attempt to fix the underlying problem... because, quite frankly, I don't know what it is. Oh Stannieman, where are you when I need you?
I think I've figured out what the underlying issue is: it appears to be, quite simply, 'path too long'. A bit of background: the file access APIs on Windows have been limited to paths shorter than 260 characters (known in the trade as MAX_PATH) going back to at least Windows 3.0. Of course, it made much more sense back then, when filenames were limited to 8.3 - and this limitiation still exists in the ANSI versions of the API calls, even on Windows 8.1. NT, however, has a way to circumvent it: you can use the Wide (that is, Unicode) API calls, and turn off path parsing with a special prefix to the file name or path parameter (explained at some length here at MSDN). Alas, I'm pretty sure this feature was not backported to Windows 9x. So, the VBScript Host, being a contemporary of Windows 9x, doesn't know (or probably even have access to) any NT tricks, and appears to just use those path-length-limited ANSI API calls. KNARZ was trying to extract the SPP Component package, and getting target paths that were slightly too long. I looked inside my Windows 7 AMD64 ISO, and ascertained that the following is the longest target path generated if you try to extract the SPP Component package: Code: C:\Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Package~31bf3856ad364e35~amd64~~6.1.7601.17514\amd64_microsoft-windows-s..ponent-sku-ultimate_31bf3856ad364e35_6.1.7601.17514_none_f7e6a2aa970662b7\Security-SPP-Component-SKU-Ultimate-TIMEBASEDSUB-ul-oob.xrm-ms This has a length of 266 bytes, just blowing MAX_PATH. There are quite a few other files in that SxS assembly folder that will generate target paths in the 261-264 byte range. I failed to notice this on my computer, because I'm running Windows 8 Pro i386, where the following is the longest path in my SPP Component package: Code: C:\Microsoft-Windows-Security-SPP-Component-SKU-Professional-Package~31bf3856ad364e35~x86~~6.2.9200.16384\x86_microsoft-windows-s..nt-sku-professional_31bf3856ad364e35_6.2.9200.16384_none_476f2fc01e78d3a1\Professional-Volume-CSVLK-1-ul-oob-rtm.xrm-ms This is only 250 bytes: while 'Professional' is slightly longer than 'Ultimate', 'x86' is two bytes shorter than 'AMD64', so it balances out. But the files contained in the SxS assembly folder have noticeably shorter filenames, with Microsoft appearing to throw away the 'Security-SPP-Component-SKU' prefix between Windows 7 and Windows 8. So a simple solution presents itself: specify a nice, short target path, instead of just letting the script construct one from the (no doubt long) package name: Code: C:\>cscript.exe sxsextract.vbs /online C:\Windows\Servicing\Packages\Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Package~31bf3856ad364e35~amd64~~6.1.7601.17514.mum C:\Output The real solution is for Microsoft to fix VBScript to use the Wide API file access calls. I'm not holding my breath for that one. Bonus edit: Those who are eagle-eyed will see why KNARZ could copy the files in from the command line successfully, after the script failed. I have no doubt he typed something like this: Code: C:\>cd "C:\Windows\WinSxS\amd64_microsoft-windows-s..ponent-sku-ultimate_31bf3856ad364e35_6.1.7601.17514_none_f7e6a2aa970662b7" C:\Windows\WinSxS\amd64_microsoft-windows-s..ponent-sku-ultimate_31bf3856ad364e35_6.1.7601.17514_none_f7e6a2aa970662b7>copy *.* "C:\Microsoft-Windows-Security-SPP-Component-SKU-Ultimate-Package~31bf3856ad364e35~amd64~~6.1.7601.17514\amd64_microsoft-windows-s..ponent-sku-ultimate_31bf3856ad364e35_6.1.7601.17514_none_f7e6a2aa970662b7" ... 'X' file(s) copied. None of the specified file names/paths were longer than MAX_PATH, so it worked. However, I just tried it with absolute path and file names, as I'm sure the VBScript Host (and therefore, my script) expands them to absolute paths during folder copies: Code: D:\long_folder_name_to_compensate>copy "C:\Windows\Winsxs\x86_microsoft-windows-s..nt-sku-professional_31bf3856ad364e35_6.2.9200.16384_none_476f2fc01e78d3a1\Professional-Volume-CSVLK-1-ul-oob-rtm.xrm-ms" "Microsoft-Windows-Security-SPP-Component-SKU-Professional-Package~31bf3856ad364e35~x86~~6.2.9200.16384\x86_microsoft-windows-s..nt-sku-professional_31bf3856ad364e35_6.2.9200.16384_none_476f2fc01e78d3a1\Professional-Volume-CSVLK-1-ul-oob-rtm.xrm-ms" The file name is too long. 0 file(s) copied.
Can you mountvol the winsxs folder to shorten the path. Or some sneaky "Net Use" to map the folder to a drive letter directly. Code: net use Z: \\MyComp\C$\Windows\winsxs Or take it the one step further, check path length and only replace paths if needed, as they are read from the decompressed .manifest and mount to each sub-folder. That or convert them to 8.3 paths.
Wrong end of proceedings, Ginger - it's the target path length that's the issue, not the source. The path to the WinSxS folder is nice and short (usually C:\Windows\WinSxS - only 18 characters) - the (default) target folder, if it's a package with a really long name, isn't - hence why a short target path (like C:\Output) works around it. I'm working (on and off) on an updated version that can spot paths that violate MAX_PATH, and exit with a fatal error. However, since I'm busy this weekend, it's slow going - a few minutes here and there while I'm waiting for a train or something, when I flop out my laptop. Now there's an idea with promise...
With output-path it seems to work pretty nice! very good job! New project could be to find a way to uninstall core packages that are not indexed nor hidden. like "Microsot-Windows-TrustedInstaller" i'm curious what would happen.
I just noticed - the changelog I've posted is wrong: it's not to help extracting Adobe Flash, it's to help extracting the TFTP client. Anyway, /VICIOUSHACKS turns on a little routine inside the script, that fiddles the SxS reference names a bit if it can't find a match. For example, inside the TFTP client .mum file, it references Microsoft-Windows-TFTP-Client-Deployment - but no such manifest exists! There is, however, a Microsoft-Windows-TFTP-Client-Deployment-Package (which, on my system, is 'x86_microsoft-windows-t..-deployment-package_31bf3856ad364e35_6.2.9200.16384_none_5b78ab9254f63df8' in assembly ID format), so when it can't find the referenced name, it tacks on -Package, tries again, matches that, and the script can get on with its life. Similarly, if a SxS reference ends in -Package, and it can't find any matches, it will chop -Package off the name, and try again. I recall adding this part of the hack to extract Adobe Flash, but having just looked at the .mum file, it isn't needed for that. All in all, it's a nasty, vicious hack. Hence the switch's name.
I want to try some thing.. but unfortunatly I'm running into problemes with MUI / en~us packages. - They all don't contain any files except mum, cat files. Also with some regular packages I run into some trouble (no files). I tried als to subst to shorten the path's - no success. Code: sxs.vbs /vicioushacks /image:Q: P:\XXX.mum W:\Output Q=W:\PRO\Windows P=Q:\servicing\packages /VICOUSHACK works also kind of good (better). Packages are MCE related (x86) you can try yourself to extract Microsoft-Windows-MediaCenter-Package-avcore.cab But over all it seems to be very close to final.
I can't find any assembly folder associated with that package - I've studied my WinSxS folder at length, and there's nothing that remotely matches the filename, or the checksum. I can't help but feel this is by design... but what a wacky design. However, every cloud has a silver lining: using SUBST is just plain brilliant. I considered it, but thought you needed Administrator privileges to use DefineDosDevice (which I'm pretty sure is how SUBST works). I think I'll be throwing away (most of) the latest version I've written.
I sent you the list i wanted to export as PM. Manifest: x86_microsoft-windows-m..e-avcore-deployment_31bf3856ad364e35_6.3.9600.16384_none_f0cd17f5cfb135c9.manifest En~Us Manifest "x86_microsoft-windows-m..oyment-languagepack_31bf3856ad364e35_6.3.9600.16384_en-us_4fb12d9208618c73.manifest" --> name "Microsoft-Windows-MediaCenter-Package-avcore-deployment-LanguagePack" I see that there are no files in this component. As there is no single entry in 'COMPONENTS' hive. So it looks like the script is working fine and I was wrong. But it's Microsoft non-sense --> empty component. But I guess this is for some overview / indexing.
Ta. Snooping around the servicing stack (my wuv Agent Ransack ), I found: Code: Microsoft-Windows-ProfessionalWMCEdition That appears to be the 'root package' for all of those - it is on my Windows 8 Pro computer, anyway. It references a lot of packages that aren't in your list, though - Windows Backup, Hyper-V, group policy client, .NET... the list goes on. So I tried to narrow it down, and got... Code: Microsoft-Windows-Editions-ProfessionalWMCEdition-Package This one nails nearly all of it in one shot: it appears to reference (of course) the *-Editions-ProfessionalWMC packages, *-Branding-ProfessionalWMC, *-Help-ClientUA, *-MediaCenter, and *-Anytime-Upgrade. In fact, the only ones it misses are *-Security-SPP-Component-SKU-ProfessionalWMC - and of course, the 'root' Microsoft-Windows-ProfessionalWMCEdition package. Perhaps you should extract those separately? Though I'm not sure you'd want to for the root package, and end up with half of Windows in your extract folder... The only problem I can forsee is that these packages don't appear to be DISM-friendly, as they aren't marked as 'feature packs' in the manifests. I could be wrong though - but if I'm not, you might be able to work some magic using PKGMGR.EXE. Yes, it's quite strange. The only sensible explanation I can think of is that, there was at some point in WMCs development - or in case there would be - MUI resources associated with the avcore package. So a manifest to reference them was allocated... but in the end there weren't, so rather than change the manifests (and have to re-test installation/deployment/activation of the feature), M$ just left the manifest pointing off into space.
Ahh okay. Thanks. I didn't look into the mum/manifest which packages might be included in some other package, like Microsoft-Windows-Editions-ProfessionalWMCEdition-Package. Next time I will do. - SPP Package is not integrated as this is licence not feature's related I guess --> Other department/devision within microsoft.
SUBST until I finish writing my version that does SUBST automatically - sorry, busy weekend turned into busy week(s)!