What was the most simplistic or hardest technical problem you couldn't solve?

s-n-c-godfather

Hi I recently joined this forum and hoping for help desk/ desktop technician advice for this question.

CodeBlox

Everything gets resolved eventually. At my current gig, there is no "couldn't solve it". I can't really give you something that couldn't be solved eventually. Some of the harder stuff just takes more time.

ratbuddy

I had an issue recently that I did solve, but it drove me up the wall for about two hours. I was trying to install some System Center 2012 stuff, and the script kept failing with no error message. I tried one thing after another, and nothing was helping.

Finally, by pure coincidence, I noticed the disk was full. Yeah.

Dieg0M

A bad cable.

kohr-ah

The user wouldn't listen (simplistic) that the cable wasn't plugged in all the way. I told her to pull the cable out and plug it in the wall and the wall end into the computer as one of us probably installed the cable backwards. She had no problem with that and it came up.

Hardest - Cisco Network Admission Control (NAC) system wasnt accepting the SSL certifications I had updated in it and noone knew the original password to the system so I couldn't login to the Linux shell to do any commands to troubleshoot. That was a long day.

Eventually I found a cracking utility had to boot off the utility with and hooked a monitor keyboard and mouse I luckily found to the back and reset the password that way then deleted the traces of the old SSL cert that the GUI didn't see.

Ryan82

A few years ago when I was dabbling on the systems side of the house, we lost power to a rack of equipment that housed our exchange server. The power hit ended up corrupting the priv and pub databases. Just restore it from a backup right ? Well, come to find out that the backups weren't working properly for several weeks . I spent like 27 hours straight before I was able to recover the databases.

earonw49

Dieg0M wrote: »

A bad cable.

This.

I've had problems in which loopback testers for RJ-45's that read everything right but eventually I solved a problem (regardless of the positive results from the loopback tester) by simply replacing the RJ...

W Stewart

I spent hours on the phone with a customer and with cisco tech support troubleshooting a VPN issue. I'm not really a networking guy but I am CCNA certified so I'm at least familiar with the cli. Anything I learned about ASA firewalls and VPNs I had to learn on the job. It turned out to be something along the lines of the guy having a bunch of access lists and crypto maps with the same ip addresses because he kept calling in to have more VPNs set up for testing but never removing the old ones. The cisco technician was the one who figured this out after hours of troubleshooting.

cyberguypr

Years ago I went with my then boss to a remote site to check on an intermittent connectivity issue. The router was acting all wonky and there was no concrete evidence of the nature of the issue. After troubleshooting and coming up empty, we ended up calling Cisco TAC. We were on the line with them for a while and they couldn't find what the heck was going on. We rebooted the unit, applied a new image, etc. The engineer, running out of options, suggested switching RJ45 and serial cables a second time. We did that, issue remained. Having literally no other option, he said to go ahead and swap the power cable. My manager argued that it was a futile exercise as he knew the cable was working. After going back and forth for what seemed like an eternity, my manager ended up replacing the power cable. As soon as the router booted we noticed the issue was gone and it was working perfectly. The whole ordeal took 6 hours.

This must've been 7 or 8 years ago. To this day I still bring up the story when people refuse to start troubleshooting at layer 1. We could've saved ourselves hours that night.

netsysllc

I spent about 8 hours remotely helping someone setup a vpn between cisco ASA's that would only work in one direction. He ended up buying a smartnet contract, he spent about 4 hours going through all of the same things again with TAC, then finally Cisco TAC suspected it was a bad ARP entry on the switch.The last thing they had him do was reboot a switch which fixed it.

santaowns

General steps to fix most problems, layer 1, if not layer 1, then reboot lol

Hypntick

Yeah, bad cables are usually one of those things that cause the most random issues that look like everything else but a bad cable.

santaowns

Usually you working with something that at one point worked just fine, so you have to look at what could have changed? Did someone bump something and jar a cable loose, did a patch or change happen on this device or on something that relates to this device? IF your change control is really good, this will be easy to find, if not it will be a full on log dive to find out what happened.

Params7

when you're hired as level 1 and level 3 tells you to stop assigning them tickets and solve problems yourself, even though issues are clearly level 3 and in trying to research/resolve those issues without supervision we risk corrupting the company-wide system. Everyday is hard technical day. Then level 3 yells at you at the end of the day for getting nothing done. I like it.

coreyb80

Just had one where I had to take a remote guy off the domain and then add him back on. Removing him wasn't the issue, but getting him back on was confusing at first. That was until I remembered to VPN as myself and then add him back to the domain on his machine. Had to do the same thing to restore his profile. Took a minute to put it all together, but I got it. Love working in IT!

W Stewart

I'll admit, every now and then I've waisted a good amount of time by not troubleshooting at layer 1 first. That's my new years resolution. SQL assertion error? Have you tried swapping the power cable?

N2IT

For me it's when an application that updates several tables suffers a network drop and only some of the tables get updated, some of which columns are primary keys and or foreign keys. Going back through to figure out which screen the end user was in when this happened and then which tables are part of the insert or update. Then going back in and removing the information which sometimes has a stored procedure or some other item based off of it. It can get tricky.