business, humor, Technology

2001 vs 2021 (aka 2020 CU1)


IT planning Meeting: / Project = Document Management

Teams present: IT Architect, PM, InfoSec, Network, Storage, Accounts, Licensing, Customer stakeholders, Customer stakeholder stakeholders, Stakeholders for other stakeholders, Vendor reps handing out business cards and shaking hands, all packed in one conference room.

Preliminary: Storage and Network teams are blaming InfoSec for system issues. InfoSec is blaming Licensing for holding up a PO. Licensing blames the CFO. PM asks them to keep it down.

Vendor: “(blah blah blah blah blah blah) some pointing and hand gestures learned from a sales book.

IT PM:Thank you for the introduction, Bob.”

Vendor: “Uhhh, it’s Doug, actually.”

IT PM: (turns to stakeholders) “So, what features do you need from Electronic Document Management?

Customer: “What does it do?

IT Architect: (talks for 30 minutes, reads directly from PowerPoint slides, attendees coughing, staring at Blackberry phones, texting jokes about TV sitcom episode from previous night, sounds of thumbs clicking on physical keypad, spoons clanking against coffee cups) … “Any questions?

Customer: “We need all of it.

General IT takeaway: (old-timers: dread. younger folks: excitement)


IT Planning Meeting / Project = Cloud Security

Teams present: Cloud Architect, PM, InfoSec, Cloud Networking, Cloud Identity, Licensing, Customer stakeholders, Customer stakeholder stakeholders, Stakeholders for other stakeholders, Vendor reps, everyone on a Teams call.

Preliminary: Azure/AWS/GCS and M365 teams are blaming InfoSec for system issues. InfoSec is blaming Licensing for holding up a PO. PM asks them to keep it down.

Vendor: “(blah blah blah blah blah blah) some more PowerPoint slides and a QR code.

IT PM: “Thanks for introduction, Juan.”

Vendor: “Uhhh, it’s Carlos, actually.”

IT PM: (turns to stakeholders) “So, what features do you need from Cloud Security?

Customer: “What does it do?

Cloud Architect: (talks for 30 minutes, reads directly from PowerPoint slides, attendees not on mute add background sounds of cats, dogs, birds, car horns, kitchen pots and pans, messaging about Netflix/Hulu/YouTube/Amazon/HBO show from previous day, crumpling fast food bags, spoons clanking against coffee cups) someone keeps taking a heavy drag on their vape in front of the mic … “Any questions?

Customer: “We need all of it.

General IT takeaway: (old-timers: dread. younger folks: excitement)

business, Devices, Scripting, System Center, Technology, windows

5 Things You Should Have Automated by Now

The Long Back-Story

(queue the campfire scene, under the stars, with distant harmonica and bearded old man, smoking a pipe of something, and all the little systems engineers, all gathered around to listen in their fuzzy pajamas)

For the last three decades, the roaming bean-counters of the world have quietly been building up a pressure-cooker of angst from all the walk-up status inquiries in the IT cube farms of the world. Each time they’d ask for a status update, they’d get a magical (mythical) answer. Specificity was lacking. Upper management was not happy. Vendors kept nodding in agreement, but were still focused on the product users, not the check-writers. That changed soon after the Cloud popped up.

I may blog about my thoughts on “The Future of the IT Worker”, if I have enough wine or beer to motivate me.

Short version: Shareholders buy stock in a company to make a profit on rising value (stock prices). Stock prices rise when the company increases profits. To increase profits, the company can only increase the gap between revenue and expenses. For 99.9% of businesses, IT is a “cost center”, or an expense. Shareholders DGAF* about imaging computers, change management reviews, or what your name is. They care about 2 things:

  • Increased profit margins
  • No bad press

Both of those points are impacted by expenses. Shareholders don’t like expenses. They bitch about expenses, a lot. They hire consultants to analyze expenses, and these days, one of the first areas they look is IT. Asking question like:

  • Why so many IT staff?
  • Why are you re-imaging every computer you buy, when they already work?
  • Why do you still have datacenters?
  • Can we move to a cheaper lease?
  • Training?! You don’t know this stuff already?

Seriously, the emphasis on “what value do you bring to the company?” is only going to get heavier and heavier.

So, in the interests of making yourself more valuable, I suggest bringing a little automation to your job. And, based on what most customers I know have already implemented, this is my 5-point list of gotta-have things:

[1] Active Directory User Account Processing

New hires. Temp staffing. Terminations. Name changes. Promotions and transfers. All of these tend to chip away at your precious time. Relying on a bundle of task-specific scripts is a good start: creating accounts, resetting passwords, adding/removing group members, and so on. But anything you have to stop and tend to with your own hands needs to be considered for automation.

Like all automation processes, it starts with the “authoritative source” of information. Usually HR. Whatever data they’re entering for a new hire, use that to drive everything else. Do not duplicate efforts by entering that information again somewhere else, as this not only wastes time, but adds risk of inconsistency.

If you don’t already have it, request access to whatever information you need to drive the entire process along. Make a list of all the user-related processes you deal with. Divide each process into distinct phases or tasks and work on them one at a time until you have the whole conveyor belt running.

Ideally, when HR says someone has been hired, your IT systems should immediately handle it. Changed departments? New surname? New job title? Done. Got fired for having sex on a forklift during work hours? Done.

Gaining experience with the HR systems and processes not only makes your job easier, it makes your role more valuable in the organization. Once the processes are automated, they will run more consistently and predictably, even if you go on vacation, and the organization will likely ask you for help automating other processes.

[2] Active Directory Computer Accounts Clean-Up

If you only have a dozen or so computers in your AD domain, you might get a pass here. But if you’re managing dozens, hundreds or thousands of computers, and you’re not running some sort of automated process to clean-out stale/unused accounts, you should be tasered in the crotch until the battery goes dead.

If you don’t already have something in place to automate this boring-ass chore, get moving. It’s really easy to implement a 3-step clean-up process:

  • Determine what criteria will be used to say a device account is stale
  • Identify and move stale accounts to an OU, and disable them
  • After X days, delete them

Once that process is tested, schedule it to run on its own.

There are hundreds of utilities and scripts available today to help automate this process, or you can build your own. Having a process in place means you can answer questions about asset inventory with a straight face, and calm down those bean-counters who freak out over the thought that things are out of control. “Relax, bean-counter person. I have it under control.

Icing on the cake: “I know we requested 1500 licenses of that software, but I confirmed we only need 1250. And with that $3000 I saved us, I’d like to attend MMS MOA this year, and buy a Hello Kitty flamethrower.

[3] Patch Management

The biggest problem I see today isn’t the patching itself, or the tools available to manage the patching. The biggest problem I still see is a lack of a process or procedure. If you’re still manually updating computers, especially endpoint devices (desktops, laptops, tablets, etc.), but even servers, pause here and do the following first:

  • Design a patching process: What, When, Where, and Who (owns each machine or system)
  • Give each group of machines or systems a name
  • Identify test machines within each group to validate monthly patches
  • Identify machines that can be patched at the same time, and which ones cannot.
  • Identify when machines can be rebooted

Having that mapped out will make it so much easier to pick and test the right solution (product or script).

After that, use your selected “test” machines for the initial pilot, and scale out from there. Start with the less critical machines and add the more critical machines later. That way you cover more machines early on, and work out the kinks before touching the high risk environments.

In the VAST majority of environments I’ve seen, the exception cases are the minority. So knocking out the machines with a consistent schedule also knocks out the biggest portion overall.

[4] Inventory Reporting

Fancy or basic, it doesn’t matter. The only thing that matters when the executives ask “how many ___ do we have?” is can you answer the question without lying your ass off. The other thing that matters, is when the BSA* comes to your door with a warrant, but that’s another story altogether.

