My first experience with data recovery

My first experience with data recovery

It was 1997. I was working my first full-time  job, and my phone rang with my first crisis.

“What happened to the K drive?” the caller asked.

I glanced over at my network drive cheat sheet, which listed all of our shares and what server they were on. In those days, most of our servers still had 300-400 megabyte drives and that meant every file server hosted, at most, a couple of shares. There was no K drive on our list. I was afraid this was about to get interesting. Read more

Pipe output to the clipboard in Windows

Besides all the changes to the GUI that happened post-Windows XP, they also made one useful change to the command prompt. When you run a command, it’s now possible to pipe output to the clipboard.

If you’re like me and write a lot of documentation, or you just take a lot of notes while doing computer maintenance, it’s a big boon.

Read more

My first really bad day in IT

Next weekend is Labor Day weekend. I can’t remember if it was one Thursday or two Thursdays before Labor Day weekend in 1997, but one of those two days happened to be the beginning of the first crisis of my career.

Whichever Thursday it was, it was getting close to midnight when my phone rang. It was Max. The print server wasn’t working. That happened a lot. That server had IBM’s Services for Macintosh on it, which never worked all that well, and, worse, tended to make the rest of the server act up a lot. That in and of itself shouldn’t have been a crisis. But I’m getting ahead of myself.
Read more

DOS war stories

In honor of the IBM PC turning 30, I thought I’d tell some stories about my experiences with the operating system introduced with it, PC DOS (aka MS-DOS).
Read more

What happens when you put a dipstick, a screwdriver, and a SAN in the same room

It was 2007, give or take a year. I was working a shop that had a WAN connecting four data centers around the world. A couple of hard drives in a SAN at one of the remote data centers had either failed or were in the process of failing.

No problem, we said. We’ll send some drives, and we’ll send along some extras so the next time it happens, you can just grab a spare off the shelf, slam it in, and not miss a beat.

Simple, right? Well, you should never underestimate a human being’s ability to make the simple difficult.
Read more

Misguided security, episode 14

I was working in a data center, where we had a couple of Cisco VOIP phones. I don’t know who put them in or when–it’s possible they predated me. We never got them working, but nobody ever really tried, either.

The idea was that two guys working on servers in different datacenters across the WAN might need to talk. The reality was that we didn’t do that very often and usually had other ways to do it–a cellphone being the most obvious option. Our networking guys always had much more pressing issues than getting the VOIP phones working, so the phones just sat there and looked pretty. Until the wrong guy noticed them one day, that is.

Read more

It must be that system idle process…

One day, I came back to my desk after lunch and my boss cornered me. “You know about these things. What’s Half-Life?”

I hesitated for a minute. “I’m pretty sure it’s a computer game.”

It wasn’t a game I’d played. If it isn’t Railroad Tycoon, I’m probably not interested. Read more

Why every sysadmin needs to know how to hack into Windows systems

Yesterday, Lifehacker posted an article called How to Break Into a Windows PC (And Prevent it from Happening to You). Some people weren’t happy that they posted a tutorial on how to hack into Windows systems.

Let me tell you why every sysadmin needs to know how to hack into Windows systems, given physical access. I can give you three scenarios that I’ve run into. Read more

Barfy.

I started my professional career doing network administration at the University of Missouri. (I generally don’t count my stint selling low-quality PCs at the last surviving national consumer electronics chain towards my professional experience anymore.)

Read more

Something to try when ERD Commander’s Locksmith doesn’t work

So maybe you’re like me and you’re administering a system that fell off its Windows domain, and the system was built by your predecessor’s predecessor, the local administrator account was renamed, and nobody has any clue what the account name or password is.

And you try ERD Commander because it worked in the past, but not this time…Usually the Locksmith works. But in this case, it didn’t, and of course everyone wanted the server back online an hour ago. We tried everything else we could think of for about three days, including downloading some things that I was sure would get me a visit from a security officer. Nothing worked. At least when I got the visit from the security officer, he just wanted to know why there were repeated attempts to log in with certain accounts.

“I was trying to hack into my own server and it seems I’m not a very good hacker,” I said. Duh.

So I found myself standing at the server with another sysadmin, having used my last idea. “I don’t suppose you have any ideas?” I asked. “I figured if you did, you would have said so by now, but…”

He shook his head.

Finally, I had one last idea. I asked him what he set the password to when he used ERD Commander.

“Password,” he said. “To make it easy to remember.”

Aha! A light went off. This system was hardened to require stronger passwords than just an 8-character alphabetic password. I had a hunch that was what was keeping us from being able to log in using our hacked account.

So we booted off the ERD Commander CD yet again, connected to the Windows installation, located what we were pretty sure was the renamed local adminstrator account, and I reset it to the standard mixed-case special character password we use for the local admin accounts.

We held our breath, rebooted, and tried to log in.

Success. Finally.

So if ERD Commander isn’t working for you, try using a stronger password to satisfy your local system policy.

And just in case you’re wondering why a computer falls off a domain, computers have usernames and passwords just like users do. Occasionally the passwords get reset. If for some reason the domain controller thinks a member computer’s password is one thing, and the member computer thinks it’s something else, you end up with a computer that says it’s on the domain, but can’t authenticate against it. The solution is to log in with a local administrator account, then either run NTDOM.EXE from the Windows Support Tools, or remove the computer from the domain and add it back in. You can just put the computer in a workgroup, ignore the dialog box that says you have to reboot, then add it to the domain, and then reboot.