Chris Nackers

ServiceNow

What OS Deployment Taught Me About ServiceNow

2026-10-26

Before ServiceNow, I spent years in ConfigMgr and MDT land. OS deployment, task sequences, driver packages, the whole thing. A big chunk of the 600-plus posts on this blog came out of that work.

It’s been a long time since I was in that world. So I went back through my old posts to see what actually stuck. Turns out a lot of it did, just with different names on it.

Here are six lessons from my OSD days that still shape how I run ServiceNow work today, each with the old post where I learned it (sometimes the hard way).

1. Pilot first

Then: In 2009 I removed the step that auto-logged in after imaging, to streamline things. Seemed harmless. On the next big laptop refresh, machines that had never had a user log in dropped into standby, and Wake-on-LAN couldn’t wake them mid-build. As I wrote at the time: “Often as you automate things, other nifty glitches you didn’t see coming creep up.” (Dealing with Laptop Standby Power Mode)

Now: Still the same. Work in dev, promote to test, verify, then promote to prod. Most ServiceNow customers have at least two sub-production instances, so we do our work, then test, UAT, and so on. That’s just standard release management.

2. Garbage in, garbage out

Then: At a client in 2010, Distribution Manager was logging about 2,000 errors for a package called “.NET Framework”. I went through every package and couldn’t find one with that name. Turns out the console builds the display name from three fields, but the status messages only show one. The fix was boring and effective: a naming standard. (Importance of Properly Naming Packages)

Now: Same lesson, bigger stakes. Whether it’s AI or ServiceNow, you need clean design, clear direction, and some thought up front. Bad data in the CMDB doesn’t throw 2,000 errors. It just quietly gives you the wrong answer.

3. Automate the repeatable, keep people for the challenging stuff

Then: Drivers were the classic fight. Automatic driver matching was quick, but it always grabbed the newest driver, and our CAD workstations needed one specific certified video driver. When I really sat down and thought about it, the video driver was the only one that mattered. So I let automation handle everything common and hand-controlled the one exception. (ConfigMgr 2007 Driver Management)

Now: 100% still relevant. Automate what you can. It improves efficiency and frees up your architects and business process consultants for the work that needs a human: design, and understanding why things are the way they are.

That usually means workshops with the customer. I like to start with the framework (if there is one), ITIL for example, then find out how they actually use it in relation to the platform or framework. From there, we either bring it closer to standard, or confirm they really do have an edge case that needs what they built.

4. Know what you changed

Then: In 2013, driver imports suddenly started failing at a client, both in the console and from a script. I searched for a while before it clicked. In my own words: “Well as it turns out, I had just moved around the DB and Log files for this client to new drives.” (Unable to Import Drivers After Moving SQL Files)

Now: We really didn’t do much formal change control back in the OSD days. It wasn’t true development, or at least it didn’t feel like it. Today it’s standard practice: change records, testing, a way back. Standard release management and project methodology covers it. ServiceNow also does a pretty good job of capturing changes in update sets so you have a running log of changes made (mostly).

5. Use the tool as it is

This is the big one for me.

Then: Two posts tell the same story. In 2009 I hand-added mass storage drivers to my WinPE boot source, and every update of the deployment point rebuilt it and wiped my change. (Integrating Mass Storage Drivers) The fix was to use the supported way to add files, so the change got re-applied every time.

And in 2011, at a client, we imported a pile of exported custom reports over the stock ones and broke the built-in report links. “Recently was working at client, we caused ourselves a slight reporting issue.” Slight. :) The way back was regenerating the original stock reports from the product’s own files. (Recovering Stock Reports)

Now: I’m always comparing to stock. ServiceNow designed it a certain way for a reason. So when a business does something their own way, I want to understand the reasoning. Did they always do it that way and not know better? Or is there truly a valid business reason? As a Solution Consultant, I don’t just assume the customer is doing it wrong, I always try to understand why they do it a certain way, and if that differs from what we would recommend as an implementation partner, then we have that conversation in a thoughtful way.

Use the tool as it is. Don’t bend the tool to your way.

6. Community

Then: My very first post on this blog thanked myITforum, because it had been a tremendous help to me. The next year at MMS 2010, Johan Arwidmark and Michael Niehaus presented on driver management, and Johan gave me a nice plug for my driver post. A blog post turning into a conversation with the people I’d learned from was a pretty great feeling, especially when I was just starting out. (Microsoft Management Summit 2010)

Now: The OSD community was pretty small and tight-knit back then. ServiceNow is a beast, and the annual Knowledge conference has over 20k attendees. For me, I haven’t been doing all the speaking at conferences like I did back in the Microsoft days, with ServiceNow it’s a focus on the customers and conversations I’m having. Hundreds of customers, across every industry, and talking to the varying roles at a company: helpdesk, developers, directors, CIOs. Understanding everyone’s view of the platform, what they think it can or can’t do for the business, and helping change that perception and drive adoption company wide, that’s my passion now. Operational excellence, that’s what we strive for with our customers.

The short version

  • Pilot first. Dev, test, prod.
  • Garbage in, garbage out, in the CMDB and in AI.
  • Automate the repeatable. Save people for the challenging stuff.
  • Know what you changed.
  • Use the tool as it is.
  • Community is everyone who touches the platform.

Different platform, same lessons. At least I think so… I could be wrong!

Hope this helps someone else who made the jump from one world to the other. If you came from System Center too, I’d love to hear what stuck with you!

-Chris