Jump to content

Silent .NET Maker synthesized 20100118 - W2K/XP/2K3 x86


strel

Recommended Posts

I finally worked out the whole thing as I wanted. Tested on VM and worked fine. Here are my final decisions to share:

  1. for KB971276, I finally think it's safe to use original one.(WindowsXP-KB971276-v3-x86-ENU.exe for XP, WindowsServer2003-KB971276-v2-x86-ENU.exe for 2k3). But the hotfix update shell replacement is harmless and can be applied to reduce size.
  2. on msi:

    1. CA_BlockDirectInstall* in CustomAction and InstallExecuteSequence prevents msi from direct install. Removing them ensures the msi can be installed without "ADDEPLOY=1".
    2. .NET 2.0 specific: DWFolder.D0DF3458_A845_11D3_8D0A_0050046416B9 and needed parents should NOT be removed in Directory, it's needed by debugger registry(DW20.exe).

    3. on mst:
      my final working set is here. workingmsts.zip
    4. on install.cmd:
      modifiedinstallcmd.7z
      EDIT: I have changed some paths.. be careful. as far as i can see, I didn't restore the path for XPS_LanguagePack in the document.


      EDIT2: @Raul90
      Have you integrated VC2005/2008 runtimes when you are doing a test?
Edited by YumeYao
Link to comment
Share on other sites


Hi YumeYao.

I had no time last days to make tests I'm beginning now. About your proposals:

1. I'm using your fixed method to apply new update shell to WIC and XPS. You say "safer" to only use the update shell from this hotfix, probably, but is there something I should know?

2. Good point and very good point. EDIT: This last one not needed, see bellow.

3 & 4:

- Well I'm splitting NETWUFIXES but I'm making it even more atomized, and scripts will not be touched. I'm trying to pre-apply all transforms also to avoid .mst extra files in the installer packages and later cached when installed. This means, that 3.0 langpack extra values you added methodicly (InstallSuccess and Version, resembling 2.0 langpack values), but not checked by win/ms update, will not be included. It can be expected update system will keep cheking the same values. And you're not applying those 3.0 extra values in the right regkey with your VBS scripts. Check Registry table of a 3.0 langpack installer to compare.

