KB928365 Err 663, on production SQL2K5 serve CANNOT uninstall .NET

Hello,
I have the same issue discussed here in July quite often. Common hint:
"uninstall .NET 2.0, 1.1 and 1.0, install them and run updates again" DOES
NOT HELP me a lot, since it means for me: uninstall SQL 2K5 (5 instances)
uninstall MS CRM 3.0 and uninstall WSS30. Since all this in production
environment, this would meant the same like throwing the server out of the
window. Any other idea ? There must be some very exact reason why so many
people have this erro 0x663, and a way to correct it manually, ha ?
Thanks for ideas.
Regards, Pazu

"Pazu" <> wrote in message
news:AA1823D2-B8D2-43B2-BF5B-...
> Hello,
> I have the same issue discussed here in July quite often. Common hint:
> "uninstall .NET 2.0, 1.1 and 1.0, install them and run updates again" DOES
> NOT HELP me a lot, since it means for me: uninstall SQL 2K5 (5 instances)
> uninstall MS CRM 3.0 and uninstall WSS30. Since all this in production
> environment, this would meant the same like throwing the server out of the
> window. Any other idea ? There must be some very exact reason why so many
> people have this erro 0x663, and a way to correct it manually, ha ?
> Thanks for ideas.
> Regards, Pazu


<cmd_output OS="XPsp2">
F:\WINDOWS\system32>set /a c = 0x663
1635
F:\WINDOWS\system32>net helpmsg %c%

This patch package could not be opened. Verify that the patch package exists
and that you can access it, or contact the application vendor to verify that this
is a valid Windows Installer patch package.
</cmd_output>


What does the log say? Try a verbose log if not enough clues so far?
Do you have the right version of the installer?

Hmm... the KB article even mentions that possibility:

http://support.microsoft.com/?kbid=928365

<quote>
Prerequisites
To install this security update, you must have Microsoft Windows Installer 3.1 installed on the computer.
</quote>


If you are doing a manual install your problem is really more related
to the product involved than to the way that it is deployed (e.g. WU).
So you may get better assistance in a newsgroup which specializes
either in the product.being updated or the enviroment in which you
are installing it.

BTW can't you take one server out for maintenance? ; }


HTH

Robert Aldwinckle
---

> <cmd_output OS="XPsp2">
> F:\WINDOWS\system32>set /a c = 0x663
> 1635
> F:\WINDOWS\system32>net helpmsg %c%
>
> This patch package could not be opened. Verify that the patch package exists
> and that you can access it, or contact the application vendor to verify that this
> is a valid Windows Installer patch package.
> </cmd_output>
----
Yes, it corrsponds, to what is in a log:

+ Installing patch
Product: (null)
validating products...
+ Validate product version
VersionString: 2.0.50727
Version was valid
- Validate product version
+ Validate product language
Language: 0
Language was valid
- Validate product language
+ Validate product upgrade code
retrieving package local package path
Local package found at "C:\WINDOWS\Installer\1116ad.msi"
ERROR: [110] Failed to open local package database.
- Validate product upgrade code
No valid products found! shell out.
+ Core patch application
No target product was specified.
Command line: "C:\WINDOWS\system32\msiexec.exe"
REBOOT=ReallySuppress /p "C:\WINDOWS\TEMP\ZNW270\NDP20-KB928365-v2-X86.msp"
/qn
+ Launching process
Command line: "C:\WINDOWS\system32\msiexec.exe"
REBOOT=ReallySuppress /p "C:\WINDOWS\TEMP\ZNW270\NDP20-KB928365-v2-X86.msp"
/qn
- Launching process
- Core patch application
- Installing patch

---- I have MSI 3.1 - it shoudl be OK.

> If you are doing a manual install your problem is really more related
> to the product involved than to the way that it is deployed (e.g. WU).
> So you may get better assistance in a newsgroup which specializes
> either in the product.being updated or the enviroment in which you
> are installing it.
>
> BTW can't you take one server out for maintenance? ; }
--- Really not easy, really risky. It is the only server for WSS & CRM.

