MSXML 4.0 /4.0 SP2 failed to install Document ID: 286004 error 1603

[Joey_Ahrens]

Currently backupexec 10d and attempting an upgrade to 11. getting the msxml 4.0 failure message (both applications are installed on the server in add/remove programs) and sending me to the error page for the same:

http://seer.entsupport.symantec.com/docs/286004.htm

Not sure if those apps were installed in the first failed attempt or not. saw a post from someone upgrading from version 9 who just renamed the msi file and it fixed it, I wasn't so lucky but I'm looking at the log and I see a lot of:

11-29-2006,13:32:52 : InitData failed to open the cluster wrapper
11-29-2006,13:32:52 : InitData failed to open the cluster wrapper
11-29-2006,13:32:52 : InitData failed to open the cluster wrapper

and

1-29-2006,13:34:34 : Executing BE_InstallMSXML.

11-29-2006,13:34:34 : msiexec /i "C:\VeritasUPGRADE\BEWS_11D_32BIT_VERSION\WINNT\INSTALL\MSXML\msxml.msi" /l*v C:\DOCUME~1\ALLUSE~1\APPLIC~1\Symantec\BACKUP~1\Logs\MSXML4.log /qn REBOOT=ReallySuppress

11-29-2006,13:34:34 : V-225-235: MSXML 4.0 failed to install. ***To search for information about this error, click here

11-29-2006,13:34:34 : V-225-235: MSXML 4.0 SP2 failed to install... Canceling installation. ***To search for information about this error, click here

11-29-2006,13:34:34 : Failed to install third party products.


Should I uninstall the msxml 4.0 stuff?

Any help would be greatly appreciated.

[Joey_Ahrens]

Veritas boys, you need to rewrite your code. As stated previously by a fellow user, inside the error log I found the following:

Event Type:Error
Event Source:MsiInstaller

Description:
Product: MSXML 4.0 SP2 Parser and SDK -- Error 1316. A network error occurred while attempting to read from the file: C:\VeritasUPGRADE\BEWS_11D_32BIT_VERSION\WINNT\INSTALL\MSXML\msxml4sp2.msi

that file DOES NOT EXIST in the zip file its looking in.

[Deepali_Badave]

Hello,

We would like to inform our email support primarily handles the "Installation" and "Evaluation" issues of Backup Exec for Windows Servers (BEWS) version 9.1 and 10.x and 11d.
As your issue does not fall into this category, we request you to log the query via Email support to get the resolution to your case.

Regards,

[Joey_Ahrens]

NO. This IS an INSTALLATION error/question. And it should be your responsibility to pass on this information to the people who package those installations because they are causing ERRORS when WE the CUSTOMER try to install them.

How can you say its NOT an installation error?

[Russ_Perry]

This issue seems to come from the way MSI determines if MSXML 4 SP2 is present and where it came from. This is an excerpt from another thread that provided a way to get around the failure:

The be11d setup starts the msxml.msi from WINNT\INSTALL\MSXML and fails (with the msiexec installer log saying that it cannot find file WINNT\INSTALL\MSXML\msxml4_sp2.msi).
The reason for msiexec to look for file msxml4_sp2.msi seems to be that this was the name of the file with which SP2 was originally installed (it really was installed like that). Putting a copy of msxml.msi named msxml4_sp2.msi into WINNT\INSTALL\MSXML causes msiexec not to fail. So, this seems like a msiexec issue, not be11d.


Russ

[Joey_Ahrens]

ok. How does windows install a file? it pulls information from an INF file or the msi file that comes from the creator of the msi file. It uses the information from that file to find the files that it needs in order to install the program correctly.

Which means that the installer service on the server running the installation was TOLD by the INSTALLATION INFORMATION to look in that specific location for that specific file. Which means that whoever packaged that installation program placed that file in the wrong part of the installation OR the code was written incorrectly to look in the wrong place.

Easily fixed with human intervention who read the error log in the event viewer, however, the purpose of an MSI file means that you don't have to repackage the installation for the creator of that installation file. it should be prepared correctly so that this type of problem does not occur.

Thus, it is an INSTALLATION problem... or a step further back, it is the CREATION OF THE INSTALLATION problem, which is still the responsibility of the creator/provider/SYMANTEC to fix.

[Steffen_Hoffman]

the answer is simple. there is a programming error in the installation file of symantec.
the only things you have to do is 1. enable 8dot3 names on the command line:

fsutil behavior set disable8dot3 1

2. restart your server
3. give the folder backup exec a 8dot3 name on the command line:

cd docume~1
cd alluse~1
cd applic~1
cd symantec
fsutil file setshortname "backup exec" backup~1

then you are ready to install.

[Joey_Ahrens]

excellent answer, and it may work. However it defeats the purpose of an MSI file from a provider who should be deploying/sharing a file that can be doubleclicked and run without further ado.

[Robert_Kuhn]

In the following message thread:

http://forums.symantec.com/discussions/thread.jspa?messageID=4467885#4467885

It pretty much recommends the same thing and it does work or at least it does get past the MSXML part of the install.

But you're right, it does defeat the purpose of an MSI file.