About INSTALL.CMD script. (I only checked .doc version suppose it's equal to .docx)

- About renaming the cached installer, this lines will be kept, as well as VBS ones. As I said before, original installers always use same file names for cached installers, and while you pointed right the update system don't check them and that you can manage new names, maybe other software could rely on them, and I'd like to keep as much as possible things untouched to avoid potential problems (I'm not referring with this to .msi installers and fixes applied obviously) EDIT: This is not correct, see below.

- I don't know where this %VERBOSITYHOTFIX% come from, but I'll take it as you're referring to verbosity value for the installer.

- I'm trying to make the INSTALL.CMD to check whether it is executing on GUI mode setup by detecting NetworkService profile folder, and thus managing issues around this, like %TEMP%.

- About DNFWIN#.TXT ARP entries removal, you don't see the difference because your OS has an up to date windows installer 4.5.

- About delaying 3.0 subcomponents install to logon, I'm using RunOnceEx entries instead of a RunOnce script, thus I'm able too to rise up its related dialog about what's installing, executing it first before any other software installing from there (unless rare regkey names applied), but only in case verbosity is not silent. And I don't get why are you relying on SSIP setting to switch to delayed installing. I understood from what you told, both XPS and WIC were executing spupdsvc.exe in every circumstance, so what SSIP has to do with this? I suppose you're not installing WIC, hence delaying it because your script is for XP SP3.

I'm beggining my tests now, hope all the above can be achieved.

Edited by strel
Link to comment
Share on other sites

Hi YumeYao.

I had no time last days to make tests I'm beginning now. About your proposals:

1. I'm using your fixed method to apply new update shell to WIC and XPS. You say "safer" to only use the update shell from this hotfix, probably, but is there something I should know?

1. yes. My first method(branches) will bring a result that proper catalog is not installed on xp. My second method is a fault because it won't installs on xp sp3(I was working on xp sp2 those days so....).

Now I uses a modified inf and a patched update.exe for my release. If you don't want to use the patched one, you can apply my second method on KB971276-XP-V3(I didn't test that on 2k3 but I suppose it works). If that doesn't work, then using KB971276-XP and KB971276-2003 seperately is the safest way.

Still, I mean replace all update shells with the one in original XPS printer because those in XPS printer are latest.

- Well I'm splitting NETWUFIXES but I'm making it even more atomized, and scripts will not be touched. I'm trying to pre-apply all transforms also to avoid .mst extra files in the installer packages and later cached when installed. This means, that 3.0 langpack extra values you added methodicly (InstallSuccess and Version, resembling 2.0 langpack values), but not checked by win/ms update, will not be included. It can be expected update system will keep cheking the same values. And you're not applying those 3.0 extra values in the right regkey with your VBS scripts. Check Registry table of a 3.0 langpack installer to compare.

About INSTALL.CMD script. (I only checked .doc version suppose it's equal to .docx)

- About renaming the cached installer, this lines will be kept, as well as VBS ones. As I said before, original installers always use same file names for cached installers, and while you pointed right the update system don't check them and that you can manage new names, maybe other software could rely on them, and I'd like to keep as much as possible things untouched to avoid potential problems (I'm not referring with this to .msi installers and fixes applied obviously)

I'll test about the .msi cache names. I didn't notice what you said "original installers always use same file names for cached installers". If that's true, then I'll agree with you.

EDIT2: tested and here's a screenshot:

post-82036-1254326259_thumb.png

what you said does not happened.

so you can take a look at my msts and vbses, they will handle this issue properly.

- About delaying 3.0 subcomponents install to logon, I'm using RunOnceEx entries instead of a RunOnce script, thus I'm able too to rise up its related dialog about what's installing, executing it first before any other software installing from there (unless rare regkey names applied), but only in case verbosity is not silent. And I don't get why are you relying on SSIP setting to switch to delayed installing. I understood from what you told, both XPS and WIC were executing spupdsvc.exe in every circumstance, so what SSIP has to do with this? I suppose you're not installing WIC, hence delaying it because your script is for XP SP3.

On a live system it's always safe to execute spupdsvc.exe(consider how user installs hotfixes). Only on a system-setup-in-progress OS, it may damage. So I determinate it with SSIP.

RunOnceEx is also ok.

WIC won't execute spupdsvc.exe, that's why I doesn't make it RunOnce-delayed.

I'm beggining my tests now, hope all the above can be achieved.

good luck.

EDIT: forgot to say. look at this:

http://catalog.update.microsoft.com/v7/sit...aspx?q=KB951847

This 69.2 MB stuff is not same as the one in download.microsoft.com, if you can make your script compatible for this one, that will be good.

@ YumeYao.

I only integrated this one:

http://www.ryanvm.net/forum/viewtopic.php?t=5063

sorry, I can't see the reason why your install fails. All I use is also code's addon.

Edited by YumeYao
Link to comment
Share on other sites

Your program yielded this fancy install.CMD file for me...

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: ::
:: Installer created with ::
:: Silent .NET Maker synthesized 20090922 ::
:: http://www.msfn.org/board/index.php?showtopic=127790 ::
:: ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

SETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION
SET VERBOSITY=passive
SET SWITCH=%1
IF /I "%SWITCH:~-4%"=="sive" (SET VERBOSITY=passive) ELSE IF /I "%SWITCH:~-4%"=="uiet" (SET VERBOSITY=quiet) ELSE IF /I "%SWITCH:~-4%"=="lent" SET VERBOSITY=quiet
IF NOT EXIST FILEVER.vbs (
ECHO>>FILEVER.vbs Set objFSO = CreateObject^("Scripting.FileSystemObject"^)
ECHO>>FILEVER.vbs Wscript.Echo objFSO.GetFileVersion^(WScript.arguments^(0^)^)
)
FOR /F "DELIMS=. TOKENS=1" %%I IN ('CSCRIPT //NOLOGO FILEVER.vbs "%SYSTEMROOT%\SYSTEM32\MSI.DLL"') DO IF /I "%%I"=="2" (
IF /I "%VERBOSITY%"=="passive" SET VERBOSITY=qb!
IF /I "%VERBOSITY%"=="silent" SET VERBOSITY=qn
IF /I "%VERBOSITY%"=="quiet" SET VERBOSITY=qn
)
SET SYS2K=1
IF EXIST %SYSTEMROOT%\system32\reg.exe (
SET SYS2K=
FOR /F "DELIMS=" %%I IN ('%SYSTEMROOT%\system32\REG QUERY "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v ProductName') DO ECHO>DNFWIN1.TXT %%I
FOR /F %%I IN ('FINDSTR/I "2000" DNFWIN1.TXT') DO SET SYS2K=1
)
IF NOT DEFINED SYS2K FOR /F "TOKENS=3" %%I IN ('REG QUERY "HKLM\SYSTEM\Setup" /v SystemSetupInProgress') DO SET SSIP=%%I
IF /I "%SSIP%"=="0x1" (
REG DELETE "HKLM\SOFTWARE\Microsoft\PCHealth\ErrorReporting\DW" /f
REG ADD "HKLM\SYSTEM\Setup" /v SystemSetupInProgress /t REG_DWORD /d 0 /f
)
IF EXIST *.TXT DEL /F *.TXT
XCOPY/DY DNF30\SYS32\rgb9rast_2.dll %SYSTEMROOT%\system32
%SYSTEMROOT%\system32\regsvr32 /s %SYSTEMROOT%\system32\rgb9rast_2.dll
START/WAIT DNF30\WIC\update\update.exe /%VERBOSITY% /norestart
START/WAIT DNF30\XPS\update\update.exe /%VERBOSITY% /norestart
NET STOP MSIServer
COPY /Y REMFONTCACHEFIX.mst DNF30
START/WAIT DNF30\Netfx30a_x86.msi /l*v "%TEMP%\NETFX30install.log" TRANSFORMS=REMFONTCACHEFIX.mst;NETWUFIXES.mst ADDEPLOY=1 ARPNOMODIFY=0 ARPNOREPAIR=0 /%VERBOSITY% /norestart
FOR /F "TOKENS=3" %%I IN ('REG QUERY "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\0DC1503A46F231838AD88BCDDC8E8F7C\InstallProperties" /V UnfixedDBName^|FINDSTR "UnfixedDBName"') DO REN %%I 39d3e.msi
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\0DC1503A46F231838AD88BCDDC8E8F7C\InstallProperties" /V UnfixedDBName /F
%SYSTEMROOT%\REGEDIT /E DNFWIN2.TXT "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall"
TYPE DNFWIN2.TXT>DNFWIN3.TXT
FINDSTR/R "\[" DNFWIN3.TXT>DNFWIN4.TXT
FOR /F %%I IN ('FINDSTR/IR "\.KB958483" DNFWIN4.TXT') DO ECHO>>DNFWIN3.TXT %%I
FOR /F "DELIMS=[]" %%I IN (DNFWIN5.TXT) DO REG DELETE "%%I" /f
START/WAIT DNF35\vs_setup.msi /l*v "%TEMP%\NETFX35install.log" TRANSFORMS=NETWUFIXES.mst;NOFFADDONFIX.mst ADDEPLOY=1 ARPNOMODIFY=0 ARPNOREPAIR=0 /%VERBOSITY% /norestart
FOR /F "TOKENS=3" %%I IN ('REG QUERY "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\26DDC2EC4210AC63483DF9D4FCC5B59D\InstallProperties" /v UnfixedDBName^|FINDSTR "UnfixedDBName"') DO REN %%I 39d44.msi
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\26DDC2EC4210AC63483DF9D4FCC5B59D\InstallProperties" /v UnfixedDBName /f
REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CE2CDD62-0124-36CA-84D3-9F4DCF5C5BD9}" /v SystemComponent /t REG_DWORD /d 0 /f
REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\26DDC2EC4210AC63483DF9D4FCC5B59D\InstallProperties" /v SystemComponent /t REG_DWORD /d 0 /f
%SYSTEMROOT%\REGEDIT /E DNFWIN2.TXT "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall"
TYPE DNFWIN2.TXT>DNFWIN3.TXT
FINDSTR/R "\[" DNFWIN3.TXT>DNFWIN4.TXT
FOR /F %%I IN ('FINDSTR/IR "\.KB953595" DNFWIN4.TXT') DO ECHO>>DNFWIN6.TXT %%I
FOR /F %%I IN ('FINDSTR/IR "\.KB958484" DNFWIN4.TXT') DO ECHO>>DNFWIN6.TXT %%I
FOR /F "DELIMS=[]" %%I IN (DNFWIN6.TXT) DO REG DELETE "%%I" /f
IF /I "%SSIP%"=="0x1" (
FOR /F "DELIMS=" %%I IN ('ECHO %PROGRAMFILES%\Common Files\Microsoft Shared') DO SET SHD=%%~sI
REG ADD "HKLM\SYSTEM\Setup" /v SystemSetupInProgress /t REG_DWORD /d 1 /f
REG ADD "HKLM\SOFTWARE\Microsoft\PCHealth\ErrorReporting\DW\Installed" /v DW0200 /t REG_SZ /d !SHD!\DW\DW20.EXE /f
)
%SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\ngen.exe executequeueditems

I perused it a bit to try and find out what was causing my problems with my uninstallers not working, and I noticed this...

%SYSTEMROOT%\REGEDIT /E DNFWIN2.TXT "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall"
TYPE DNFWIN2.TXT>DNFWIN3.TXT
FINDSTR/R "\[" DNFWIN3.TXT>DNFWIN4.TXT
FOR /F %%I IN ('FINDSTR/IR "\.KB958483" DNFWIN4.TXT') DO ECHO>>DNFWIN3.TXT %%I
FOR /F "DELIMS=[]" %%I IN (DNFWIN5.TXT) DO REG DELETE "%%I" /f

Specifically, I think...

FOR /F %%I IN ('FINDSTR/IR "\.KB958483" DNFWIN4.TXT') DO ECHO>>DNFWIN3.TXT %%I

is actually supposed to be...

FOR /F %%I IN ('FINDSTR/IR "\.KB958483" DNFWIN4.TXT') DO ECHO>>DNFWIN5.TXT %%I

Is that correct?

By the way, I don't think this has anything to do with my broken uninstaller (since I don't actually use install.cmd). It's just something I noticed while I was looking through the file.

Edited by Dumpy Dooby
Link to comment
Share on other sites

I been using SNM for a long time and its a great tool, thanks for you hard work.

I'm currently using SNM 20090913 and it works great, no problems on XP, but Win2003 is asking for KB951847.

Thanks for any help

Link to comment
Share on other sites

2 YumeYao.

About SSIP, don't know what I was thinking, it's pretty obvious what it has to do, and is a better solution than the one I was using. I'll use it. Thx.

About cached installer files renaming, I was introducing some confusion. You're right, cached installers are not getting actually the file names I'm using for renaming them in the script, when installed from redistributable package, nor when installed from KB951847 in a test I just finished now, so it seems renaming is not needed. Although I'm confused, and wondering: but if you're right, why did I include this renaming in the script?, and my answer is I'm sure at the time I included renaming I was getting always the same file names for cached files when installed from KB951847, and that's the reason why renaming is in the script. So I've compared dates when I included renaming, with last modification date for KB951847, and the framework installer subcomponent therein, has a later last modification date. So I think cached installers file names has changed, from fixed to aleatory, for KB951847 in the meantime, hence my confusion.

I'm changing my mind about restoring DW regkey. Reason why it is removed from registry is that, as stated by Aaron Stebner, creator of this workaround, 2.0 framework installer (office11 debugger subcomponent supposedly) doesn't have permissions to write to it during setup. In addition he don't restore later this regkey, so I have to suppose it will be written when needed later. I have no reason to think office debugger installed from office 2k3 during setup (thing I've never tried) wouldn't have the same restrictions, and problems.

