Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Photo

[Tutorial]Modify an offline msi installer for administrative install

- - - - -

  • Please log in to reply
33 replies to this topic

#1
YumeYao

YumeYao

    a RyanVM.net member

  • Member
  • Pip
  • 73 posts
  • Joined 10-December 05
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. :D.


Example (.NET 3.5 SP1):
visit http://www.ryanvm.ne...opic.php?t=7696 to get more info.

Edited by YumeYao, 30 September 2009 - 05:33 AM.



How to remove advertisement from MSFN

#2
KiSystemStartup

KiSystemStartup
  • Member
  • 3 posts
  • Joined 13-January 09
Thanks for the effort. I think I'll have to first install MSXML6 to run it. B)

#3
strel

strel

    segmentation fault

  • Member
  • PipPipPipPip
  • 629 posts
  • Joined 24-February 08
  • OS:XP Pro x86
  • Country: Country Flag
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. :thumbup

Edited by strel, 17 September 2009 - 08:08 AM.


#4
YumeYao

YumeYao

    a RyanVM.net member

  • Member
  • Pip
  • 73 posts
  • Joined 10-December 05

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. :thumbup

thx for this and I'm glad you can apply it on your SNMs to share it with more people.

Edited by YumeYao, 14 September 2009 - 10:31 PM.


#5
YumeYao

YumeYao

    a RyanVM.net member

  • Member
  • Pip
  • 73 posts
  • Joined 10-December 05
I updated the tutorial with strel's help. Now it's bug-free.

#6
strel

strel

    segmentation fault

  • Member
  • PipPipPipPip
  • 629 posts
  • Joined 24-February 08
  • OS:XP Pro x86
  • Country: Country Flag
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 by strel, 18 September 2009 - 10:38 AM.


#7
YumeYao

YumeYao

    a RyanVM.net member

  • Member
  • Pip
  • 73 posts
  • Joined 10-December 05
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 by YumeYao, 18 September 2009 - 11:16 AM.


#8
strel

strel

    segmentation fault

  • Member
  • PipPipPipPip
  • 629 posts
  • Joined 24-February 08
  • OS:XP Pro x86
  • Country: Country Flag
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 by strel, 18 September 2009 - 03:12 PM.


#9
YumeYao

