While checking out a Windows PC that hadn’t been updated in recent times, I came upon this gem of a warning message:

That is all.

The Book

I just finished a book called “The Phoenix Project“ written by Gene Kim, Kevin Behr, and George Spafford. It is the first book published by IT Revolution Press. It seeks to instruct the reader in the rudiments and benefits of IT done “Devops Style”, or rather, IT done according to the tried and true methods of factory / plant management that have been explored for a few generations now. It does this through the telling of a fictional tale. Skeptics of the so-called DevOps movement, don’t be alarmed.

 

The TL;DR Review

The book is a fictional account of a director of IT at a large enterprise; an enterprise that has a deeply flawed IT organization that is dragging the company into destruction. He is quickly turned into acting VP of Operations after the sudden departure of the last VP. Bill has 90 days to turn the IT department around or face the dual threat of a total IT outsourcing and the failing company being split apart by an aggressive and impatient board of directors.

The storytelling is poor. The concepts themselves are great, however not explained to the depth that you would expect from a 300 page book. If you have a genuine interest in doing better as an IT person in general, pick the book up and see if it excites your interest in the various operational methods to getting things done for the business using IT. This is not a management book. This is not a developer book. This is not an operations, sysadmin, cloud, ITIL, infrastructure, or $buzzword book. This is about workflow management done from a factory background that can be applied to anyone’s work. If you’re skeptical of the so-called DevOps movement, don’t be afraid of this book.

I’d give it 3.5 out of five stars.

The Long Review

The story centers around Bill Palmer, a late-thirties ex-Marine (I know, I know – “no such thing as an ex-Marine!” – you know what I mean) with a wife and two kids. He starts the story as the Director of Midrange Technology Operations. Side note: I have no idea what “midrange technology operations” is, nor did I figure it out after some Googling.

He is quickly thrust into the position of VP of IT Operations to fill a sudden vacancy. He and his entire department is thrust under the intense scrutiny, skepticism and frustration of a hard nosed CEO, board of directors, and SVP of Retail Operations. It’s fix or fail time, and he’s got everyone working towards failure.

Before we go any further, let’s get the bad parts out of the way

The Bad

The storytelling is awful. The book is not intended to weave a masterful tale, so I’m not terribly disappointed. However, there came a point about halfway into the book that the writing became grating to read and was an obstacle to the subject matter.

There is virtually no character development, and what little development can be seen is either banal (Bill Palmers, toughened Marine, fighting back tears while telling about his bad father at a team building session) or bizarre (late devops adopter, security-guy-John, disappearing for weeks in a drunken haze without being fired, then suddenly reappears with a shaved head and GQ clothes and now he “gets it”). Neither dramatic occurrence helped move the story along very much if at all, and in fact the sudden addition of drama looked garish standing in such obvious contrast to the rest of the vanilla story.

Adding to the lack of character development, is that each character reads like every other character. There were many times in the book when a character would be delivering two or three consecutive paragraphs of dialog and halfway through I would lose all notion of who was speaking. Was it Wes? Patty? Bill? John?

Each character is gruff, cold, worn out, and mildly bitter. I wanted to punch Erik, the supposedly sage-like purveyor of factory Zen, sometime around the book’s halfway point. By the end of the book I wanted to lock him in his precious heat-treat oven. I was genuinley surprised at some of the raw language. I don’t flinch much at cursing (I didn’t notice any of it in Reservoir Dogs), and certainly in the real world some meetings can have blue streaks pour out from under the doors. That’s life. However, I found the sheer number of “goddamn”s and “shit”s distracting to the book, not an addition of realism. Maybe if the writing had been better, it would have fit. Instead, the book seemed like it was trying too hard to be one of the cool kids, and as a result there are a not insignificant amount of people who will find the language to be a distracting irritant to the core of the book. Some people will not finish it at all.

The story is also a bit sing-songy at times with some meteor sized tropes that crash and burn in the midst of the text. Examples include total chaos being turned around in double time, skeptics are silenced at just the right time, the tough guys show their tender sides, and there is a self-seeking back stabber who gets their comeuppance (sort of?). Oh, and there’s an irreverent hippy who sticks it to the man! Want more? How about someone who has a hidden special forces background. To complete the cycle, the book just needed a dragon slain by a cowboy who gets the girl and rides off into the sunset singing a love song.

I think the storyline was unrealisticly biased in favor of the concepts. I do not think it is possible to have turned around such a large company as Parts Unlimited that was as deeply flawed in its operations, company structure, workflows, and personalities in the just over four months. I do not think it is realistic at all to have so many changed hearts and minds in so short a time. From years of bitterness, frustration and institutionalized failure to suddenly, in four months, most people “get it” well enough to be embracing, adopting, and successfully practising such drastic changes. Is it possible? Yes. Possible in that amount of time? No.