How anyone can manage a computing environment without some sort of inventory reporting is beyond reason. That’s like expecting airlines to operate without flight plans.

Of all the examples listed on this post, this one is the oldest of them all. And since it’s been around the longest, there’s really no acceptable excuse to not have it automated by now.

If you don’t have a software product, or service, in use, get one. Many are free. If they don’t cut it, you can easily build your own with scripting and duct tape. Even if your devices are scattered across the globe, as long as they can touch the Internet, you can build something to make them squeal and give up their inventory data.

[5] Event Monitoring

Imagine if your car didn’t have a dashboard. Or your smartphone didn’t have a battery indicator. That’s pretty much the same thing when you manage computers without some sort of event and/or log monitoring. The data is being tracked somewhere, but unless you have a clear view of it somewhere, you’ll never know. Until it all goes sideways, and then you’re scrambling to find out where to look “under the hood” as the house is burning down.

Of all the support cases I ran into between 2015-2019, which related to some sort of “oh shit, our shit is broke! please help fix!“, most of the root causes fell into one of the following buckets:

  • Ran out of disk space
  • Service account was locked
  • Service failed to start
  • Configuration change impacted other processes
  • Network connectivity failure
  • Anti-virus was blocking a critical process

Every single one of these could have been avoided with the following simple tools:

  • A monitor to report potential problems
  • An automated process to remediate each of the potential problems before they get worse

Flying blind is no way to run a datacenter, let alone a bunch of computers. Whether you prefer to buy a solution, or build it yourself, just get something in place. In every instance where this was done, the number of “oh shit!” events dropped significantly.

Maybe you like getting a panicked call from a manager on the weekends, at 3am on a weekday, or while you’re on vacation. That’s not my idea of a happy life. And applying some basic automation to monitoring is not only one of the easiest types of automation, it’s often a good on-ramp to scaling your efforts into other areas that drain your time every day.


business, Projects, Technology

The Top 20 IT Problems I Still See at Most Organizations

[NSFW-Warning] The following list of douche-brained issues are not in any particular order, so some items may be more or less important to you than others, regardless of their assigned number. I just needed a way to count them after finishing a glass of whiskey (with an “e”).

Most, if not all, of these are systemic, and are human-related. Most of these appear in groups, rather than isolated, which points to lack of coordinated management from the top, but that doesn’t excuse those at the bottom by any means. Ultimately, continued disregard of these will lead to what some analysts refer to as your shit will become entirely fucked.

Remember the 2 most important rules:

  • Good | Fast | Cheap >> pick 2
  • TARFU >> SNAFU >> FUBAR >> GFO (the “G” is for “Goat”, the animal)

In many cases, failing to address these items can land your organization on front-page news in a bad way. And shareholders do not like front-page bad news.

20 – Turning off Firewalls

A lot of organizations have adopted the habit of turning off client firewalls entirely. Even if you use a network firewall, turning off client (and especially server) firewall services is a bad idea. It’s always best to identify port and protocol requirements for whatever apps and services need to communicate, and allow those through the firewall as needed.

Leaving the firewall completely off is like leaving the bathroom stall door wide-open while you’re taking a dump at Walmart. If that’s your thing, more power to you, but I hope you stock up on antibiotics and chap stick. I mean, seriously, if your application needs to blabber on port TCP 1433, and only inbound, then open TCP 1433 inbound. It’s not that hard to do.

19 – Turning off UAC (Windows 10)

Similar to turning off the firewall service, this is a bad idea. Yet, I still see this fairly often. UAC, or User Account Control, is a protection service that intercepts requests for system-wide resources, and prompts for administrative approval before continuing. It’s the bouncer at the club. Unless you like fully-armed meth addicts wandering into your kid’s birthday party, you should keep UAC turned on.

If you use an application that requires you to disable UAC, get another app. If there isn’t another app, lean on the vendor REAL hard to stop drinking the bongwater and get off the sofa to fix it. It’s a clear sign of lazy programming, and it’s your money, so you have a right to complain.

18 – Ignoring Firmware Updates

This often smacks people in the face during device imaging (aka provisioning). “Why won’t this )#$*ing thing PXE boot?!” Yeah, check the BIOS version. Visit your network, storage and security appliances on a regular basis to check their firmware too.

Hell, check all your shit. You’re probably jaw-jacking about last night’s sports game anyway, or wasting time on Facebook. While you’re busy arguing about Trump and Pelosi, hackers are applying Vaseline to your security holes, and well, that just sounds bad already.

17 – Installing Multiple Anti-Malware Products

That was the “in” thing to do in the early 2000’s, when you had Justin Bieber posters on your wall, and spent evenings updating your MySpace page.

But today’s products have grown up. While most of them do a very good job of protecting your system from being hacked, the built-in Windows Defender product has quietly stepped up to the lead of the pack.

If you’re using Symantec, McAfee, Cylance, Crowd Strike, Carbon Black, Sophos, Malware Bytes, Jimmy’s Atomic AntiVirus, or whatever, you really should do a careful evaluation of what you really need. You could save a lot of money and headache in the end. And I just hate the shit out of McAfee. I had to get that in before I move on to the next item.

In most cases, if there is someone with a job title that references the product (e.g. “McAfee administrator”) it will be tough prying them away from it, because it will feel like a direct threat to their job. Be tactful. If that doesn’t work: try pepper spray.

16 – Not Keeping Active Directory Clean

I would estimate that in the last 10 years, 90% of customers I’ve encountered don’t apply rigorous controls over Active Directory user and computer accounts. The portion of stale accounts often ranges between 10% to 30%, and often includes virtual machine accounts.

I’m not going to dive into methods for cleaning up AD, or keeping it clean, just Google it. There’s a metric shit-ton of free solutions out there. If you prefer to write your own using PowerShell or something else, that’s pretty easy as well. But first: get a process in place and then build the solution.

The most common approach I’ve seen (and recommend) is a 2-step offboarding process:

  • Step 1: Identify accounts that you determine are obsolete, disable them and (optionally) move to a special OU.
  • Step 2: Delete them little bastards. (I recommend yelling out “Die you little bastards!!!!” with a diabolical laugh)

When you’ve tested it enough, set it to run as a scheduled job. Don’t forget to include logging.

15 – Not Keeping Up With Software Updates

This is by far THE most common issue in most organizations, big or small. And I’m pretty sure this doesn’t surprise you either. But the most common problem I see is not having a patching process defined. At the very least, I recommend identifying what your patching process needs to include:

  • Products to be patched
  • Machines to be patched
  • Business or process schedules to work around
  • Who “owns” the products and machines/systems
  • Where are the machines (on-prem, roaming, cloud, etc.)
  • Test machines and test users

Once you have the what, when, where, and who, you can look at the how. You don’t need to worry about “why” unless you’re dealing with complete idiots. Compare patch management products carefully to see which ones fit your needs, and your budget. Pilot test them and confirm the results. Start small and scale out. Then start working on your drinking skills, because you’re going to need them.

14 – Doing More Configuration Work Than Necessary

This is another thing I see mostly with regards to imaging computers. Custom Start menu and Taskbar layouts, shortcuts, wallpaper backgrounds, screensavers, legal banners, yada yada… I recommend having a sit-down with your users and ask some really basic questions, like:

  • Are you so stupid that you really need “us” to prepare your start menu for you?
  • Do you really need us to make shortcuts to the company intranet web site?
  • Are you smart enough to respect our advice to use Chrome or Firefox for most of our web sites and not the built-in Edge browser?
  • Did you know that legal banners at login don’t really hold up in court anymore?
  • Are you still awake? Is this thing on? Hello? (thump thump)

