ponghy

If you are using the classic IE 6, place the following in WINNT.SIF: [Branding] BrandIeUsingUnattended = Yes ; Do not make any Microsoft-related favorite. [FavoritesEx] As you can see, if the FavoritesEx section is empty, no links will be created. This is the preferred form. Note: The above will not work with IE 7. Good luck.

Hi: I'm updating my nLited Windows XP Pro SP2 CD, still using IE 6 (IE 7 not integrated), and I have the following question: Since nLite is unable to slipstream KB931768 (cumulative update for IE 6), I'm slipstreaming this hotfix by hand. I've unpacked the hotfix, and I've checked the update\update_SP2QFE.inf file. Pay attention to this section of that file: [ProductInstall.ReplaceFilesIfExist] DelFiles=Cache.Delfiles CopyFiles=System32.files CopyFiles=program_files.internet_explorer DelFiles=System32.Delfiles [System32.Delfiles] plugin.ocx As you can see, this update removes a previous system file (plugin.ocx). Therefore, can I remove this file (plugin.ocx) from the installation source (CD) since this file is no longer needed? I know must update DOSNET.INF and TXTSETUP.SIF files, but I'm not sure if this action will produce problems in the near future... Any advise? Thanks

Indentation only is for readability purposes. Spaces to separate tokens are optional (again for readability purposes). Quotes only are needed with values containing spaces. For example "This value requires quotes" (note: The product key does NOT require quotes. Many people think quotes are required for this value, but not really, because it does not contain spaces). You can place comments in any place of the file (use the ';' symbol to begin a comment until the end of the line). Asterisk '*' is an special value to indicate null or default (depending of the directive), but only is recognised in some directives (for example AdminPassword = *, to assign a blank password to Administrator). Some directives only recognises a 0. For example, MsDosInitiated = 0 (value "1" is ignored). Other directives recognise "Yes" or "No". Values and directives are case-insensitive. Hope this helps.

I think OOBEINFO.INI is not processed if you specify this directive: UnattendSwitch = Yes in WINNT.SIF, but I'm not sure. According to ref.chm: I.e., "Windows Welcome" = "OOBE", and OOBEINFO.INI is processed by OOBE. Correct me if I'm wrong.

@elajua: Thanks for your reply. I'd like to reinstall (without uninstalling) the modified Messenger package over the standard package. Is this not possible? I've checked product codes and are the same... Since you are spanish american, I can show you the error, that is: (ellipsis indicates an arbitrary path, not relevant)The problem is when I launch the command to install WLM81.msi (the modified package) and if it is installed the standard package (MsnMsgs.msi), Windows Installer does not replace the standard for the modified one, simply it issues the previous error and terminates. I'd like to know a way to replace the standard package with the modified one without: - renaming the modified one to match the standard's name. - uninstalling the standard package. Assuming the product codes are the same for both packages (the same product). Is this possible elajua? Thanks very much for your interest

I'm experiencing the following problem: I've customized a Windows Live Messenger MSI package and I've changed the name of this package to WLM81.msi. If I reinstall this package over an existing Windows Live Messenger 8.1 *standard* package, not modified and named as 'MsnMsgs.msi' in the Windows Installer Cache (%WINDIR%\Installer) I get an error indicating a network issue (indeed, cannot find the original package 'MsnMsgs.msi'). My problem is that Windows Installer expects the MsnMsgs.msi file while reinstalling with the WLM81.msi. Do you understand? I want to suppress the error message and reinstall the WLM81.msi only if needed, i.e., reinstall missing parts of the application. I've tried the following: MsiExec /i WLM81.msi /qb TRANSFORMS=WLM81.mst REINSTALL=ALL REINSTALLMODE=vomus But I'm getting the same error as explained. The WLM81.mst transform contains my personal tweaks, but as you can see I don't modify the original package (WLM81.msi is *identical* to MsnMsgs.msi, only the name of the package is changed), so the product code should be the same ? Thanks for your help

Is this impossible? I would appreciate any answer...

Same problem here. Any solution for this (edit Layout.inf properly)?

I bump this topic since I'm experimenting an issue when rebooting at the RunOnceEx stage. I've properly setup the needed entries into the Registry in order to run my tasks, and the last task is the reboot. Okay, you know Windows runs some tasks in the First Run after the user logs on, in order to configure Desktop, Internet Explorer, Themes Setup, and so on. When the reboot begins, I notice Windows WANTS to launch the tasks I've mentioned (configure Desktop, Internet Explorer, Themes Setup, i.e., the First Run), but the reboot takes place and all tasks are FORCED to stop and close, producing the appearing (sometimes) of an Error message box with the following text (more or less): 'DLL initialization error: Application failed to initialize because the application window was closed...'. Sometimes, a blank message box appears with the following title 'Custom Settings'. Both boxes disappears in less than 1 second, but this issue generates an error in the Event Viewer with the Source name "Application Popup". If I remove the reboot process in the RunOnceEx stage, these errors are NOT generated (checked), but a reboot is necessary because I install programs which require it. I think the reboot task is not suitable if the "First Run" tasks are scheduled to launch AFTER the RunOnceEx keys are processed (and Windows always do this, check it out). My question is: Is there any way to avoid "The First Run" tasks the first time the user logs on to the system, then in the RunOnceEx stage prepare the Registry (or whatever) in order to schedule these tasks for the SECOND logon and finally reboot the system. In this way, Windows would not be forced to shutdown in an unpolite way. Any ideas? Anyone has been experimenting this issue? I'm using Windows XP SP2 Pro with latest hotfixes integrated with nLite (the RunOnceEx stage is configured by me). Thanks for any answer to this hard question, I know PD: I'm using the UnattendSwitch=Yes directive in WINNT.SIF, so no OOBE is launched after Windows is installed. The RunOnceEx stage runs immediately. EDIT: I have found the Registry key corresponding to these components (Desktop, Themes Setup, ...). It is: HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components Any way to prevent this run?

