strel Posted October 10, 2009 Author Posted October 10, 2009 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\DisableRollbackHKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer\DisableRollbackYou 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.
Dumpy Dooby Posted October 10, 2009 Posted October 10, 2009 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):msiexec.exe /qn /l*v+ "%SystemRoot%\RSRTerr.log" /i "%~dp0dotNET20SP2\Netfx20a_x86.msi" ADDEPLOY=1 ARPSYSTEMCOMPONENT=0 ARPNOMODIFY=0 ARPNOREPAIR=0 REBOOT=ReallySuppress FASTOEM=1 ALLUSERS=1 DISABLEROLLBACK=0 CURRENTDIRECTORY="%~dp0dotNET20SP2" MEDIAPACKAGEPATH="%~dp0dotNET20SP2" ROOTDRIVE="%~d0"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.
strel Posted October 10, 2009 Author Posted October 10, 2009 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.
Dumpy Dooby Posted October 10, 2009 Posted October 10, 2009 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.
strel Posted October 10, 2009 Author Posted October 10, 2009 (edited) 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. Edited October 25, 2009 by strel
George King Posted October 13, 2009 Posted October 13, 2009 New update released:http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=491874d4-5eea-4545-9b7d-3861857c862e
Dumpy Dooby Posted October 13, 2009 Posted October 13, 2009 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. :\
strel Posted October 14, 2009 Author Posted October 14, 2009 (edited) George KingA lot of thx. I've included it in the guide.Dumpy DoobyNETWUFIXES.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. Edited October 14, 2009 by strel
Dumpy Dooby Posted October 14, 2009 Posted October 14, 2009 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.
Tomalak Posted October 14, 2009 Posted October 14, 2009 George KingA lot of thx. I've included it in the guide.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
strel Posted October 14, 2009 Author Posted October 14, 2009 I've added too KB953297 for 1.1 fx with a "not supported" advice as well as to KB974417.Checking...
Dumpy Dooby Posted October 14, 2009 Posted October 14, 2009 (edited) I can confirm.After applying the patch:msiexec /p NDP20SP2-KB974417.msp /a Netfx20a_x86.msi...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. Edited October 14, 2009 by Dumpy Dooby
Dumpy Dooby Posted October 14, 2009 Posted October 14, 2009 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.dllThey are receiving the GDR update from the MSP.So it's just a matter of manually telling WU that the hotfix is installed, right?
user_hidden Posted October 15, 2009 Posted October 15, 2009 (edited) 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.dllThey 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\PatchesHKLM\SOFTWARE\Classes\Installer\Products\DC3BF90CC0D3D2F398A9A6D1762F70F3\Patches Edited October 15, 2009 by user_hidden
Dumpy Dooby Posted October 15, 2009 Posted October 15, 2009 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.exeSo something's not right.
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now