Keep in mind that the characters and storyline are mere vehicles to transport much larger concepts to the reader. It’s an overgrown parable that has been fattened too much to comfortably carry its heavy topics on such a brittle skeleton. You will gain the most if you can discard the storytelling and focus on the concepts.

The Okay

Fortunately the parts of the book that could truly be called “bad” aren’t directly tied to what the book is actually about. The book is about how to get IT, from infrastructure to development, from management to security, to work closely together with eachother and the other business units while using workflow management methods that have been vetted on factory floors for generations.

What’s merely “okay” is that the book doesn’t do complete justice to the core concepts that it intends to teach. Seemingly every chapter introduces a new manufacturing term, plant management buzz phrase, or factory concept. From “takt time vs cycle time” to the difference between bill of goods and, I believe, “bill of resources.” Oh, and during one dialog, the book refers to ”single-minute exchange of die” as a legendary concept. Okay – I’ll take their word for it. However, these concepts and terms are thrown at the reader in clusters that can be overwhelming. They are explained well enough to get you through that portion of dialog and whet your appetite, however at times they are dropped unceremoniously into the reader’s lap for them to stare at and grope for the full meaning.

Terms like “kanban”, “katas”, “The three ways” and references to Toyota’s manufacturing prowess are woven throughout the book, however they seem like mere allusions and foreshadowing to a future time in the book. However, the foreshadowing doesn’t blossom into an actual in-depth explanation of any of them. Certainly those concepts and tools are large and themselves need many books to be fully developed, however I think a few pages of focused explanation should have been given to them. I still don’t know what a “kata” is precisely and what “The Three Ways” are in any concrete way.

In spite of all the above, the book did excite an interest in these things. You instinctively understand that there are many large concepts that are being introduced, each of them mere tips to golden icebergs. That sensation offers a bit of forgiveness to the lack of clear explanations for some factory terms and processes. Even the main character Bill Palmer has to write down a few words and phrases for later review, which leads me to believe the authors knew what was happening with the flood of factory-think. However, it only works if you later mop up the mess you made, but instead you’re sometimes left cold and wet wondering what just happened. The deeper concepts that inspired the book seem near and dear to only one or two characters in the book, but kept at a distance from the reader.

The Good

I started this review with the negative so that I could end on a positive note. With all of the above said, you might think that I hated the book. I didn’t hate it. I didn’t love it either. I liked it – and want to like it more than I do. I think it deserves a re-read once I take in some of the works that represent the larger body of knowledge that this book rests on.

For example, I’m planning on reading Dr. Eliyahu Goldratt’s book, “The Goal: A Process Of Ongoing Improvement”. Apparently The Phoenix Project follows closely in the footsteps of “The Goal” in structure and topic. I want to learn more about “The Toyota Way” of manufacturing and look into Jez Humble and David Farley’s book “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.” I’m interested in the concepts behind agile and lean manufacturing as applied to software development, but also on a larger scale of IT project delivery.

To be fair, I was gaining more and more interest in those concepts before this book, however The Phoenix Project wrapped up many of these concepts, and in conjunction with the the book’s blog gave interesting backstory and history to them. As a result I think it does a good job of encapsulating very complex topics into a primer in the form of a fictional case study. I think the storytelling, being as poor as it is, gets in the way at times, but if you can ignore that, the book has a good chance at exciting you over the possibilities that an IT department has if monolithic thinking is let go in favor of a more holistic, business-centered approach that includes lean manufacturing concepts.

One of the most fantastic elements to the book is that it isn’t at all focused on the tactics involved. No specific technologies are talked about, no vendors, no task management styles, no ITIL. It seems that there was great effort spent on not mentioning any vendor for any reason. For a book over 300 pages long about IT, there are hardly any references to what they’re using to deliver the services. It’s mentioned briefly that one of the ops teams manages 1,000 Windows servers. Another time a reference is made to an Oracle database. That’s about it. No specific mention of any vendor is made. No language, no hardware, no software. The closest thing to an endorsement is a few references to the various IT teams using open source tools to quickly create a solution, and that’s about as specific as it gets. Literally, it’s just about three sentences scattered around the book that basically say “the team used some open source tools to create a solution for…”

The Phoenix Project is about the strategic understanding of work. Not just IT work. Not just project management. Not operations. Not development. Just work. The concepts can be applied to any work wether it’s making fences from driftwood on the shores of a Madagascar to the most complex operating environemnt in the most web 2.5 trendy-kewl devop shop you can imagine. It very wisely and deftly avoids any vendor bias.

It also avoids departmental bias. SysAdmins, security, development, management – they’re not intentionally pitted against eachother. Bill, the protagonist, comes from an infrastructure background and his character has the typical negative mindset towards developers as being only in the business of crashing production systems and the security guys as only wanting to halt all projects with inane restrictions. The mindset is eye-rollingly stereotypical, however it shows each department’s conversion to a belief in a larger concept than just their small team’s goals. If any team got short shrift in the book, it was security, but I’m willing to admit that my understanding of how and why security was treated like it was is a bit foggy. I think there are larger concepts and business processes that I’m not familiar with that would explain what happened and why. (I won’t spoil anything – read it for yourself and if you figure it out, let me know!)

On a more nuts-and-bolts level, the book is presented in a very clean fashion. There’s no table of contents. There are no chapter titles save for having a date printed beneath the chapter number. There are 35 chapters spread across 338 pages making the story flow in small, manageable chunks. I like this format for this book since it makes less of an emphasis on story development and more on getting the reader to consume concepts in small bites. Had I not been multitasking so hard for a week, it could have been finished in two evenings. One Saturday if you’ve got nothing to do on the weekend.

The Background and Foreground

This book is apparently the first fruits of  the digestion and practice of an enormous body of work and decades of combined life/work experience among the authors. Much of the material that this book is founded upon is listed in the IT Revolution Press blog post “Where to Learn More About Concepts In The Phoenix Project”.

These four authors have worked together before with the books “The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps” and “Visible Ops Security: Achieving Common Security and IT Operations Objectives in 4 Practical Steps”.

There is a second book on the horizon for IT Revolution Press called “The Devops Cookbook.” In fact, there is a very transparent pitch for this book that is woven into the final pages of the story. (Side note: I found the setup for “The Devops Cookbook” to be the most gag inducing part of the book, but by the time I made it to the last few pages I had gained a startling ability to quickly suspend my distaste for the storytelling and take the bumbling attempts at using various literary devices out of the equation.)

Those that know me a little closer than just through the blog (say, through ServerFault, forums, IRC, IM, email or meatspace) know that I’m somewhat critical of devops on a broad scale. Or rather, what is passed off as devops. Devops itself is a nebulous term that is in its infancy and still has no strict definition, so anyone can call anything “devops” and be nearly as right as the next person. However with an author lineup like John Allspaw, Patrick Debois, Damon Edwards, Jes Humble, Gene Kim, Mike Orzen, and John Willis, you know this will be the real deal. Not “I know ruby, installed puppet and now know everything about network management” which is what much of “devops” appears to be these days.

It is interesting to note that while the book is, of course, fiction, it does have an interesting way of blending reality into the story here and there. Mostly to make mention of certain names and books like Rother, Ohno, “The Game” and references to Toyota in the 1950s. In chapter 30, the 2009 Velocity Conference where John Allspaw and Paul Hammond delivered their “Ten Deployments Per Day” talk is referenced and takes the focal point for a few chapters as characters are aghast at the thought of that many deployments.

Final Words

On the back of the book’s dust jacket, Adrian Cockroft is quoted as saying the book is an “IT swamp draining manual for anyone who is neck deep in alligators.” It isn’t. It’s an introduction course on wetland management written by a few brilliant professors that didn’t earn stellar marks in literature class.

The book feels like someone has overturned a box full or Erector Set parts in front of you and provided a few wrenches and torn instructions. You have a great sense of potential at what you see laying before you. The instructions give opaque guidance on the ultimate value that could be created with them. But you know you need more resources to draw on and time to think in order to pull it together a high degree of skill and success.

(Note: Apparently the book had a name change from “When IT Failts” to “The Phoenix Project.” This can be a bit confusing when researching the book itself. Even in the acknowledgements section at the end of the book, one of the authors refers to the book as “When IT fails.” Thanks to whoever was the catalyst behind changing the title from what would have been one of the most ill conceived book titles in the history of publishing to something compelling and worthy of the book’s awesome cover art. Thank you.)

If you can get past the story telling, and ignore the tropes and unrealistic outcome (or rather, the unrealistic timetable that the outcome developed over) then I think you can be fired up to probe deeper into this realm of plant management, katas, kanbans, and other means of managing projects. I think anyone looking to learn more about what IT can bring to a business, not just geeking out on specific technologies, this book will be a good tool to get your feet wet in some pretty large topics and give you a diving board into much deeper waters.

(I’ll let you borrow my pet-peeve glasses for a moment, if you’ll just follow me as I track down an old prey of mine.)

“Failure is not an option!” an impassioned executive cries.

Between the time I started to write this post and the time I published it, I’m certain that a few dozen people in a wide variety of roles and circumstances across this globe spouted those words with the fervor of any politician hoping to sway their constituents.

In a personal effort to speak more simply and accurately, I’m trying to remove non-words and anti-think from my vernacular. This seems like a good place to start. When someone says “Failure is not an option” I believe they most likely mean a number of things:

