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 Comments
Leave a Reply. |