ponghy

Thanks for your answers prathapml: I know that pack, and I know nLite does an excellent work integrating updates. The purpose of my post is only 'experimental'. I'm trying to 'decipher' the copy directives of TXTSETUP.SIF following the superb Gosh tutorial. I have been doing some tests with fresh installs and upgrades, and in upgrades, some files are not overwritten by newer versions (I understand the upgrade and new install code, but I want to perform a double-check). Thanks again for your help

Hi guys. I need technical and comprehensive information about how Windows Update detects installed hotfixes and checks for correct file versions. I need to do a self-check in my nLited CD install. I must ensure that *ALL* file versions are properly updated. I'm talking about 90+ hotfixes, therefore it is a very hard work. If Windows Update does not show an specific update, can I say that this update is correctly installed (*all file versions*)?. If I downgrade a file corresponding to a hotfix, will WU say that this update is NOT installed? Does WU check for ALL files of a hotfix or only for *key* files? Another problem is I have integrated non-critical & non-recommended hotfixes that they're not recognised by WU. How can I do a sanity-check for these hotfixes without WU? Do QFECheck or MBSA will do this? Thanks in advance PD: I need the above because I have *modified* the INF files created by nLite for "experimental" purposes...

Ok, you're welcome. Let me know if it works (it should).

You can do this programatically by using the Win32_WindowsProductActivation WMI class. You can write a VBS script to do this. More info here. Here is explained how to implement this. See the following example: Option Explicit Dim obj, activated For Each obj In GetObject("WinMgmts:{impersonationLevel=impersonate}").InstancesOf("Win32_WindowsProductActivation") ' You need the ActivationRequired field of the current instance (e.g., "current computer"). If obj.ActivationRequired = 0 Then activated = True Else activated = False End If Next If activated Then ' Install IE 7, WMP11... Set obj = CreateObject("WScript.Shell") obj.Run "your_command_line1_here", 0, True obj.Run "your_command_line2_here", 0, True obj.Run "your_command_line3_here", 0, True ' ... etc. ' Free resources. Set obj = Nothing End If Hope this helps. Ponghy.-

