Tools that do "snapshotting" aren't actually capturing the logic in an installer, and could do the wrong thing under circumstances different than when the snapshot was taken. Patch management tools that claim to automate the patching process have always given me a bit of pause.
I've never used a third-party patch management tool, so I can't comment. I disable the updater as a transform to the MSI for Adobe Reader. Users don't have "Administrator" rights on their computers and can't install any updates themselves anyway. I need to be able to centrally control the deployment of updates such that I can test the update prior to deployment. Having the client computers download patches themselves via the built-in updater functionality in Adobe Reader is useless to me. (If you've got the money to pony-up for Microsoft's System Center Configuration Manager, you can use the built-in System Center Update Publisher to deploy these types of updates.) If they do go to EXE-based updates, I'll write scripts to deploy them silently via computer startup scripts. (Hopefully they'll stick to a Windows Installer based patching regime from here on out. If Adobe decides to start distributing EXE-based patches, then I've got a problem and have to begin writing scripts. This recent Adobe Reader patch (9.1.2) is MSP-based, so I'm able to deploy it in my usual manner. I don't particularly like doing things this way, but it's the least labor-intensive method I can see. I've been applying MSP-based patches to my Adobe Reader installation points and then instructing client computers to reinstall via the "Redeploy." functionality in Group Policy. I install Adobe Reader via Group Policy and software assignment.
0 kommentar(er)
