Author: Bryan Dam (page 2 of 3)
12/20/18 Update: Removed a check for WSUS cmdlets that prevented the script from working on 2008 R2 and the ReSyncUpdates from the WSUS standalone config file. 12/10/18 Update: Fixed a configuration file parsing problem and added licensing information for GPLv3. Note: When updating you will need to update any existing plugins as well. Despite a […]
As a rule, you shouldn’t need to do this but there is currently a specific use case where you will. The impact of getting it wrong is not pretty so learn from my mistakes. Then vote on UserVoice to make the whole thing just go away.
App Model: Good. Supersedence: Bad From the start I’ve tried to make the most of the ability to define application dependencies and supersedence relationships. For instance, we create dependencies for Visual C++ redistributables so that we can identify the apps that rely on those that are not longer supported. The later however, supersedence, has rightfully […]
The first release of my update reports was a total lie. There was absolutely no dashboard in what I called ‘Yet Another Software Update Dashboard’. I’ve fixed that.
I went to MMS. I have a blog. You figure it out.
Things got real last week and ‘all of a sudden’ organization realized that what the product MVPs have been saying for years is true and simply not optional: you must be running a software update maintenance script. I’ve updated mine to be more useful. Because I’m like that I guess.
With the Olympics over, my MMSMOA session drafts in, taxes done, and a thousand or so pages of classic sci-fi read it’s time to post something. My degree is software engineering and for a brief period of time I was a professional developer. Instead of a profession it’s become more of a hobby that I enjoy […]
Configuration Manager’s Automatic Deployment Rules are the ‘killer app’ that makes the product one of the most powerful tools for software updates. However, with that power and flexibility comes complexity that can be daunting for the uninitiated. In this post I try to brain-dump the lessons I had to learn when coming up to speed in the hope that it might help others.
When looking to prove that Configuration Manager was actually patching devices I quickly found the built-in reports lacking. I looked at existing solutions but I wanted something just stupidly simple that I could send to management and be informative at that level. At the same time I wanted to be able to drill-down so that administrators could identify and resolve any issues. Here’s what I came up with … let me know what you think in the comments section.
There’s lots of ways to define compliance but if/when you move to the cumulative update model the biggest question is simply: do I have the latest cumulative update applied. You’d think that’d be easy to report on but it gets messy quickly. Here I’ve released my first shot at it.