Skip to main content

what makes a sysadmin? (a response to call out)

i hope this ends up being a terse response to hal’s call out.  you should have seen his original “bio”.  wow.

 

how old were you when you started using computers?

i don’t remember.  i was just a kid.  it was sometime after the commodore vic-20 was released because i was insanely jealous of my neighbor.  i ended up getting a commodore 64 not long after that.  i guess whatever time frame that is…

what was your first machine?

read above.  the commode-door 64.  my sister ruined it with kool-aid and markers.  ended up with a commode-door 128, master-flush cover edition.

what was the first real script you wrote?

i didn’t write any of my own.  my parents had no interest in getting me any programming books so i wrote all the examples in the crappy manual that came with the c64.  i don’t even remember what they did.

what scripting languages have you used?

batch, vbscript, and breaking into powershell.

what was your first professional sysadmin gig?

i handled pc support at a health insurance company.  of course, stating even that makes it sound pretty glorified.  i spent most of my time decollating print jobs that ran off the as/400s.  you remember, right?  the triple-layered printer paper with the perforated edges, with the holes on the side, with a carbon sheet between each layer.  yeah.  every morning, 6am, get in and break them apart.  run them through the decollating monster, load a cart with paper reams a mile high and go to every floor, dropping off reports.  fun.  killed lots of trees there.

if you knew then what you know now, would you have started in IT?

hell yeah.  i would be the master scripter by now!  :)  there’s lots of things you learn along the way that you wished someone had told you before.

if there is one thing you learned along the way that you would tell new sysadmins, what would it be?

be diligent in your pursuit of knowledge.  it’s not enough to expect your trade on-the-job.  if you want to be really good at what you do, invest time in it.

what’s the most fun you’ve ever had scripting?

i’m not even indulging this question.  i wish this question was about horrifying experiences.  i have plenty of those.

who am i calling out?

john the hann
pete zerger
rory mccaw
bryce kinnamon
andy dominey
blake mengotto
anders the burning village bengtsson

Comments

Popular posts from this blog

using preloadpkgonsite.exe to stage compressed copies to child site distribution points

UPDATE: john marcum sent me a kind email to let me know about a problem he ran into with preloadpkgonsite.exe in the new SCCM Toolkit V2 where under certain conditions, packages will not uncompress.  if you are using the v2 toolkit, PLEASE read this blog post before proceeding.   here’s a scenario that came up on the mssms@lists.myitforum.com mailing list. when confronted with a situation of large packages and wan links, it’s generally best to get the data to the other location without going over the wire. in this case, 75gb. :/ the “how” you get the files there is really not the most important thing to worry about. once they’re there and moved to the appropriate location, preloadpkgonsite.exe is required to install the compressed source files. once done, a status message goes back to the parent server which should stop the upstream server from copying the package source files over the wan to the child site. anyway, if it’s a relatively small amount of packages, you can

How to Identify Applications Using Your Domain Controller

Problem Everyone has been through it. We've all had to retire or replace a domain controller at some point in our checkered collective experiences. While AD provides very intelligent high availability, some applications are just plain dumb. They do not observe site awareness or participate in locating a domain controller. All they want is the name or IP of one domain controller which gets hardcoded in a configuration file somewhere, deeply embedded in some file folder or setting that you are never going to find. How do you look at a DC and decide which applications might be doing it? Packet trace? Logs? Shut it down and wait for screaming? It seems very tedious and nearly impossible. Potential Solution Obviously I wouldn't even bother posting this if I hadn't run across something interesting. :) I ran across something in draftcalled Domain Controller Isolation. Since it's in draft, I don't know that it's published yet. HOWEVER, the concept is based off

sccm: content hash fails to match

back in 2008, I wrote up a little thing about how distribution manager fails to send a package to a distribution point . even though a lot of what I wrote that for was the failure of packages to get delivered to child sites, the result was pretty much the same. when the client tries to run the advertisement with an old package, the result was a failure because of content mismatch. I went through an ordeal recently capturing these exact kinds of failures and corrected quite a number of problems with these packages. the resulting blog post is my effort to capture how these problems were resolved. if nothing else, it's a basic checklist of things you can use.   DETECTION status messages take a look at your status messages. this has to be the easiest way to determine where these problems exist. unfortunately, it requires that a client is already experiencing problems. there are client logs you can examine as well such as cas, but I wasn't even sure I was going to have enough m