The most accurate solution (if you cannot to apply the tweak at T-12, when the Default User profile is loaded to the Registry, and no users exist, except Administrator and special users like SYSTEM), but the hardest to perfom, is to modify the Default User profile and other profiles you want to modify. Users are identified in the Registry with a SID (Security Identifier), a long alphanumeric string. You can get the SID of a user by querying the Win32_UserAccount WMI class. In the query, specify the user name and the domain name (the local computer if you're not in a domain). When you get the user instance, you must retrieve the SID field with this string. When you get his SID, you can get his profile path, by querying the following key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<User_SID>\ProfileImagePath where <User_SID> is the user's SID. ProfileImagePath is a REG_EXPAND_SZ string, so you must to expand it before use it. Then, load the profile to the Registry, in memory, by using the REG.EXE tool: REG LOAD HKU\AN_USER <Path_To_User_Profile>\NTUSER.DAT Note NTUSER.DAT is the user hive on disk. You will get a new hive under the HKEY_USERS key, named "AN_USER" with all settings of the specified user. You can write or modify any value under this key. When you're done, unload the hive by using the REG.EXE tool again: REG UNLOAD HKU\AN_USER Changes will be committed to disk, and the profile will be permanently changed. For the default user, you can get his profile path by querying the following values: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ProfilesDirectory HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\DefaultUserProfile With the first value, you get the base path (e.g. C:\Documents and Settings on a XP System) and with the second, the name of the default user, usually "Default User". Now, build the entire path to the profile: <First_value>"\"<second_value>"\""NTUSER.DAT", and you're done. Repeat the same steps above to load and unload the hive. By modifying the default user profile, *all new users* you create will *take* the changes. The default profile has NO effect on existing users. Remember HKEY_CURRENT_USER is NOT the default profile, but the current profile (the current user logged on to the machine). I have a VBS script that performs this. If you want, I can post some parts of it. Hope this helps. Ponghy.-

Can you be more explicit? Thanks.

Nuhi, can you give me a solution for this? I know this is not easy, bue there must be a way, don't you? I'm familiar with editing INF files, so don't worry for the complexity of your solution. Thanks again

The KB925454 cumulative security update for IE 6 is not recognized by Windows Update when using direct integration. I'm using a fresh Windows XP Pro SP2 source (spanish language). I know that IE 6 cumulative updates are special for nLite, because the language files. But, Is there any workaround for this issue? (modifying config files, INF files, etc.). Thanks. Regards and keep up the good work. PD: I'm using nLite 1.2.1, not 1.3 beta.

Bump

the_guy: Are you sure KB885835 is replaced by KB924270 for XP? MS Bulletin says: Windows XP Service Pack 2 -> MS06-040: Replaced (only KB921883). Regards

Hi Nuhi: No, I've used only the original exe from Microsoft to integrate directly with nLite as a normal hotfix (ASMS compression was NOT checked). nLite version used was 1.2.1 final. Tested on a fresh Windows XP Prof. SP2 source. Thanks very much for your support.

No ideas?

I can confirm this issue even with NO hotfixes integrated. Only IE 7.

Ok, I have to say I've integrated IE 7 final in spanish, version 7.00.5730.11. Anyone else with this problem? May it be language-specific? Thanks again.

Hi Nuhi. I've tested your fabolous nLite 1.2.1 and I've seen the following problem: When integrating IE 7 into the install (and of course several hotfixes too), I get the following error messages in C:\WINDOWS\Setuperr.log: Error: Setup program could not register OLE control C:\WINDOWS\system32\mshtml.dll due to the following error: GetProcAddress returned error code 127 (specified procedure was not found). *** Error: Setup program could not register OLE control C:\WINDOWS\system32\msrating.dll due to the following error: GetProcAddress returned error code 127 (specified procedure was not found). *** Error: Setup program could not register OLE control C:\WINDOWS\system32\inseng.dll due to the following error: GetProcAddress returned error code 127 (specified procedure was not found). *** Error: Setup program could not register OLE control C:\WINDOWS\system32\webcheck.dll due to the following error: GetProcAddress returned error code 127 (specified procedure was not found). *** Error: Setup program could not register OLE control C:\WINDOWS\system32\imgutil.dll due to the following error: GetProcAddress returned error code 127 (specified procedure was not found). *** Error: Setup program could not register OLE control C:\WINDOWS\system32\pngfilt.dll due to the following error: GetProcAddress returned error code 127 (specified procedure was not found). *** Note 1: The messages have been translated to english because my language is spanish. Note 2: I've used *only* hotfix direct integration feature of nLite. I've not removed any component nor applied any tweak. Can you confirm if this is a bug in nLite 1.2.1? Thanks very much in advance. Regards.

I've downloaded the integrated version of the RyanVM site. Apparently is similar to mine, but RyanVM's works perfectly. I'd like to know what are the exact steps he has made to make the package (skip the steps to compress in 7-zip). Thanks very much.

I think I've found the problem: It's a bug on the administrative install of patch KB917283. If you do the admin install without the patch (install /a) and install the framework, you can uninstall without problems from Add or Remove Programs. But if you "slipstream" the KB917283 patch in the usual way: msiexec /p [extracted_msp_file_from_patch] /a netfx.msi The patch would be integrated with the main install, but you could NOT uninstall the framework in Add or Remove Programs. If you attempt it, you'll receive a severe error (Microsoft ask you to send an error report), and the uninstall process will FAIL. Anyone can reproduce this bug and confirm it? Thanks and regards.

Hi Mikesw, I will try to answer some questions: Those folders ("Program Files", "Windows") are needed for the administrative install of .NET Framework. They are the result of the 'expansion' of the original netfx.msi. You can install the Framework directly with the MSI in the following manner: msiexec /i netfx.msi ADDEPLOY=1 Notice the public property ADDEPLOY. This is necessary because the MSI was designed to work with the install.exe program. With this directive, we force the installation through the MSI, without the wrapper. But be careful, installing in this way is NOT recommended. Install.exe stops the Windows Installer service and performs several sanity checks that Windows Installer doesn't. The recommended way is this: Copy the install.exe, install.ini and install.*.res files to the administrative installation. Also copy unicows.dll and EULA.*.txt files. So, you can install the administrative install point with the original installer, by simply running install.exe (it is more secure, believe me). Note: If you are going to use only the english language, you can get rid of the install.*.res and EULA.*.txt. Only copy install.1033.res and EULA.1033.txt. The issue of non-recogntion of KB917283 is well known in this forum, and people think is a Microsoft bug (I agree). Don't worry, if you did this: msiexec /p aspfix.msp /a netfx.msi Your netfx.msi will include the necessary modifications given by the KB917283 patch. You can substitute the Setup.exe file contained in the WinXP CD (DOTNETFX folder) in a simple manner: Follow the steps given in this post. When done, copy the file install.exe from original dotnetfx.exe (extract with WinRAR, for example) to the administrative install point of .NET Framework 1.x and you're done. You can install the framework by running install.exe. If you pass it the /Q switch will perform a silent installation. Again this is the recommended way due to the issues mentioned above. Hope this helps

Ok, thanks very much for your feedback Mmmm, I'm studying the Windows Installer technical reference, and I've found this public property: REINSTALLMODE=<value> The reference claims if REINSTALLMODE=v, Windows Installer recaches the source package. I've not checked it out yet but it is interesting... Another question, more off-topic: I see in my profile a Warn message (with value 0%). Have I violated any forum rules? Any moderator can answer to this? I've tried to accomplish the rules all the moment...

I've changed my mind to pack the .NET 2.0 Framework. due to the 'null success' of this post. Therefore, I've decided to do an admin install patched with KB917283. I'm doing the following: install /a -> to do the main admin install. msiexec /p aspfix.msp /a netfx.msi -> to patch the netfx.msi against the KB917283 hotfix. To install the product, I run install.exe from a wrapper written by me (note I'm not using direct MSI install with MSIEXEC). Everything was fine, except when uninstalling the product. If I click on the Remove button of Add Remove Programs, Installer exists with severe serror (prompts me to send an error report to Microsoft). I've investigated the problem and I've found that install.exe copies all source files to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft .NET Framework 2.0, but the 'cached' netfx.msi is DIFFERENT from the patched netfx.msi. Indeed, the patched netfx.msi occupies about 3MB apart from install directories ("Program Files", "Windows"), and the 'cached' MSI (the MSI located on that folder) occupies about 24MB (this has no install directories, I think this stored distribution is the same as the original .NET 2.0). I suspect this MSI is the original, not the patched one. I'm pretty certain that when MSI files are different, Uninstall process cannot be done. The question is : how to workaround this? (save the proper files when installing, not the original ones). If this is not clear, my goal is to integrate .NET 2.0 + KB917283 in one pack, automated install from the shipped install.exe (more secure than installing the MSI file directly for several reasons). Installation is driven by a wrapper written by me, that calls install.exe with the proper arguments. I hope you guys can help me this time