YumeYao

    a RyanVM.net member

  • Member
  • Pip
  • 73 posts
  • Joined 10-December 05
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 Attached File  slimandclean35sp1.mst   22.5KB   10 downloads by cleaning all original entries then copy in modified entries :blushing: (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.

#10
strel

strel

    segmentation fault

  • Member
  • PipPipPipPip
  • 629 posts
  • Joined 24-February 08
  • OS:XP Pro x86
  • Country: Country Flag
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 by strel, 19 September 2009 - 04:44 AM.


#11
YumeYao

YumeYao

    a RyanVM.net member

  • Member
  • Pip
  • 73 posts
  • Joined 10-December 05
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.

#12
strel

strel

    segmentation fault

  • Member
  • PipPipPipPip
  • 629 posts
  • Joined 24-February 08
  • OS:XP Pro x86
  • Country: Country Flag
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 by strel, 19 September 2009 - 07:38 AM.


#13
YumeYao

YumeYao

    a RyanVM.net member

  • Member
  • Pip
  • 73 posts
  • Joined 10-December 05
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.
Attached File  vs_setup.7z   190.95KB   11 downloads
EDIT: the base msi is original vs_setup.msi in .NET 3.5 Install pack.

Edited by YumeYao, 19 September 2009 - 05:33 AM.


#14
YumeYao

YumeYao

    a RyanVM.net member

  • Member
  • Pip
  • 73 posts
  • Joined 10-December 05
see this screenshot in VM......
Attached File  Windows_XP_Test_2009_09_19_19_19_10.png   103KB   29 downloads

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 by YumeYao, 19 September 2009 - 05:34 AM.


#15
strel

strel

    segmentation fault

  • Member
  • PipPipPipPip
  • 629 posts
  • Joined 24-February 08
  • OS:XP Pro x86
  • Country: Country Flag
I though this key could be the cause, but seems not to be causing the problem

Edited by strel, 19 September 2009 - 07:39 AM.


#16
YumeYao

YumeYao

    a RyanVM.net member

  • Member
  • Pip
  • 73 posts
  • Joined 10-December 05
works for me..................


EDIT: msi tested by copying windows folder(containing VC9) together.

I'll view mst file now.

Edited by YumeYao, 19 September 2009 - 07:23 AM.


#17
strel

strel

    segmentation fault

  • Member
  • PipPipPipPip
  • 629 posts
  • Joined 24-February 08
  • OS:XP Pro x86
  • Country: Country Flag
Now seems to work, you were right from the beginning, it was the test version of the script I'm using, I didn't notice it was inserting the property in the command line. Install errors from .msi with sxs tables removed were caused because the sxs binary was no removed as predicted.

Edited by strel, 19 September 2009 - 07:58 AM.


#18
Dumpy Dooby

Dumpy Dooby

    Advanced Member

  • Member
  • PipPipPip
  • 424 posts
  • Joined 16-May 05
RogueSpear's latest .NET 3.5 Lite release (which omits .NET 2.0 SP2 and MSXML 6 Service Pack 2) is 28MB. Using your method, could his "Lite" installer be slimmed down even more?

I'm not sure I really get what it is that you've accomplished, but judging by your excitement, I'm assuming it's something worthwhile.

IceBlackIce> ill just take you are not a experienced person with coding [source]
^lol


#19
strel

strel

    segmentation fault

  • Member
  • PipPipPipPip
  • 629 posts
  • Joined 24-February 08
  • OS:XP Pro x86
  • Country: Country Flag
You'll see it soon.

#20
YumeYao

YumeYao

    a RyanVM.net member

  • Member
  • Pip
  • 73 posts
  • Joined 10-December 05

RogueSpear's latest .NET 3.5 Lite release (which omits .NET 2.0 SP2 and MSXML 6 Service Pack 2) is 28MB. Using your method, could his "Lite" installer be slimmed down even more?

I'm not sure I really get what it is that you've accomplished, but judging by your excitement, I'm assuming it's something worthwhile.

When I wrote a subtitle for this thread ".NET 3.5 installer for 34MB", I mean it's 2.0+3.0+3.5. .NET 2.0 is about 15M(compressed), so, a lited 3.0+3.5 can be as small as 34M-15M=19M. Cheers.

#21
Dumpy Dooby

Dumpy Dooby

    Advanced Member

  • Member
  • PipPipPip
  • 424 posts
  • Joined 16-May 05
Good estimation. That's exactly what it is. 18.5MB 7zip, and about 19MB after turning it into an SFX.

Your method removes HtmlLite.dll, WapUI.dll, and a bunch of other files (including more DLLs) from the root directory of the MSI. Is this intentional? Are there any negative impacts as a result of this, or were these just more redundant entries?


I'm about to attempt a RunOnceEx installation of this bad boy on a freshly formated VM. Afterwards I will try uninstalling it from Add/Remove Programs. We'll see how it goes.


Does anyone know of any v3.5 applications that I can use to test and make sure everything installed successfully?

IceBlackIce> ill just take you are not a experienced person with coding [source]
^lol


#22
strel

strel

    segmentation fault

  • Member
  • PipPipPipPip
  • 629 posts
  • Joined 24-February 08
  • OS:XP Pro x86
  • Country: Country Flag
http://www.getpaint.net/
http://www.ranorex.c...nvironment.html
http://usa.autodesk....amp;id=12433125
http://www.telerik.c...ilverlight.aspx

Edited by strel, 21 September 2009 - 10:02 AM.


#23
Dumpy Dooby

Dumpy Dooby

    Advanced Member

  • Member
  • PipPipPip
  • 424 posts
  • Joined 16-May 05
Well, all of those applications ran smoothly, so I guess it's safe to assume it installed just fine.


The only problem is that none of my .NET Frameworks are uninstallable.

IceBlackIce> ill just take you are not a experienced person with coding [source]
^lol


#24
strel

strel

    segmentation fault

  • Member
  • PipPipPipPip
  • 629 posts
  • Joined 24-February 08
  • OS:XP Pro x86
  • Country: Country Flag
Not my case. For 3.5 SP1 you can change the SystemComponent settign if this is what's causing the problem. For the rest of the versions don't know what could be the problem.

Edited by strel, 25 September 2009 - 12:51 PM.


#25
YumeYao

YumeYao

    a RyanVM.net member

  • Member
  • Pip
  • 73 posts
  • Joined 10-December 05
once .net 3.5 can not be removed, then it blocks .net 3.0 and 2.0 from being removed.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN