1.Short file name creation is disabled on the target machine.
Resolution: Enable support for 8.3 name creation, i.e. short file names, on the target machine. Navigate to the following registry entry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
A NtfsDisable8dot3NameCreation value of 0, zero, enables the short file name creation functionality and a value of 1 disables this functionality.
Registry modifications require rebooting the target machine for the change to take affect and this should be done before attempting to launch the setup again.


2.The Windows Temp folders are full.
Resolution: Free up hard-disk space by removing unneeded files.Clean up the windows temp folder as well.

If this does not work then you will need to open a service request. Quote bug 53008 and that will help support in the next step here..

Thanks,
Alan

Alan,
Thanks for the recommendations. I should have mentioned in the first post that this is also an active/passive Microsoft cluster. We receive the error on both nodes of the cluster, regardless of which node is hosting the resources.

1. I checked the registry and NtfsDisable8dot3NameCreation is set to 0 already on both nodes.

2. The C: drive, which is where all Temp variables point to has 300GB of free space on each node.

I will go ahead and open a Service Request.

Thanks,
Aran

Aran, Did you get a resolution to this? I noted emc156651 which might help.

Go to Control Panel.

Start > Settings > Control Panel.

Double-click Add/Remove Programs, select Add New Programs, and select CD or Floppy.
Select Next.
Select Browse.
Locate the folder of the Replication Manager software (or Service Pack) source location.
Change the Files of Type to all Files.
Select ermpatch.bat, and choose Open.
Ermpatch.bat is added to the command line that appears in the Open box of the Run Installation Program dialog box.
Select Next to begin the installation.
After the installation of the Service Pack is complete, on the After Installation dialog box, select Next and Finish to complete the installation and to return from install mode to normal user mode.

The issue has not been resolved yet, the SR is still open.

I tried the process you listed and the results were the same.

Whats the SR ? i'll track it down.

It is 24848542. I received an update from the support technician this morning, the issue has been forwarded to Installshield by the engineering group.

This issue has occurred because a number of catalog (.cat) files are corrupt on the system. The .cat files are used by the Microsoft Windows Installer.

See solution emc212632 for workaround.

Alan

Message was edited by:
KCSPam

Yep, this has actually happened on a couple of different systems when upgrading to other versions of RM as well. The catalog file replacement fix resolves the issue every time.

Did you open an SR with Support ? Thats your route to getting Engineering assistance to provide the necessary files to fix this.

Alan

Eduardo,
The key was determining which catalog files were causing the installer to fail. To determine this you have to enable logging of the msi installer.

Open the registry and create the following path and keys:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Reg_SZ: Logging
Value: voicewarmupx

Then when you run the installer a msi.log file will be created in your local profile's temp directory. After the installer fails search for the string "hash doesn't match" in the msi log. You should see and entry like this:

MSI (s) (A4:64) [08:20:20:943]: File:
C:\WINDOWS\winsxs\Policies\amd64_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a
1e18e3b_x-ww_d780e993\8.0.50727.42.cat; Overwrite; Won't patch;
Existing file is unversioned and unmodified - hash doesn't match source file

Rename the extension of the .cat file listed to something else like .bak and then copy the .cat file from another server that is at the same patch level as the server experiencing the issue.

Run the RM upgrade again. If it fails again, repeat the process above until all the .cat files that cause the process to fail have been replaced.

Sirius,
I can't find that Primus article on Powerlink. Can you double check the primus article number?

Solution emc212632 exists but the segment you posted (reg key .etc) is viewable to support only. The idea being like you said to identify the problematic .cat files and that RM Eng would provide the needed good ones. Copying them from another known good server of course would work fine too

Message was edited by:
KCSPam

Is it not a publicly viewable article then? When I search for that article in the knowledge base it returns zero results.

I checked and it was only internal, i have changed this to be customer viewable.....Thx, Alan