Last year I wrote a blog post on how to update ConfigMgr clients in a way I consider quite lazy, I’m talking about this one:
This method worked fine but it still required some administrative effort and the behavior was a little bit difficult to manage.
Last week, I attended a session of the Dutch Windows Management User Group, also known as WMUG NL, where two gentlemen were speaking about Patch Management using ConfigMgr. I’d like to thank Kent Agerlund and Brian Mason for sharing their knowledge and tips on how to manage Patch Management using ConfigMgr. Most of the stuff they talked about is already familiar to me, but there’s one thing that caught my attention that Brian was talking about.
Brian stated in his presentation that he uses System Center Updates Publisher 2011 to publish ConfigMgr 2012 Cumulative Updates to WSUS which will then be imported and deployed by the same ConfigMgr 2012 Site infrastructure. After some digging I found Microsoft’s TechNet article that describes it:
It even describes the required steps to publish a Cumulative Update.
I’m currently involved in a project where I have to build a ConfigMgr 2012 R2 test environment that the customer can use to test his required ConfigMgr 2012 R2 related features. It allowed to find out how to publish these Cumulative Updates. I have to admit, it was ridiculously easy to do. After synchronizing Software Updates I was able to see and select the Cumulative Updates for further deployment.
Using this method makes patching more or less a ‘fire and forget’ thing which is way more sophisticated than my previous approach which has now become obsolete J
For newly deployed machines using OSD, I believe I wouldn’t bother to install the patch in the client installation task using the PATCH=<whatever> parameter. I don’t like that method and it requires me a lot of administrative effort to get it right. Installing the update as a patch is far less of a hassle…