BR, Pazu

I had the same issue, and was totally unwilling to uninstall SQL 2005, .NET
etc. and reinstall just to get the patch to work.

But I found the cause, and a non-destructive fix.

Basically, .NET, SQL 2005, Visual Studio, MSXML and many other packages that
use Windows Installer tend to drop MSI and MSP files in C:\Windows\Installer.

Updates to such packages often seek the original files in this folder.
The .NET 2.0 patch q928365 is one such update.

But these files can be rather large and you can end up with a lot of them,
and if the C: drive gets full, some people identify this folder as using a
lot of space and figure correctly that .MSI and .MSP files are not required
for any existing software to run, so they are safe to delete...

On my server, the MSP & MSI files had been moved to another drive, and if
you hover the mouse over them or right-click and select properties, summary,
it tells you what each was for.

I just copied all the MSI and MSP files that identified themselves as
relating to .NET back to C:\Windows\Installer and reran the patch, and it
worked, no problems.

"Pazu" wrote:

> Hello,
> I have the same issue discussed here in July quite often. Common hint:
> "uninstall .NET 2.0, 1.1 and 1.0, install them and run updates again" DOES
> NOT HELP me a lot, since it means for me: uninstall SQL 2K5 (5 instances)
> uninstall MS CRM 3.0 and uninstall WSS30. Since all this in production
> environment, this would meant the same like throwing the server out of the
> window. Any other idea ? There must be some very exact reason why so many
> people have this erro 0x663, and a way to correct it manually, ha ?
> Thanks for ideas.
> Regards, Pazu

Hello,

There is a seed of truth in your idea, because I moved the files, from which
W2K3 server and SQL server, where installed form C: to D: - but these are
normal setup files copied form CDs.

Anyway I never touched directory C:\Windows\Installer, it exists and it
looks to contain a lot of GUID-named folders and some hexa named MSIs. I
compared with another server and there is much more msi and even msp files,
however their hexa names seem to be machine-specific.

Any idea how to determine which "hexa".msi are missing ?

Thanks - Jiri

"Adrian" wrote:

> I had the same issue, and was totally unwilling to uninstall SQL 2005, .NET
> etc. and reinstall just to get the patch to work.
>
> But I found the cause, and a non-destructive fix.
>
> Basically, .NET, SQL 2005, Visual Studio, MSXML and many other packages that
> use Windows Installer tend to drop MSI and MSP files in C:\Windows\Installer.
>
> Updates to such packages often seek the original files in this folder.
> The .NET 2.0 patch q928365 is one such update.
>
> But these files can be rather large and you can end up with a lot of them,
> and if the C: drive gets full, some people identify this folder as using a
> lot of space and figure correctly that .MSI and .MSP files are not required
> for any existing software to run, so they are safe to delete...
>
> On my server, the MSP & MSI files had been moved to another drive, and if
> you hover the mouse over them or right-click and select properties, summary,
> it tells you what each was for.
>
> I just copied all the MSI and MSP files that identified themselves as
> relating to .NET back to C:\Windows\Installer and reran the patch, and it
> worked, no problems.
>

The file name is always different but it's an MSI and the properties are:

Title: Installation Database
Subject: Microsoft .NET Framework 2.0
Revision: {BFC5E8EF-C140-454A-9B47-EEC73A4AAB3F}
Size: 2060 KB

The exact file name is recorded at

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Installer\UserData\S-1-5-18\Products\D6461317C3DC4F04799BDCE9E42626FE\Insta llProperties\LocalPackage

so if all else fails, you could find the MSI file with those properties on
another Win2003 server, copy it to your affected server
(c:\windows\installer) and rename it to whatever that registry key shows on
the affected server...

Adrian






"Pazu" wrote:

> Hello,
>
> There is a seed of truth in your idea, because I moved the files, from which
> W2K3 server and SQL server, where installed form C: to D: - but these are
> normal setup files copied form CDs.
>
> Anyway I never touched directory C:\Windows\Installer, it exists and it
> looks to contain a lot of GUID-named folders and some hexa named MSIs. I
> compared with another server and there is much more msi and even msp files,
> however their hexa names seem to be machine-specific.
>
> Any idea how to determine which "hexa".msi are missing ?
>
> Thanks - Jiri
>
> "Adrian" wrote:
>
> > I had the same issue, and was totally unwilling to uninstall SQL 2005, .NET
> > etc. and reinstall just to get the patch to work.
> >
> > But I found the cause, and a non-destructive fix.
> >
> > Basically, .NET, SQL 2005, Visual Studio, MSXML and many other packages that
> > use Windows Installer tend to drop MSI and MSP files in C:\Windows\Installer.
> >
> > Updates to such packages often seek the original files in this folder.
> > The .NET 2.0 patch q928365 is one such update.
> >
> > But these files can be rather large and you can end up with a lot of them,
> > and if the C: drive gets full, some people identify this folder as using a
> > lot of space and figure correctly that .MSI and .MSP files are not required
> > for any existing software to run, so they are safe to delete...
> >
> > On my server, the MSP & MSI files had been moved to another drive, and if
> > you hover the mouse over them or right-click and select properties, summary,
> > it tells you what each was for.
> >
> > I just copied all the MSI and MSP files that identified themselves as
> > relating to .NET back to C:\Windows\Installer and reran the patch, and it
> > worked, no problems.
> >
>

I have done this. The symptoms for KB928365 remained the same, but it is
true, that in log file now it complains for not having
NDP20-KB917283-X86.msp. I tried to find 917283 in registry, but I cannot find
the "hexa" name for it to be able to rename it. Comparing with what I
downloaded from MSFT found, it is an msp file with length of 777 728 bytes,
but I have no Idea what "hexa" name it should have on SQL machine.

"Adrian" wrote:

> The file name is always different but it's an MSI and the properties are:
>
> Title: Installation Database
> Subject: Microsoft .NET Framework 2.0
> Revision: {BFC5E8EF-C140-454A-9B47-EEC73A4AAB3F}
> Size: 2060 KB
>
> The exact file name is recorded at
>
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Installer\UserData\S-1-5-18\Products\D6461317C3DC4F04799BDCE9E42626FE\Insta llProperties\LocalPackage
>
> so if all else fails, you could find the MSI file with those properties on
> another Win2003 server, copy it to your affected server
> (c:\windows\installer) and rename it to whatever that registry key shows on
> the affected server...
>
> Adrian

BINGO !

I reiterated the same process also for all patches found under key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Installer\UserData\S-1-5-18\Products\D6461317C3DC4F04799BDCE9E42626FE\Patch es:

- find what is "hexa" name on "good" machine in registry
- find what is "hexa" name on "bad" machine in registry
- copy file from good machine under new name to bad machine

"hexa" names for patch I found in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Installer\UserData\S-1-5-18\Patches

(the same guids apply)

