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.

@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.

@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.
Click to view attachment

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

@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.

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.

I'm kinda of a newbie here but I had a package made with the previous release with .net 1.1, 2.0 SP2, 3.0 and 3.5, that I integrated fine with nlite with no problems, now I made the same package with the new version and after windows install thw windows update ask's me for KB951847, can someone help with this one

thx in advance

Seems like the same problem as 7yler, can you attach your NETFX##install.log files for 2.0 3.0 and 3.5? Due to another bug if you installed from T-13 (nlite add-on for example) you'll find them in %SYSTEMFOLDER%, instead of %TEMP%.

I can't find the files you are asking, either in %SYSTEMFOLDER% or %TEMP%, I searched the system for log files and couldn't find it

@strel Hey there. I wonder if you can help me trouble shoot this one. It's a head scratcher...

I downloaded your latest build of SNM Synth and created default packages (no .ini file changes) for each .Net Framework using all related updates currently listed in Microsoft Update (including the Firefox related one), but no language packs. I integrate them into my WinXP Pro SP3 XPCD as follows:

1. DNF20.exe - installed from svcpack.inf
2. DNF30.exe - installed from RunOnceEx
3. DNF35.exe - installed from RunOnceEx
4. DNF11.exe - installed from RunOnceEx

NOTE: All packages are fully updated with all their perspective SP and KB updates, I just rename them to shorter generic names.

On VirtualPC, Windows XP Pro volume installs correctly, which it has every time I have ever used your script or the original SNM by Tomcat76.

Today, I was rebuilding a PC with Win XP Home Edition OEM. And RunOnceEx fired off after the first user logged in and it started working as normal. However, when RunOnceEx got down to the .Net Framework 3.5 entry the installer unpacked and installed but the RunOnceEx process just halted afterward. There was no HDD activity, the mouse just sat there and RunOnceEx didn't progress to the next entry. After 30 minutes I pressed the PC reset button and rebooted it. After logging in as the same user again RunOnceEx continued on the next item after the .Net Framework 3.5 entry, which is .Net Framework 1.1. but the .Net Framework 3.5 entry was still listed. Then RunOnceEx completed as did the first user log in.

So I checked Control Panel - Add/Remove Programs and all four .Net Framework installations were listed as expected, despite the process hanging and the forced PC reset. So at this point, I rolled back to my XPCD to the previous .Net packages I created using an earlier SNM Synth build and started over (no other changes to the XPCD). I got exactly the same results.

This time I also downloaded and ran the .NET Framework Setup Verification Tool from Aaron Stebner's WebLog and all four .Net Framework installations checked out okay. So I looked in the %TEMP% folder and I see the unpacked 7zip temp folder with the .Net Framework 3.5 files still inside. I've zipped up all the files your script created in the root of that folder and attached them here.

But I have no clue what is happening or why it would work with Win XP Pro on VPC and not XP Home on a real PC. Any ideas?

^ Did you check to see if there were hanging instances of MsiExec or anything? I'm not sure what Ngen.exe does, but you might consider looking for it as well.

It might also be looking for some sort of user interaction. To check this, rename INSTALL.CMD to INSTALL2.CMD. Create a new INSTALL.CMD with this:

That will direct all output from his script to the log file. So if the last line in the log is "Are you sure you want to..." or something like that, then you know why it's hanging.


That's what I'd suggest doing if you want to try troubleshooting it yourself. Otherwise you can wait for Strel and he might have some more useful tips.

skyhacker
Don't know if you read my PM, it would be of great value to check the install logs for 2.0 3.0 and 3.5 and its related langpacks (which install ad-hoc KB951847FIX), if you don't find them, better you uninstall .NET and use the installer to reinstall them and generate the logs. As you probably used an all in one 1.1+2.0+3.0+3.5 add-on for nlite, you'll find the installer in i386\SVCPACK folder of your nlited source, or you can extract it from the add-on. Uninstall all .NET framework versions, and then execute the installer. %TEMP%\NETFX##install.log and %TEMP%\NETFX##LNGinstall.log files should be created. Logs for 2.0, 3.0 and 3.5 and its langpacks should reveal if KB951847 fixes have been correctly installed. Can you attach them? Are you installing over windows 2003?

DarkShadows
You can check %TEMP%\NETFX35install.log, if you used installers made with later versions, otherwise you can search for the related %TEMP%\MSI*.log by date.
Can you attach it?

DumpyDooby
ngen pre-compiles .NET libraries to be used by .NET software, in the case of this script, not waiting to idle time to complete this process.

Since my last post, I attempted installing my XP Home OEM XPCD again, this time with the new .Net packages generated by the most recent version of SNM Synth (again using all .NET Framework updates actually listed in Microsoft Update). This time, not only did the installation hang, but the .NET Framework Setup Verification Tool report shows errors.

