Jump to content


  • Posts

  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United States

Posts posted by mikesw

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

    Here's some info on how to properly recache the .msi file on your computer for future repair after

    the msi file has been patched.

    To patch installations using an administrative image:


    Create the administrative image, if it does not already exist, with the following command line:

    msiexec /a <path to the MSI>\package.msi


    Update the administrative image by running the following command-line option:

    msiexec /a <path to administrative image>

    \package.msi /p <path>\patch.msp


    This update changes the *.msi on the administrative image by directly applying the patch.


    Update users' computers by running the installation of the application from the administrative image using one of the following command-line options:

    msiexec /fvomus <path to administrative image>\package.msi


    msiexec /i <path to administrative image>\package.msi


    If you know all the features that the patch will affect, you can set REINSTALL to the complete list of features (delimited by commas) to affect only those features. This is likely to decrease the time the update operation takes. For more information about the REINSTALL property see the Windows Installer SDK, which is available from the Web Resources page at http://www.microsoft.com/windows/reskits/webresources/

    Applying a patch to an administrative installation modifies the original *.msi. The "v" argument is required in this situation to cache the modified *.msi to the local system. Failure to cache the *.msi prevents the application from performing maintenance operations. The consequences of this are discussed in the following paragraphs.

    Important: A patch changes the package code of an .msi file. To allow Windows Installer to perform maintenance operations such as adding, removing, or repairing an installation, the package codes for the installed application and the source must match. Therefore, a computer that still has the original package code installed cannot be maintained by using a patched administrative image until you update the computer.

    If the deployment of the patched administrative image of an application is an update, not a new installation, and it takes a considerable amount of time to reach all target client computers, it is recommended you take one of the following actions:

    • Create a new administrative image for the application and apply the patch to it. You can then distribute this new source to the appropriate systems. After you upgrade all systems, you can remove or patch the original administrative image to provide a redundant source.

    • Patch the clients directly on a local computer, as described in "Applying Patches to Installed Software" in this paper. This method does not modify the .msi cached on the local system, and therefore the .msi in the administrative image and on the local system remain identical.

    Either of the two preceding methods can prevent the application on the client computer and the source administrative image for the application from becoming unsynchronized. If the client computer and source administrative image for an application become unsynchronized, Windows Installer cannot perform maintenance operations for the application, such as adding, modifying, removing, or repairing an installation.

    Important: To remove a patch that you have applied, you must remove the entire application, and then reinstall the application without the patch. There is no way to roll back the changes a patch applies to the original package.

    Here's the link that has alot of good info for you to read, and where this info came from.


    The changes made by the patch persist on the administrative image. However, these changes are not automatically propagated to existing installations. The application must be reinstalled by using a command with the following arguments: REINSTALL and REINSTALLMODE properties.


  2. Thanks for the info. I'll try it out.

    The link you posted from 4/2005 was great although I did find a more general but

    similar post al the way back in 2004 on this list. In the last step they did this vs. SFX.

    You can compress these with iexpress. Command to be executed:

    msiexec /qb /i netfx1.msi


    BTW, can all of this information be combined and made into a sticky on the topics main page?

    That is, your comments, the links, along with the batch files by others that replied to the post that

    you specified in your link. It would eliminate alot of going back through 19 pages of history and

    trying to sort through the facts. Sort of a lessons learned summarization.

  3. I had issues trying to get the bloody thing to integrate the normal way like version 1.1 and sp1 did.........

    I patched .NET v2.0 with the KB patch the same way as the poster did. I noticed that it

    created alot of subdirs i.e. "win", "windows", "program files" in the c:\temp directory that I used to

    do the merge in. I wasn't sure how the "install.ini" and "manifest.ini" would merge together (note the

    manifest.ini was extracted from the KB patch). To test the patch before putting it on a slipped Win XP disk.

    I just selected "install.exe" since if I selected the patched "netfx.msi" it said to use the "install.exe".

    I saw that the .NET v2.0 and KB# hotfix appeared under the "add/remove programs" selection.

    However, when I did "Microsoft Update", it came back with a recommendation to install the KB patch #

    that the "add/remove programs" said was already there. Moreover, I searched the registry for the

    KB# to see if it was there and it was. So I redownloaded the KB# and installed it just to keep

    microsoft update happy.

    To comments:

    a). I didn't dump the registry after doing the .NET v2.0 with patch and then redump the registry after

    using Microsoft download and doing a repatch with the KB #. Then, comparing the two registry

    dumps to see what's different in the registry.

    B). Do I need all those created subdir's in the c:\temp directory?

    c). I didn't notice any version number update to the .NET v2.0 software when patched. It still

    shows v2.0.50727 whereas the properties on the patch show version v1.0.93.243 on the KB file.

    d). How, to repackage the extracted files back into a form that the Win XP Cd can use.

    I assume the eula txt and dll's that contain the language code pages are needed along with the

    ".msi" and " install.exe" file etc. Once I repackage it (how???) I'd put it in the components/dotnet

    or "dotnet" directory on the Windows XP CD for easy reinstall. Currently they show the

    "dotnetfx.msi" only which I assume contains all the other stuff mentioned above.

    How to do the v1.0 and v1.1 .NET with patches so they can be included on the Win XP CD?

    They don't have a ".msp" file to patch with. :(

  4. When you run nlite, the splash screen says 1.0.1.

    If one selects "nlite.exe" and does properties on the file along with

    looking at the "assembly version" and "product version" it says "".

    You may want to update this so they are the same version number should one use

    properties vs. the splash screen. :sneaky:

  5. From a previous post about 2 weeks back I made a similar comment.

    I removed .NET v2.0 and patch from the system. I then started Nlite 1.0.1 to see what error

    message I'd get. I realize that it requires .NET v2.0. I have .NET v1.0 and v1.1 on the system.

    Here is the error message I got.

    "A fatal error occurred.However, mscorees.dll could not be loaded to display the appropriate

    error message. Please reinstall the .NET framework."

    Although this message is ok, the problem is that a beginner may not realize for the

    particular version of Nlite they have, that it requires a specific version of .NET. Of course,

    they should Read the manual, but...... Suggest that the message be modified to specify

    which version of .NET is required. Thus, change to "Please reinstall the .NET 2.0 framework." :yes:

  6. When Nlite'ing a windows installation, Nlite always freezes at the finalization of the Nlite when doing the compression of CAB files. It freezes the entire OS, can't even move the mouse and i have to hit hte reset button. I've tried numerous times, dunno what hte problem is.

    Try bringing up task manager and display the processes sorted from Max cpu% to least. Then

    bring up Nlite and repeat what you are doing. Watch the task manager %'s change to see

    what is taking up all the time. Usually recompressing to cab files (even with 1 gig memory on 1ghz

    machine) takes awhile. About 15 minutes on my machine.

  7. I was wondering that with all the various MSoft Win slipping tools out there, has anyone

    made one where the tool has different skins to imitate their favorite slip tool? :w00t:

    Just a thought anyways...... :whistle:

  8. Here is an update to the problem using Nlite v1.0.1final (not the Beta).

    Here is what was done.

    a). reintegrated SP2 on top of Windows XP Pro SP2 (that is MSoft did the SP2 first and I redid it)

    b). Included the hotfix KB885835 and got "unexpected error". The following is the list of variations

    that were done, with item (a) above being repeated on a clean XP Pro SP2 copy before continuing

    with the next variation listed below.


    a) Integrate without the "direct" integration flag enabled, and all the hotfixes except KB885835

    Passed without problem.

    b). Integrate KB885835 only without the other KB's and by the "direct" integration flag being ON

    Passed without problem.

    c). Integrate KB885835 only without the other KB's and by setting "direct" integration flag OFF.

    Passed without problem.

    d). Integrate the following KB's with KB885835 in KB numeric order along with all the other

    KB's too in numeric order and by setting the "direct" integration flag ON.





    <and the rest of the KB's>

    Passed without problem.

    e). Integrate the same way as item (d) above but turn the "direct" integration flag OFF.





    This "fails" and gives "UnExpected Error" on file KB885835.

    I suspect a problem between KB885835 and one or all of the other KB files

    listed before KB885835 shown above when not doing direct integration.


    If I select "direct" integration, will I see the KB numbers appear under the "add/remove"

    program selection once the XP OS is installed? If not, will they show up if BelArc advisor

    is used to do system inventory of all software and OS patches?


  9. When trying to select from a directory, the list of KB hotfix files to include for inclusion,

    one can't select the wildcard of "*.*" or "*" which selects all the files. One must select

    them by the CTL-Shift method. This could be a problem as the number of KB files increases

    and it exceeds the number of characters that Windows XP can handle on the command line.

    Need fix to handle filename wildcards.

    This problem occurred on older version of Nlite too.

  10. Hi,

    I'm upgrading a neighbors Windows XP Home from SP1a to SP2 using Nlite 1.0 ( or earlier one).

    During the merge process, it asks the user via a popup if one wants to use the "NEWER" version

    of the file to be merged. Because, there are so many popups during this process and one wants

    to do it unattended (that is not to answer every popup question for every file), I'm asking that

    Nlite have an configuration option via a menu to set so that all questions like this are answered

    with a "yes" or "no". That is, if the option is checked, the answer is "yes" and all the newer files

    are used. If the option is 'not' checked, the answer is "no" and all the newer files are not used.

    This will allow the user to do the merge unattended without having to sit in front of the computer.

    Moreover, it will eliminate accidently mistakes. That is, after quite a few yes', the user may accidently

    click on the wrong popup box to select "no" and there is no way to correct this mistake besides,

    stopping the merge, and restarting the whole merge process over again. This has happened a few

    times by me trying to do the merge late at night and being tired. :blink:

  11. All,

    While I'm rebuilding the OS CD disk, I might as well rebuild the whole thing including all the other stuff

    as much as possible. :P

    Why doesn't Nlite have builtin support for updating files in the /support/tools and /valueadd/msft/usmt

    directory so that one can update them with newer versions. I see that RyanVM doesn't

    include some of these too.

    I.E /support/tools/

    MSRDPCLI.exe new version for download is v6.0.2600.0. My version is v6.0.2448.

    ACT20.exe new version for download is v4.1 with v5.0beta available too.

    If one does properites on the ACT20.exe file, it says its "installshield" whereas if one

    goes to MSoft's site, for "Application Compatibility Toolkit" it doesn't mention "Installshield".

    Moreover, the download file is a ".msi" file and not ".exe". Another tool is KB294403 "Grabmi.exe"

    ACT41 http://www.microsoft.com/downloads/details...;displaylang=en

    FASTWIZ.exe "Files and Transfer Wizard"

    my version with SP2 is 6.0.2448. IS there a "NEWER" version out? I can't locate

    the download link. Moreover, per this KB304903 which is dated 2001 it lists

    the settings that can be migrated. Of course the listed apps will be out-of-date and

    incomplete. Things have changed alot since then.


    USMT.MSI "User State Migration Tool" currently v2.6.1 is ready for download.

    Note: v2.6 does alot of the older Windows version i.e. Win95 whereas

    v2.6.1 doesn't do the discontinued Windows versions put does win XP x64 too.

    Note2: In v2.6.1 there are two different msi files: one for AMD and one for Intel.

    Why two different ones? I assume if one has an AMD processor, the Intel

    one should work. However, in v2.6 there is only one msi file. I guess in

    v2.6.1 it needs to support the x64 bit extensions between AMD and Intel

    for the Win XP x64 OS...?

    Note3: Is it correct that USMT is used to migrate one i.e. from Win95 to WinXP

    during the installation process of WinXP? If true, then these files need

    to be ugraded to at least V2.6. If v2.6.1 is used, it may not let one upgrade

    from i.e. Win95 to WinXP since these older versions aren't supported now.

    One will have to check the *.inf files for what's in them.

    Moreover, if I don't want i.e. the old acrobat reader v5.0 migrated when

    updating from Win95 to WinXP, then I'd modify the .inf file so that it isn't

    migrated. Thus, during the install of WinXP, I can use the latest Acrobat

    reader 7.0.8. The same applies to the other applications too!

    Probably could use some NLITE options to prevent or allow various

    Win95,Win98,WinNT, etc... applications from migrating during WINXP

    upgrade. This eliminates alot of hand editing/jamming of the *.inf

    files in the Win9XMig subdirectories and others too.

    USMT261 http://www.microsoft.com/downloads/details...;displaylang=en

    gbunicnv.exe "GB unicode converter" I have v1.0.0.1

    The gbunicnv.exe is part of the GBEXTSUP.MSI package. One will have to

    extract it from this MSI file. Is there a need for the other files in this MSI file?

    GBEXTSUP10 http://www.microsoft.com/downloads/details...;DisplayLang=en

    Other files are , but version unknown and were to get the updates for them all:






  12. Hi,

    I have Win XP Pro SP2 and have integrated all hotfixes/security patches since Aug 2004 when

    SP2 was released minus the cumulative updates except for the latest-n-greatest one using the SVCPACK

    directory (not direct integration).


    a) This amounts to about 43 files as of the end of June 2006 for the OS.

    During the hotfix merge process, I got "an unexpected error" message popup for KB885835.

    I tried merging the KB file by itself without the others and also redownloading it (assumed it was corrupt).

    This didn't make any difference. Thus believe Nlite v1.0 final has a bug.

    All hotfixes that were added were sorted using Nlite in numerical order vs. using the build date order.

    I don't think this will affect the actual merge and install of the OS though.

    b) A similar problem occurred when trying to reintegrate SP2 into the Win XP Pro that already had

    SP2 integrated by MSoft. NLite 1.0final said it was corrupted. I redownloaded SP2 and it integrated

    ok. The strange thing is that it worked with older versions of Nlite without a problem. Somebody

    else had this problem on a similar thread recently.

    NOTE: Would like NLITE to give error message popup when NLITE requires i.e. .NET v2.0 to run.

    Hence instead of crashing/aborting it would check the registery or the DLL version number to see

    if the .NET is installed or that the correct version number is present. This will make NLITE dummy proof.

    Here are some articles/links on how MSoft suggests that one can do this.


    KB article mentioned KB318785 or link http://support.microsoft.com/kb/318785/en-us

    MSoft gives example programs/scripts that do the checking of the version number. Probably borrow

    them and integrate them into NLITE to display a popup to the user.

  13. :}

    ok i did that and it worked fine!

    thanks a lot ZcWorld :thumbup

    you saved me from downloading again sp2 :wacko: because i have started to believe that it is corrupted for real

    Yes, I had the same problem with Nlite 1.0 final.

    I tried a couple of times to integrate SP2 into a Windows XP Pro that already had SP2 integrated.

    I wanted to see if it would reintegrate without any problems.

    My solution was to redownload SP2 again and since then, there has been no problem (I reintegrated

    SP2 about 3 times so far onto the same XP Pro SP2 version). I don't know why my original SP2

    had problems, but it shouldn't be due to the file being corrupted. :}

  • Create New...