• “I intensely do not want this situation to end in failure.”
• “I want to impress on all of those involved that this is a very serious situation.”
• “If this situation ends in failure it will result in severe negative consequences.”
• “I will rule by force and vague threats to see that a situation ends in success.”
• “I am a big person and can say scary things because rawr!”

Say What You Mean

“I meant what I said, and I said what I meant. An elephant’s faithful one-hundred percent.” –Horton the elephant

“Suffer from Diarrhea.” –Coors Beer

Language can be the determining factor between enjoying a cold one and a biohazard situation. I believe that precision should be taken to make sure that most of what we say is actually contributing to a situation in a meaningful way. The alternative is misunderstandings.

If someone says “Failure is not an option”, while there are many interpretations of that phrase, the ultimate meaning is anything but what the phrase means on the face. However, the reality in which we live is that failure is really an option. It’s always an option. It’s always available and looming around all corners. The goal is to deftly choose the best options to avoid that one damning and ever-present possibility.

Why Does it Matter

To some of us, it matters in three ways:

1. Saying “failure is not an option” is strongly implying stupidity on the part of the audience. You really think the listening audience believes that? You think they’re too dumb to see the facts and interpret them correctly?
2. Saying “failure is not an option” makes a person seem completely out of touch with reality and does not foster an environment of facts. Better to face truth and be willing to say “Failure will kill us all with nasty big pointy teeth” than start telling fairy tails.
3. Saying “failure is not an option” is a gross display of hubris with nothing to back it up. You can not see the future and do not know what a second may bring. You can do your best, prepare for the worst, and perform admirably. You cannot, however change a situation by sheer force of will and speaking an obnoxious shibboleth. It’s one thing to think positive, and another to be hackneyed.

A Suggested Alternative

Be factual. Be open.

An environment of reality and openness is simultaneously highly valuable and very uncommon. It’s the little things that count towards a culture and building a team. Facing the possibility of failure will help explore more solutions, make the consequences more real than any vague and empty threat ever could, and show respect to listeners as being rational, thinking adults.

Don’t fall prey to empty speech. Be forthright. Failure is not an op…

…I’ll show myself out.

(And an excellent post that is a spin-off / partial response to my post: IT Science vs. IT Religion. Again )

In the last six months or so, I’ve been on a rampage to cut out material and immaterial clutter from my life. It has come to my attention that email has taken entirely too much of my life with very little return on that investment. In my last post titled “Two Quick Tips to Regain Time and Productivity in Your Day” I explained how I started unsubscribing from almost every serial email that I received. That wasn’t enough though. I pared down my email habits a little bit more.

What I’m about to write about isn’t ground breaking and many other people before me have said the same things. However, perhaps my own style and anecdotes can add a slight difference and connect better with different people. Here are my three of my tips concerning email simplicity.

First, Consolidate Email Accounts

I don’t know about you, but I had too many email accounts. There was a time when I had about two dozen email accounts on my iPhone. I would create an email account for use on websites that pertained to chess. An email account for FaceBook. An email account for family, one for friends, one for business, one for YouTube videos of computer stuff, one for YouTube videos for family, one for Flickr, one for… you get the idea.

I looked at all the email accounts I had and either closed them or I made a permanent forwarder to one main account. I’m down to (don’t laugh) six email accounts on my iPhone. One of them I kept around just to make sure that I don’t need it, so I’ll make a permanent forwarding rule and then not check that mailbox anymore. Maybe I can get down to three, which I believe is the bare minimum at this stage in my life.

If you have multiple email addresses (and perhaps there are only a few of you), consolidate them. Ask what separate domains of influence and information you were creating those addresses for in the first place, and then seek to consolidate them all into as few as possible.

Second, Consolidate Email Ingress Points

Yes, I’ve been working around firewalls lately. The title simply means: make fewer ways that email can get to you.

At one point I had email accounts (remember, I had two dozen accounts!) spread over a laptop, desktop, Kindle Fire, ASUS Transformer, and my phone. Sending me an email pretty well guaranteed that my house would suddenly sound like a Chinese New Year celebration.

Not only did I remove the email accounts from all devices but my laptop and phone, but I also got rid of the two tablets, which is a consolidation story all to itself. I need email on my phone for clients and family to get in touch with me. That’s pretty much set in stone. I also need it on my laptop (my main working computer). Or do I?

I’m now considering a further consolidation by doing all of my email from my phone! I use Rackspace hosted Exchange and Gmail for my two most important accounts (work and personal, respectively). Both work great on the phone and both have interfaces to the broader set of calendars and contacts that each system provides.

Now I’m not suggesting that I need to thumb-type every email message out (although the three sentences people would be okay with that). I would use my bluetooth keyboard for typing on the phone. However I am suggesting that having only one device that email can come to me on is probably an improvement in simplicity that I would benefit from.