FYI, the older SNM Synth .Net installation packages that worked (after resetting the PC in the middle of RunOnceEx) were built by 20090514_SNMsynth.zip. The only other difference between those packages and newer ones is the new ones contain NDP35SP1-KB963707-x86.exe.

Here's a download link to the requested logs: SNM-Synth-Logs.zip. I've also included the log file generated by .NET Framework Setup Verification Tool as well as the temp files generated by your INSTALL.cmd.

Thanks for the help.

I don't see anything strange in the logs. 3.5 SP1 installs correctly, and you reboot 10 minutes after runonceex hangs and 1.1 install takes effect. What's failing should be after 3.5 install command in its INSTALL.CMD file, and the best candidate is ngen as Dumpy Dooby was suspecting, I don't think the rest of the commands are stopping execution in this manner. Don't know what's failing, but I have to suppose it has to do with something in your xp home source (the way you modified it or not) with 3.5, because ngen (if that's what's failing) is not hanging RunOnceEx when it is ran from 3.0 SNMsynth installer. If ngen is the culprit, this doesn't mean it is not finishing its work, if it didn't finish it before reboot, it will after reboot on idle time. You should check event viewer to see if any errors was produced by ngen or anything apart of .NET installing.

If the error was caused by ngen, you can try to avoid this error by removing ngen command from 3.5 INSTALL.CMD script, this will cause the default .NET behavior of running it later at idle time, and surely then it won't break anything. Or you can use RunOnce or GUIRunOnce instead of RunOnceEx to still run it at logon, probably it's something with RunOnceEx and not with install time.
And anyway, now you can too install all frameworks during GUI-setup as new SNMsynth versions managed to workaround the errors that 3.0 was producing in event viewer (actually it didn't harm anything) when installed at that time, surely it'll can finish correctly.

What if he tried?:


Then it won't wait for ngen.exe to finish, but it can still run in the background.

Would that have any negative effects?

Then it won't wait to idle time, and there should not be negative effects, as neither there are not when you install .NET from original installers, it's just a compiling process, but it will slow down other tasks running, that's what this script avoids. But in your example you should run ngen executequeueditems

strel
I re-integrated an XPCD for Windows XP Home (OEM) and Windows XP Pro (Volume), both installing .Net Framework packages built with the latest SNM Syth build. Both install the .Net Framework packages from svcpack.inf in this order:

• DNF20.exe
• DNF30.exe
• DNF35.exe
• DNF11.exe

I installed the Windows XP Home to the actual PC, and Windows XP Pro to Virtual PC, and in both cases Windows Setup never hangs. It is still puzzling about why RunOnceEX would just hang, but it looks like the issue is safely worked around when installing from svcpack.inf (which I would rather install from anyway).

Now in both installations, the .NET Framework Setup Verification Tool still shows several errors of files missing. However, I can see now that they are files for languages other than English (all are named with 4-digit language codes and 1033, which is English is not reported as missing). Since everyone I support speaks only English, I do not install any language packs. So I'm guessing that the errors reported by this tool are not as big of a deal as I first thought.

Again, thanks for your help.

-DS

I don't think they are language package files, but generic english installer localization files. They are removed intentionally, so don't worry. And thx for the information.

My installer is working fine again.

skyhacker
Sorry, I've just read your PM now. I'm confused you say you integrated an AIO 20090922 add-on with nLite. You say all frameworks got installed, but KB951847 is still listed in win/ms update. But you say too, no logs are present in %SYSTEMROOT% (20090922 bug when installed from T-13/nLite) nor in %TEMP%, and no framework version appear in add/remove programs.
I'm wondering if actualy you got installed any framework at all. Can you check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{VARIOUS GUID FOLDERS}\DisplayName values for .NET versions installed? If there's frameworks installed you can use the command in the UninstallString value, on a command line to uninstall each framework or langpack; and then reinstall manually with SNMsynth installer (you'll find it in i386\SVCPACK folder in your windows source, or you can extract it from the nLite add-on), to get the install logs in %TEMP% and check what's happening with KB951847FIX.

Raoul90
Glad to hear that.

[edit]
Let me preface this post by saying that it has nothing to do with your program. I'm merely using this thread as a public place to ask you a question, and I didn't think my question warranted a thread all to itself.
[/edit]

Hey strel, do you know if there is an easy way to override the rollback setting for the .NET Frameworks? The reason I ask is because the installation time could be decreased tremendously if we could get FASTOEM to work with these (I'd recommend making it conditioned on whether the user is running the installation during a system setup, i.e., from svcpack or first boot; on a live installation, you don't want to use FASTOEM). FASTOEM forces the installation routine to disable the creation of a rollback script. The .NET Frameworks look for the rollback script, and if it isn't there, they exit so as not to have a broken installation. Obviously there would be no such broken installation if it's being run from SVCPACK and the like. Additionally, disabling the rollback script also disables "commit custom actions," which is why .NET Frameworks are freaking out.

If there is a way to re-enable rollbacking via an MST or something, that would be wonderful.

These are the public properties that I set:


As you can see, I tried overriding FASTOEM's preference to disable the rollback script by manually disabling the DISABLEROLLBACK property, but that didn't work because FASTOEM is always processed last in the public property check.


In my above example, I was trying to do it with .NET Framework. As expected, the installer exited with an error, "You must enable rollback to continue with setup."


So any thoughts on this one? I'm thinking it's impossible because FASTOEM moves files instead of copying them, which means that a rollback script would be next to impossible to manage. But if you have any suggestions, I'm all ears.

I've tried to use this property without success before, but I may be mistaken.

Don't forget /qn switch. Don't know if it would make a difference but you can try modifying it as system policy (REG_DWORD values):

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer\DisableRollback

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer\DisableRollback

You can try to do it too with an .mst, setting the the property with a custom action of the required type, and inserting an instance of the custom action in the InstallExecuteSequence table, search a verbosity logfile for DISABLEROLLBACK property before sequencing, to get an idea of what position to use in the sequence.

Anyway I'm dubious about the possibility of success. Tell us your progress.

Yeah, I perused a verbose log file and saw that an "OEM" instance will always trigger a DisableRollback.

I had tried setting those registry keys before, but that didn't work. I set the registry keys, and then changed the permission on them to prevent the "SYSTEM" account from writing to them, and that didn't work either.


The only option I can think of would be to remove all of the checks from the MSI itself (via MST or otherwise), but then I have a feeling that the installation of the frameworks will fail because of its inability to commit custom actions.

And yeah, I use /qn. My previous post only showed what public properties I was setting. The full command line would look something more like this (in a batch file):



I'll play with the MSI a bit and see what I can do.



On a side note, using the "+" directive for the logging switch does append the log file, but it seems to be inserting a NULL as every other character. I have to do a regex find/replace for \x00 (hex value for NUL). Any idea why it does that? Is there a specific encoding that you know that I should be using when creating that file? I'm only asking because you seem to know your way around MSI deployment; figured you might know.

Are you using the latest windows installer for your OS? I'm reading the 3.1 version solves an issue about logging null characters used in a registry value marker or a service dependency.

Yeah, I'm using 4.5.6001.22159.

If I let MSIEXEC create the log file, then this doesn't happen, even when subsequent installations append to it. It's only when I create the log file beforehand. Maybe it's an encoding issue. Anyway, it's not a big deal. I just figured I'd ask you in case you knew. It's something I can easily overcome just by making a few adjustments to my installation routine.

EDIT: About encoding maybe you're wondering if I changed something on the .msi files to apply the transforms or so. That's not the case. For the next version some tricky operations changing encoding setting on the .msi files will be done to apply some transforms to langpacks, but encoding setting will be reverted inmediately after this. So I don't think this method is causing any encoding problems for the version you're using (nor for the next one), if any, may be there before.

Nevertheless, I'm not a guru of anything. You should try in appdeploy.com message boards, sure there you'll get more detailed information about this, if any.

New update released:

Ugh. I can't figure out what WUFIXES.MST does, exactly, so I can modify it to support the newest update. I got the update applied to the MSI just fine, but I don't know what changes need to be made to WUFIXES.MST. :\

George King
A lot of thx. I've included it in the guide.

Dumpy Dooby
NETWUFIXES.mst (in the latest release) contains ad-hoc fixes to block some hotfixes for not to appear in win/ms update, because of its absolut nonsense (the case of langpacks for SP0 versions, not even installed) or because they are not really needed unless you use this piece of software, though ms pushed them to you as if they were required (that's the case of .NET 3.0 and .NET 3.5). I have yet to install the new hotfix to see if there is any surprises that would require an extra fix to correctly apply it, but I don't expect that. The script process this new hotfix seamlessly, so no changes needed there about it.

Oh really? I thought you and YumeYao were doing something with the MST that required an update every time there's a new hotfix release. If what you're saying is correct, then awesome. I'm all set then.


I was able to export the data from the MST, by the way. I saw the VBS files. I actually just got them extracted from it and I was looking to see what I needed to modify to make it work right. I'm glad I decided to stop by this thread first because I've now learned that I don't need to change anything! Yay!


Thanks for the info.

This does not work for me, I'm sorry.
I added KB974417 yesterday when I rebuilt my silent .Net packages (2.0SP2, 3.0SP2 and 3.5SP1) for T-13 installation (doing my WIndows setup with hfslip) witn SNM of 20090922, but afterwards this patch was still listed as missing in Windows resp. Microsoft Update... For some reason it is not recognized as installed.
Can anybody confirm this? Can I help somehow in debugging? Thanks in advance!

Regards,
Tomalak

I've added too KB953297 for 1.1 fx with a "not supported" advice as well as to KB974417.
Checking...

I can confirm.

After applying the patch:

...and reinstalling Windows completely with integrated .NET Frameworks,

I get this:






Edit--
I don't install Microsoft .NET Framework 1.1. So there may or may not be updates that show up once that's installed.

I can verify that the following files are actually getting copied over:
- dotNET20SP2\Win\Microsoft.NET\Framework\URTInstallPath\mscordacwks.dll
- dotNET20SP2\Win\Microsoft.NET\Framework\URTInstallPath\mscorlib.dll
- dotNET20SP2\Win\Microsoft.NET\Framework\URTInstallPath\mscorwks.dll

They are receiving the GDR update from the MSP.


So it's just a matter of manually telling WU that the hotfix is installed, right?

i think it's the same as KB951847 when we had to add a few reg keys to supress MU.
i'm actually in midst of a looooong manual install straight off of MU to see what is required.
**** only spare pc i had was a PII800, i cant remember taking hours to install.

unless someone has the keys already...

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\DC3BF90CC0D3D2F398A9A6D1762F70F3\Patches
HKLM\SOFTWARE\Classes\Installer\Products\DC3BF90CC0D3D2F398A9A6D1762F70F3\Patches

There seems to be an issue with applying the hotfix.

Here's a program that utilizes one of the files. Just drag and drop an EXE onto this program (it's written by a fellow community member; the program reduces the privileges of an EXE) and it should work. Test it without the latest hotfix slipstreamed into .NET FW 2, and you'll see that it works. Then test it after the hotfix has been slipstreamed, and it will say it can't find that file.

http://xp.xpdnc.org/RunRestricted.exe

So something's not right.

removed did it a diferent way.

@ Strel & Dumpy Dooby

integrate the KB974417 msp than to stop the MU nag add the below reg key.

Thanks user_hidden

Also when integrating KB974417 add this line to what you already mentioned:

sorry for late replying, I am a little busy these days.

What strel said is not correct on the new KB974417, we still need a reg fix if we pre-apply msp to the install package.
It's totally similar as how we block KB95848x.(KB951847).

The key is:
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\DC3BF90CC0D3D2F398A9A6D1762F70F3\Patches\9E0DE89293FE9BB33898F24ED18CCF08"
Add this key, then a dword value "State"=0x1 under it.

the key name in "patches" can be calculated like this:
Click to view attachment
This is also a generic way to convert a GUID to plain text.

best regards.

Great info. Thanks for posting YumeYao.

Forgive me guys for not being up to speed with what you are talking about. I'm using silent .net maker for a combined .NET 1 and 2 addon pack for nlite. And yes, KB974417 is still showing up under automatic updates even tho SNM reported that it was processed. What exactly is the fix for nlite/SNM so you don't have to screw with anything after a fresh install?



Can I make nlite add the above reg key? Forgive me, but I'm not too good with this stuff yet....

you can save it as *.reg, and merge it into your registry.

Ok. Thanks. I assume you mean to add 'regedit' as a runonce command and point it to the above *.reg file on the installation media? I'll give it a try.

yes, it's ok as far as it's added at any time after .NET installation.

As I have not yet seen the latest Windows 2000 specific patches listed in this thread, I'd best mention them:

For .Net 1.1 sp1:
dotnetfx.exe
NDP1.1sp1-KB867460-X86.exe
NDP1.1sp1-KB953297-X86.exe
NDP1.1sp1-KB971108-X86.exe Required for W2K (replaces KB947742)

For .Net 2.0 sp2:
NetFx20SP2_x86.exe
NDP20SP2-KB958481-x86.exe
NDP20SP2-KB974417-x86.exe
NDP20SP2-KB971111-x86.exe Required for W2K

Even better: save it with the name DNF20.REG and place it in the root of the 7zip sfx archive (use 7zip split and 7zip for this)
I have used this content, thank to zorro:


works flawless with snmsynth 20090922.

Hi,

Could you update snmsynth 20090922 so that it takes into account the new update (NDP20SP2-KB974417-x86.exe)?
I tried this version but the update is requested by Windows so I think it did not work ....
Thank you in advance

good info. thanks dude.

I guess strel is busy IRL. If needed I can help update his script.

Hi,

Could you update snmsynth 20090922 so that it takes into account the new update (NDP20SP2-KB974417-x86.exe)?
I tried this version but the update is requested by Windows so I think it did not work ....
Thank you in advance