[Problem when uninstalling .NET 2.0 patched admin install]

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:

1.

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

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

2.

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

msiexec /a <path to administrative image>

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

3.

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

4.

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

REINSTALL=ALL

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

REINSTALL=ALL REINSTALLMODE=vomus

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.

http://www.microsoft.com/technet/prodtechn...ity/winmsi.mspx

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.

[Problem when uninstalling .NET 2.0 patched admin install]

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.

[Problem when uninstalling .NET 2.0 patched admin install]

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.

[Latest nlite has wrong version number]

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 "1.0.0.16".

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

properties vs. the splash screen.

[testing Nlite 1.0.1 error messages]

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

[Nlite Crash]

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.

[Slip tool skins?]

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?

Just a thought anyways......

[Nlite 1.0final and KB885835 hotfix problem]

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.

Variations:

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.

KB873333

KB873339

KB885250

KB885835

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

KB873333

KB873339

KB885250

KB885835

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.

Question:

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?

+

[Integrating these two KB files that are Win32 Cab extractors]

I'd like to use the hotfix menu selection on nlite 1.0.1 to merge the following KB numbers.

KB913433

KB898458 which is the interactive training software

These are very old security problems for Windows XP Home/Pro

[nlite v1.0.1 and hotfix wildcards]

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.

[Nlite feature request for SP2 merge]

Perhaps have another check box that says to ask me, which would give the popup question too.

This will eliminate the all or nothing of Yes/No to all check boxes mentioned last week.

[Nlite feature request for SP2 merge]

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.

[nlite used to update support/tools directory etc?]

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.

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.

NOTE: USMT found in VALUEADD/MSFT/USMT/

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:

DEPLOY.CAB

SUP_PRO.CAB

SUP_SRV.CAB

SUPPORT.CAB

SUPTOOLS.CAB

[Nlite 1.0final and KB885835 hotfix problem]

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

PROBLEMS:

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.

http://msdn.microsoft.com/netframework/def...tml/netfx30.asp

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.

[nlite 1.0 final]

ok i did that and it worked fine!

thanks a lot ZcWorld

you saved me from downloading again sp2 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.