Great ! I have been solving this via MSFT WU incident in parallel more then
month and no such valuable idea came form these guys yet :-(
Partially because messages in setup log are misleading and focusing on temp
directory.
Anyway I dare to say that this happened after using Accesories/System
tools/Disk clean up.


"Adrian" wrote:

> The file name is always different but it's an MSI and the properties are:
>
> Title: Installation Database
> Subject: Microsoft .NET Framework 2.0
> Revision: {BFC5E8EF-C140-454A-9B47-EEC73A4AAB3F}
> Size: 2060 KB
>
> The exact file name is recorded at
>
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Installer\UserData\S-1-5-18\Products\D6461317C3DC4F04799BDCE9E42626FE\Insta llProperties\LocalPackage
>
> so if all else fails, you could find the MSI file with those properties on
> another Win2003 server, copy it to your affected server
> (c:\windows\installer) and rename it to whatever that registry key shows on
> the affected server...
>
> Adrian
>
>
>
>
>
>
> "Pazu" wrote:
>
> > Hello,
> >
> > There is a seed of truth in your idea, because I moved the files, from which
> > W2K3 server and SQL server, where installed form C: to D: - but these are
> > normal setup files copied form CDs.
> >
> > Anyway I never touched directory C:\Windows\Installer, it exists and it
> > looks to contain a lot of GUID-named folders and some hexa named MSIs. I
> > compared with another server and there is much more msi and even msp files,
> > however their hexa names seem to be machine-specific.
> >
> > Any idea how to determine which "hexa".msi are missing ?
> >
> > Thanks - Jiri
> >
> > "Adrian" wrote:
> >
> > > I had the same issue, and was totally unwilling to uninstall SQL 2005, .NET
> > > etc. and reinstall just to get the patch to work.
> > >
> > > But I found the cause, and a non-destructive fix.
> > >
> > > Basically, .NET, SQL 2005, Visual Studio, MSXML and many other packages that
> > > use Windows Installer tend to drop MSI and MSP files in C:\Windows\Installer.
> > >
> > > Updates to such packages often seek the original files in this folder.
> > > The .NET 2.0 patch q928365 is one such update.
> > >
> > > But these files can be rather large and you can end up with a lot of them,
> > > and if the C: drive gets full, some people identify this folder as using a
> > > lot of space and figure correctly that .MSI and .MSP files are not required
> > > for any existing software to run, so they are safe to delete...
> > >
> > > On my server, the MSP & MSI files had been moved to another drive, and if
> > > you hover the mouse over them or right-click and select properties, summary,
> > > it tells you what each was for.
> > >
> > > I just copied all the MSI and MSP files that identified themselves as
> > > relating to .NET back to C:\Windows\Installer and reran the patch, and it
> > > worked, no problems.
> > >
> >

"Adrian" wrote:

> The file name is always different but it's an MSI and the properties are:
>
> Title: Installation Database
> Subject: Microsoft .NET Framework 2.0
> Revision: {BFC5E8EF-C140-454A-9B47-EEC73A4AAB3F}
> Size: 2060 KB
>
> The exact file name is recorded at
>
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Installer\UserData\S-1-5-18\Products\D6461317C3DC4F04799BDCE9E42626FE\Insta llProperties\LocalPackage
>
> so if all else fails, you could find the MSI file with those properties on
> another Win2003 server, copy it to your affected server
> (c:\windows\installer) and rename it to whatever that registry key shows on
> the affected server...
>
> Adrian
>
>
>
>
>
>
> "Pazu" wrote:
>
> > Hello,
> >
> > There is a seed of truth in your idea, because I moved the files, from which
> > W2K3 server and SQL server, where installed form C: to D: - but these are
> > normal setup files copied form CDs.
> >
> > Anyway I never touched directory C:\Windows\Installer, it exists and it
> > looks to contain a lot of GUID-named folders and some hexa named MSIs. I
> > compared with another server and there is much more msi and even msp files,
> > however their hexa names seem to be machine-specific.
> >
> > Any idea how to determine which "hexa".msi are missing ?
> >
> > Thanks - Jiri
> >
> > "Adrian" wrote:
> >
> > > I had the same issue, and was totally unwilling to uninstall SQL 2005, .NET
> > > etc. and reinstall just to get the patch to work.
> > >
> > > But I found the cause, and a non-destructive fix.
> > >
> > > Basically, .NET, SQL 2005, Visual Studio, MSXML and many other packages that
> > > use Windows Installer tend to drop MSI and MSP files in C:\Windows\Installer.
> > >
> > > Updates to such packages often seek the original files in this folder.
> > > The .NET 2.0 patch q928365 is one such update.
> > >
> > > But these files can be rather large and you can end up with a lot of them,
> > > and if the C: drive gets full, some people identify this folder as using a
> > > lot of space and figure correctly that .MSI and .MSP files are not required
> > > for any existing software to run, so they are safe to delete...
> > >
> > > On my server, the MSP & MSI files had been moved to another drive, and if
> > > you hover the mouse over them or right-click and select properties, summary,
> > > it tells you what each was for.
> > >
> > > I just copied all the MSI and MSP files that identified themselves as
> > > relating to .NET back to C:\Windows\Installer and reran the patch, and it
> > > worked, no problems.
> > >
> >

BINGO !

I reiterated the same process also for all patches found under key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Installer\UserData\S-1-5-18\Products\D6461317C3DC4F04799BDCE9E42626FE\Patch es:

- find what is "hexa" name on "good" machine in registry
- find what is "hexa" name on "bad" machine in registry
- copy file from good machine under new name to bad machine

"hexa" names for patch I found in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Installer\UserData\S-1-5-18\Patches

(the same guids apply)

Great ! I have been solving this via MSFT WU incident in parallel more then
month and no such valuable idea came form these guys yet :-(
Partially because messages in setup log are misleading and focusing on temp
directory.
Anyway I dare to say that this happened after using Accesories/System
tools/Disk clean up.


"Adrian" wrote:

> The file name is always different but it's an MSI and the properties are:
>
> Title: Installation Database
> Subject: Microsoft .NET Framework 2.0
> Revision: {BFC5E8EF-C140-454A-9B47-EEC73A4AAB3F}
> Size: 2060 KB
>
> The exact file name is recorded at
>
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Installer\UserData\S-1-5-18\Products\D6461317C3DC4F04799BDCE9E42626FE\Insta llProperties\LocalPackage
>
> so if all else fails, you could find the MSI file with those properties on
> another Win2003 server, copy it to your affected server
> (c:\windows\installer) and rename it to whatever that registry key shows on
> the affected server...
>
> Adrian
>
>
>
>
>
>
> "Pazu" wrote:
>
> > Hello,
> >
> > There is a seed of truth in your idea, because I moved the files, from which
> > W2K3 server and SQL server, where installed form C: to D: - but these are
> > normal setup files copied form CDs.
> >
> > Anyway I never touched directory C:\Windows\Installer, it exists and it
> > looks to contain a lot of GUID-named folders and some hexa named MSIs. I
> > compared with another server and there is much more msi and even msp files,
> > however their hexa names seem to be machine-specific.
> >
> > Any idea how to determine which "hexa".msi are missing ?
> >
> > Thanks - Jiri
> >
> > "Adrian" wrote:
> >
> > > I had the same issue, and was totally unwilling to uninstall SQL 2005, .NET
> > > etc. and reinstall just to get the patch to work.
> > >
> > > But I found the cause, and a non-destructive fix.
> > >
> > > Basically, .NET, SQL 2005, Visual Studio, MSXML and many other packages that
> > > use Windows Installer tend to drop MSI and MSP files in C:\Windows\Installer.
> > >
> > > Updates to such packages often seek the original files in this folder.
> > > The .NET 2.0 patch q928365 is one such update.
> > >
> > > But these files can be rather large and you can end up with a lot of them,
> > > and if the C: drive gets full, some people identify this folder as using a
> > > lot of space and figure correctly that .MSI and .MSP files are not required
> > > for any existing software to run, so they are safe to delete...
> > >
> > > On my server, the MSP & MSI files had been moved to another drive, and if
> > > you hover the mouse over them or right-click and select properties, summary,
> > > it tells you what each was for.
> > >
> > > I just copied all the MSI and MSP files that identified themselves as
> > > relating to .NET back to C:\Windows\Installer and reran the patch, and it
> > > worked, no problems.
> > >
> >