In this second installment of our ConfigMgr community highlights, I had the opportunity to have the MVP Maurice Daly (@modaly_it) participate. I’ve known Maurice for many years now, as one of my projects at my former company was starting to cross paths with a project Maurice was just releasing initial versions. We both wanted to reach out to vendor provided BIOS & Drivers, pull down and use in our environment, but doing it automated with PowerShell. At the time, I wanted to run the script on the end point during OSD an apply BIOS & Drivers directly from the vendors website to the machines. Maurice was making a bit more polished solution, where you’d pull down the vendor files into your source location and build our the CM Packages to support them.
Thanks to the efforts of Maurice reaching out to vendors and getting them to publish their catalogs in machine readable formats, many things are now possible for those scripters that wasn’t just years ago. And if you follow Maurice on twitter, you’ll see him calling out vendors when they publish faulty catalogs and getting vendors to improve their own processes. If it wasn’t for Maurice pushing OEMs to create and maintain these catalogs, many of the things I personally have created for work wouldn’t exist.
I’m unsure how many downloads of his tools there are, but I’d imagine it’s quite high. He has taken a difficult process and simplified it, helping admins everywhere take control of drivers and BIOS, and allowing everyone to do it through a simple easy to use interface.
On a personal level, Maurice is an all around great guy. We’ve had several interactions via twitter over the years, and run into each other in person at user groups and MMS, its always an absolute pleasure to chat and hang out.
What was your drive for creating the Driver Automation Tool, was it personal, professional or other modifications behind it?
Developing the script that ultimately became the “Driver Automation Tool” was just something that started off as a personal goal for me within my role as a systems admin. At the time I was managing an estate of several hundred machines, quite small in the grand scheme of things, but I had a goal to keep client machines up to date with the latest drivers and BIOS releases. I suppose this goal stems back from when I used to work with an OEM and found that simply deploying and ignoring these updates was something that could lead to instability and cause me a bigger headache down the line. The monotonous monthly cycle of downloading, importing, distributing, and deploying these updates became a bit of a chore. At the time I was also starting to play around with PowerShell scripting, so I thought I would look at how I might automate some of this process for my own gain. Initially I discovered I could parse websites, obtain links, and automate the download process, which I thought was a good start, but I wanted to go further. Adding more and more lines of code, I was then able to automate the process of importing the packages, and distributing them to the DP’s, which was amazing at the time. I could now simply kick off a script and come back the next morning to a new fresh set of drivers for all the models in our environment. For me that was an amazing personal achievement. I had created something that saved time for me, allowing me to focus my efforts on other things. At this point it was time to publish the code so people could use it.
Was creating a “Community Tool” a goal?
To be honest, initially no, I just wanted to share what I had done. Then this thing kind of just grew legs all by itself. I posted the initial command line based solution online on the now sadly defunct Microsoft TechNet, and soon after it started to get a fair bit of traction, but I thought the script based solution might not be for everyone if this was going to become something that everyone could use. Lets face it, the majority of us were forced away from the command line to UI’s in our career, and if you are in that generation of engineer, being forced back to the command line via PowerShell was something that many did not want to embrace. I set about converting the code into a UI, and ultimately published the first release which I called the “Dell Driver Tool”. Publishing this on TechNet generated a lot of traffic, in fact within a couple of days I was contacted by Warren Byle (@WarrenByle) in Dell, asking politely if the Dell logo could be removed from the UI as they had been receiving calls on how to use the tool. Not wanting to invoke any legal issues, I VERY quickly obliged. The next step was to support more OEM’s, so through Twitter I started building up lists of contacts who worked within these large corporations but were so willing to help. These include Nathan Kofahl (@nkofahl) from HP, Joe Parker (@joe_lenovo) from Lenovo, and Carl Luberti (@CarlLuberti)from Microsoft. Over the years it has changed from being several separate OEM tools, to an all inclusive one today, and I learned a lot during the process. Sure if I was to start over again, I would write a lot of the code differently, but it does its job and over the years I have moved away from parsing websites (thank you Gary Blok for giving me that push), I have added more and more features, and I am always trying to refine it (when time permits given an ever busier work and family life)
What is the feature in the tool you are most proud of?
For me it wasn’t so much features within the tool that I am proud of, OK I am proud of a lot of the UI elements as that took time, but to me it’s the fact that the development of the tool lead to OEM’s developing XML catalogues which initially were used within the tool and now are used within their own product sets. That to me is amazing that community contribution can drive development for tools which then extend the capabilities of Configuration Manager and other products.
How did other members of the community influence you, and help you add more features?
When I started off by looking up to those in the Configuration Manager online community, most of which was happening on Twitter, and discovered a mind-blowing list of people who were putting solutions together to help automate things. Individuals like Kim Oppalfens (@TheWMIGuy), Mike Terrill (@miketerrill) and Johan Arwidmark (@jarwidmark) were putting down solutions which I was starting to consume. The tool really came into its own though when I got together with Nickolaj Andersen (@NickolajA) and we started creating a deployment script based solution with a web service back end, effectively creating an end to end automation process that was a single line within your task sequence. I am sure Nickolaj would agree with me that we never intended for it to use up so many hours over the years, but it was been something we have been passionate about for the community.
Any developments on the horizon you can share?
Recently the deployment scripts have been re-written to support the AdminService, and there has been a bunch of additions for compression options. The one thing I am going to focus on for the next release is providing is porting the solution to Intune, and getting through the list of feature requests that are building up on GitHub. I do though see a point where much of what has been done in this whole area becomes a more native function, this might take time, and its great to see white papers coming out on what this might look like from the OEM’s. Until then I’ll keep posting updates and supporting those using the solution.
Any final thoughts or comments?
I must say a massive thank you to everyone who has contributed over the years. The configuration manager community online is quite unique I believe, as we are all willing to share ideas, solutions, and help those in Microsoft who develop the product we love.
As Maurice mentions, this is a unique community to be a part of, so helpful, willing to share, and genuinely wants to help lift each other up. I’ve added twitter names to the folks Maurice name dropped, and if you don’t already follow them, you should do so right after you finish reading this. Thanks Maurice for taking time to answer a few questions and provide a glimpse into how some of our favorite tools came into being.