In the past 5 years, I’ve managed to get 3 customers to meet with their users and their upper management, and eliminate a good chunk of the silly training wheels and plastic helmet crap they were spending days keeping up to date. In the process they also gained a bit more respect from the users who no longer viewed IT as condescending control-freaks, but as enablers.

And if that doesn’t work, a pipe wrench should.

13 – Paying for Products and Services Not Needed

Custom apps are fine, when they fill a need that just doesn’t exist in the base operating system, or another product you already have. Supporting multiple, competing products, can lead to all kinds of headaches. From deployment and updates, to licensing, training, support requests, and more. In every single case I’ve encountered, the reason given was “we’ve always used it”, which isn’t technically a bad reason. But failing to revisit alternative options is technically a bad habit.

I’ve seen companies where different divisions used different products for the exact same function. As it turned out, just by picking ANY one of the products as the company-wide standard, would have saved them a significant amount from volume discount licensing. In several other cases, customers were paying for client backup software licenses, even though they had cloud drive synch products installed and used.

Other examples: Visio Pro, and Project Pro, when Standard licenses would have been just fine. PDF editors, when viewing and printing was all they really needed. The list goes on. TIP: Consider a Bounty program (see below)

12 – Granting Local Admin Rights by Default

I’ve blogged about this several times already. Most recently here. In short, don’t do it. Let them complain, after all, it’s for the good of the company. Or better yet: implement an embarrassment protocol for requesting admin rights. Something like having to come to work dressed as a giant sex toy, or wearing diapers on their head all day. Actually, you better check with HR first. And if they approve, ask if you can carry a sidearm to work as well.

11 – Insufficient Training

Technology is changing faster than ever before. Training is becoming a continuous pipeline. If your employer values what you do for them, they’ll value keeping you on top of it as well. If they don’t, then maybe it’s time to move on. There are employers out there who value their IT staff.

10 – Insufficient Staffing

Whether you’re any good at what you do, or not, eventually, you may end up with too much on your plate. If you spend most of your time keeping things running, rather than exploring ways to improve things and lower costs, then you may need a few more people to handle the load.

I’ve blogged about this quite a few times as well. The ever-popular “do more with less” mantra is becoming stupid. Not only is it bad for employee morale, and productivity, it’s even worse for the employer because it creates greater risk to business continuity (proverbial “hit by a bus” scenario).

If upper management doesn’t care about turnover rates, then it’s your signal to move on.

9 – Lack of Documentation

Often a sign of insufficient staffing (see previous item), this is usually from neglect due to lack of time. But when it suffers from lack of having defined policies and procedures, then you have bigger problems. Make a hit list of things to document first, and get to work. Even if you just get outlines and brief notes written down, that’s better than nothing at all.

If you suffer from lack of staffing, here’s your chance to prepare for a new hire. Make sure you provide enough detail to hand to the new person and let them run with it. You’ll be glad later on, that you took the time to do it.

8 – Insufficient Change Control

Everyone hates change management. It’s a necessary evil, especially in larger organizations. Many small shops can get away with minimal CM effort, but even then, it pays to keep track of changes and dates. So many times I’ve seen it point to a root cause for those “It just started failing. But we didn’t change anything” situations.

7 – Avoiding Cloud Services

Without sounding like a salesperson, not only is the Cloud here to stay, it is absolutely the future. We are at the same crossroads that existed when the automobile was sharing the roads with horses and buggies. Love it or hate it, get used to it. The sooner you get familiar with it, the better off you’ll be (and the more marketable your skills will be)

Don’t worry about feeling left behind or hopelessly lost. There’s plenty of online training and tutorials to help you. And everyone, I mean everyone, is still on a continuous learning conveyor belt just trying to keep up. It’s evolving and improving every day, so nobody knows it all.

6 – Using Servers as Desktop Computers

It’s one thing to use a “jump server” for isolating access to production environments. But you shouldn’t use production servers like a routine desktop computer because it adds more junk and overhead with each user profile and user session. It also opens up more risk for hacking exploits and malware.

Windows Servers in particular were designed for remote management. Make use of that. Whether it’s MMC, Server Manger, Windows Admin Center, CLI or PowerShell, there are many ways to easily manage remote servers.

5 – Treating Users Like the Enemy

It’s seems to me (anecdotally/subjectively) that about 25% of organizations with more than 200 users develop an “us vs. them” culture. Either users hate IT, vice versa, or both. Forcing conditions on users without giving them an opportunity to request changes only makes them unhappy, and less productive. You should want your organization to thrive. If not, you’re in the wrong job. Quit now.

Rather than making one-sided assumptions about what should or should not be included in their standard computer setup, start having conversations with them about what they like and don’t like. Take notes. Ask deeper questions. Even if you end up not making any real changes, it instills a sense in them that your group cares. That alone can go hundreds of miles when you need their help later on for a big project. Users as allies is always better than users as enemies.

4 – Not Selling Themselves to Upper Management

Not getting the budget you asked for? Not getting anyone to approve another position to hire? Not getting approved for training? Not getting approved to modify an old process?

Here’s why that is: Suits talk, read, think and dream in dollar figures. You have to convert nerd-speak into dollar-speak, or it doesn’t work. But beyond just translating your request for new software into dollars (costs), you need to show believable calculation of how it will either [A] lower operating costs, or [B] generate more revenue without incurring equal-or-greater costs. That’s it. Oh, and pour some chart sauce on it. Suits love chart sauce.

3 – Insufficient Monitoring and Reporting

So many times I ask “How is <fill-in-product-name> working for you guys?“, they respond with, “It’s working good“. Then I follow that with, “How do you know?” The responses from here can be interesting. Everything from “Well, it hasn’t broken-down or anything” to “It seems to work okay“.

But the only answer I want to hear is “Our monitoring and reports indicate it’s working fine” or maybe “Our monitoring shows it’s working fine, but we could use a few tune-ups to make it better

The flip-side to this is alert-overload, where monitoring is excessive and sending so much information to the IT staff that they soon ignore it.

Anyone familiar with monitoring, regardless of product, will agree that it’s somewhat of an art to find the ideal balance of alerts and reports. Just enough to feel confident in what’s happening, but not too much to keep up with. However, if I had to err on one side or the other: too much, or none, I’ll go with too much any day. At least that can be tuned. Having no monitoring solution in place is just flying blind and asking for trouble.

This doesn’t mean you need to buy an expensive monitoring solution, but many of them are certainly worth the cost if you need the features they provide. You can get by using built-in tools like Event Forwarding, PowerShell scripting, and the old Task Scheduler. The three of those, along with a few cans of Red Bull, some sugary snacks, and a few cups of double espresso, and you can build amazing things.

But many shops still have absolutely nothing in place to alert them when something fails. This is very risky and easy to avoid.

2 – Poorly Maintained Network Infrastructure (and DNS, DHCP)

We’ve all heard the jokes about “it’s never DNS” and how often we find out it was DNS. But I still see problems due to neglect. The most common issue I see is a perception that DNS just takes care of itself. A Ron Popeilset it and forget it” service that needs no TLC. This is a bad perception. That’s like saying your car changes its own oil (you Tesla owners just be quiet and go along with me here, mmkay?)

Some typical things that shine a light on lack of oversight:

  • New subnets created without being communicated
  • Changes to VLAN’s and DHCP scopes without being communicated
  • Firewall changes without being communicated
  • Firmware updates affecting routing
  • Subnets without a DHCP server (and no routing)
  • PXE across multiple subnets without IP helpers
  • Not reviewing DHCP scope settings after shifting device usage from static to roaming (older environments)

1 – Lack of Concern About Security

“Nobody would bother hacking us”. To me that sounds like “This ship could never sink!” While many shops go crazy with anti-malware products, there are also those who just don’t use anything. It sounds crazy, and some consultants I know refuse to believe these unicorns really exist. They do.