Third, Limit Email Notifications

There was a time when my accounts were tied into my IM program and each email would pop up an IM alert, as well as jingle my phone and tweak any full email client that checked the account. The email client would pop up a windowed notification for not only new email but calendar appointments, contact birthdays and some other minutia.

Enough! Email now only gives me an audible alert when new messages come in and scheduled appointments are due. I think that can even be pared down to only audibly warning me when appointments are due and only check mail at predetermined times during the day, however I’m not in a place to do that yet.

I won’t harp on the evils of multitasking and how constant interruptions to our concentration are making us dumber. I think we are aware of that. Simply take a few distractions out of your day and remove visual cues that will certainly pull your mind elsewhere. Limit what devices can alert you, why they alert you and if possible when they alert you. If you can have an email client only check for email every 30 minutes, do so. Push email is great, but it can be a pain if you have a segment of time wherein you’re getting an alert every 60 seconds.

Bonus Point! Track Your Email Usage

If possible, every time you have to manage email, track how much time you spend on it. Since I’m an independent contractor / consultant, I use time tracking tools to invoice with, as well as track my own time that I use internally to develop my systems and services. I have combined time tracking with my pervasive use of kanban and have several “15 minute correspond” tickets on my “done” side of the kanban board each day. Once I start getting a few “30 minute correspond” as well as a batch of 15 minute tickets, then I know something is up and I need to figure out why email is eating my life away.

Guard Your Time

Your time is finite and precious. It’s the only thing you can spend but never earn back. Don’t let something as potentially useful as email become a tool that breaks the hourglass.

Got any other tips along this vein? Let me know!

I have made two changes to my computer-based behavior in the new year that have regained an enormous amount of time and changed the way I do things in a positive way. I’d like to share them here for the benefit of others and to hear from you what other things you’ve done with similar results. Here are my two tips:

I Don’t Save Browser Tabs

It starts innocently enough. You have a project or an idea and you start machine-gunning the control-t key combo. New tab! New tab! New tab! You do some Google searches on various keywords to start your data gathering efforts. You middle or command-click the search result links to open those pages in new tabs. You scour those pages, absorbing their information and further middle / command-click links on them. Treesort on a Sandy Bridge Xeon couldn’t find the root node of your tab history before the heat death of the universe. In fact it would probably make a measurable contribution to the universe’s heat death.

Before you know it, your 8GB workstation is slower than an anesthetized tree sloth and your browser is hugging its knees while rocking itself in a corner. Even worse, you might have multiple browser instances, each with their own standing army of open tabs. “Yeah, Chrome window #1 has all my Exchange migration tabs. Chrome #2 is all about the Cisco problem I’ve been having. FireFox is for the MikroTik research and I think Safaris #1, #2, and #3 can be blamed on Reddit.”

Starting any web browser on your PC takes longer than booting Vista from punchcards. A browser crash that loses your tabs requires your co-workers to quickly recall how to use the portable defibrillator unit that HR put in the server room the last time vSphere had a major version upgrade to perform.

I know all of the above well, because that person is me. Or rather, was me. Not anymore. I no longer save tabs. Closing a web browser loses all tabs and opening a web browser brings up a fresh, single tab populated with an innocuous home page (i.e. not Reddit). This has several positive side effects:

First, it forces me to collect information in a more orderly fashion. Every time I close a browser, I know that all information is gone for good. This has changed my information gathering habits to now put information that I need to retain for any length of time, either as a bookmark or in another information gathering tool like OneNote or EverNote.

I was a OneNote fan for a long time. I still am. However, I switched to Linux two years back, and then moved to a Mac a few months ago. The switch to Linux required a virtual machine to keep OneNote around, but that was a little cumbersome. Then moving to a Mac, I wanted to integrate into that OS more. Thus, I switched to EverNote (Yay cross-platform!). Doubly helpful is their cloud storage of notebooks that I can see and use on many other devices.

Whatever you do or use, I would venture to say that not saving tabs in such a volatile thing as a web browser will get you to reconsider your main method of information storage. It will likely improve your research habits and make information easier to store, find and annotate. It’s starting to for me.

Second, I’m beginning to use bookmarking better. Caused by point #1, I now look to the cloud bookmarking features of Safari and Chrome. I’m now making better use of browser bookmarking in general. An improper cataloging system can be a huge burden, just as bad as tabs that go on forever. However, I’ve found that research-based links are better organized by date whereas links that are generally used and useful are better categorized by topic.

So the big pfSense project I’ve been agonizing over for the last few days? (Okay, weeks) Those tabs and links should be put in a dated hierarchy. I start with year, then month, then week or day. I can then think “I was working on pfSense… January. I think it was January,” and have a good shot at finding those links later. Putting my myriad of pfSense links that are specific to the problem I’m having into a general “Networking > pfSense” folder would be futile and cluttering. In my experience anyway. Your tastes might vary, and indeed my own preferences might change as I continue to use this method.

