ponghy

Ok, I checked it out that package and Ryan removes the source cache feature. This is the way I've repackaged my version, but it's not the better solution (may be the only one). The repair capability is missing from Add or Remove Programs. The original package from Microsoft can be repaired with its installer, but not this one. Thanks anyway for your reply.

Tomcat76, are you there? Anyone?

@Tomcat76: Okey, it worked reversing steps 3 and 4, but I have the problem said above: As a result, if you try to repair the existent installation through Add or Remove Programs (click "Modify or remove" and then select "Repair"), .NET Framework 2.0 Setup finalizes with an irrecoverable error. I'm completely sure this issue is because the netfx.msi file in the source cache subdirectory is not properly updated. Check out this and you'll agree. If this issue is true (and it is, believe me), I'm wondering if replacing the netfx.msi file in the CSetupMM subdirectory with the updated version (the NON-administrative image) and hacking the netfx.msi file (the administrative image, located on the root directory of the package) with Orca (I have experience modifying MSI files with the Orca editor) can workaround the problem. May be changing the size and hash values in the File and FileSaid tables? The last problem is, how can I compute the new hash of the updated netfx.msi? Of course, the irrecoverable error does not occur if CSetupMM contains the updated version of netfx.msi. .NET 2.0 Setup expects the updated version in the cache repository. Thanks again. I hope we can solve this issue together. It may be useful for your Silent .NET Maker, if you didn't realize the source cache issue.

@Asymmetry: nLite does not create entries corresponding to hotfixes in the Add or Remove Programs dialog if they are directly integrated. That hotfix which you can see probably it is from a Windows Media Player installed separately or another application which installs hotfixes. However, those 61 hotfixes will be installed. You can check out this visiting the Windows Update web site. The reason for this is because nLite slipstreams files included in hotfixes directly to the installation source, replacing the originals on the I386 folder. If you want to see again the entries in ARP, uncheck the option "Direct integration" in the "Advanced options" button of nLite. Note that disabling direct integration installation will be slower at T-13 phase (because hotfixes must be launched one by one) and the installation source will take more space on the CD/DVD.

@Tomcat76: I do the following: 1) Extract dotnetfx.exe with WinRAR (it's not necessary to extract with the /t switch, WinRAR it does well) to the dotnetfx directory. 2) Extract the MSP file from the EXE patch (KB928365) with WinRAR too. 3) Apply the patch to the extracted installation: msiexec /p KB928365.msp /a dotnetfx\netfx.msi The patch makes some folders with the new versions of the files in the dotnetfx directory. Note netfx.msi is NOT an administrative image at this point. 4) Now, I perform the administrative install: dotnetfx\install.exe /a to a target directory, such as c:\temp. The administrative installation point is created with the patch applied. This method it worked for KB917283 and KB922770, but not for KB928365. Very strange... If I switch steps 3 and 4, the administrative image is properly generated, but the netfx.msi file in the source cache subdirectory (\Win\Microsoft.NET\Framework\URTInstallPath\CSetupMM\netfx.msi) is NOT updated. Be careful with this, because no repairs can be made if the netfx.msi of this subdirectory is not properly updated. Therefore, I don't reverse steps 3 and 4. But, all my theories don't work for KB928365. Have you integrated KB928365 in the .NET 2.0 administrative installation point. How? Please, help. And thanks very much for your interest. I know this issue is not easy to workaround...

@Asymmetry: You don't have any catalog in the [ProductCatalogsToInstall] section. If you have Windows File Protection enabled, catalogs are required. Also, try to remove the qchain.exe file at the end. This tool is obsolete, since new hotfixes have this tool integrated. Qchain allows to install several updates without rebooting. This is no longer necessary. Note: In order to integrate hotfixes, it is necessary to use the /integrate switch with type 1 hotfixes. How did you integrate the hotfixes? It's not enough editing the SVCPACK.INF file. Another changes are required.

Hi all: I'd like to know how to integrate the new KB928365 hotfix into the .NET 2.0 installation files. I've tried the following, but no go: 1) Uncompress the dotnetfx.exe package. 2) Apply the the MSP patch file to the Netfx.msi file (msiexec /p ...) 3) Do an administrative install to another directory. 4) Repack the files installed in step 3. Also, I tried swapping steps 2 and 3 (e.g., first, do the administrative install and then, apply the patch to the extracted files). The integration appears ok (no errors are shown), but Windows Update shows me 3 security updates, including KB928365 (which replaces KB917283 and KB922770). My question is: Is there any way to REALLY integrate the KB928365 patch to the installation files? And please, don't suggest me any third-party packs, like silent installers and so on. I want to know how to achieve this myself. The method above it worked to integrate KB917283 and KB922770, but not for KB928365. Thanks very much

