[Tutorial]Modify an offline msi installer for administrative install

[YumeYao]

Let me explain the issue first:

.NET 3.5 SP1 and its language pack are offline msi installers indeed. They are different than regular installers therefore once you use "msiexec.exe /a" to deploy it, the output dir is much bigger than before and both msi and cab files are still there. Even updated files are useless as the msi file is totally same as before so it only regard the cab file as a valid source.

This fact is severe.

1. you can't get patches applied because updated files are ignored by the msi file.(you can try installing user_hidden's dotnet 3.5 and check file version of %SYSTEMROOT%\Microsoft.NET\Framework\v3.5\NetFX3.5InstallPath_GAC\System.Data.Services.Client.dll, it should have been 3.5.30729.196 if updated, but in reality it is 3.5.30729.1)

2. size is bumped. the original msi and cab is still there, and new files are in, so the final size increases.

3. If you just keep the original msi and cab, without attempting administrative install, you should have all patches applied later by starting msp files. this will still result a big 7zipped file.

So finding a way to make it administrative-deployable is very helpful for reducing package size.

Solution:

**** This part needs some basic msi knowledges ****

To work out a solution, we must first understand how is an offline msi installer different from a regular one.

When I'm paying effort on removing the msi itself and source cab from the msi's file table, I find that no matter how "clean" I think I have done, the modified msi still doesn't work. So I realized the copying of the msi and the cab must play a very important role during the installation, there a thought of "offline installer" rose.

Actually, I'm correct. As there is no document describing how to run the 2nd-step installation of an msi file, I decide to strip out the first step and then it works!

Open vs_setup.msi(comes from .NET 3.5 SP1) with orca, move to "Feature" table, you'll see a feature named "NetFX35_EXP_enu_x86_net_SETUP" with a level flag of 2, whereas most others are with a level flag of 1. So yes, this the "first step" which I want to strip out! To totally remove it, "Feature" "FeatureComponent" "Component" "Files" "Registry" and some more related tables(such as msifilehash, not necessary for a working msi) should be modified.

In next part I'll introduce with detailed steps for how to do it.

Steps:

Before we start, I recommend that you use InstEd to edit the msi file. It really has saved me a lot of time, so the steps below are all following InstEd.

1. make a copy of vs_setup.msi, for example here: vs_setup_org.msi. This copy is used for acquiring info for removed entries in progress.

2. open vs_setup.msi and vs_setup_org.msi in 2 windows of InstEd. Although InstEd allows you to open multiple msi files in one window, here we start 2 windows because once there is a dialog over it, you can't switch to a nother tab.

3. switch to vs_setup.msi, go to feature table, remove NetFX35_EXP_enu_x86_net_SETUP by selecting it and hitting delete key. InstEd pops a dialog prompting you for deleting related entries, click OK.

4. switch to vs_setup_org.msi, go to FeatureComponents table and look for all entries with Feature NetFX35_EXP_enu_x86_net_SETUP, each one points to a component.

5. switch to vs_setup.msi, go to component table, sorting entries by first column, then remove all components obtained in the previous point. Every time InstED pops a dialog, click OK directly.

6. go to FeatureExtensionData table, remove NetFX35_EXP_enu_x86_net_SETUP. (don't know if this step is necessary)

7. go to Property table, remove 2 entries: INSTALLLEVEL and ARPSYSTEMCOMPONENT.

8. save it, now you can deploy it!

Credits:

strel (one of Silent .NET Maker synthesized authors), who helped me realize how to make the installer uninstallable and shown in ARP. He also pointed that some steps are verbose and unnecessary, so I removed them.

Known Issues:

there is no issue currently. .

Example (.NET 3.5 SP1):

visit http://www.ryanvm.net/forum/viewtopic.php?t=7696 to get more info.

Edited September 30, 2009 by YumeYao

[KiSystemStartup]

Thanks for the effort. I think I'll have to first install MSXML6 to run it. B)

[strel]

YumeYao, thx for sharing your method, I was aware of it but didn't put hands on it until now. Ultimately I realized too 3.5 was oversized but I hadn't a good solution. Your method rocks and I managed to fix it and to include it in the new Silent .NET Maker synthesized version.

1. you can't get patches applied because updated files are ignored by the msi file.(you can try installing user_hidden's dotnet 3.5 and check file version of %SYSTEMROOT%\Microsoft.NET\Framework\v3.5\NetFX3.5InstallPath_GAC\System.Data.Services.Client.dll, it should have been 3.5.30729.196 if updated, but in reality it is 3.5.30729.1)

