Windows 7 Embedded Standard Package "Subconfiguration"

Discussion in 'Windows Embedded' started by Avexrion, Aug 26, 2015.

  1. Avexrion

    Avexrion Guest

    #1 Avexrion, Aug 26, 2015
    Last edited by a moderator: Aug 26, 2015
    Compared to regular Windows 7 without WAIK, Embedded 7 Standard is a godsend. However, I am curious if you can configure the packages further during an install.

    I have narrowed down a set of ~30 or so feature set packages needed for a fairly functional install. Only thing is, this is still not "granular" for my needs and there are still small items included I have absolutely no need for.

    Examples of this might be the "Network and Sharing Center" package including "Homegroup," or the "Accessories" package including "Gadgets." These are included alongside the things I need in the cabinet files, and I see they have their own manifests.

    The ICE toolkit does not have anything that lets you configure and remove these smaller subpackages in the feature packs themselves (which I would expect.) However, there are some vague hints that you can remove or disable smaller features in the configuration file (or autounattend.xml.)

    Normally, packages are added during servicing with "package action="install"." There are hints though about using other versions of "action" like "stage," or "configure" along with a permanence setting. Therefore, it seems like you can use a variation of the package installation option to remove or prevent smaller named features.

    Only issue is, I have found very little information on this. I'd post some links, but this forum does not let me post them...

    Anyone have some experience with subconfiguring these packages under Windows 7 Embedded Standard? It would be great to get rid of some of these useless features without compromising the things I need. I'd rather not resort to scripting like "setupcomplete.cmd."
     
  2. KNARZ

    KNARZ MDL Addicted

    Oct 9, 2012
    895
    482
    30
    Unfortunatly there are no official ways to reduce the (cab) packages.
    you can try/use tweak_wim_install (unhide pakages, than you maybe able to remove gadgets kind of "official" as you use dism to remove the package) but i'm not sure if it works.
    the action task (at least "remove") will throw errors afai remember... something with "only owner can remove pakages" this could be related to the owner key within the components store (tweak_wim_install will handle it for you) and so on... the dependencies may continue.

    I have/had many plans on this topic in generall but I don't find the time as this is a huge topic.
     
  3. Avexrion

    Avexrion Guest

    Thanks for the response. Yeah, I had the vague feeling this was not going to be a simple procedure. I just wish Microsoft would release a standard version of Windows that we could fully 100% configure what was included (aka, an advanced mode with no support.)

    I understand charging more for more features, but what about the same for the potential of less features? Getting tempted at this point to just make my own distribution of Linux... it's just so much work though.
     
  4. Avexrion

    Avexrion Guest

    #4 Avexrion, Oct 2, 2015
    Last edited by a moderator: Oct 3, 2015
    (OP)
    I've actually been investigating this a bit more, and making a bit of progress.

    The first step I am taking here is integrating all of the required packages normally installed via autounattend.xml, and adding them to install.wim directly via DISM. You then remove the package install lines from the servicing section, and .cabs from the offlineservicing directory. This works great for the most part, but the hurdle I am experiencing now is a "failed to open distribution share" message if you remove all the packages.

    Ironically, if you just leave one, this does not actually happen. It also doesn't even matter which single package either. I even tried fudging this by creating an empty blank.cab, and told autounattend to install this as a feature pack. It got past the distribution share error, but of course failed to install as the .cab was not something valid to install.

    It looks like this might be related to calculating the amount of total space for an install by looking at the entire distribution share on disk (if it exists.) By installing packages, this seems to initialize some sort of variable allowing it to inspect the directory... but if there are no packages to install, this never seems to get set and it complains. There should be a way to set or bypass this check by setting something in the autounattend.xml, I just don't know what.

    Aside from this, I need to see if I can only install part of a .cab feature pack using DISM. It looks like you can only install a full package, or remove one from the install.wim.
     
  5. KNARZ

    KNARZ MDL Addicted

    Oct 9, 2012
    895
    482
    30
    #5 KNARZ, Oct 3, 2015
    Last edited: Oct 3, 2015
    Sry I don't understand what your approach is good for, what is the benefit?
    If you don't add a feature pack windows setup shouldn't complain anyway. You may just missed the servicing tag (required, at least with just one line as: <servicing/>)

    Hm if you want I to remove subpackages: you can try my unpoofen approach:
    Best way to may uninstall (the correct / faked way) subpackaged with dism would be:

    Create a small image, take a snapshot (registry and files)
    add a new package to the online image (a very small package e.g. branding-embedded-neutral-package)
    create a second snapshot and compare the images

    than you know the structure of a main package.
    the challenge now is to create a new/fake main package (not a cab, i think just registry info and maybe a mum file) that links to the manifest (sub-package) you want to remove.
    than you remove the placeholder/fake main package with dism /remove-package.

    than your sub-package/manifest should be removed by creating a temporary main dummy package.

    if you than also automate this with a script or something you can (if it works) easily remove all sub packages you want.
    the whole approach is based on not verifying files while remove, but why should there be some verification while remove?!??!


    maybe you don't need to create a mum file but i guess you have, than you copy one easy mum and just edit the critical parts (from original mum with the info that includes the package you want to remove)
     
  6. Avexrion

    Avexrion Guest

    Just wanted to condense all of the feature packs into the install.wim for simplicity along with some of the updates. This speeds up the install a bit as well, and reduces the total image size as the .wim file seems to have a bit of compression to it.

    What basically is going on is under the <servicing> tag, I deleted all of the <package action="install">s as I already integrated all of these packages. Therefore, installing them is not necessary (and the packages are removed under the "AutoUnattend_Files" directory as well.) Didn't miss the </servicing> tag at the end of the block either, and I have tried completely deleting the entire block, leaving it with a single dummy <package action="configure"> or just leaving it as <servicing></servicing>.

    Simply put, if you have absolutely no packages to install, the WinPE environment stops the installation as it seems to want to find the "D:\DS" directory for the distribution share (hence the above message.) However, if you have just one, it works perfectly fine. That's why I tried the dummy .cab trick as it seems to initialize something and make it work (didn't go nearly as far as you described to actually make it functional.) I no longer have any packages to install, they were all inserted into the install.wim (so the work is done.)

    There should just be a way to tell WinPE to just not bother with packages and get to the regular install dialog box (like some sort of flag or variable to set in the autounattend.xml.) Otherwise, it complains about the DS directory or the "DirectoryShare" variable not being correctly set. It just sounds like the <package action="install"> somehow initializes something.

    Just read the part about the subpackage idea, that's probably the best way to do it. Once I get some free time, I'll mess around with that.
     
  7. KNARZ

    KNARZ MDL Addicted

    Oct 9, 2012
    895
    482
    30
    I understand what you do but this isn't the deal about WES. This works for 1 customer or 1 project but not for more.
    Sidenote: I'm not completly sure if <servicing></servicing> and <servicing/> is completly identical for Windows Setup. I guess it is but I'm not sure.

    If you add lp.cab as the last package to the core wim than you may can use boot.wim from regular windows setup.
    but from my POV this all doesn't make much sense but I won't judge.
     
  8. Avexrion

    Avexrion Guest

    #8 Avexrion, Oct 3, 2015
    Last edited by a moderator: Oct 3, 2015
    (OP)
    Yeah, lp.cab is usually what I left on there (which works just fine.)

    It's a strange procedure for sure, but the main reason I am trying to combine all of these packages into the install.wim is to create a dual boot autounattend.xml assisted install. Aka, you put the DVD in, select x86 or x64, and install the deployed version. If all the packages are installed, there is no worry about platform mismatch during the <servicing> section as there are none to look at (and if you include both x86 and x64 versions of the packages, it just complains about the packages being incorrect.)

    No packages, then there is no problem as you simply omit "processorArchitecture=" from the other sections that are agnostic towards either version, or have an x86 and a x64 version like described on pages like this: www . msfn . org/board/topic/141254-possible-to-make-an-autounattendxml-for-x86-x64-on-one-dvd/

    The embedded WinPE environment does indeed work with the x64 version via "imagex /export," it just does not play nice with multiple architectures in the <servicing> section...


    By the way, thanks for your responses. I very rarely get responses on more technical forums that actually read what I am trying to do. My process on this is a bit unorthodox, but at least you are not attacking me for it. This is appreciated.
     
  9. KNARZ

    KNARZ MDL Addicted

    Oct 9, 2012
    895
    482
    30
    #9 KNARZ, Oct 3, 2015
    Last edited: Oct 3, 2015
    I have 1 UFD with 2 DS and can provide every WES Image I want. x86 or amd64 doesn't matter. ;)
    You only have to customize the XML file(s) the right way. ;)
     
  10. Avexrion

    Avexrion Guest

    #10 Avexrion, Oct 3, 2015
    Last edited by a moderator: Apr 20, 2017
    (OP)
    Is there a way to determine what the processor architecture at autounattend.xml runtime? Aka, create something like:

    Code:
            <package action="install">
                <assemblyIdentity name="WinEmb-Interface-Explorer" version="6.1.7600.16385" processorArchitecture="%processor_architecture%" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" />
                <source location="%configsetroot%\AutoUnattend_Files\offlineServicing\%processor_architecture%~winemb-interface-explorer~~~~6.1.7600.16385~1.0\WinEmb-Interface-Explorer.cab" />
                <ew:packageInfo releaseType="Feature Pack" customInfoVersion="1.0" />
            </package>
     
  11. KNARZ

    KNARZ MDL Addicted

    Oct 9, 2012
    895
    482
    30
    I'm not sure if %processor_architecture% wouldn't really work. - There is some env. variable support in XML and from Setup. But than the variable depends on the boot.wim (x86/amd64) you would load. Have you tried it?

    If you want more customizations in WinPE I would recommend to use some scripted installation.

    My workspace is more designed to have full custom images, there is one decision for the architecture and no switching with identical packages. And if, i would have 2 unattend files which are identical except the architecture. If I would have more projects that wanted to switch architecture I would create some kind auf pre-script that (if %process_architecture% won't work) reads "my" generalized XML and replaces some placefiller with targeted architecture.
     
  12. Avexrion

    Avexrion Guest

    Yeah, tried it and it didn't work. Oddly enough, leaving processorArchitecture="" seems to make it work, although I get hit in the face about "<DistributionShare>" not being correctly configured again... I'm sure there is some sort of way to get around that that I'll figure out years from now...

    Basically, I have a WIN7EMB32 and a WIN7EMB64 image set which are just that - identical except for the processorArchitecture. Do you have some sort of custom bootloader that is letting you switch prior to going into WinPE? Otherwise, I am not seeing how this is possible.

    I'd love a single disk I could just put in, select whether I wanted x86 or x64, and just install from there. Not sure how you can have a universal package set that works on both architectures, or two autounattend.xmls without heavily modifying something :g:.

    Might just stick to two disks after all, they at least work with little fuss, lol.
     
  13. KNARZ

    KNARZ MDL Addicted

    Oct 9, 2012
    895
    482
    30
    Send you a PM as I don't want to publish all details. ;)