Change OemSkipWelcome=0 To: OemSkipWelcome=1

@Asymmetry: This is not a WFP issue, but a non-signed desktop theme issue. You need to patch the UXTHEME.DLL file. Read carefully the following page of the Unattended Guide: http://unattended.msfn.org/unattended.xp/view/web/67/ Good luck

Hi ElTorquiro: I've carefully read your post here. Indeed, a very good research work . I'm very surprised with your discovery, put the '\\' character at the beginning of any path in SFCFILES.DLL But, are you completely sure this will not have adverse effects? I'm unsure if modifying system files is a good idea, although SFCFILES.DLL is not signed. Let me explain the SfcFileException() trick: According to Collake's researchings (http://www.bitsum.com/aboutwfp.asp), this API function generates an exception in the watcher thread of SFC, so no files will be modified in the system, but SFC is instructed to unprotect the file. It works very well. You can run SFC /SCANNOW and the file will not appear! But, it's not perfect, and it has a little fault. Suppose the following scenario: 1) You upgrade your Windows version with another version which reinstalls the previously unprotected file. 2) You use my tool to delete again the unprotected file. And yes, the file will disappear from the system32 subdirectory (no attempts are made to restore it. This is good). 3) But if you run again the SFC /SCANNOW command, the file will appear ONLY at the dllcache subdirectory!! Note the file will NOT appear under the system32 subdirectory (thus, the file will not be "present" for the system, i.e., it will not be usable). I think it's necessary to add your trick to my tool, in order to permanent delete the file across Windows reinstalls. If you want, I can send you via PM the source code of my tool. It's written in pure C++ (not C# or .NET), compiled with VC++ 6.0. Thanks for your interest too PD: I think Windows updates use the SfcFileException() method in order to delete unnecesary/unsupported files, because they have the SAME fault as described in the above scenario... PD2: Do you think it is possible to install a patched SFCFILES.DLL file directly from installation source (i.e., replace the original file in the I386 installation source with the patched and modifype'd version)?

Yes, you're right. Thanks for the tip. Finally, I've coded my own tool to delete the protected system file, by calling the SfcFileException() undocumented API function. It works like a charm and probably it's the only way to bypass WFP. If anyone is interested in my tool, let me know.

@NaDer_GenKO: It's an 'old' update, but still not superceded by another one. See the release date (2/7/2007). This patch updates the local time of many countries. It may be useful.

@mrnxdmx: I think you'll find no "official response". Most Windows setup files are not documented at all. Remember this is propietary software, so Microsoft reserves the rights of not documenting certain parts of the operating system. Only researchers and hackers (such as the the missing gosh of this forum) can explain them. And not completely, only partially. I think the exact purpose of this section still is unknown. However, in my own tests I've found out that this section is necessary when you add files of your own (like drivers), because if you don't make this, Windows Setup can show you an error box indicating the file was not found and Setup is unable to continue... Add the undocumented flag "16" to each added file. This is specially true when upgrading from another version of Windows. Hope this helps.

Ok, thanks for your reply, cluberti I've installed the complex and powerful Process Monitor tool from Sysinternals. Then, I've installed the patch and monitored the changes. But there are several changes to analyze, even with activated filters!!! I can pass you the log if you want help me a bit more... Thanks again

I believe it's possible. Install the system normally with the target file (plugin.ocx). Now, install the KB933566 hotfix (a cumulative update of IE) and you'll realize that this hotfix PERMANENTLY removes this file from the system and this file is no longer protected by Windows File Protection. These actions are done without any error in the event log (try this in a VM and you'll agree). With this idea, I've tried to monitor the system changes when installing this patch, but I've not found the proper registry entry or file modification that do the trick. Download the KB933566 patch. Now, run it and find the temporary directory this patch creates in order to put the extracted files (for example, C:\a0c7cbee6146a2ef23). Then, navigate to the update subdirectory and open the update_SP2QFE.inf file. Now, search for the [system32.Delfiles] and [Cache.Delfiles] sections. Note that these sections only reference 1 file, my target file: plugin.ocx. Indeed, these sections are launched by 2 DelFiles directives in the [ProductInstall.ReplaceFilesIfExist] section: [ProductInstall.ReplaceFilesIfExist] DelFiles=Cache.Delfiles; <-------- Directive to permanently remove the file from the WFP repository. CopyFiles=System32.files CopyFiles=program_files.internet_explorer DelFiles=System32.Delfiles; <-------- Directive to permanently remove the file from the System folder. Due to this, I think it's possible to emulate the patch behavior, but how? Any other user with experience in monitoring registry and file changes can do the test for me? (in a VM, of course). Thanks very much in advance

Thanks for your replies. @cluberti: It's the "plugin.ocx" old file. This is no longer supported by Microsoft, and it's deleted in serveral cumulative updates of Internet Explorer. If I remove that file from installation source I get the following error in setuperr.log: LoadLibrary cannot register ActiveX control blah blah blah... Is it possible to get rid of this file?? (without the previous error). @jdoe: Actually, that trick doesn't work. If you leave the CD-ROM inserted on the drive, Windows File Protection will silently copy the file again, without warning boxes.

@Wesmosis: Yes. In fact, the standard name for unattended upgrades is "Unattend.txt", but you can name it as you want. WINNT32.EXE /unattend:winnt2.sif for example. If your drive letter is D and the SIF file is located on the I386 folder of this drive, then it would be: WINNT32.EXE /unattend:D:\I386\winnt2.sif Under odd circumstances (depending of the content of the SIF file and the Windows version which you are upgrading) it may be necessary to copy the SIF file from CD-ROM to a temporary folder and then invoke the WINNT32 command referencing the copied file, because Setup will not found the CD-ROM drive after rebooting. Inspect the \Windows\setuperr.log file when the upgrade is complete. If you see errors indicating missing sections and the like, you need to copy the SIF file to the temporary directory first. For example: WINNT32.exe /unattend:C:\Windows\Temp\winnt2.sif Hope this helps.

Hi all. I'd like to know how to delete a file located on the system32 and dllcache subdirectories after the operating system is installed. If I delete the file with a VBScript after the system is installed, this file is automatically regenerated (copied again from source). I've tried several ways, including the editing of \Windows\System32\restore\filelist.xml in order to add the file to the exclusion list. Please, bear in mind that I don't want to disable or hack Windows File Protection, only exclude this file of the list of protected files. The file should be deleted permanently. And another important thing: I don't want to remove this file from the installation source in order to avoid errors in the setup log. Is this possible? Thanks.

May be you need Windows Installer 3.x at least? You cand download 3.1v2 from HERE.

You must register before trying this app: http://www.vmware.com/download/ws/eval.html . You have a 30-day trial period for evaluation. It is located on the I386 directory of your installation source (setup disc). That is. You must not leave that field blank. If so, Setup will prompt you the password at T-33 phase. If you don't want a password for this user, you must specify an asterisk ('*') as a value (i.e. "AdminPassword = *"). Don't remove any networking component with nLite. Do the test again without removing anything and check the results. Good luck.

Verify the installation media (discs) for errors. Also use a virtual machine to perform your tests (VMware recommended over Virtual PC). If Setup is asking you the Administrator password is because you have not included the following directive in your WINNT.SIF file: [GuiUnattended] AdminPassword = "your_password" Open your WINNT.SIF file and check if that line is in it.

Nilfred: Why do you think KB927891 is a trojan horse directly from Microsoft? I have checked it out and it appears harmless. Only it has a DLL file to update the Windows Installer engine...

Thanks for your reply.

Anyone?

I'm not explaining "a method", only I'm explaining that probably OOBEINFO is not processed if the UnattendSwitch = Yes directive is set. Can you explain better why it is 'useless'?