Nevertheless, using bookmarking better is a good thing, and in my opinion using cloud bookmarks is even better because you’re not out of luck if you tend to spread work out over multiple computing devices. I’ve got a laptop, a desktop, a phone and a tablet. Bookmark syncing can be very helpful in that scenario.

I’m Unsubscribing

There was a time when I used mailing lists and newsletters as a means of not having to remember things. If there was a product or company that I liked the looks of, I’d subscribe to their marketing newsletter to gradually learn more about them. Would that feature that could really help me really come out in the next six months like the sales guy said? (Ha!) What other products do they have that I didn’t know about? Are there little training tips that I’m missing out on? Maybe I just want to be reminded about this company a few times so I don’t forget them when I need their product.

(Believe it or not, that last reason has actually been a useful tool for me. I remember things based on repetition [as do most people] so if there’s a vendor / product that has the potential to be useful, I’ll sign up to their newsletter for the sole purpose of seeing their brand and products over the course of a month or two. Then when I’m reasonably sure I’ll remember their name and products, I unsubscribe. I don’t think that habit needs to change change insofar as I remember to unsubscribe at an optimal time.)

I also used to sign up for general industry news outlets. Smart Briefs, IEEE newsletters, Technorati, Gizmodo, Garner, Forrester, Techcrunch, YouTube channels, yadda yadda yadda. There was a time when I would receive about a 100 to 150 emails a day, most of which were glanced at for five seconds or less. Or worse – they were immediately discarded in annoyance. My reasoning, especially for the news briefs, was that I’d scan them for 30 seconds, see if there’s anything I think I should know about as an IT professional (or just an individual), and then read the article.

(Side note: That thought process also encouraged the problem I mentioned above concerning browser tabs. That Smart Brief on IT management? Three tabs would spawn. The top stories on LinkedIn? Two tabs. Gawker? Another two. Or Twelve. Then I’d have, quite literally, 10 to 20 tabs of stories that I thought would enrich me. In reality, I’d recognize that it would take at least an hour to get through them all, and I can’t spare that amount of time for reading what amounts to virtual newspaper articles. So I’d skim them. The end result? My concentration discipline was weakened, I never deeply absorbed any of the information, and I got dumber.)

My email inboxes (yes, plural) would consume two or more hours of my day. That wasn’t even counting actual correspondence with anyone. I was essentially just managing text files. Two horribly unproductive hours. Two shameful hours of not just being unproductive, but getting stupider. I was a vile, filthy, wretched, untoward, worm of a… well, okay, I just let a bad habit get worse and didn’t question it until the habit got very wasteful.

Summary

Question your use of time. In fact, why are you reading this? Should you be doing something else? I’m not trying to nag you like your mom, but am I actually helping you? Is that my blog’s general tendency or do you often think “Why did I just drag my eyeballs across that?” If you get this blog in your inbox, consider unsubscribing. If it’s in your RSS feeds (I stopped reading my RSS feeds long ago for similar reasons), make sure I’m one of the more useful ones. If you’re on my site, reconsider coming back.

Seriously.

If it’s not helping you, it’s hurting you. If I’m not consistently enriching you, get rid of me. Same goes for anything else. Tabs, emails, and more. Ditch it.

Any other helpful hints to gain time back? Even during the writing of this post I thought of a few other time vampires that I could write about, but I didn’t want to make the post any longer than it already is. Let me know in the comments below, and feel free to contact me if you want to write a post about it and share it with a broader audience. Or write on your own blog and I’ll link to the post. Time is a limited resource – use it wisely.

If you don’t know about Talentopoly, well, you should! It’s a growing community of sharp technical workers from all walks of IT life. There’s a vibrant culture of sharing great articles that I for one would never come across on my own. I’ve discovered quite a few blogs, websites, and resources that I wouldn’t have known about otherwise. There is also a place to ask questions and start discussions.

A relatively new feature of the site is their job board. Think of it like Craigslist with a vetting process that weeds out the jokers. On the job board you can find both full-time jobs as well as smaller “gigs” that can allow someone who already has a job to pick up some side work. In their own words:

We want a place where developers & designers can find full-time jobs and paid gigs on the same site.

So we’re doing what any good hacker would do, we’re building it.

We’re personally vetting each job and gig listed and are committed to keeping the quality high and the noise low.

Yes, Talentopoloy and their job board does tend to favor developers over administrators, but I believe that’s slowly changing as more administrators participate. It’s a new service so there’s not a ton of job postings there yet, but I thought you might like to get in on the ground floor. I’ve even considered turning to it when I needed some quick work done on a project. You can get emails from their low traffic newsletter that lets you know of any new jobs that have been posted.

