Here in Part II i’ll show you how to properly manage the future with ADR’s, whilst catering for the past with Baselines.
Handling Windows Updates can be tricky at the best of times. Timing, testing and the sheer resource to complete that can be a headache. However by utilising SCCM’s ADR’s (Automatic Deployment Rule) and ensuring we are testing on Dev machines first can really take the strain off.
It’s been a long time since I’ve seen anything spread like the WannaCry/EnternalBlue exploit has over the past 24 hours. And I like many other admins around the world have been pulling together reports and ensuring our estate is fully patched with Microsoft MS17-010, so to ensure the devastating damage done to the likes of the NHS has doesn’t spread further.
There have been some great guides through the years on configuring WSUS with SCCM from the ground up, but i felt it was time for me to add to the library with an updated version to cover Server 2016, and particularly my personal recommendations for a successful A-Z setup.
In Part I i’ll take you through configuring the required Server Roles & Features, WSUS Installation and Configuration, IIS settings, Folder Permissions and linking it all up into SCCM.
I’ve created dozens of State Migration Points over the last few years, and 99% of the time, i’ve had to alter the permissions in 1 place or another to get it to work properly.
Having researched this alot, I note there is no 1 place to say, Set these permissions…Until now..
How do we make OSD failure obvious? How do we make it so it’s impossible to miss even to the most basic of user that the machine they are looking at has not been deployed correctly, and needs attention..
Picture this if you will, you have 20 models of hardware in your organisation that you’ve meticulously created Driver Packages for and ensured they build correctly with your managed images, thus creating a list of Supported Hardware. Sounds good, right?
So imagine the surprise and confusion when on a cold and dark Monday morning before your first cuppa, someone rings you up to say their computer won’t build, or missing certain drivers once it does!
Only, things aren’t as they seem. As you find out once you’ve delayed your first cuppa, and have come to find out that this computer is a completely different Manufacturer, let alone Model from anything anywhere near your list of Supported Hardware. So it’s not surprising it’s failing to build!
Sound familiar?
Bringing OEM Files back to life, and why you should use them.
OEM Files as I call them, or $OEM$ as it was more commonly referenced in MDT times gone by, are quite simply a bunch of files and folders that you wan’t to copy onto every machine you image. Why would I want to do that? – I hear you ask, well for a multitude of reasons I would reply.