As I said before, I've already solved the issue. I was missing the spruNNNN.dll (locale dependent) file. This file must be copied as XPSP3RES.DLL.

Solved. Thanks for your interest.

@mariog60187: Well, I have done that, and Windows Update asks me to install the hotfix again. Catalog has been installed and the registry entries are present. The AGENTDPV.DLL file is present on disk. Any clue? Thanks.

Do I need only that? Compress the file and place it in the I386 folder? What about catalog files and the HFINT.DAT? I think a hotfix is more complex than that. Anyway, thanks again.

Thanks for your answer, but I'm not looking for replacing the file with the OEM distribution folder. I want to know how to slipstream *by hand* a hotfix. Can you explain this?

Hi: I'm wondering if it is possible to integrate the new hotfix KB932168 directly. I have nLite 1.3.0.4 and this version cannot slipstream this hotfix; it integrates normally. The hotfix is only the file AGENTDPV.DLL, no special registry entries needed (verified). Another hotfix, KB920213 is properly slipstreamed by nLite, and it contains the same file (AGENTDPV.DLL). All in all, can I slipstream all hotfixes except KB932168 and then simply replace the agentdpv.dl_ (corresponding to KB920213) with the shipped in KB932168? (forget the registry entries to recognize the new hotfix, I know how to reproduce them). How can I do this? Thanks in advance

Nilfred: KB935448 is required for those users using the Realtek HD drivers. If this patch is not applied, these users will receive severe errors (generated by KB925902) when starting up the system. Therefore, it's better to use KB935448 than KB928843 (at least ONE is required to patch the ActiveX vulnerability), since both patches fix the same vulnerability, but the former has no address conflicts and the latter it has. Also, it has been reported that KB935448 fixes other issues introduced by KB925902, not only the Realtek HD problem.

Add to the Nilfred's list hotfix KB935448, that fixes the issues of KB925902 (Realtek HD Control Panel problems). In addition, KB928843 is no longer necessary, because this hotfix has been superceeded by KB935448. Note: Files contained in KB935448 and KB928843 are the same in version and size (HHCTRL.OCX), so be careful, the newer version is in KB935448, and these files are binary different. Microsoft should mark with a different version the new file, but they didn't. Regards.

- Please delete this post, duplicated -

Dear Nuhi, can you say any word about this? Thanks in advance.

Yes, I'm refering to that folder. Are you completely sure that this folder is no longer necessary? Read carefully the proposed scenario... Regards.

Hi, only a simple question. Since nLite does not create this folder when slipstreaming hotfixes into install source, can this folder be necessary when applying future updates? I have read that this folder contains previous file versions of installed hotfixes, and its goal is to copy files newer than those contained in a new hotfix (if I'm not wrong...). Suppose the following scenario: Hotfix H installs file with version 1.0, but a previous hotfix -G- included that file with version 1.1. The system replaces the affected file with the version contained in the $hf_mig$ folder (hotfix G), not the contained in the new hotfix (H). Thanks

What's the purpose of the [FileFlags] section included in the TXTSETUP.SIF file? What's the meaning of the 16 value per entry (file)? Anyone ? I have searched over the net and on this forum and no go Thanks

I have checked the above. Anyone?

Hi: I have nLite 1.3 installed (yes, I know there is a 1.3.0.4 version, but according to the changelog does not fix my problem). The problem is very simple: nLite does not recognize the new versions of INTL.INF contained in the KB897338 hotfix package. The result is the old INTL.INF is not replaced by the new version. There are 2 versions of the INF file in the hotfix package: - In the SP2QFE\ip subdirectory - For Windows XP Professional . - In the SP2QFE\ic subdirectory - For "Consumer use", I suppose this INF is for Home Edition. nLite should copy the proper version (depending the target install source -Pro or Home-) to the I386 directory of the CD, replacing the old INTL.INF. Can anyone confirm this ? Thanks Regards

Hi Sorry for my late answer... I think QFECheck analysis is more accurate. You can do a sanity check yourself (there are not much hotfixes). Proceed in the following manner: 1. For each hotfix, search for information on the Knowledge base: http://support.microsoft.com/?kbid=NNNNNN , where "NNNNNN" are numbers identifying the hotfix. 2. Write down the new versions of affected files posted on the Knowledge Base, and compare them with the files installed on your system. If file version of your system is LESS than file version of the hotfix (see the Knowledge Base as explained), the hotfix is NOT properly applied. If it is greater than Knowledge Base claims, don't worry, because some hotfixes replace the same files with newer versions. 3. Also, check the following Registry value: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KBNNNNNN\Valid . Valid must be EQUAL to 1, otherwise the hofix is improperly installed or not installed at all. 4. An additional check to ensure that needed Registry entries for the hotfix are present may be done too. But this is more complex, and it requires you inspect the uncompressed hotfix package. Regards and good luck