If your employer is looking to post a job description, have them check out the Talentopoly job board where thousands of highly qualified developers and administrators congregate. They might fill their position without having to go through a long recruitment process with outside agencies.

Check out the Talentopoly job board, and let me know if you need an invite to the site. It’s still invite-only to keep the quality high. I’ve got 5 invites as of this posting and it’s first-come, first-serve. If you’re interested, email me and I’ll send an invite to the address you email me from.

PowerShell is a powerful tool. It’s also very different than the cmd and VBScript way of doing things that we’ve suffered through since the beginning of time. About a year ago, I set out to rewrite our custom imaging scripts and AD automation tasks that were mostly VBScript using PowerShell. I took on this effort in part (ok, in whole) as an excuse to learn PowerShell. If you haven’t taken the plunge yet, I’ll introduce some basics and get you set up to start chugging along on your own.

First thing is first, you need the Active Directory PowerShell modules and PowerShell 2.0. You need to grab a copy of the Remote Server Administration Toolkit (RSAT) for your OS and architecture from the Microsoft Download site. After you install it, enable the Active Directory Commandline Tools feature. If you’re on Windows 7 or later, you’re done. If you’re on Vista, please accept my condolences and grab PowerShell 2.0 or later from Microsoft Update.

The next thing that you need is to be able to actually run the cmdlets from the AD module against your domain controllers. If you’re on 2008 R2 or later, this is enabled by default. If you’re on Server 2008 or 2003, you need to install the Active Directory Management Gateway Service on at least one Domain Controller in each domain that you wish to manage with PowerShell. Some of the prerequisites for this may require a reboot, so plan to do this during a maintenance window.

Ok, phew. So now we can actually start using PowerShell to manage AD objects! Fire up a PowerShell prompt and run import-module activedirectory. That will load the AD module and we can start having fun.

Do you want to see all user accounts in your domain?  get-aduser -filter * will do the trick. You’ll notice that each user is presented like this:

DistinguishedName : CN=Some User,OU=My Users,DC=My,DC=Domain,DC=ORG
Enabled : True
GivenName : Some
Name : Some User
ObjectClass : user
ObjectGUID : blahblah-1111-111a-dddd-blahblahblahblah
SamAccountName : suser
SID : S-1-5-blahblahblah
Surname : User
UserPrincipalName : [email protected]

Woah, that’s a lot of info! And guess what, it’s an OBJECT! That means that we can select individual properties or pipeline the whole damn thing. Pretty cool, right? Say that you just want the SAMAccountName for all of the users in your domain. That’s what the select-object cmdlet is for.

get-aduser -filter * | select-object samaccountname

will spit out just the account name for each user we just saw in the previous command.

We can also save a set of objects to a variable for manipulation later. If you run $users = get-aduser -filter * and then type $users, you’ll see the whole output. This is useful when scripting PowerShell.

Let’s get to something useful, ok? What if we wanted to know a bunch of information about every account in the domain, including the last time it was logged in and whether or not it’s enabled. What’s that? You want it in a CSV so that you can poke around at it in Excel? That’s fine.

Get-ADUser -Filter * -Properties name, samaccountname, description, distinguishedname,enabled,lastlogondate |
Select-Object name, samaccountname, description, distinguishedname,enabled,lastlogondate |
Export-CSV c:\scripts\users.csv -NoTypeInformation

That looks a little complicated, but let’s break it down. The first line is basically the first command we ran, but we’ve added -Properties, which retrieves specific properties from the user accounts that aren’t returned by default. The pipe operator | takes the output of one command and spits it into the next – this will be very familiar to anyone that’s worked in Linux. So, we’ve taken all of the user accounts and piped it to a select-object, which we understand from before as well.  Then, we pipe that to export-csv  which basically formats everything nice and neatly into a csv file. There is also an import-csv cmdlet, which can be used as a data source, but we’re not going to get into that today.

If you ever want to see what options are available for a command, or how it handles things being piped to it, there are excellent manpage-style help files available. get-help get-aduser -full will show you all of the options available for the get-aduser cmdlet and will also include some sample commands to point you in the right direction.

The Active Directory module has 76 cmdlets available, so get-aduser is just the tip of the iceberg. get-command -module activedirectory will show you all of them and you can use get-help to see what they do and start playing around.

I hope this helps you get over your fear of PowerShell and get you started with some PowerShell-based reporting! You’ll have your whole account creation process automated in no time! (protip: use new-aduser)

Someone I know shared this link with me from www.OnlineMBA.com. I thought it was interesting enough to share:

There’s a lot, and I mean a lot, that can be translated into the realm of systems administration and delivering products and services to customers and clients. I’m just too lazy to be the one doing it right now. Anyone care to step up? =)

