Tuesday's Printer, Password, and Panic Fixer

9:07 in the morning. The moment I open the office door, someone at the end of the hallway waves at me. It's the signal that the printer has died again. Before I even have a chance to set my coffee down, I open the ticket queue and eight requests have already piled up, three of them marked "URGENTE." Tuesdays are always like this. Problems that build up on Monday all explode at once on Tuesday morning.

My desk is in a corner on the third floor of a mid-sized company in downtown Guadalajara. Two monitors, a tangle of LAN cables, and drawers stuffed with adapters. From this spot, I handle an average of about twenty-five tickets a day. Half are password resets; the other half are battles against the vague complaint, "My computer is acting weird."

The Morning Printer War

Printer issues are IT support's oldest enemy. That day, the shared printer on the third floor got stuck in the print queue, and it took nearly 40 minutes to find the cause. I reinstalled the driver, checked the network connection, and restarted the print spooler service. In the end, the culprit was someone who had half-pulled the USB cable out of the back of the printer. 40 minutes of software debugging, solved by pushing a cable back in. I quietly laughed to myself as I lay on the floor plugging it in.

When this kind of thing keeps happening, you develop your own checklist.

• Is the power on (seriously, you have to check every time)
• Physical cable connections
• Network ping test
• Driver version check
• Clear the print queue

Suspecting software first is a bad habit of mine. I should check the cables first, and I know that, yet every time I open the terminal first. Once I spent two hours digging through firewall settings only to discover the Ethernet cable was plugged into the phone jack on the wall instead of the switch. After that day, I wrote "cables first" on a Post-it and stuck it on my monitor. It's still there.

Password Resets: The Never-Ending River

Around 11 a.m., password-related tickets start flooding in. "I can't log in" is the most common sentence in IT support, and in most cases the answer is simple. They forgot their password, Caps Lock is on, or they've been caught by the 90-day password change policy.

Just because it's simple doesn't mean it's quick. You find the account in Active Directory, set a temporary password, explain the new password rules to the user (one uppercase letter, one number, one special character, at least 8 characters), and then 10 minutes later the same person calls back saying, "The new password doesn't work either." Turns out the old password saved in their browser was being auto-filled.

One Tuesday, I did seven password resets in a single hour. I suggested to the seventh user, "Have you ever thought about trying a password manager app?" They replied, "What if I forget the password to the password manager?" They weren't wrong.

I usually eat lunch at my desk. My favorite taco place is two blocks from the office, but if I go out and come back, tickets pile up again, so I often just eat whatever a coworker brings back. One birria taco and a glass of agua de jamaica is enough energy to get through the afternoon.

The Real Problems of the Afternoon

In the afternoon, the simple morning tickets taper off and more complex issues come in. This particular Tuesday, a ticket came from the accounting team saying their VPN connection kept dropping. An employee working from home was getting disconnected just five minutes into every session when connecting to the company server.

It took 20 minutes just to connect remotely and check the logs. The user's internet was stable, and the VPN client version was up to date. Eventually, digging through the server-side logs revealed the issue: an MTU value mismatch. The user's router was using the default MTU of 1500, and packets were getting fragmented going through the VPN tunnel. I walked them through lowering the MTU to 1400, confirmed the connection was stable, and only then closed the ticket.

Solving problems like this is the best part of the job. Nobody celebrates, and the accounting employee just says, "Oh, it's working? Thanks," and moves on. But the small thrill of finding the cause buried in the logs is something only I know. That feeling when you're reading packet flows with tcpdump and you spot the exact anomaly. Would it be an exaggeration to say it's like defeating a hidden boss in a video game?

Around 4 p.m., the entire second-floor network suddenly went down. Panic mode. I ran down to the server room and checked the switch. Every port indicator light was off. I checked the power cable, connected to the console, and dug through the change logs to see if someone had messed with the settings. It turned out the cleaning staff had unplugged the switch's power outlet briefly to use a vacuum cleaner and plugged it back in, but the switch hadn't booted up properly. It took 15 minutes to manually reboot it and verify the port configuration. The moment the entire second floor came back to life, a sales team member I ran into in the hallway asked, "Why did the internet go down?" I just said, "There was a brief maintenance check." I didn't want to get the cleaning staff in trouble.

Between these sudden outages, routine tickets keep rolling in.

• "My Excel file won't open" (the file extension was .xlxs instead of .xlsx, a typo)
• "My monitor keeps flickering" (loose cable connection)
• "I can't send emails" (the attachment exceeded the 25MB limit)

Each one is a small thing, but when dozens pile up in a day, it gets pretty draining. So I started compiling frequently occurring issues and posting them on the company wiki. Documents like "Email Attachment Size Limit Guide" and "Step-by-Step Password Change Instructions." As more people started reading the wiki and solving problems on their own, the simple tickets gradually decreased. The achievement I'm proudest of isn't a software deployment or a server migration. It's those fifteen wiki articles.

I usually leave around 6:30. I check the ticket queue one last time, leave notes on the ones still in progress, and organize everything so I can pick right up when I come in tomorrow morning. As I walk out of the office, I pass by the third-floor printer, and the indicator light is glowing green. Thanks to that cable I plugged back in while lying on the floor this morning.

The bus ride home takes about 30 minutes. On the Línea 1 del Tren Ligero, I put in my earbuds and listen to a Linux podcast, or sometimes I just look out the window. In my head, I'm organizing that VPN MTU issue from earlier, thinking maybe I should write it up on my blog in case a similar case comes up again. Then I quietly sigh, remembering that a server patch is scheduled for tomorrow, Wednesday.

When someone asks me what IT support does, I used to say, "It's doing things for people that they can't do themselves." These days, I've changed my answer a bit. "It's teaching people how to do things they're actually capable of but just don't know yet." That's what I realized after seeing a single wiki article eliminate ten tickets.