This never happened with SNMsynth installers, don't know if that happened in the previous versions of user_hidden installers, I don't think so, but obviously not on the last version. I suppose both are being made from admin install, I don't know why it would fail in his case.

Known Issues:

The deployed msi is not uninstallable by using "msiexec.exe /x". I don't attend to fix it in the future. If any of you would look for a solution, help yourself and it's welcome that you post anything you find.

I was trying to make this value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CE2CDD62-0124-36CA-84D3-9F4DCF5C5BD9}\UninstallString (the GUID refers to 3.5 SP1 framework) work by setting a fixed uninstall log filename for each framework version, but I was failing. From a failed uninstall process log I realized that, in the case of 3.5 SP1, Add/Remove Programs is not calling msiexec but %SYSTEMROOT%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe that is not copied with your method. That's why uninstall fails from Add/Remove Programs and why you said (I think) msiexec /x don't work for uninstall, but the later is not correct, if you open a command line and execute the UninstallString msiexec command, uninstall takes effect.

SOLUTION: The following modifies your guide.

- In point 4 forget about selecting remove on that feature and go to FeatureComponents table and look for all entries with Feature NetFX35_EXP_enu_x86_net_SETUP, each one points to a component. Don't do anything

- In point 5 remove all components obtained in the previous point including ARP_REG_NETFX35_x86.3643236F_FC70_11D3_A536_0090278A1BB8 component (it's causing ARP to call %SYSTEMROOT%\.......\setup.exe)

- Avoid point 6

- EDIT: AVOID POINTS 8, 9, 10, 11 AND 12. I was unsure at first but now not. Sequence in FileTable and Last Sequence values in MediaTable, only has to do with .cab files. No .cab file, no worry about sequence. Editing it is totally unneeded.

- You should remove too in the Registry table, all values pointing to SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[ProductName]

- After you build your installer and install it you should change the following registry values (or maybe you can insert them in registry table, didn't try that):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CE2CDD62-0124-36CA-84D3-9F4DCF5C5BD9}\SystemComponent to 0 (this makes a 3.5 SP1 entry appear in ARP, but this one is not pointing to setup.exe)

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\26DDC2EC4210AC63483DF9D4FCC5B59D\InstallProperties to 0, this one has no effect but to keep congruency.

And then you are able to uninstal from ARP.

In SNMsynth I have not included the rest of your modifications, I have yet to see if it worth it. And in the next days I'll try to apply it too 3.5 framework and all 3.5/3.5 SP1 langpacks.

Thx a lot YumeYao.

Edited September 17, 2009 by strel

[YumeYao]

This never happened with SNMsynth installers, don't know if that happened in the previous versions of user_hidden installers, I don't think so, but obviously not on the last version. I suppose both are being made from admin install, I don't know why it would fail in his case.

I didn't do test on his latest works but when I used it long ago it was.

I was trying to make this value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CE2CDD62-0124-36CA-84D3-9F4DCF5C5BD9}\UninstallString (the GUID refers to 3.5 SP1 framework) work by setting a fixed uninstall log filename for each framework version, but I was failing. From a failed uninstall process log I realized that, in the case of 3.5 SP1, Add/Remove Programs is not calling msiexec but %SYSTEMROOT%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe that is not copied with your method. That's why uninstall fails from Add/Remove Programs and why you said (I think) msiexec /x don't work for uninstall, but the later is not correct, if you open a command line and execute the UninstallString msiexec command, uninstall takes effect.

ok, I later think it is an issue in user_hidden's work, his original installer doesn't have this one uninstallable even from "msiexec /x" when I tried to remove it manually.

you see i'm always too lazy to download the original .NET installer. lol.

SOLUTION: The following modifies your guide.

- In point 4 forget about selecting remove on that feature and go to FeatureComponents table and look for all entries with Feature NetFX35_EXP_enu_x86_net_SETUP, each one points to a component. Don't do anything

- In point 5 remove all components obtained in the previous point including ARP_REG_NETFX35_x86.3643236F_FC70_11D3_A536_0090278A1BB8 component (it's causing ARP to call %SYSTEMROOT%\.......\setup.exe)

- Avoid point 6

- You should remove too in the Registry table, all values pointing to SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[ProductName]

- After you build your installer and install it you should change the following registry values (or maybe you can insert them in registry table, didn't try that):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CE2CDD62-0124-36CA-84D3-9F4DCF5C5BD9}\SystemComponent to 0 (this makes a 3.5 SP1 entry appear in ARP, but this one is not pointing to setup.exe)

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\26DDC2EC4210AC63483DF9D4FCC5B59D\InstallProperties to 0, this one has no effect but to keep congruency.

And then you are able to uninstal from ARP.

In SNMsynth I have not included the rest of your modifications, I have yet to see if it worth it. And in the next days I'll try to apply it too 3.5 framework and all 3.5/3.5 SP1 langpacks.

Thx a lot YumeYao.

thx for this and I'm glad you can apply it on your SNMs to share it with more people. Edited September 15, 2009 by YumeYao

[YumeYao]

I updated the tutorial with strel's help. Now it's bug-free.

[strel]

If you remove NetFX35_EXP_enu_x86_net_SETUP in FeatureExtensionData table, I suppose CSetupMM_NetFx35_x86.3643236F_FC70_11D3_A536_0090278A1BB8 should be removed in Directory table.

And I'm only one of the authors of SNMsynth, I don't deserve this treatment.

Edited September 18, 2009 by strel

[YumeYao]

good finding.

CSetupMM_NetFx35_x86.3643236F_FC70_11D3_A536_0090278A1BB8, DesktopFolder, ProgramMenuFolder, StartMenuFolder and StartupFolder can be removed together with related entries in CustomAction and XXXXXSquence, ensuring a cleaner .msi file.

ok, i can edit the post, lol.

Edited September 18, 2009 by YumeYao

[strel]

I don't know how do you apply this new update of your method to the .msi file; me just like SNMsynth, making .mst pre-applying .mst, making admin install, installing. Well, with the new update of your method I cannot make ARPSYSCOMPONENT property to write its regkey to 0 (again), I need to fix the reg after install.

Moreover I don't see the point in using INSTALLLEVEL, I mean, this setting is meant to set what features run and what not depending of its install level; well I don't know if using it over the .msi when your are installing makes sense (I hope it isn't just bloat) but the way I use it with SNMsynth, i.e. for pre-modifying the .msi prior to make the admin install, it makes no difference. Or in other words I expected I could avoid the execution of whole NetFX35_EXP_enu_x86_net_SETUP feature with INSTALLLEVEL property while making the admin install, thus getting a slimmed down output with far less pre-editing the .msi files through the .mst files, but I cannot manage to do that, and I've tested deeply.

I'm comming back to my previous .mst set to include the rest of the new changes that will improve it.

Cheers.

Edited September 18, 2009 by strel

[YumeYao]

I don't know how it fails you but in my test, the registry value SystemComponent doesn't exist in key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CE2CDD62-0124-36CA-84D3-9F4DCF5C5BD9}, after I removed ARPSYSCOMPONENT in Property table. so did you modified ARPSYSCOMPONENT to 0? or did you removed ARPSYSCOMPONENT and you forget to clean up the original registry value(since in my test, no value is set, therefore if there is an old value there it may cause this issue).

anyway, I created slimandclean35sp1.mst by cleaning all original entries then copy in modified entries (I'm too lazy to remove them again one by one), and I have tested applying it, it works.

This mst files do slip redundant components including VC, and do all cleaning up I've found.

additionally, in your script:

START/WAIT MSIEXEC /a "!TMPDIR!\WRAP35\vs_setup.msi" /l*v "%TEMP%\TRANSADMIN.LOG" NOVSUI=1 /qb TARGETDIR="!DNF35DIR!\DNF35"

I didn't use NOVSUI=1. and I believe a slimmed down vs_setup.msi doesn't need this any more. and in my testings, msi files are executed by only adding flag ADDEPLOY=1.

[strel]

It's almost equal than mine, except I divide, slimming, and removing VC9 in 2 files, and for slimming, I haven't removed the properties, nor MsiSFCBypass nor SxsMsmGenComponents tables, just empty them because of that install errors I told you, but I'll keep testing, nor the Binary SxsUninstallCA (I haven't seen it, maybe it's the cause), and I'm still dubious about all that folder related CAs apart from that related with the FeatureExtensionData entry removed, they just set properties, and I have not checked they are not used at all in the process. And I suppose you're right with no NOVSUI property once removed it and with ARP related properties on install command.

EDIT: I edited the resultant .msi files and removing of both variables are working as you expected, I obviously did something wrong, I should be crossing some tests in one install. I'm going to update the .mst file set and scripts to achieve that.

EDIT: Read my next post.

Edited September 19, 2009 by strel

[YumeYao]

thanks for reminding those CAs, I'll look further into them and I'll keep them if I can't find a potent reason.

and I'm glad it works for you.

[strel]

Wait!!! not that fast, I'm removing both properties in the .mst files and preapplied them to .msi, do admin install, and get .msi with both properties removed, checked, ready to install, but after install now SystemComponent reg value is set to 1, and this regkey was removed from registry in the previous uninstall, again checked.

EDIT: Strange, that's only happening for 3.5 sp1 .msi not for langpack or for 3.5 or its langpack. There's still hope.

Edited September 19, 2009 by strel

[YumeYao]

well.... I just used this script (extracted from your script) to apply mst on msi.... like this:

ECHO>35SP1SLIMMING.vbs Set instobjt = Wscript.CreateObject^("WindowsInstaller.Installer"^)
ECHO>>35SP1SLIMMING.vbs Set dnfdb = instobjt.OpenDatabase^("vs_setup.msi", 1^)
ECHO>>35SP1SLIMMING.vbs dnfdb.ApplyTransform "slimandclean35sp1.mst", 0
ECHO>>35SP1SLIMMING.vbs dnfdb.Commit
CSCRIPT /NOLOGO 35SP1SLIMMING.vbs

It works very very very smoothly for me.

vs_setup_MOD.msi is modified manually and vs_setup.msi is transformed by this script.

vs_setup.7z

EDIT: the base msi is original vs_setup.msi in .NET 3.5 Install pack.

Edited September 19, 2009 by YumeYao

[YumeYao]

see this screenshot in VM......

install command was

msiexec /i vs_setup.msi TRANSFORMS="NETWUFIXES.mst" ADDEPLOY=1 ARPNOMODIFY=0 ARPNOREPAIR=0

and the (EDIT: original, before administrative deploying) msi is in previous attachment (EDIT: after administrative deployed.).

EDIT2: have you cleaned "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\26DDC2EC4210AC63483DF9D4FCC5B59D\InstallProperties" before testing?

Edited September 19, 2009 by YumeYao

[strel]

I though this key could be the cause, but seems not to be causing the problem

Edited September 19, 2009 by strel