Once upon a time, some dread and fabled tech-berzerkers saw a need for a new online village targeted to sysadmins. Given the blessings of King RedGate they established an outpost and began recruiting other like-minded admins. That community was known as The SysAdmin Network.

Fast forward two years or so, and the outpost has become a small town of very smart individuals who share their trials and success. Their fears and hopes. Dreams and nightmare. It’s not yet a bustling metropolis, but it has potential. There are 912 members that are currently enrolled, with a few more signing up each week.

Built on the Ning platform, there are a lot of inherent features that exist to help the community gel, communicate, and participate. There exists a forum, gallery, chat room, an ability to schedule events, user blogs, videos, and a few more lesser features. One of my fondest memories is of a Solaris / ZFS event done by Isaac Bush (who I also interviewed after he revealed on the SysAdmin Network that he removed all anti-virus from his Windows machines and survived quite nicely). With that I first learned of the wonders of ZFS and began to consider using it for production systems.

Heck, I even relied on The SysAdmin Network as a means of communicating with members of the 2012 RedHat Study Buddy group.

RedGate is reordering its commitments and the SysAdmin Network has come under scrutiny. It’s a fine community, but deserves more love and care than it is currently getting. That’s where the sysadmin community at large can step in.

Friends. Geeks. SysAdmins. Lend me Your Modship.

RedGate is looking to pass off the moderating and managing of the SysAdmin Network onto interested members of the SysAdmin community at large. There’s no hard pre-requisites or rules of engagement. Just show a real interest in the community and participate in its moderation.

The opportunity has been offered to me, but I’m hesitant to accept it alone. I’ve got a lot that I’m working on lately and don’t think I can do a community like that the justice that it deserves. At least, not alone. However with a posse of responsible co-leaders, I think it can be done.

Here’s the question posed to you:

Will you be an administrator for the SysAdmin Network? If you’re interested, of an adult age and truly experienced as a systems administrator, please consider this opportunity. Personally, I’d like to see The SysAdmin Network flourish, but to do so it would take genuine effort to cultivate participation and a healthy, vibrant culture. That’s great, but it needs a small population of motivated individuals to make it happen. It can’t happen with just one person.

Personally, I’m hoping to see at least two other people show enough interest in this to make it happen. There’s no true limit. If just one person speaks up with genuine interest, then you’re likely to be seriously considered. After all, this is RedGate’s baby to pass off, not mine. I’m merely interjecting my own thoughts into the matter. I believe a handful of interested people would be nicer.

To be sure, there is no recompense for this responsibility. It’s just a labor of love. Neither RedGate nor anyone else is offering any kind of renumeration. If you feel like contributing to the sysadmin community in this way, comment below or email me at [email protected] and I can get you in touch with the berserkers at RedGate.

Lastly, I can neither confirm nor deny any allegations that viking helmets help your chances of being granted moderator status.

I started out the 2012 RedHat Study Buddy Group with the best of intentions. I really did. And then, life happens. Or maybe that’s my excuse. The short story, is that my personal development in this endeavor has halted in the last three weeks, thus I have not posted anything about it.

TL;DR

I’m lame

Okay, Maybe There’s More to It

A few rush projects for a client got in the way and I’ve been working nearly around the clock. I’ve been trying to move into some of my own colocation space as well as get the applications and services set up that will track billing and accounts. It’s been a pretty sunup-to-sundown-and-then-some affair, and when it came down to it, getting RedHat certified wasn’t going to net me any paid invoices in the very near future.

So what does this mean for me? It means that I’m going to keep chugging along at a reasonable pace to learn the skills that I need to be more profitable. That means RedHat studying. However, at the moment, it’s looking like the goal of a RedHat certification on my wall before the year ends is going to be unattainable.

So what does that mean for the study buddy group? It means that with a leader that goes AWOL, it’s harder to focus. However, the group remains the same and I hope you’ve all been studying a lot better than I have. Keep it and and stay vigilant – even if I haven’t. =)

What do You Need?

If you’ve signed up to pledge the acquisition of a new RedHat certification before the year ends, let me and the group know what you need to be more successful. Comment below or go to The SysAdmin Network and start a conversation. If you need virtual machines, some conceptual help, real world anecdotes, or whatever, I’m sure someone will be able to give you some of what you need.

We had 11 people sign up for the study buddy group. Where are you all at in your studies? Kenny? Noe? Simon? Jeff? Shashi? Matthew? Adam? Ahmed? Eddy?

We’ve still got time. Truth be told, I could probably buckle down and still make a late December exam. It’s not entirely out of the question. I have to sit down and evaluate what’s important, what is getting me paid, and what would be most beneficial for the coming months.

If you’re still on track, let us all know. If you’re off the tracks, let us know that too. =)