2 Dumpy Dooby

You're right, typo I introduced somehow. I was not aware of it. Thx. And about your problems uninstalling sure they are caused by what's answered in YumeYao's method thread to this question.

2 7yler

Don't know what's happening to you, for now. Always try to use latest version to check problems are still there, but if they are, and not on previous versions, now you have many previous versions ready to download in the changelog section, so you can test.

EDIT: Can you post NETFX##install.log files for 2.0 3.0 and 3.5 frameworks you should have in %TEMP% folder?

2 Raoul90

So I suppose KB963676 restricted hotfix didn't solve your problems.

Edited by strel
Link to comment
Share on other sites

good info.

Then it seems:

DW fix is not needed for we removed office debugger.

SSIP fix is (possibly) not needed for VC8 assemblies are initialized during txt-setup mode(if proper addon is integrated). I'm not sure and I havn't done any test for this.

Link to comment
Share on other sites

YumeYao

You now say WIC don't run spupdsvc.exe but on post #351, you don't say that, and WIC has this file in its folder, I think you were right first time.

Dumpy Dooby

I saw your new error in the YumeYao's method thread. Probably you cannot uninstall because all installer related files used on install are not on %SYSTEMROOT%\Installer folder, for some reason, maybe permissions, don't know why, they should be there. Probably you're getting this new error because, as it seems, the uninstall process are not finding required files, probably .mst files in %SYSTEMROOT%\Installer\{GUID} folder where GUID is the GUID of the component to uninstall, as you said you found the .msi (I'd check if it is the same filename as the uninstall regkey); so it is searching them in the original install folder, that is the temporal folder where the SNMsynth installer was extracted on install, now deleted as it seems.

