What is the proper way to replace or update a protected system file? I have received a vendor package that is replacing one protected system file msvcp50.dll. This of course causes windows to complain. I've contacted the vendor about this and it is my assumption that they have authored their package wrong in the method they are using to update a protected system file. Web searches for replacing protected files results in too many hacking pages. I want to find out what the MS supported method is for replacing a protected system file is. If the vendor's package is incorrect I want to be able to let them know that it is a problem with their software and not our workstations. My guess would be that they would need to have this dll certified with MS and have it signed in order to replace it correct? Anyone know?
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
This bit from msi.chm might help. Make sure the wfp protected file is a component keypath.

Note that if a Windows Installer component contains a WFP file, this file must be specified as the key path for the component.
When the installer attempts to install a component's key file on Windows 2000, it first calls Windows File Protection to determine if the key file is protected. When the key file of a component is protected by WFP, and that key file is already installed, the installer updates the component only if the version of the key file in the package is greater than the installed version. If the installation package specifies that a component be installed, and the key file of the component is not currently installed, then regardless of whether the key file is protected the installer installs the component. Once any component having a key file protected by WFP is installed, it is permanently installed, and the installer never removes or replaces the component.
Answered 01/11/2008 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
Hello All,

Owen are you suggesting that the component holding a WFP file should be made keypath and how about marking the component as 'Transitive' as well. Just an thought, please let me know if am wrong.

Cheers[8|]
Answered 01/13/2008 by: India_Repackaging
Blue Belt

Please log in to comment
0
The problem, I suspect, is that the vendor hasn't conditionalised the component to NOT install the system file under Windows XP. I would think that this file has been left so that the application works under Windows 2000 systems and earlier. The route to take would be to just conditionalise the component using "VersionNT <= 500", then the file wont attempt to install under a Windows XP system, thus avoiding your problem.

P
Answered 01/14/2008 by: Inabus
Second Degree Green Belt

Please log in to comment
0
The route to take would be to just conditionalise the component using "VersionNT < 500", then the file wont attempt to install under a Windows XP system, thus avoiding your problem...except, of course, the OP *wants* the file replaced, not to avoid its replacement! :)
Answered 01/14/2008 by: VBScab
Red Belt

Please log in to comment
0
WFP is there for a reason, updating a core system file like this is just plain silly when Microsoft could potentially patch it with a security update down the line.

You then have the version question, what version of the file is currently installed and "protected" and what version of the file doesn this vendor MSI want to install?

I would like to point you too the following article:

http://support.microsoft.com/kb/898628

And I quote "WFP prevents applications from overwriting system files. Windows Installer cannot overwrite WFP-protected files."

P
Answered 01/14/2008 by: Inabus
Second Degree Green Belt

Please log in to comment
0
Well, that was kind of my point. Your last response answers the original question. A more complete answer would have advised that WFP files can't be replaced and that if the vendor MSI is trying to do that, the relevant component needs to have a condition added to not install it for systems with W2K and above.
Answered 01/14/2008 by: VBScab
Red Belt

Please log in to comment
0
My answer was to fix the problem the vendor has produced however you have rightly pointed out I didnt give the reason for my answer, so in future ill try to avoid ambiguity.

P
Answered 01/14/2008 by: Inabus
Second Degree Green Belt

Please log in to comment
0
I should have mentioned that this vendor patch is not an MSI but rather a legacy install shield setup.exe. The original mscvp50.dll has a date of 8/23/2001 and the new one has a date of 5/13/2007. So it looks like I should tell the vendor that they need to fix their package so that it does not try and replace this file because it could be overwritten by MS with an update? I would like to be able to tell the vendor why/how they should fix it rather than just say it's broken and have them blame my environment.

I've noticed that when it comes to software support problems where you can tell the vendor exactly what the problem is and suggestions on how it can be fixed gets better results than just having them open a trouble ticket for a problem one person is having.
Answered 01/14/2008 by: joedown
Second Degree Brown Belt

Please log in to comment
0
Just snapshot it as its a legacy setup.exe and not an MSI.

If I was to ask the vendor to fix it I would say conditionalise the component the file is comming from so it wont deploy to an XP and upwards system.

P
Answered 01/15/2008 by: Inabus
Second Degree Green Belt

Please log in to comment
Answer this question or Comment on this question for clarity