Pay Attention to the Person Behind the Curtain

After a tumultuous Presidential election here in the US – which I’m only beginning to be able to talk about without sweating – I wanted to offer a takeaway lesson that’s much broader than politics: Don’t watch the birdie.

Read More

Forums Spam is REALLY a Problem

Forums spam has really become a problem. For example, Google “OST Recovery” and look at all the crap posts that come up from everywhere. Over at, we’ve been dealing with exactly those jerks – and we’ve recently come across a great weapon.

Read More

Logic is Usually Not Persuasive

My friend Lee used to work for a company that did Sales training. Sales is, at its very essence, about persuading people to buy something. Even if they need that something, you have to persuade them to buy yours, rather than someone else’s. And one of the big maxims Lee’s company would teach is that logic is not persuasive. 

And it’s true. I have my own version of the phrase: “Don’t drag logic into a conversation where she’s not invited.”

Read More

Security Can’t Just be “No.”

There’s an enormous problem inside some organizations where, whether this is just perceived or actually true, the InfoSec team “maintains” security by “just saying no to everything.”

Obviously, no business can survive if one component of itself is simply shutting down all initiatives willy-nilly. “No” isn’t a security position; it’s a death knell. And, if you work for a company where this is really, really true, you should maybe evaluate your career choices. It doesn’t make sense for good IT people to work at that kind of organization, and if the answer is always “no” anyway, they don’t actually need you. InfoSec should say, “yes – but.” Meaning, they should be taking the time to understand why something is necessary to the business, understand how it works and what its vulnerabilities are, and understand how to safely and securely introduce it to the business.


Just as many IT Ops people are not experts in the InfoSec disciplines like auditing, forensics, pen testing, incident detection and response, and so on, many InfoSec people are not familiar with the intimate details of Ops technologies, what their business benefits might be, or how they work under the hood. This is why everyone needs to work as a team to make these decisions.

“Hey, we’d like to implement PowerShell Remoting. It uses WS-MAN.”


“It’s better!!!”


Totally understandable conversation, actually. It should have gone like this:


“It’s massively lower-weight in terms of server overhead, and unlike RDP it’ll trigger less mandatory restarting of servers – so we get better availability.”

“How’s it work?”

“It runs over a single port, and we should have a requirement that that port be HTTPS. Credentials are delegated across that connection – no clear-text passwords! – and I can show you how we’d enable full-text auditing of everything admins do via that channel. It’s actually a lot more auditable and locked-down than RDP.”

“OK, let’s look.”

If you present a valid business case, and then can work together to understand how the technology works, then you’re doing it right. “We need to understand the encryption used” isn’t a challenge you need to defend. The proper response is, “yeah, we do! I don’t know a ton about encryption – can we dig into this together?” Encourage that teamwork. Nobody should be on the defensive or offensive – you’re all supposed to be working for the same team. Too many times, though, the Ops folks I’ve seen go down this road – with anything, not just PowerShell Remoting – aren’t taking a team approach, and they’re not making a business case.

And let’s say you do start the conversation right, with a business-level justification (with some numbers, please – businesses understand numbers). You do go in as a team player. If you still get needlessly rebuffed without even a fair hearing, and without a reasonable justification (“yeah, not now – we’re busy recovering from the 10M user accounts that were compromised last week, k?”), then…

Evaluate your career choices. Ask yourself why you’re so broken inside that you’d work for a dysfunctional situation.

Why Don’t You See More “Advanced” IT Classes?

As a Curriculum Director at Pluralsight, I get more than a few comments form our learners that they’d like “more advanced” courses. We try to accommodate that as much as possible… but, if you’ve ever thought that same thing to yourself, there’s something you need to understand.

Entry-level classes are easy. They’re obviously a need, the things they need to cover are usually pretty well understood, they’re relatively straightforward to create, and so on. Almost anyone who is experienced in their field, and who’s good at breaking down what they do, can point to the fundamentals. From there, it’s easy to build intermediate-level content, too – meaning, content which assumes you already know the basics. In fact. training is usually pretty easy to design so long as you’re sticking to the 80% rule. That is, when you’re covering the material that 80% of the people use 80% of the time.

But move into “advanced” training, and things get squishy.

First, you deal with the problem of imposter syndrome. This is where most people, much of the time, feel that everyone around them must know a lot more than they do. They realize how much they do know, so they know they’re not beginner or intermediate; ergo, they must need “advanced” training. They don’t necessarily know what that is, just that they don’t know everything, and so “advanced” stuff must be next.

Second, teaching only works in a generic sense. That is, I can teach you something, but only insofar as what I’m teaching is broadly applicable to the everyone in the field. I can teach you advanced IP network design, but only to the point where you start saying, “yeah, but in my company…” at which point a class starts to turn into consulting. Fact is, if you’re at the point where you need a lot of specificity for your situation, you probably are already advanced, and what you really need is a consultant, not a class.