You can obtain GUID from the 3.5 SP1 uninstall regkey you mentioned "in the backgroud" on your YumeYao's method thread post. Once you get the GUID, you can create the GUID folder if it's not there, and copy the required .mst files, you'll find them inside the SNMsynth installer you used (you can check the script to see which of them were effectively used by 3.5 SP1 install process, because if it is a merged installer, where other framework versions reside, there could be .mst files not used by 3.5 SP1, though I don't think it is going to harm if you copy to GUID folder, extra .mst files). Once you have the required .mst files in the GUID folder and .msi in the Installer folder, uninstall should work.

Hopefully for the next version, will be no problems if .mst files are not in Installer folder because they will be preapplied to .msi.

But if for some reason all this doesn't work, because maybe your install got corrupted for some reason with all this trials (not so rare) you still can use: .NET FX Cleanup Tool.

7yler

Don't know if you read it, can you attach your %TEMP%\NETFX##install.log (or in c:\ if you used SNMsynth installers from T-13, there's still a bug with that) files for 2.0 3.0 and 3.5 versions, you're getting on the problematic 2003 install (showing KB951847)?

Edited by strel
Link to comment
Share on other sites

I use InstallShield to preapply the MSTs directly to the MSI files so that shouldn't be a problem. You did give me an idea, though. I'll try copying vs_setup.MSI file to %SystemRoot%\Installer\{GUID HERE}\. Or perhaps even try copying vs_setup.MSI to the installer folder and replacing the MSI that's generated by the installer itself. For good measure, I'll also try putting the MSTs in there too, just in case they're needed.