Besides the endpoint protection aspects, cyber-security as a whole is a big topic, and more than I can cover even if it were the entire blog post subject. But…. the emphasis on security has to start from the very top. The numero uno golf-player in your organization has to be the one pushing it, or it doesn’t work. There are exceptions where the grass-root side works, but it’s not the norm. Because it takes a concerted effort from IT, users, partners, customers, and suppliers to make a dent.

The news is full of stories where shit imploded in full public view because someone missed something and now it’s too late. You’d think with so many still showing up in headlines, that by now there’d be almost no one left who isn’t working furiously to close the loopholes. You’d be wrong.

Part of the issue (in my humble opinion), in the US at least, is the lack of consequences those companies face when they suffer a major breach. Especially when the breach impacts customers. CIO’s are rarely held accountable in a meaningful way (e.g. getting a $500k severance package isn’t a real punishment for failing the company)

Did someone say Bounty Program?

If you’re not familiar with the term “bounty program”, you may at least be familiar with something that tech companies like Microsoft and Google do where they pay $$$ to hackers who find and report vulnerabilities (privately of course) with respect to their products.

Companies (organizations in general) can also adopt a similar approach by offering employees a reward (bonus pay, added vacation, etc.) for reporting vulnerabilities in your IT services and tools. If you do consider this approach, be sure to meticulously document the rules and consult your legal counsel, and HR department.

I have had conversations with customers who have used this approach with success, and it can be very helpful if planned and managed properly. Also, don’t limit the participation to only IT staff. Encourage any employee to participate.

It’s 2020. Make your checklist and get busy!

business, Projects, Technology

Basic Automation Tips

There are many great articles on how to automate things in the IT world. User accounts, devices, software installations, configuration settings, security controls, monitoring, logs, and more. But it seems that when it comes to when you should automate, there’s not quite as much noise being made.

Low-Hanging Fruit

Start with the smallest, but highly-repetitious tasks. Two that I see most often are clearing old log files, and copying files or folders from one place to another. If you’re doing this (or should be) on a recurring schedule, start with that. Knocking out the little stuff is the best approach for two (2) reasons:

  • Quick turn-around. Because they’re less-complicated, they’re often easier to automate.
  • Rapid time savings. Because they’re quicker to automate, you can knock out more of them in less time, getting back more free time to invest in automating the more complex tasks.

A third benefit is momentum. Once you get on a roll automating the less-complicated tasks, it will propel you on to automating more things.

Tracking and Accounting

After you’ve knocked out a few of the most basic/simple tasks, you should pause for a moment to assess what else “could be” automated, and compile a list. For each item on the list, make some notes:

  • Value to You
  • Value to the Organization
  • Time and Cost Savings
  • Expense
  • Complexity

Value to You refers to how important is it to making YOUR job easier or less of a pain. Consider how often you need to redo things due to mistakes. Automating the task will often reduce or eliminate common mistakes.

Value to the Organization refers to how import is this to your employer. Would automating it provide any benefit to them? If so, list those benefits. Consider time savings as one of the benefits (e.g. not waiting on you to manually complete the task)

Time and Cost Savings are THE MOST IMPORTANT note to consider. Even if your employer doesn’t harp on you about spending money to save money, calculate the savings. Consider ((labor rate x time) + (cost of deferred tasks)), where “deferred tasks” are those which have to wait while you complete the first task. Calculate how much time will be recouped by having the task(s) automated.

Expense refers to any costs required to implement the automation. If you need to buy any products or subscriptions, note the cost. You’d be surprised how many tasks require zero expense to implement. It’s usually about time.

Complexity refers to a subjective rating of how difficult the task will be to automate. Don’t think of how difficult learning a scripting language will be. This is only about the task itself. Are there a lot of steps? A lot of if/else conditions to check for? Does it require an inconsistent schedule, or manual approvals along the way?

The following example is from one of my customers. Converting nerd-speak into MBA-speak won the management team over quickly, and his request to devote the time and expense were approved.

To help explain some of these columns: TS/M = time-savings per month, TS/Y = per year. CS/M = cost savings per month, CS/Y = per year. TS/A = time spent to automate (one-time), EX/A = expense incurred by one-time automation. My Value, Org Value, and Complexity are on a scale of 1 to 5. Rate/Hr = labor rate per hour for the person performing the task (only him at the moment).

Garbage In, Garbage Out – Part 1 : Trimming the Fat

An old friend of mine used to say “If you automate a broken process, you can only get an automated broken process“. It’s true. Automation won’t fix a bad process. It’s just a transcription from human to machine. A bad recipe will only produce a bad meal.

Before you start automating anything, break it down into each step to determine which steps are really necessary. Aim to combine steps, split steps, and most importantly: remove steps. Whatever it takes to make the process “correct”. Don’t worry about “easy”, since you’re (hopefully) not building it yet. Get the plan nailed down first, then worry about the execution.

An example I recall was when a customer was following the same routine every month to add computers to an AD security group, which was then updated during discovery by Configuration Manager to add them to a device collection.

As it turned out, the computer names alone were the only unique criteria (workstations with prefix “ACT”). So the AD security group management step was a complete waste of time. The collection query rule simply needed to be updated to filter on the names. A step was eliminated and the process is now more efficient.

However, the most-common task I see that can be eliminated from most environments is device naming (refer to my earlier blog post on this topic). In 99% of cases I’ve seen, the naming process existed simply out of comfort and habit, but provided absolutely no tangible (measurable) value or cost savings to anyone.

The placement of devices in AD OU’s is a close 2nd place in this regard. Unless you need to isolate the devices for GPO targeting or some process that requires the OU location, it’s often unnecessary.

Data Ownership and Liability

If your automation process involves human input at ANY point in the sequence, make sure you place STRONG controls over data input. If you can eliminate human input, do it!

Always use the “authoritative source” for all of your data inputs. If you need employee information, import it directly from the HR system, don’t let someone re-enter it. If another department owns the data you need, have them feed it directly to your process. Don’t forget: It’s not your data. You’re just making use of it.

No matter who provides the data you will use, you still need to validate it. They might let sloppy work get past their QA step, but it might blow up on you later on. If you expect certain types of values, verify them in your code.


Everyone hates that word, synergy. Sales people ruined it years ago. But, it’s an important piece in any project trying to implement automation. Look for ways to show benefits to other groups/departments, not just your own.

You’d be amazed at how much good can happen by getting enthusiastic support from other groups in your organization. They will bring ideas you never expected, and many of them will crossover into processes you use. And, most importantly, the bigger the impact to the organization, the more support you’ll gain from upper management.

Happy Friday! 🙂

business, Devices, Technology

The Great Big Tiny Book of Computer Naming Conventions

UPDATED 2019/10/03 – Fixed boneheaded pasting of wrong code snippet for chassis type lookup.

It’s now October 2019, and I’m just back inside my office, after enjoying almost 30 incredible minutes of a relaxing backyard bonfire, until my neighbors called the fire department on me. Bastards. I didn’t even use gasoline this time. I need a 40-acre ranch, or an RPG launcher. I’m pretty sure that previous sentence is why I’m not allowed to win any big lottery jackpots.

Anyhow, I was thinking of how many variations I’ve encountered from customers who insist on naming computers “their way”. Someday, I might actually bust out my Sinatra impression (which sucks) of “My Way”. This is focused primarily on workstations, rather than servers, which often use entirely different drug-induced conventions.

DISCLAIMER: This is in no way whatsoever an endorsement for any particular naming convention, nor any naming convention at all. Do whatever you want with your devices. I prefer gasoline and a torch. This is just an observation of some of the many ways to name computer devices that I’ve run across (and had to deal with).

