Today I was thrown an interesting challenge. Get GDIPLUS.DLL updated on 17,000 machines in a real hurry.

What makes it interesting is it seems dozens of products have all isolated this DLL to some degree ( either side by side assemblies or privately ).

Also it seems many of these products use MSI and make the DLL a key file so I think just simply searching the harddrive and replacing or deleting the file is out of the question since resilency would come by and "repair" it.

So I'm reaching out to my MSI community for thoughts on how to create an effective way for fixing all vunerable DLLs regardless of the product or installation method that was used.

So far Microsofts way seems to be to scan your machine for products that need to be patched then offer you a seperate exe ( bootstrapped .MSP ) for each product.

That doesn't seem like that would be easy to implement on the 17,000 machines in my enterprise.

Anyone have any ideas?
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
Since you have applications with the DLL isolated I think that is going to be your only option unless you want to redeploy / reinstall every application that uses it. You can push that DLL out there but as soon as new installs, reinstalls and self healing occur you will be left with the old DLL.
Answered 09/17/2004 by: kkaminsk
Ninth Degree Black Belt

Please log in to comment
0
Actually now that I think of it if you manage to copy that DLL to every location that has the dll the MSIs should not regress the DLL on self heal but when you get new installs you'll still have to update your existing packages.

Also a uninstall / install of the application will break this too if no other application is using the DLL or if it's isolated.
Answered 09/17/2004 by: kkaminsk
Ninth Degree Black Belt

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