Support diary: Tony Geraghty (Monday)

Have you ever wanted to read someone else's diary? Here's your chance. This week, find out what IT is like in Ireland.

This week’s diary comes from Tony Geraghty, a network and systems administrator living in Ireland.

Meet Tony
I'm 31 years old, married with no children. Our three cats are about all the responsibility I need in that department! I started working in the retail grocery sector when I was 18, moving up to branch manager in a large chain here in Ireland. When I was 25 and tired of that, I moved into a confectionery company as a sales rep.

I've always been intrigued by computers, and did some programming in my youth on the old Spectrum and Tandy machines. So when the confectionery company (Cadbury—you may have heard of them—they export a small range to the U.S.) decided to develop a system to allow sales reps to use laptops to take orders and upload to the systems in head office, I was chosen to look after the project. When it finished, I moved into the IT area full-time.

Monday starts at 6:30 A.M.
Following a shower and a quick bite to eat, I check e-mail and read today's Dilbert and User Friendly strips while I wait for my wife. We're on the road before 7:30 A.M. I drop her to work and arrive in the office for 8:00 A.M.

I dock my laptop and begin the usual routine of checking the nightly backups, switching tapes, and running a systems check on all the servers and communication equipment in the computer room.

All the backups are successful, all routers, hubs and switches are showing green, and the two NT servers and three UNIX boxes are humming away to themselves, so it’s back to the office to have a quick look at Slashdot before 9:00 A.M., when things start to get busy.

9:00 A.M.
Sure enough, 9:00 on the button and the phone rings. One of our users in a remote office has forgotten her password and accidentally disabled her account on the main HP 9000 application server. A quick logon and reactivation, and everyone is happy again. My first happy customer of the week.

I'd like to hope the rest of the week runs this smoothly, but since the other IT team member is on a site visit in the UK for the next three days, something tells me it won't. I start to install the OS and company software on a laptop for a new civil engineer while I wait for the next call.

9:30 A.M.
I hate being right all the time. I get four calls in the space of five minutes, all detailing the same problem. One of the NT servers in the UK is refusing to validate logons. I drop the laptop and use Hyena to check the services and event log on the remote system. Everything looks okay, but using Proxy Master to connect to the system shows a blank desktop, and no response from keyboard or mouse.

There are only two users with open documents, so I give a quick phone call to ask them to try to save their documents. One server reboot later, and all is working again. Not the cleanest approach to the problem, but I don't have time to troubleshoot right now. Once it’s up, I begin the tedious task of sifting through the event log to see what may have happened.

Nothing untoward shows up, so I mark it down as something to watch for in the next few days. It’s the first reboot of that particular server in three months, so hopefully it was a simple case of NT reminding me who the boss is. Back to the laptop.

10:30 A.M.
The laptop is ready to go, and the phone hasn't rung. Maybe it’s time to take some time out to give you some background into who I am and what I'm doing.

I work for a large construction company in Ireland. I've been here a year and a half now. Originally hired as a Desktop Support Specialist, I had three years’ technical experience, having come late into the arena from, of all vocations, a retail sales environment. I was hired as part of a reorganization and modernization plan for the IT department.

Ireland has been experiencing phenomenal economic growth over the past five years, and the construction industry was one of the main beneficiaries of this growth, so senior management had decided a restructuring of the business and the way in which it utilized technology was in order.

Within three months of my joining, the previous network admin left for pastures new. I like to think this had nothing to do with me! Finding a replacement proved no easy task for the group IT manager, and I took up the slack and threw myself into learning network administration with gusto. This was closely followed by our UNIX admin announcing his forthcoming retirement due to ill health, and the recruitment requirements were changed slightly from a network admin to a network and UNIX systems admin.

I had absolutely no UNIX experience whatsoever, but after one UNIX fundamentals training course and a Linux box to play with later, I was ready to learn a new OS and cover for him until a replacement could be hired.

Three months went by pretty quickly with me providing all desktop, network, and UNIX support for a company with nine regional offices and numerous long-term building sites around the UK and Ireland. And I realized I wasn't particularly keen on handing my newfound network and system administration responsibilities to a stranger. I spoke to my immediate boss, and after some discussion we decided I would remain responsible for the network and UNIX end of things. The recruitment requirements changed yet again, this time with the aim of hiring someone with good desktop skills who wants to develop networking and UNIX skills, thereby allowing us to complement each other. The operations team was rounded out recently by the hiring of an operations manager, to whom the new desktop support person and I now report.

11:00 A.M.
It looks like my prediction of a hectic day was premature. It’s decidedly quiet, so I take the time to catch up on some long-overdue administrative duties like keeping the asset register up-to-date, matching delivery notes with invoices, forwarding them for payment, and all of the other wonderful little jobs we hate.

This takes me nicely up to 12:00 noon and time for a quick trip upstairs to install two dot-matrix printers and network them. While I'm there, one of the users mentions that they are unable to print from a very old spreadsheet application on the DRS6000 UNIX system that's due to be scrapped sometime soon.

There is a bit of history with this problem. Whilst I was on holidays in California last summer, this system crashed quite spectacularly and trashed a hard disk. When I returned from holidays, I discovered the crash was caused by a disk hardware failure. It was decided that since the HP 9000 had already taken on the DRS system's workload there was no point in replacing the disk.

I reinstalled the OS on a substantially reduced disk capacity and retrieved any old financial data from tape to enable transfer from the old system to MS Excel-compatible spreadsheets. Every now and again, someone needs to access some old data that hasn't yet been transferred, and if the /var filesystem has reached capacity they won't be able to print. Every time this happens, I tell myself I must write a small script to clear out the log files and keep capacity at 90% or thereabouts. I usually follow that up with the thought that it’s not going to be here for much longer, so what's the point?

The crash happened three months back, and the DRS is still here. Maybe I should write that script. Anyway...with the printers installed and the /var directory cleared, it was time for lunch!

2:00 P.M.
No sooner am I back from lunch, than the phone rings again—another printer problem. I have a quick look at the offending computer using the Proxy software, but everything seems okay. It’s quite possible the printer drivers need to be reinstalled, and as this user is located here in head office, I decide to take a walk to the other end of the building and have a look in person.

I could easily do the job over the network, but I believe it’s always a good idea to let the users know there's a real person on the helpdesk end of the phone, so I try to pay a visit to their desktops whenever possible to fly the IT flag.

4:30 P.M.
It’s a fairly quiet afternoon, so I take the time to begin the installation of a new PC after I'd finished reinstalling those printer drivers. It seems to be the day for printing problems. Another two users have reported print problems, but fortunately, they were both user errors. One failed to notice when someone had switched the printer offline, and another failed to log into the network and therefore had no network printing capability.

A quick chat with the business systems analyst has turned into an appointment for 5:30 P.M. to have a chat about the interface we're working on to provide data exchange between two UNIX applications.

6:30 P.M.
The meeting is quite interesting. One or two niggling points are cleared up, and we decide to run some tests tomorrow. Just as I'm packing up to leave for the evening, the phone rings. A panicked user is unable to print and needs to produce a report immediately. What is it with the printers here today?!

I spend a few minutes poking around on the HP9000—everything looks okay. I can ping the print server box the printer is running from, so no connectivity issues. Maybe it’s just a dodgy cable. After a fruitless ten minutes, I ring the user to arrange a divert to another printer, only to be told he'd gone home just after calling me.

Obviously, the report wasn't that important. Feeling slightly miffed, I decide to leave the printer until tomorrow and head for home.
If you’d like to share your reaction to this diary entry, please post a comment below or follow this link to write to Tony .

Editor's Picks

Free Newsletters, In your Inbox