Key Terms

  • AT = Asset Tag or Serial Number
  • FC = Form factor code (desktop, laptop, tablet, etc.)
  • LC = Location Code
  • UN = User name, UserID
  • AN = Abbreviated User Name
  • DC = Organization Group Code
  • OS = Operating System indicator (e.g. “W10”)
  • VC = Vendor Code
  • RC = (functional) Role Code
  • HV = Hardware Value


Most variations come down to the order by which the chosen key-values are combined, with or without a delimiter (usually a hyphen)

  • [VALUE] + “-” + [VALUE] example: “ATL-123456”
  • [VALUE] + [VALUE] example “D123456”
  • [VALUE] + “-” + [VALUE] + [VALUE] example “NYC-L123456”

Asset Tag and Serial Number (SN)

This is most often queried from the WMI stack using PowerShell or some other script or utility. The most common classes under root/cimv2 are Win32_BIOS and Win32_SystemEnclosure. I have also worked with customers who enforce their own proprietary “asset tag” numbering system, which is generated from some sort of asset inventory system (database output), along with a bar code sticker.

function Get-SerialNumber {
  param ([int] $MaxSerialLen = 15)
  $sn = (Get-CimInstance -Namespace root/cimv2 -Class Win32_SystemEnclosure).SerialNumber
  if ([string]::IsNullOrEmpty($sn) -or $sn -eq 'None') {
    $Script:WarnFlag = $True
    $sn = ""
  Write-Verbose "*** raw serial number is $sn"
  if ($sn.Length -gt $MaxSerialLen) {
    $sn = $sn.Substring(0,$MaxSerialLen)
  Write-Output $sn

Form Factor Code (FC)

This is usually an abbreviation of the form factor general type. Most often these are “L” or “LT” for “laptop”, “D” or “DT” for “desktop” (or “W” or “WS” for “workstation”), and so on. Other variations I’ve seen include “LAP”, “LTP”, “WKST” and whatever else a tube of model glue will conjure up.

Form factor can be derived from various means, depending upon the scale and variety of devices in the environment. For some, it’s easiest to use distinct model names as indicators, such as Dell Latitude vs OptiPlex, or HP ProBook vs ProDesk.

In other cases, it requires querying the ChassisTypes value from WMI class Win32_SystemEnclosure, and dealing with potential array values (docks, dongles, port replicators, etc.). For a list of chassis type values, go here. One example for deriving the form type using PowerShell:

function Get-FormFactorCode {
  param ()
  try {
    $mn = (Get-CimInstance -Namespace root/cimv2 -Class Win32_ComputerSystem).Model
    $ct = ((Get-CimInstance -Namespace root/cimv2 -Class Win32_SystemEnclosure).ChassisTypes)
    # ignore docks/port replicators which often 
    # return an array rather than one value
    if ($mn -match 'Virtual') { $ff = 'V' }
    else {
      if ($ct.Count -gt 1) { 
        $ct = $ct[0]
        Write-Verbose "*** multiple values returned"
      Write-Verbose "*** wmi chassis type = $ct"
      switch ($ct) {
        {($_ -in (3,4,5,6,7,13,15,24,35))} { $ff = 'D' }
        {($_ -in (8,9,10,12,14,18,21))} { $ff = 'L' }
        {($_ -in (17,19,20,22,23,25,26,27,28,29))} { $ff = 'S' }
        {($_ -in (30,31,32))} { $ff = 'T' }
        {($_ -in (11))} { $ff = 'M' }
        {($_ -in (1,2,33))} { $ff = 'O' }
        {($_ -in (34))} { $ff = 'E' }
    Write-Output $ff
  catch {}
} # end of function

Location Code (LC)

This is usually some form of identifier for the physical (geographic) location of the device. This is also predicated (typically) on a stationary device, such as a desktop or server. However, it can also be generalized to things such as city, state, region, or building. Other instances I’ve seen floor number (or name), room number, and row/column indicator for large, tabular-arranged, computers.

  • Country
  • City, County
  • State, Region, Territory
  • Subdivision or Office Park
  • Building
  • Floor Number
  • Room Number
  • Ship, Submarine
  • Aircraft
  • Assembly Line
  • Mile Marker

Organization Group Code (DC)

Also called “Department Code” or “Division Code”. This is usually one of two forms: abbreviation, numeric code. Examples include “ENG” for “Engineering”, and “0132” for “Marketing” or “Project X”, etc.

Another variation I’ve seen is concatenated Department + Division, which can be either, or both (hybrid), such as “AC04” for “Account Department, Division 4”. Other examples include Project Code, Budget Code, and Contract Number.

Username or UserID (UN)

Some organizations prefer to name devices in reference to the assigned user. This is typically the Active Directory “SamAccountName” value. However, in some environments this may be the employee number value.

Abbreviated User Name (AN)

This is usually similar to Username/UserID formats, but may use first initial + last name or some substring portion thereof. For example, user John Smith may be assigned device “JSMITH”.

Operating System

Some organizations include some sort of code to indicate the operating system of the device. The reasons vary, but the most common examples I’ve seen include “W7″, ‘W10”, “LX” (Linux), “MAC” (Apple MacOS), and “UB” (Ubuntu)

Vendor Code (VC)

This is usually some indicator of the hardware manufacturer, such as Acer, Apple, Dell, HP, Lenovo, Microsoft or Samsung. In some environments that use custom-built devices, it may indicate the manufacturer as well.

Role Code (RC)

This one is most-often related to how the device is used. For example “K” for kiosk, “CR” for conference room, “TK” for ticketing, “X” for x-ray viewing, “HV” for HVAC controller, “EC” for elevator control, “LAB” for, well, a lab, and “CAM” for security camera recording.

Hardware Value (HV)

Hardware values (that I’ve seen) are usually derived from something relatively consistent and reliable for uniquely identifying a device. The most common example I’ve seen is MAC address, or UUID. Some organizations leverage this from the packaging label on new shipments, which can be scanned easily to feed into other systems, which in-turn can assist with imaging and naming automation.

Using a MAC address, for example, the name will often remove the colon (“:”) delimiter to shorten the result, and avoid other problems during renaming. For example, with PowerShell using the WMI class Win32_NetworkAdapterConfiguration:

$name = $((Get-WmiObject Win32_NetworkAdapterConfiguration | ? {$_.IPEnabled -eq $True})[0].MACAddress -replace ':', '')

Oh yeah, Servers

I mentioned workstations and servers near the beginning of this mind-dump. Servers are weird. Server admins are weirder, and I should know, because I met one once. Servers typically get named by their function and/or location. This age-old practice is smoking even more Drano with the introduction of (dum-dee-dum-dum-dummm!) the Cloud.

As if it wasn’t bad enough when the names got stupidtarded when virtualization fell on their heads. Admins just barely crawled out of the pile of bodies from that keg party when the cloud came long and hit them in the face with a pipe wrench.

I’ve seen some really cool naming conventions, like comic book characters, movie characters, and some really stupid conventions like comic book characters and movie characters. Others include names of ships and rockets, Greek mythology characters, Roman leaders, US presidents, city names, state names, country names, and names of sports teams.

One of my favorites was a place that intentionally named servers to be confusing AF. Like mixing O’s and 0’s and 1’s and l’s, etc. Something like “O0O1l1ll11OZ2ZZ2Z”. I’m sure that guy wore Kevlar to work every day.

I suppose that if you can’t afford beer, drugs, or a big gun, it could provide badly-needed entertainment.


These are just some of those I’ve seen until now. I won’t be surprised if I run into yet another spin on this.

I’ve heard just about every argument, thought, theory, postulate, axiom and pontification on the subject of naming conventions for computer devices. Ultimately, I prefer using the least complicated option for a given situation, and hopefully one that provides some real benefit (operational efficiency or cost reduction, etc.).

I still get the urge to talk customers out of doing things just because “that’s how we’ve always done it”, and when they’re receptive, it’s nice. When they’re not, I move on to the next task.

I can see how it’s an easy trap to fall into. On the surface it seems intuitively helpful to apply a controlled naming process, but it’s often very challenging to produce any real value from it (cost savings, or revenue increase). Still, it seems like a porch light and a moth.

What are some other conventions you’ve dealt with? What (tangible) benefits did it provide to your organization?

business, humor, Projects

How to Use Your Consultants

If you work for a company, or maybe you own a company, or maybe you just know of a company, and you hire or work with consultants for various things, there are some common things to pay attention to which are often overlooked. Let’s get started!

Let’s say that your boss asks you, “Hey, Jim. Don’t we have some vouchers sitting around?

You answer, “We sure do, Bob, and my name is Dave.

That’s great, Jim! Maybe we can use those to get a fancy consultant in here to whip us into shape!

Yes ma’am, I’ll get right on it!

You dig around and find the vouchers, and then call your trusty vendor representative, who was already eagerly awaiting your phone call. He/she tells you about their “partner program”.

You swallow hard, and ask, “Tell me about this ‘partner’ thing?

It’s a fantastic program we offer to only our highest-valued premium super-awesome platinum-level customers, just like you! It’s a program with partners.

That sounds awesome! How do we use it?!

It’s easy Dan.”

It’s Dave.”

Right, sorry about that, Doug. Anyhow, it’s where we offer you a list of partner consulting firms, and you choose one to help you solve a technical challenge, or adopt a new challenge, right from the comfort of your conference room.”

You slam the phone down, jump around and squeal like a baby pig, then calm down and make some calls. You ask all your drunk high school buddies for recommendations, and they all agree that they don’t know what a consultant is. So you pick one from the vendor list, and arrange a conference call to discuss your ideas.

Soon after, you’re on your way to pursuing a new project. Now it’s time to plan how to misuse their services to greatest benefit of someone else, not you. Here’s how you do it…

Don’t have a clear list of objectives

That’s right. Clear objectives are for the movies. Real people don’t have them.

Figure out what the consultant should do when he/she arrives. They don’t mind waiting around for vague direction. And whatever issues you’re facing each day, you can leverage the consultant to help with those, while they’re waiting for the actual project to begin. You hired them to help onboard O365 and Intune accounts, but why not ask them to help with your printer issues? It’s your money, so burn it up however you want.

Also, all that mumbo-jumbo the vendor mentioned about “valid uses” for using your vouchers is just talk. They don’t care if you want to use them for completely unrelated products and services. Microsoft vouchers? No problem, they’ll be fine for working on that VMware problem.**

Don’t assign one person to each role

Leave every decision to a committee. It works great. After all: If one person can make a great decision, then 8 people can make an even greater decision! It’s like traffic: Just add more lanes and the traffic jams go away.

When the consultant asks for a user account to be created in Active Directory, it should involve as many people as possible. One for each object attribute if possible. And when it comes to PXE, oh boy, that should involve at least one person from every protocol-related aspect of your business.

For example, to create the guest account for the consultant, you might need the following:

  • Someone from the Networking team (because PXE needs a network)
  • A Facilities person or two (because networks have wires and stuff, and they use closets sometimes)
  • Someone for DNS (since your imaging process will probably need name resolution somewhere)
  • Someone else for DHCP (of course)
  • An Active Directory team:
    • Someone to focus on the naming convention
    • Someone to focus on group memberships
    • Someone to focus on the initial password
    • Someone to create the account incorrectly the first time
    • Someone to fix the incorrect account, but also remove it from requested groups
    • Someone to add the fixed account back to the missing groups
  • Someone from IT Security (because they have to be at every meeting anyway, so why not?)
  • Someone from HR to make sure the consultant isn’t offensive or insensitive.
  • A Telecom person (make sure the conference room is working for the remote folks)
  • Someone from Accounting (because something will cost something),
  • At least one Project Manager for each group above (got to keep those toddlers in line, after all)
  • And, someone from the cafeteria (you’re going to need coffee during all those meetings).

After a dozen or so meetings, you should have a clearer picture of how many weeks it will take to get the first account created, and a few more weeks to get the correct permissions assigned to it. If you start now, you might get 3 accounts created before the next fiscal budget runs out.

As a general rule: A meeting isn’t considered appropriately-staffed unless there are at least 12 people in the room. So, to be safe – double that.

Don’t be in a hurry

You’re important. You have a lot going on. Printers jamming. Passwords expiring. Facebook is slow. Jimmy spilled another beer into his keyboard. And the cleaning crew unplugged your router again. When that pesky consultant asks for some information, make sure to take your sweet time getting them an answer. Giving them a quick answer only cheapens your value in their eyes. Taking your time earns their respect.

A typical best practice rule is at least 24 hours per question. If they ask three (3) questions, that should take at least 72 hours. And if you only work 1 shift per day, that should be 72 business hours, or roughly 31 days.

And if the consultant reminds you about some so-called “expiration date” on those vouchers, be sure to remind them how important your business is. The vendor will obviously jump through every hoop to extend your deadline, because you’re waaaaay more important than any of their other customers. As if they have any other customers. Ha ha ha!

Be Flexible

One of the worst things you can do when bringing a consultant onto a project is lock things down too much. It’s important to keep your options open. Even something like picking one system or product to focus on can be risky.

Remember: Contracts are just rules. And rules are made to be broken.

For example, let’s say you signed a contract to get a consultant to help you with migrating to Office 365 and Exchange Online. There’s nothing stopping you from shifting direction at the first meeting. Some good examples might be:

  • “We can’t get these 5-year old laptops to image with Windows 10 using our old Ghost setup and DVD disks”
  • “Skype keeps crashing on the CFO’s computer, at his condo.”
  • “The CEO’s 6 year old daughter says she knows more about Office 365 than you.”

Just remember to stay flexible and adapt to whatever you feel is important each day. After all, you don’t know how many more you’ll get.


I hope you found this article informative and educational. Doing your part to keep consultants on their toes is the best way to insure you get the most out of the shares you own in their company.

** Disclaimer: Nothing said above makes any sense whatsoever and should be completely ignored.

business, Personal, Society, Technology

Working from Home: The Good. The Bad. The Weird.

This post is not intended to be funny, so if you’re looking for a better joke, watch C/SPAN.  Wait, that was technically a joke.  Oh well.

So, a little (snooze-fest) background to get you in the mood.  Some wine, some Barry White music, dim lights, and…

I’ve now been working remote for an employer since Spring of 2015.  I didn’t seek this, because I always thought of it as a unicorn job.  But I soon discovered how many others have been doing it (in IT) for a long time and how the practice is increasing in popularity.  This is particularly true for consulting more than full-time employment (FTE) or contracting.  Consulting for an employer on full W-2, etc. is more common than independent, but I see quite a few of those as well (mostly online, that is).

Since then, I’ve had many discussions with others who work from home and it seemed odd how little information exists on “best practices” and warning signals.  There are some books, some blogs, some whitepapers out there, but most appear to be focused on a specific area within the topic, rather than taking a holistic view.  I try to avoid using “holistic” because I’ve heard it used to death, but I couldn’t stop myself.

The Good

The advantages for the consultant are pretty obvious, but not always what you expect. I won’t bother with the advantages for employers, because they should already know that, or they’re on the wrong path.

Flexibility is high on the list. When you wake up, when you take lunch, etc. Dress code is optional (more on this later), and feeling more connected to your “home” are often benefits. For example, spending more time with your kids, pets, spouse (in that order, ha ha), etc.

Flexibility also allows you to step away from some conference calls to use the restroom, get coffee, snacks, fetch the mail, etc. as long as you have a wireless headset and a mute button. I can take care of dishes, laundry, feeding the pets, watering plants, all while discussing why Configuration Manager isn’t going to automatically wipe and re-image every machine in the company from the evil PXE-beast.

Another advantage is it’s easier to multi-task (which can also be a disadvantage). For example, while one conference call is droning on about something you’re not involved with, you can work on other tasks, chat with customers, engineers, etc. As for conference calls, it’s often easier to “back-channel” on separate chat sessions, with others on the same call, than when everyone is physically in a room together.

Yet another advantage with online conferencing is the ease of sharing links, documents, etc. via the chat application (Skype, WebEx, etc.) while the meeting is still going.

The Bad

Some of these will vary by your personality, home environment, and other personal factors.

Solitude. It’s not for everyone. If you don’t like working in isolation (like many programmers prefer), and rather have people around you, then working from home may not be ideal. If you suffer from mild to severe depression, even seasonal, it can be tough, but not impossible, to accommodate.

Background distractions/disruptions. Noisy pets. Leaf blowers outside. Fans. All of these can make you a master of the mute button, but if that gets too frequent, customers (and your boss) may become concerned about your ability to focus.

What to do?

None of the following recommendations imply 24/7 focus. It’s okay if you slip off the wagon once in a while. The important thing is to keep them in front of you and try to do them whenever possible. Make a checklist if you want, whatever works. This is aside from the technical side of things, like getting a wireless Bluetooth headset.

  1. Get outside!!! Walk, run, or even sit in a chair. But get outside at least twice a day. Even if the weather sucks. It’s important to mentally feel connected to the outside world. Sunshine, even indirect/cloudy, stimulates chemical balances in your mind and body (proven, go look it up, if you don’t believe me).
  2. Get away from your desk/chair at least once an hour. Walk to another room (or outside, even better). Just move.
  3. Watch your diet. Avoid sugary snacks or putting too much sweetener in your drinks (or drinking canned/bottled sweetened drinks). Being sedentary and consuming unhealthy foods/drinks is one of the fastest ways to lose control of your health. If you think it’s easy to slip on this when working in an office, it’s twice as easy when working from home. Also, keep snacks AWAY from reach. Put all your food, coffee, drinks, etc. in another room, or across the room you’re in. Make yourself have to get up to get them.
  4. Exercise. If you’re so inclined, do some resistance workout activities, or calisthenics to keep the blood flowing and improve your health. Sitting at home is worse than sitting in an office because you don’t even walk from the office entrance to your desk and back. You can easily lose weight doing this, which is a win-win. Nothing fancy. Even arm circles, squats, and so on are better than clicking a mouse all day.
  5. Set Boundaries. Pick a time to “knock off” work and leave it behind. It’s really really reeeeeeeaaaally easy to keep working long after you should quit for the day. It’s bad for your mind, health, and can affect your sleep pattern, mood, appetite, and family time (or pet time).
  6. Have lunch with a friend, colleague, family member, etc., at least once a week if you can. Nothing fancy or expensive, just coffee or a light lunch will do. Conversation is one of the best vaccines against feeling down from isolation. It also keeps your conversation chops sharp for when you go to meet customers.
  7. Go to local meet-ups. This is VERY important for three reasons: It gets you into groups and interacting with others, it gets you away from your home office, and you learn new things. Just watch out for junk food if they provide it.
  8. Change the Scenery. Work from a different location sometimes. A coffee shop, library, park, shopping mall, etc. Whatever fits your ability to focus on what you do for work. Some people prefer busy places, some prefer quiet places. But getting out of the house is important.
  9. Personal Stuff. Shower, shave, groom, like you’re going to the office. Every day.
  10. Dress up. Yes. One of the most common changes people incur when working from home is working in pajamas, sweats, even underwear. It’s easy and comfortable. It can also gradually affect how you feel and how you conduct yourself in conference calls. You don’t need to put on a suit, although that’s fine if you like. Just jeans and a button down shirt or polo, with socks and shoes. And a belt. Believe it or not, aside from getting away from my desk, this is the most challenging one for me.
  11. Avoid cages. If you listen to music or podcasts, news, or TV shows while working, change up your selection. Avoid patterns that subconsciously make your brain feel like you’re standing still.

Anyhow, I hope this is helpful.

business, databases, Devices, Scripting, System Center, Technology

Asset Inventory, It’s not just for breakfast anymore

For those of you that read my blog this will probably sound familiar.  But for those not yet dunked in the stupid tank of my pontification gyrations, I hope you find this post useful in some way.  Maybe print it out and use it for a toilet bombing target.

Last night I was grilling some sort of roadkill and having a beer and my thumbs went out of control on Twitter.  It was a spur of the moment reflection on how this topic seems to repeat over and over.  For some reason, I assume “asset inventory” is important enough for most organizations to make it a priority.  But, more often than not, it seems not to be the case.

Why Asset Inventory Sucks

I explained why it sucks back in 2014 on my old blog, here.  It still sucks, because humans suck at keeping track of things.  However, recently I received a few requests to digress into this a bit more on the recommendation side, which is what this post is aimed at doing.  The biggest and most important piece is process. In fact, more than one process, but at least start there.

I must emphasize here the following:

There is no such thing as “perfect asset inventory”.  Whether you’re Wal-Mart or the US Department of Defense, shit gets lost.  And somewhere, somehow, that piece of shit has a record sitting in some shitty place that still says that shit is real shit and it exists somewhere.  But, if you try to put your hands on that shit, you find you’re shit out of luck.  But the goal should always be to get as close to “perfect” as you can, without inflicting harm on your business, your employees, or your customers.

Side Note: If you get bored, Google “US military missing inventory” and pull up a chair.  You’ll be reading for awhile.

Nuts and Bolts

When you look at how a device can be tracked throughout its lifetime, it’s actually not that different from how humans are tracked.

For either column, each row relates to a distinct system which maintains relevant information for that category.  And for either humans or devices, it’s not uncommon that each of those systems belongs to a different department, and they end up building silos of information.  It’s also not uncommon that each silo maintains redundant, and often inconsistent, information about the same asset/person.  Many of these systems have been developed independently for years before anyone thought to link them for various business needs.

For humans, there’s the hospital, the IRS, SSA, DMV, DHS, DOD, state and municipal government, as well as insurance companies, banks, web sites, schools, clubs, retailers, and so on.  Few of these entities routinely share the same information about the same people, and even then, still maintain their own data.  In this respect, devices aren’t that different from humans.

For devices, there’s a Purchase Order, Active Directory and Azure AD, EMS, Configuration Manager, SQL Server (behind multiple systems), HelpDesk systems, Logging systems, and disposal records.  In between, there are tons of home-grown apps/systems as well.

Finding the Wounds

The first thing to do is identify each tool (system, service, etc.) you already have, and identify what it tracks.  Document or diagram what each system tracks (types of information, attributes, etc.) and what pieces of information they have in common.  Common examples include Asset Tags, BIOS serial numbers, as well as manufacturer, model, etc.  For software-based systems, it may also be a GUID, SID or an LDAP cn, etc.

If you’re not primarily a DBA, kidnap one (they can be bribed with food, caffeine and Amazon gift cards).  Design a solution to extract ONLY the information you need to confirm the existence of an asset in each system.  In this design, determine what you need to compare across each system to insure consistency and find missing pieces (gaps).

Note: Be careful with data extraction (or queries) that you don’t over-burden the systems themselves.  This is particularly true for things like Configuration Manager, which are sensitive to SQL performance.

Get some reports to show assets which are not found in all systems, then use that to determine how the information is missing.  This often points to a process that needs to be updated.

For example, you determine that Jimmy, in the Purchasing Department, doesn’t capture some key pieces of information when a shipment arrives.  So you decorate Jimmy’s car with shaving cream and cat litter during lunch time, with a note warning him to pick up the slack.  And Debbie, ignores the weekly email report of machines which haven’t logged into AD in more than 180 days.  So, you sign Debbie up for every porn site mailing list using her personal email address, and cover her desk with cat litter, and Post-It notes with reminders to fill that information in soon.

WARNING: These are simply ridiculous suggestions made by random imaginary homeless people.  The author of this blog does not condone shaving cream, porn sites or Post-It notes.  In fact, the author doesn’t condone this blog.  Any similarity to real persons is unintentional. Batteries not included.  Void where prohibited.


Some of these may look familiar, as they are EXTREMELY common in most organizations.

  • Computer accounts left in Active Directory, long after a device has been disposed
  • Computer objects missing in ConfigMgr due to restrictive Discovery settings, limited user account, etc.
  • Asset management systems that rely on human data entry to identify assets
  • Lack of documented procedures for new hires to follow, especially in IT
  • Allowing people to “borrow” devices back from the disposal pile after they’ve been retired
  • Failing to update records when assigning an existing device to a different user
  • Relying on device names or descriptions in AD to identify user assignments

Control the Bleeding

  • Use scripting to manage orphaned AD computer accounts.
    • Search by LDAP attributes like PwdLastSet, Last-Logon, etc. (read the “remarks” section of Last-Logon for a general heads-up on using this)  You can modify the GC replication flag for these attributes (be very careful) or make your script query all domain controllers and compare results.
    • Machines which haven’t touched the network in a long time (usually more than 30 days, but it depends on the nature of your business) can be disabled and moved to a special OU using PowerShell (or whatever)
    • If nobody whines after X days, delete the accounts.  If they show-up the next day angry, just rejoin them to the domain and apply liberal amounts of pepper spray to the user. (just kidding, don’t do that)
    • For any automation you concoct, be sure it includes logging and reporting/notification throughout.  And be sure to include some “what-if” support to test without accidentally deleting the CEO’s laptop.  Think PowerShell [CmdletBinding(SupportsShouldProcess=$True)] , and $WhatIfPreference for things that don’t natively support -WhatIf, etc.
  • If you find inconsistencies between your inventory-related systems, determine why.  Then look for ways to replace human input with some sort of automation (PowerShell, PowerShell, PowerShell, a few table spoons of SQL and more PowerShell)
  • Establish (or update) your policies and procedures.  Seek advice from other organizations, books, and blogs.  Ask questions on forums like Slack, Reddit, StackOverflow, etc. as well.  Take your time, but get it right.
  • Be careful to not reinvent any wheels.  Don’t replicate more information than you really need, as it adds risk of creating yet another pool of information that could become isolated later on.

Notice that I lean towards PowerShell and building things.  You may prefer to use a third-party (free or retail) product or service, which is fine.  I come from the era before vendors bought up all the land for corporate software farming.  We had to grow our own goodies from scratch.  That’s not a binary choice however.  You can mix the two, such as using things like Sysinternals, SQL Express, and so on, along with scripting.  You have options.  Options are good.

Connecting the Dots

One final thought, and this crosses a lot of different aspects of IT operations.  This has to do with management support.  So often, the IT folks bemoan not having enough resources, training, or budgeted time, to get out front of the problems and fix them before they continue to grow out of control.  The biggest challenge in this is communication.

Management reads, writes and speaks in terms of money.  Saved or spent, it’s all about money.  A business exists to make money, after all.  IT folks read, write and speak operational efficiency.  It often ends up being like a singles bar, and Stevie Wonder is trying to hit on Helen Keller, but the bartender is just watching the train-wreck while drying glasses with a towel.  Consultants are often the bartender in this scene.

If you want to sell your idea to get support, you need to translate what you want into dollars.  Your idea HAS to either save or earn more money than any other option available to them.  This commercial was cute in its day, but it’s actually more true than anyone expected.

  • For every procedural change you want to make, be sure to identify how much money it will save (or new revenue it earns)
  • Talk to your vendors/suppliers about cost implications (licensing, terms, etc.)
  • Double-check your numbers and have someone in Finance review as well
  • Try to avoid solutions that increase costs to acquire or operate, IF you can find or build an equally capable solution for free.  Remember, you want to save your company money (or find new revenue streams).  If it comes down to one retail solution vs. another, so be it
  • Make your proposal clear enough for your grandfather to understand, even if he’s been dead for years
  • Don’t get too immersed in your solution.  There may be a better one, and ego is the devil

Good luck!


business, humor, Technology

The IT Professional’s PlayBook


So, you’re growing tired of trying to convince clueless managers about approving your requests to improve IT operations.  Maybe you’ve been doing it like this…

You: “Good morning sir/ma’am.  If we spend some money on upgrading our WAN links, we can get ahead of our backlog of projects by moving all our deployment processes out of the slow lane.”

Them: “I don’t know who WAN links is, but it sounds like Chinese food.  Go away.”

Maybe you should try rehearsing these tried-and-tested proven methods:

You: “Good morning sir/ma’am.  I ran the numbers and found we could save money by upgrading our WAN links.  A one-time cost of $14k would eliminate our need for additional infrastructure, license upgrades, controlled spaces, and lower power and cooling costs at all our remote facilities.  That alone would reduce our infrastructure costs by $5,000 per year, and cut our deployment times from weeks to hours.  The cost could be a tax deduction and we’d recoup that in less than three years.  And, are you losing weight?”

Them: “Yes, I’ve been working on my chip shot all weekend and I think it’s getting me in shape again.  I like you Bob….”

You: “It’s Ben.  Sir.”

Them: “Right, Bill, anyhow, it sounds like you think this WAN links guy is really that good?  Ok. I’ll approve him, if you think he can help with our taxes.”

Another example…

You: “Good morning sir/ma’am. I ran the numbers and it turns out we’re spending 150 hours per week installing apps by hand.  That’s 5 technicians over 150 hours at $7.50 per hour, oops, I mean $5.50 per hour.  That comes to $8,250 per week, and a backlog on other support requests in the queue.  We could spend a quarter of that packaging or wrapping the installers and procuring a product to help deploy them remotely.”

Them: “I like that idea.  We can then cut 3 of those technician’s jobs and reduce our burden rate at the same time!  Great work Bill!  You can call me Mike.”

You: “Actually, uh, no disrespect, but I don’t think we should cut…”

Them: “Consider it done Bobby!” (strong pat on the back)

And another…

You: “Good morning Ma’am.  I would like to request approval to replace Acronis and Ghost and all our other imaging tools with Microsoft Deployment Toolkit.  It’s free.  It’s very customizable.  It would allow us to reduce our image library from 43 individual images to 1 with a task sequence.  And it’s been around for years and battle tested.”

Them: “That sounds interesting.  But I spoke with Sam, who dates my daughter, and he says it’s better to maintain 43 image files every month because the extra care and feeding makes it an important job.  And he graduated from a 2 year tech school.  And he dates my daughter, so you know how that goes.  But really, Bobby, I appreciate your concern.”

You: “It’s Ben.  But thank you.”

And finally…

You: “Good morning Ma’am.  I heard about the big tax changes and how we’re going to save $20 million this year alone.  I was wondering if you had a few minutes to discuss some ideas I have about infrastructure improvements to help streamline our operations and save money?”

Them: “I’m glad you asked.  Yes, but it’s actually around $22 million.  And we already have plans to apply that towards automation, to reduce our dependency on human labor.  Oh, and what was your name again?”

Or, you could just consider a career in the legal or medical field.

business, Technology

The 5 Immutable Laws of IT Life

1 – The person you need most will be unavailable when you need them.
2 – The problem will stop as soon as you try to show it to someone else.
3 – The simplest task will end up taking the most time.
4 – The feature you need most will be the least documented.
5 – That which saves you time, will cost more money (and vice versa).