I have no idea if these tests will work, but I'll see what happens.

Also, thanks for the link to the cleanup tool. I'll try using that, but all of my tests have been on a perfectly clean install. I dunno, though. It might still make a difference. Thanks man.

Edited by Dumpy Dooby
Link to comment
Share on other sites

@Strel

I'm was running SNM post install (not T-13), and it was 2003 (showing KB951847), XP was ok.

I tried SNM 20090922 this time and I'm having problems with it not installing at all (I am using the RESTRICTED HOTFIXES), so I cant get the logs to you at the moment.

I'm currently really busy, so I will retry later in the week when I get the chance.

EDIT: Just done a quick test on 2003 (XP is ok), and it looks like 20SP2/30SP3/35SP1 are not being installed at all, possibly RESTRICTED HOTFIXES causing the problem. Maybe a RegTweak is causing WU to think it needs KB951847.

Later in the week, I will try WITHOUT any RESTRICTED HOTFIXES. By the way SNM complains if KB971595/KB972251 are used.

Edited by 7yler
Link to comment
Share on other sites

@strel

on the WIC issue:

its update.inf doesn't contain any entry calling spupdsvc.exe. This is also the first time i see such a hotfix with spupdsvc.exe yet doesn't call it.

here is also a simple test to prove it.

environment is xp sp2 chs.

wictest.7z

@dumpydooby

I always do a test on perfectly clean system before I confirm all is working.

Edited by YumeYao
Link to comment
Share on other sites

@Strel

I just done a test with no RESTRICTED HOTFIXES, just the basic patches, and it wont install on Win2003.

When I extracted the files, and run the MSI files from 20/30/35 I get following error.

post-177630-1254574625_thumb.jpg

Link to comment
Share on other sites

Probably you ran it without ADDEPLOY=1 property, the script uses. Maybe you have some framework version installed inadvertedly (apart of 1.1) blocking your install. I'd check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{VARIOUS GUID FOLDERS}\DisplayName values for .NET versions installed.

Edited by strel
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...