Third – and perhaps most importantly – is the bigger picture. It’s a picture a lot of people don’t like. Let’s be honest: the human brain learns best through experimentation and failure. Teaching is literally nothing more than a shortcut, where someone else tries to share their experiences, experiments, and failures, with you. Some people can’t even learn that way – they have to experiment and fail on their own. But so many adults are conditioned against failure that, for them, a class becomes the only way they’ll accept learning. These folks are, sadly, destined to remain at an intermediate level.

There comes a point where you’ve learned everything that can be taught to you. You’ve eaten everything that can be brought on a platter. Now, you have to go out and catch your own food. Or, in the training sense, you have to build your own knowledge. At a certain level of advancement, knowledge becomes so tied to application that the two are inseparable, which means you have to research, experiment, fail, and adapt, until you’ve figured out whatever it is you need for your specific situation. Sure, you could make a class on what you figured out, but it would very likely be useless to anyone who wasn’t in your precise situation.

This is why I’ve long been an advocate for an instructional design style called constructionism. It doesn’t work well with traditionally-taught adults, who’re conditioned to more on-a-platter styles of delivery, but it works great with kids. In this style, you don’t give kids a single fact. You give them the broad strokes of concepts, point them toward resources like documentation, and make them figure it out on their own. Kids are still willing to experiment, haven’t yet learned to fear transitional failures, and usually thrive at this kind of thing.

And people who’ve learned that way – who are, essentially, self-taught and assisted by a facilitator – are invariably better prepared to be lifelong learners. They’re not afraid to watch a quick course to pick up some concepts and shortcut the basics, and then strike out on their own to form their own learning constructs. These folks can switch careers more easily, pick up new skills, switch projects, and so on, because they have a skill set built on adaptability, not rote memorization. They don’t just learn, they understand. 

For everyone else, it becomes a matter of forcing yourself to take this approach. If you’re not a good researcher – well, that’s Job 1 in the IT biz. If you’re not a willing experimenter – well, that’s pretty much Job 2 in the IT biz. Sure, foundational concepts and core tasks can be picked up through education, but once you hit the “advanced” level – once all your learning needs are targeted to a specific, of-the-moment application – you need to construct your own learning models more and more.

[POLITICS] The White House and the Press

Much news was made recently with the current President banned several news outlets from a variety of press conferences. Indeed, the current President’s relationship with traditional media has been uneasy and tense. Many, upon hearing of the ban, proclaimed the beginning of the end of democracy as we know it. Truthfully, there’s a bit more to it, and perhaps less reason to panic.

Read More

Grammar Police: Premise


Also, premissLogic. a proposition supporting or helping to support a conclusion.
  1. a tract of land including its buildings.
  2. a building together with its grounds or other appurtenances.
  3. the property forming the subject of a conveyance or bequest.

See the difference? Something that’s on-premise is something which is aligned to the original proposition or logic. Something that’s on-premises is located on-site. if you insists, because I know how you kids are with the shortcuts these days, on-prem can be a shortened version of on-premises. 

But do not say “on-premise” to mean “on-site.” Correct other people who make this mistake. We will not lose this battle!

Wanna come (DevOps/DSC) Camping with me?

Public registration is now open for my 3rd annual “DevOps/DSC Camp” near and at my home in Las Vegas!

Camp isn’t a conference. No, it isn’t recorded or streamed. Don’t ask. Camp is a working group of experts who are dealing with DSC, and DevOps generally, in their daily lives. We teach each other how to do things like build CI pipelines, introduce DevOps into an organization, solve DSC challenges, and a lot more. It’s a tiny group – just 20 folks – and that’s what keeps it close-knit.

We begin on Thursday evening (July 27) with an evening cocktail hour, and we head off to some cool local restaurants for dinner. We get started in earnest on Friday morning with presentations and round-table discussions. Friday afternoon, we head to my house for customized personal pizzas for lunch, an afternoon in the pool, and a huge smoked BBQ dinner. All day, we’re talking shop – moving between small groups talking about getting stuff done. Truly, this is an event where everyone confirms that they’re going directly home and using what they’ve learned to effect change in their organizations. This’ll be the first year “open source PowerShell” is on the table – can’t wait for those discussions!

Saturday, we hunker down all day and learn. Most alumni will have an opportunity to present a topic, and we keep it very interactive. After swimming around all day Friday, your introverted shyness will be gone, so you’ll be ready to engage. Saturday evening we hit the town for some fun and food.

Sunday, we wrap up in the morning. In the past, Sunday afternoon has been headed up by DSC product team members from Microsoft; we can’t promise that’ll continue, but it’s a possibility. They buy lunch ;).

This is an intense and mentally engaging weekend. As I’ve mentioned, it’s a close-knit group – and we’re already close to half-full as I publish this article. If you’d like to jump in, don’t delay. I hope to see you.