You are right, WinRAR only extracts files from full installation packages, not from Microsoft patches. In order to extract the MSP you can do the following: [patch].exe /Xp:[path_to_extracted_msp] That is, use the /Xp: switch to extract to an specified file. For example: patch.exe /Xp:c:\net2\fix.msp (the c:\net2 folder must exist).

Hello and Welcome: Try this: msiexec /i %systemdrive%\winapps\dotnet\NETCFSetupv2.msi /q REBOOT=ReallySuppress I think Windows Installer (MSIEXEC) uses different modifiers of Windows patches (/q /n /z, for example). Good luck Ponghy.-

Please, give me some feedback. Any expert on Windows Installer?

Hi! I'm doing my own installation package with .NET 2.0 + ASP Fix KB917283 + Language Pack. But I have a problem, when I call in my installer to: "msiexec /p aspfix.msp /qb" (where aspfix.msp is the MSP file extracted from the security update KB917283), I got 2 message boxes in order to continue (not fully unattended). First message box is to continue install (accept) and the 2nd message box is the annoying EULA, that I have to accept in order to continue... I've searched in the forum and on the Internet and I have not found any useful solution to this. I've tried to open the MSP file in ORCA to disable the dialog and the EULA entirely, but I don't see the dialog tables... I've tried to pass common properties to Windows Installer (msiexec) like IAGREE="YES", EULA_ACCEPT=1, ACCEPT_EULA=1 and so on... but no luck!!! I don't want to perform an administrative install, because the resultant files are much more larger than the original ones (and they are compressed worse). Any ideas guys? I think this issue is not easy... but any idea will be appreciated. Thanks

Hi again! I'd like to know what registry entries these hotfixes create when they are installed from SVCPACK.INF. Any way to find out this? I've uncompressed these patches but I don't find any INF file with registry directives. I could use a RegShot like program, but I think this method is not very accurate, because other entries may be introduced in the registry while monitoring it (not related to these hotfixes). Thanks again