Earlier this year I was teaching a Configuration Manager class and we were discussing software update testing before deployment. I asked members of the class how much time they spent testing software updates before deploying them given that the average time between the release of an update and a publicly available exploit was around 6 days.
I got a variety of answers. Some of the organizations that students worked for had a lengthy update testing process which could mean it was several weeks between when an update was released and went into productions. Others had a more cursory testing scheme, deploying updates to a small number of production servers before redeploying the updates across their organization.
The answer that interested me the most was a student who told me that they simply deployed updates without testing them. His reasoning was as follows:
This approach seems to be an attempt to balance the risk of an update ganking systems with the not insubstantial cost of thoroughly testing updates before deployment. It relies on software vendors being reasonably thorough about testing updates prior to deployment. If your organization is finding few actual problems when testing updates prior to deployment, perhaps you are allocating more resources than necessary to mitigate a specific risk.
My new book: Windows Server 2008 R2 Secrets. It is a book for experienced Windows administrators new to Windows Server 2008 R2: