Tales from Tech Support

808 readers
1 users here now

founded 1 year ago
MODERATORS
1
 
 

These stories are originally posted over the past decade on Reddits TalesfromTechSupport so I am copying over to Lemmy to help bring some life into this /c/


Sigh, I had one of those Mondays. As per the rules all names are replaced to protect the identity of the stupid and ill informed.

Some auzzie slang/humour may come off as offensive, I apologise, its just how we roll in the land down under

Back story, I work for a fixed wireless ISP. I deal anywhere between integration firms and the onsite IT bloke. This particular incident took place at the HQ of a multi site medical center group


Get a call at 6:30AM

Me: G'day slazer speaking.
Customer IT guy (Lets call him Steve): Hi mate, its Steve from Medical Group our head office is offline at the moment. We had a really bad storm go though last night, it may just be power but can you guys be on stand by just in case?
Me: nyaaa, all right. I'll do my usual morning stuff and get into the office asap. Can you check out HQ and let me know?
Steve: no worries mate.

2 min later

imessage from the boss: slazer, the HQ of Medical Group is down. whats going on.
imessage to the boss: Just got off the phone with their IT bloke and he is going in to checking power. I'll get to the office early and prep our spare radios.

no reply from the boss.
[insert usual morning stuff of shower, shave, and shi....]
While driving to the office I get another call from Steve

Me: G'day Steve, how is it looking on your end?
Steve: Well, we have lost a UPS and a switch to last nights storm, you may of lost your radio though, there is no up-link light on your Cisco NTU.
Me: bugger, I guess you have tried power cycling it?
Steve: Yea, the light is on the power injector but no light on the NTU. Our sparkie (aussie slang for an electrician) is coming in to check everything else is OK, I'll get him to check your cable too.
Me: Cheers mate, I'll get a spare radio configured and head straight up to you.

3 accidents on the motorway D: a normal 45 min trip takes 2 hours but I get there eventually.

CIT: You took your time mate.
Me: Traffics a female dog.
CIT: Fair call, the sparkie had a look at the run from the server room to the radio on the roof, he said everything is fine. where do you want to start?
Me: Well lets make sure the POE injector is OK first.

We head to the server room and I notice there is no light on the POE injector. I do the usual troubleshooting and the light on the POE will only stay on while the cable to the radio is not plugged in. I check the injector by plugging in the replacement radio, lights stays on and the radio turns on and starts squawking while it searches for a base station to connect to. The port on the NTU also comes on ruling out the POE and NTU as the cause of the fault.

Me: Well the problem is not down here. Lets go for a sticky beak on the roof.
just as i finish saying the sentence, the sparkie appears out of nowhere.
Sparkie: Everything is fine on the roof, I have checked the cable and the radio is powered up
Me: ......... its not that I don't believe you, its just that..... no bugger it, I don't believe you.
Sparkie: hmmf

the sparkie walks off.

Steve: Little rude there mate? Me: Only because he lied.

Stevelooks confused

Me: By how the light was behaving on the injector, there is no way everything is fine.
Steve: Fair enough mate, let me know what you find.

He goes back to checking the servers and I head up to the roof alone. Once I get onto the roof I notice there is no light on the bottom of the radio...

I remove the waterproof bung and saw the rj45 head had been...... I don't have a word that will get passed the profanity filter for how the head looked.

Now, I have seen RJ45 heads shorted before from either over voltage (doing 54v to a 24v device) or water getting into the bung but nothing this bad.

It takes me a moment to collect myself and I begin repairing the cable. YAY for service loops!!! I install the replacement radio and get off the roof to make sure the customer is back online.


Warning: PUT YOUR DRINKS DOWN BEFORE OPENING THE PICTURE


I find the Steve in his "office" (read cubby hole)

Steve: back online are we? Good, What was the problem.
Me: May wana get the sparkie in for this.

Stevelooks confused, but pages him to his "office".

Sparkie: Whats up?
Me: When you said you checked the cable, what did you do?
Sparkie: I put a RJ45 tester on both ends and it tested OK.
Me: Again, I do not believe you. Tell me, how did you "test" this?

I gave both Steve and the sparkie a moment to collect their jaws from the table.

Steve: You can go slazer, thanks for getting the connection working. May I keep that head?
Me: Sure mate, I have a pic, that is all we require.


I am not sure if I will find out what happens with that sparkie, but I doubt I want to. On the bright side, because I had to travel before 7AM the company paid for my breakfast :D

To those of you who saw the pic before my warning of putting your drinks down, I am sorry. For those of you who blandly ignored it.... well, I am still sorry, but you were warned.


Update Time

So it turns out the sparkie vocabulary is smaller than both myself and Steve thought most sparkies have. When he was told to check the cable going to the radio on the roof he thought they were talking about the Wifi Access Point on the 3th floor.

His reasoning: Because ground, 1st and 2nd have floors above them they have ceilings. 3rd floor is the top floor so it is not a ceiling, it is a roof...... I'll let that logic sink in for the rest of you too.

2
 
 

Some background, I work full stack while we also man the support email from users. I'm manning the support email this week, but today I was also tech support for a fellow developer.

We use HP docks to connect everything from screens to keyboards. But today a dock would not do anything when my colleague attempted to use it.

Being the nosy kind, I went and asked the usual

  • Did you reboot?
  • Did you remove the power to the dock?
  • Try messing with the drivers?
  • lock the screen before unplugging?
  • Tried another dock?

All yes, none worked. Our IT support hadn't opened for the day yet and he was looking into updating the specific dock driver.

So I asked, did you try the other USB-C port? And what do you know, that worked. Then he just plugged right back into the first USB-C port and everything was back to normal. I don't know who made the drivers, but it's pretty danning when they can brick a specific USB port until it's forced to redo whatever config that messes it up, by using another USB port...

If anyone wonders, the docks have a magnetically joined charging and USB plug, so it's fairly natural to plug them in together side by side. It's also almost uniquely a dock issue and not a dead USB port, so it's funny that the enite thing uncloggs from just using another port for a second. But a reboot does not...

3
 
 

This is a more recent story while working for an MSP in Europe compared to my time working for an ISP in Australia

the cast:
Me: Slazer
OT: Other Tech


I get a message on slack

OT: Hey, I am seeing something weird in the French office for customer, can you help me look into it?
Me: Sure

Queue the Teams call.

OT: So all the Access Points in that office are reported as offline in cloud.vendor.com portal but the customer is not reporting an issue.
Me: Ok, that is odd. What is the monitoring system saying?
OT: Monitoring says everything is OK, I can ping them and do SNMP calls to all the AP, they are just reporting as offline in the portal.
OT: The other thing is the firewall says the AP are trying to access cloud.vendor.com but the local in policy is denying the traffic.
Me: That is rather strange.

I log into the firewall and check the logs and see the APs are in fact trying to access cloud.vendor.com but the destination is 255.255.255.255. Not the expected IP from the vendors documentation.

Me: Well I want to say it's a DNS issue what happens when you reboot the AP?
OT: Rebooting from the portal doesn't work but I rebooted on from the switchport and the same thing happens.
Me: Is the on prem DNS server working?
OT: Yea, the domain controller is the DHCP/DNS server and it has no issue with access, the customer hasn't reported connection issues. It looks to be just the APs.
Me: Ok then, are they being allocated the right DNS servers?

OT logs into the domain controller and everything is looking good.

Me: dafuq?..... Wait, do these even use the DNS server from DHCP or do we set one via the device template?
OT: Not sure, never had this happen before. When we provision these they are plug and play.

I log into the vendor portal and start poking around and notice all the APs have the same DNS server of 208.67.222.222 (OpenDNS)

Me: Ok, well the AP aren't using the local DNS server they are using openDNS. Lets start a packet capture to see what is going on.

I setup a packet capture on the firewall and limit it to the IP of the AP we are looking at and let it run for a bit and crack open the capture in Wireshark.
I just start laughing at the error

OT: I know that laugh, what did you find?
Me: what do you make of this error?

Every single DNS query had this as the response.

The OpenDNS service is currently unavailable in France and some French territories due to a court order under Article L.333-10 of the French Sport code. See https://support.opendns.com/hc/en-us/

OT: Wha????
Me: Yea.... Now for the hard part.
OT: Hard part?
Me: How do we fix this? There is no ssh logins to the AP, we can't push config because the devices are offline according to the portal, and there is no way we are getting console to each of those units.
OT: I see.

Then the dumb idea occurred to me.

Me: I have a dumb idea. We DNAT any traffic destined for OpenDNS to Googles DNS so we can reconfigure the units to use the local DNS servers.
OT: Would that work?
Me: It should.... I hope.

We then setup DNAT for the AP specifically to rewrite the DNS request destined for OpenDNS and forward it to Googles DNS.
After activating the config we start seeing the devices come online in the portal as if nothing happened to them.

OT: Hey, it worked.
Me: omg, it actually worked...

I am somewhat sill shocked it worked.

At some point I will get some time to clean up that DNAT and finish reconfiguring the APs.

4
 
 

This is a repost of a story I posted on Reddit a few years ago.


Story participants
Me: Slazer
Boss: the boss
T1: Tech 1
T2 Tech 2


Backstory

The boss is all about redundancy and backup. If he finds a single point of failure that I have missed he lets us know and sets a time frame for when he wants it resolved along with a when the failover testing should be done. Because an untested backup is worse than no backup.


To spare the boring BGP details
We have 2 data centres in our closest state capitol. With transit multihomed transit through a single level 2 carrier (while not true multihomed we have transit of last resort through one of our layer 2 customers).

One day the boss arrives in the office around 10:30 AM after being in a huff about hearing of a major outage in a competitors network.

Boss: Slazer, did you get our traffic balanced over our 2 transit paths like we discussed a while ago?
Me: Yes, DC1 advertises prefix 1,3,5 and the aggregate. DC2 advertises prefixes 2,4,6 and the aggregate.
Boss: What happens when one of the transit fails?
Me: I am advertising the DC2 prefixes out DC1 with the backup BGP community. Then doing the same thing for DC1 prefixes over DC2. In the event of a transit failure the upstream has a backup path ready to go. Boss: and it works?
Me: Yes, last time I tested it was about 2 or 3 months ago and it failover over correctly.
Boss: Why haven't you tested it sooner?
Me: RANCID hasn't reported a configuration change since the last test. I only test it if there has been a config change on and of those routers.
Boss: But how can you be sure it still works?
Me: Shall I force a failover now to show it works?
Boss: Sure. (which I assume he said with sarcasm)

Me: Starts logging to DC1 core router

T1 seeing me do my configuration change face.

T1: If you are doing that I am going for a break.

I shutdown our transit interface for DC1 and wait for BGP to time out.
After about 10 min with no calls the boss turns around and continues the conversation.

Boss: So when will you be testing the failover?
Me: We are, right now.
Boss: What??!! as his face drops.
Me: You agreed. Plus this way now you know for sure it works because the phones haven't started ringing.
T2: Slazer is right. The graphs show how an increase in traffic on DC2 transit.

Boss slides over to T2 desk. Sure enough, the graph for DC1 transit is reading zero traffic and the graph for DC2 is showing all the transit traffic for the state.

Boss: That doesn't looks like much traffic.
Me: Only about 20-30% of our traffic goes via Transit, the rest goes via the various IXs we are on.
Boss: Who don't we get via the IX?
Me: Customers of our transit provider who aren't on any IX, Telstra and Optus as they aren't on any IX, and any international site that doesn't use a CDN.

We continue discussing for a good 20 - 30 min about where we get various traffic from and further redundancy in the core networks. During which time T1 returns from his break.

T1: Phones are quiet?
Me: Yes.
Boss: Can you turn the DC1 transit back on?

I walk back to my desk and turn the transit interface back on and see the BGP peer back on. While T2 and the boss are watching the graph for DC2 transit it drops about 2/3 of traffic and that appears back on DC1 transit.


And from that day the Boss hasn't asked about the transit failover because now he knows it works.

5
 
 

Why do users hit me up on teams to ask me to help them with something, and when I ask if they are available for me to stop by, they ignore me? Then I go on about my day, and my manager comes to me later saying they complained that I never showed up to help them. Am I missing some unspoken rule of modern american office culture?

6
 
 

User: I need a new ssd to expand the storage on my laptop

C: Sure, for that laptop you need to submit an M.2 installation ticket.

User: No I need an ssd.

C: Yes sir, that is an ssd, it's just the form factor. Go to [company's internal website] and submit a request for an M.2 ssd installation.

User: They have 2 models to pick from, which do I choose?

C: The M.2.

User: ...Is that an ssd?

C: ...Let me just show you.

7
 
 

Dealing (primarily) with other techs

Rule T1 - CYA

Rule T1A - Always have someone else to blame it on.

Rule T2 - Never lie to another tech.

Rule T2A - Unless that tech is the person you're about to blame. See Rule T1A.

Rule T2B - Sometimes you will need to lie in order to deal with things like warranty repairs or getting ISPs to do the right thing.

Rule T3 - Never assume anything.

Rule T3A - Does the issue even exist?

Rule T3B - Is it even plugged in?

Rule T3C - Is it turned on?

Rule T4 - Don't expect your boss or coworkers or users to understand just what it is that you do.

Rule T4A - Even if they are a tech.

Rule T5 - Sometimes, you will be the one who is wrong.

Rule T6 - Don't try to do work over the Internet while in a moving airplane.

Rule T7 - Never call support with your cellphone if you can help it. Otherwise, you won't be able to drop the problem in someone else's lap.

Rule T8 - You will really screw up eventually and it is going to be a doozy.

Rule T9 - Backup following the Rule of Three. A backup, a copy of the backup, and a copy of the copy. Test them.

Rule T9A - Consider using other backup strategies. See Link TL1(https://www.unitrends.com/blog/3-2-1-backup-sucks).

Rule T9B - There is no backup. If there is a backup, it is either corrupt or years out of date.

Rule T9C - If you can't restore from it, you don't have a backup.

Rule T9D - If you haven't tested your backup recently, you don't have a backup.

Rule T9E - A year ago is not "recently".

Rule T10 - Assume that there are also inside threats, even inside IT. It's not paranoia if they really are after you (or your stuff).

Rule T10A - Don't trust your coworkers. They might be using Rule T2A.

Rule T10B - Don't even trust yourself. One error and you might cause serious damage or become a security leak.

Rule T10C - The new member on your team will send critical sensitive information to anyone who asks without trying to do any verification.

Rule T11 - When you need tech support, the tech support person is likely to be clueless.

Rule T11A - Whenever you have a problem, you will be unable to find a solution until just before the tech you called for help arrives.

Rule T11B - If the tech you called in isn't clueless, then you were and your problem has an obvious solution that you completely missed that they will point out seconds after they arrive.

Rule T11C - If none of these apply, the solution will be something random that will make no sense whatsoever to you or the technician.

Rule T12 - Every tech has their own set of Rules, even if they don't know it.

Rule T13 - Every tech is also a user.

Rule T13A - Techs will treat you like you are a user.

Rule T14 - Make sure your coworkers don't make changes before going on vacation.

Rule T15 - No technical person reads all of the rules. They will act like they know them until the place catches fire, then complain about incomplete documentation.

Rule T15A - Especially if it was the documentation that went up in flames first.

Rule T16 - Womprats aren't much larger than two meters.

Rule T17 - Third-Party IT will make configuration overhauls without notifying your company's IT department, and then blame your company for problems caused by their configuration mishap.

Rule T18 - You are incompetent. You just don't know it. At least, that's what your replacement will think.

Rule T18A - You will have to deal with techs who are incompetent.

Rule T18B - Sometimes, you really are incompetent.

Rule T19 - You might find people who support you. Reciprocate.

Rule T20 - Always verify who you are corresponding with. This includes not using Reply All.

Rule T21 - Use your inner laziness to do the most elegant solution possible.

Rule T21A - Know the difference between "truly lazy" and "plain laziness".

Rule T22 - If nothing seems to work, reboot.

Rule T23 - Cables can and will be used as ropes.

Rule T24 - Other techs will never read the manual.

Rule T24A - Neither will you.

Rule T25 - Your fellow techs will expect you to be their tech support.

Rule T26 - A tech will install equipment in dangerous environments.

Rule T27 - Third part IT will remove equipment and not tell you or the user.

Rule T28 - The biggest enemy of good IT is that they are outnumbered by lazy IT.

Rule T29 - Grow a beard so that people don't recognize you.

Rule T568A - white green, green, white orange, blue, white blue, orange, white brown, brown

Rule T568B - white orange, orange, white green, blue, white blue, green, white brown, brown

Rule T1000 - Buy stock in Boston Dynamics but sell all of it before 2029.


GitHub: https://github.com/r/morriscox

8
 
 
9
 
 

Rules of Tech Support

Rule 1 - Users lie.

Rule 1A - It may not be malicious or willful, but Rule 1 is always in effect.

Rule 1B - Users assume you don't know they are lying.

Rule 1C - Users continue to lie as a result.

Rule 1D - When caught in a lie, users get angry.

Rule 1E - Users lie even when they aren't users.

Rule 1F - If they are not lying, then they are wrong.

Rule 1G: Accept that you will eventually have to lie to get the user to do what you need them to do.

Rule 2 - Explain everything as simply as possible.

Rule 2A - There is no language simple enough to make a user understand anything.

Rule 2B - Emojis are NEVER an answer.

Rule 3 - User caused problems are caused by tech support.

Rule 3A - As it's your fault, they don't want to be billed.

Rule 3B - All issues are user issues. If there are no users, no issues get reported, no tickets get created. Ergo, it must be users who are responsible.

Rule 4 - If it doesn't work, it is your fault.

Rule 4A - If it does, you had nothing to do with it.

Rule 5 - If you take the time to visit the user's desk, the problem will magically have fixed itself.

Rule 5A - Or the solution is bound to be really simple.

Rule 5B - Or the user left the office moments after entering the ticket, and won't be back for days. How long is uncertain as these users never use their calendar.

Rule 5C - Or when they do, they won't have shared it with you or they entered an all-day event as taking an hour.

Rule 5D - The problem will be solved by doing something you already asked them to but they said it didn't work. - /u/Responsible-Slide-95

Rule 6 - All users consider their situation to be more important than others, even if they know you are helping someone else.

Rule 6A - All users want VIP treatment.

Rule 6B - But they don't ever want to pay for VIP treatment.

Rule 7 - It doesn't matter how much time the user claims something will take. See Rule 1.

Rule 8 - Users never read error messages, if they read anything at all.

Rule 8A - If a user reads an alert or error message, they don't know what to do even if they can only do one thing.

Rule 8B - The more advanced degree a user has, the less likely they are to read anything.

Rule 8C - They will give the wrong error message.

Rule 8D - If a user receives an error, when asked what it says, the user will reply: "I don't know, just an error. I closed it."

Rule 8E - "Isn't it YOUR JOB to know that?"

Rule 8F - Users will not read you the entire error code or message or will read everything else.

Rule 8G - If the user reads you the error message in its entirety, it will be irrelevant to the issue.

Rule 9 - Expect any and all jargon and technical terms (such as wireless) to be misunderstood.

Rule 9A - Expect everything to be misinterpreted.

Rule 9B - All jargon is the same to users.

Rule 9C - All jargon will be used incorrectly.

Rule 10 - About half of tech support is solving issues that are only partially related to what is supposed to be fixed.

Rule 11 - No system is idiot-proof enough to best all users.

Rule 11A - If you haven't found a user able to best your system, it's because they haven't found you yet.

Rule 11B - Nature will take as a challenge any attempt to create an idiot-proof system.

Rule 12 - There is nothing so stupid that no one will do.

Rule 12A - Stupid questions do exist.

Rule 12B - There is no such thing as a stupid question, just stupid people. Asking a stupid question identifies a stupid user and therefore the question itself is not stupid.

Rule 13 - Never believe a user who claims that there is nothing that needs to be saved. See Rule W10 and Rule W10A.

Rule 14 - Sometimes you need to trick users in order to get the job done.

Rule 14A - Sometimes you have to make people, not just users, terrified to get them to do what they are supposed to.

Rule 15 - Users care more about things working than in how you pulled it off.

Rule 16 - A user's appreciation for your work is inversely proportional to how difficult it was.

Rule 17 - If you have an accent, then you will be perceived to be in a foreign country.

Rule 18 - Never trust a user.

Rule 18A - Everyone is a user. Even you.

Rule 19 - The most intelligent person you know will be defeated by a mere computer.

Rule 19A - Even if it's you.

Rule 20 - The quickest way to find out who is responsible for something is to do the scream test. Remove that something and see who complains.

Rule 20A - If nobody screamed instantly, users may wait until it has been long enough that the thing has been thrown away and can't be recovered any more. Then you will learn that said thing was critical for some task that absolutely has to be done right now, just like every X years.

Rule 21 - Never underestimate the power of the end user to complicate things.

Rule 22 - If it looks different, then it's broken.

Rule 23 - Never give a user options.

Rule 24 - When you receive a ticket and call the user immediately they definitely won't be at their desk.

Rule 24A - If you email them they will already be on vacation.

Rule 24B - The less time that they're in the office, the more urgent their issue is.

Rule 25 - Watch out for Finagle's Law which states that 'Anything that can go wrong, will — at the worst possible moment.'

Rule 26 - Always have a small list of phrases to get users to do what you are trying to get them to do.

Rule 26A - Only share these with other techs.

Rule 27 - Don't let people know you are a tech. They are likely to ask for free tech support.

Rule 27A - Never, EVER, give out personal contact information.

Rule 28 - Sometimes, you will be the one who is wrong.

Rule 29 - Expect equipment to be placed in bad locations.

Rule 30 - It's always the printer|DNS|server|browser|connection. It's never the printer|DNS|server|browser|connection.

Rule 30A - It's always the printer. Printers are evil.

Rule 30B - Printers are evil because of users.

Rule 30C - If a document fails to print, users will keep trying just to make sure it prints.

Rule 30D - The true importance of the documents they are trying to print will be inversely proportional to the fit they are throwing.

Rule 30E - Users will mash buttons and go through random menus and do random actions until errors go away or the printer is messed up. See also Rule W84.

Rule 30F - Did you check DNS? Check again.

Rule 31 - All user provided information must be verified.

Rule 32 - If you are a female tech, users will ask to speak to a man.

Rule 32A - You will be the only one who can actually help the user even though they will not believe a girl really knows anything.

Rule 32B - You actually know twice as much as the male techs but get only half the respect.

Rule 32C - Guys will pay more attention to your looks/voice than your mind.

Rule 32D - You'll get tons of calls from men (especially if you are attractive) who will even disconnect stuff to get you to go to them.

Rule 32DD - Women will cause IT problems to keep you away from men.

Rule 33 - Just because it worked yesterday does not mean that it will today.

Rule 33A - Just because it didn't work yesterday does not mean that it won't today.

Rule 33B - Things only work when you are paying attention to them.

Rule 34 - Never refer to this Rule by its name.

Rule 35 - Updates will be both solutions and banes, usually at the same time.

Rule 36 - Sometimes, you have to nuke everything.

Rule 37 - Focus on getting things working, then on getting them done right.

Rule 37A - By hook or by crook.

Rule 37B - When things are working right, leave them alone.

Rule 37C - If something starts working, even if you KNOW what you just did shouldn't have fixed it, raise your hands in the air unthreatening-like and slowly back out of the room.

Rule 37D - You only think it's working. The real cause will wait a while and then break everything in a spectacular fashion a few months down the line. Luckily, by then it's usually no longer your problem.

Rule 37E - It will still be your problem.

Rule 38 - There's always a relevant xkcd.

Rule 38A - If you can't find a relevant xkcd, it's because you haven't looked hard enough.

Rule 38B - If there is no relevant xkcd, there is always a relevant Dilbert strip.

Rule 38C - If there is no relevant xkcd or Dilbert strip, there's a relevant entry in The Seventy Maxims of Maximally Effective Mercenaries. Link L1

Rule 38D - If you can't find a relevant xkcd, Dilbert, or Maxim, your problem does not exist.

Rule 39 - You and your work will never be appreciated since if you did your job right, none of these problems would have happened.

Rule 40 - All IT urban legends are true.

Rule 41 - If it takes TFTS to turn you paranoid, you likely haven't been in tech support for very long.

Rule 41A - You aren't paranoid. They really are out to get you.

Rule 42 - You already know the answer.

Rule 43 - Every tech is also a user.

Rule 44 - Never make changes before going on vacation.

Rule 45 - The more you specialize, the less you will remember about basic desktop functions.

Rule 46 - No technical person reads all of the rules. They will act like they know them until the place catches fire, then complain about incomplete documentation.

Rule 46A - Especially if it was the documentation that went up in flames first.

Rule 47 - Don't help anyone who is not paying you in some way as they won't take your advice seriously.

Rule 48 - Vendors will tell you that you need to upgrade to the newest version in order to fix things. If you are on the latest version, they will tell you to wait till the next version.

Rule 48A - If the problem remains reproducible on the latest version, they may tell you to downgrade. Even if you just upgraded per Rule 48.

Rule 48B - It's not a bug, it's an undocumented feature.

Rule 49 - Never assume anyone else is smarter than you.

Rule 49A - Never assume you are smarter than anyone else.

Rule 49B - A user's intelligence will always be precisely what is needed for maximum damage.

Rule 50 - Scheduled updates won't.

Rule 50A - Anything scheduled will break things, especially if you are not available.

Rule 51 - Drivers will drive you bonkers, if you can even find them. Even if you can find them they may not be compatible.

Rule 51A - Drivers are the real threat, not hardware.

Rule 51B - Drivers using hardware [heavy machinery] are also a real threat. Backhoes/diggers have a magnetic attraction to fiber optics and the drivers have an innate ability to find optical fiber. Link L2.

Rule 52 - No is the answer for every request as long as it's plausible.

Rule 53 - Treat your job like a role playing game. Link L3.

Rule 54 - Don't run stuff that you are not supposed to unless Rule 37 and Rule 37A apply.

Rule 55 - The Seventy Maxims of Maximally Effective Mercenaries are always applicable. Link L1

Rule 55A - Sometimes the applicability of the Maxims is not immediately obvious.

Rule 56 - Get to know the Dunning-Kruger effect. Link L4.

Rule 57 - You might want to consider starting the day with coffee or tea and ending with whiskey or scotch or bourbon or beer...

Rule 58 - Vendors might not follow standards.

Rule 59 - You might find people who support you. Reciprocate.

Rule 60 - When a user activates the Swedish Fish rule, they get preferential treatment.

Rule 61 - Like the military says, never volunteer.

Rule 62 - Some bugs are Heisenbugs; they can only occur if they are not being observed. Users do not count as observers.

Rule 63 - Something will be needed right after you get rid of it.

Rule 63A - Once you replace it, you will no longer need it.

Rule 63B - You will buy something and then find out that what you currently have already has what you needed.

Rule 64 - User managed projects will always fail.

Rule 64A - And they will blame you.

Rule 65 - You will complain about something and then realize that you are the one that is guilty.

Rule 66 - You will find yourself putting out fire after fire without any chance to document anything.

Rule 66A - Then get blamed for not documenting everything.

Rule 67 - Try using metaphors and analogies in addition to or instead of technical terms.

Rule 68 - The higher rank an employee is, the more problems you will have with them.

Rule 69 - Refer to Rule 34.

Rule 70 - Anything that will show up as a link should be a link.

Rule 71 - Never take actions that assume a system is a certain way.

Rule 71A - Especially if not assuming makes little or no difference to the troubleshooting process.

Rule 71B - And never if the incorrect assumption will be recognizable to the user.

Rule 72 - Always give users the least amount of access/permissions that you can realistically get away with.

Rule 73 - It's always Dave or Steve or Kevin. Unless it's a Karen.

Rule 74 - Try to phrase things in a way that helps users save face.

Rule 75 - Maintenance, and sometimes coworkers or users, will unplug things and plug them back in wrong or not at all.

Rule 75A - If anything goes wrong they won't tell anyone. You will get to handle the "website down!" or "the internet stopped working!" tickets.

Rule 76 - Only have the minimal required equipment needed for users.

Rule 77 - Your company will be in a very old very shoddy building.

Rule 78 - If someone is acting odd, it might be a social engineering attack. Verify everything.

Rule 78A - VIPs within the company that actually do have the power to have you fired at whim will be the most angered by attempts to verify and will be the hardest to verify.

Rule 78B - Social engineering attackers know Rule 78A.

Rule 79 - Users think they can connect to anywhere from anywhere.

Rule 80 - If this port is taken, port 443 will be as well.

Rule 81 - Most of your job is figuring out what users are talking about.

Rule 81N6 - The GoogleBing awaits.

Rule 82 - Temporary solutions aren't.

Rule 83 - Every company has a Production environment and a Testing environment. If you're lucky, they are separate environments.

Rule 84 - Users already have a certificate of proficiency in computering.

Rule 85 - Always let someone know that you are there to fix a problem.

Rule 86 - You might encounter a user who is nice, doesn't need everything explained, takes you seriously, reads you complete error messages, and does what you tell them to do with no drama. neigh Seriously, they do exist.

Rule 87 - Users who always demand the latest hardware never work in a position that requires the latest hardware.

Rule 88 - Sometimes you need a user to fix your problem.

Rule 88A - Only a user will find the real problem.

Rule 89 - You will be expected to be your own tech support.

Rule 90 - You will have to support software older than you are.

Rule 91 - The OSI model has layer 8 (user) and layer 9 (management).

Rule 92 - It's always a bad sign if someone is happy to see you.

Rule 93 - "Only one thing" never is.

Rule 94 - Hypothetical questions aren't.

Rule 95 - Every mail from the helpdesk or system administration will be too much to handle if it is longer than two lines.

Rule 96 - Business will demand more experience for their job postings than exists.

Rule 97 - Always keep copies of drivers you download.

Rule 98 - Don't ask users if something is on the screen. Have them read the screen.

Rule 99 - A fix will only work until you fall asleep.

Rule 100 - A theme, especially a system theme, will make it difficult to read anything.

Rule 101 - Urgent isn't.

Rule 102 - Someday you will forget to use the mute button. Double mute.

Rule 404 - You will never find it. See https://www.explainxkcd.com/404

Rule 404A - If a page is not found, then the entire site|Internet is down.

Rule 404B - Online manuals will disappear without warning. Download a copy for yourself.

Rule 600613 - Used to go to websites instead of going directly.

Rule Ferengi - Users want their problem fixed quickly. Bribes will ensure they will be.

10
19
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]
 
 

This doesn't exactly fit but it's close enough.

This was in 2016 or 2017.

A good friend of mine was in need of a new PC and wanted to buy a prebuilt. I gently (maybe not so gently) told him that was a waste of money and I could build a better one for cheaper. So I put together a decent budget oriented mid tier build for him. i5 and a GTX 1060 6gb. All was well at this point. We ordered the parts to his house and I got on a train to his city to put it together.

At this point in time, I wasn't an expert on building PC's. I had built two PCs in total. both very budget oriented.

So we (I) start building the PC. All goes well. Each part at it's place. Each cable connected (supposedly). Press the power button. doesn't POST. reseat everything. doesn't POST . My friend is getting very anxious at this point which is slightly annoying to me... Saying he should have just built a prebuilt. This in turn is making me uneasy. We decided to take it a PC shop so that they can test if a component is dead. And mostly to ease his anxiousness.

We take the whole computer, which is basically 'ready' in a cardboardbox to the pc shop. Taking public transit with a huge and decently heavy box isn't that comfortable. Arriving at the PC shop we explain the problem to the worker. He takes one look at it and goes: 'You haven't connected to 6pin power cable for the CPU'

Cue embarassment. But also relief that it was just a stupid oversight, fitting to my inexperience.

Back in his home, we connect the cable. It posts. all is good. Mainboard has no wifi built in so we get an ethernet cable. No connection. Ethernet doesn't work. I tried everything that I could and it didn't work. He bought a cheap usb wifi adapter. which works. To this day The ethernet doesn't work. He is still using that PC. I'm telling him he should upgrade it, or more like replace it completely.

He want's to buy a prebuilt. I tell him I can build him a pc for better and cheaper. I feel like im experiencing a deja vu. Hope the second round goes smoother..

11
 
 

I work in the IT department of a mid-sized company. One of my responsibilities is encoding newly-entered tickets (we use pretty old software for this, so auto-encoding isn't an option). Because of this, I get to personally greet every new ticket that comes knocking at the front door of our Service Desk, from the frustratingly complex to the yawn-inducingly mundane. This ticket fell in the latter category, and came across as follows.

NEW TICKET: Desk phone is not working

[Head of HR] has opened a ticket

Comments: My desk phone does not work. There is no dial tone, but there is a message for me that I cannot retrieve.

The head of our HR department isn't exactly the most tech-savvy, but she's polite and (usually) puts in tickets instead of calling us directly. That, plus her elite status in the company, means we usually give her tickets a higher priority.

Phones aren't normally my area, but I figure that something like this shouldn't be too hard. The first few thoughts that cross my mind include some imaginations of the HR lead somehow managing to unplug her desk phone completely and some speculations that she may have swapped out the typical receiver with a faulty headset. To test these theories, I call her desk phone from mine. It rings all the way through, and then goes to voicemail. From this, I conclude that the phone must at least be connected.

Since I'm a fairly organized (read: obsessive) person, I quickly type a note of what I've tried in the ticket, and submit a comment that I'll stop over sometime that morning. After maybe two minutes, I get a reply back that I can stop over anytime. Not wanting to put it off until after lunch—as I've been known to do with "easy" tickets on occasion—I let my teammates know what I'm doing and scale the mountain leading to the executives' lairs. As I reach the top of the stairs, I immediately notice that the HR lead is in a meeting. She spots me, she gives me a look that says, "Sorry!", and I slink back to the dungeon where we IT people dwell.

As I go to update the ticket to mention that she was busy when I went to investigate the issue, the lady herself ventures into our cavernous halls. "Sorry about that, GrammarPanda. You should be able to look at the phone now!" I delete the update I was typing on the computer, smile, nod, and hike back to the office to take a look.

Walking into her office, I find her desk phone and immediately see that it's functional. The display is reading normally, and all the right lights are on. Okay, so it's definitely a receiver thing, I reason. I pick up the receiver, and find that the dial tone is, in fact, missing. But, in pulling the receiver to my ear, I notice two things:

  1. I've never in my life seen anyone tangle their desk phone's receiver cord so badly; and,
  2. The receiver is connected to some sort of sound amplification device.

This is when I recall that our HR lead is very, very hard of hearing. It was actually what made me suspect a receiver issue in the first place. But, I didn't realize that she installed this gizmo to help. Oh, well; it's pretty neat, and it makes sense. In any case, the device has several LEDs on its front, and none of them are on. I notice that the receiver is plugged into the device, and the device is plugged into the base of the phone. All the wires are securely connected, so either a cable is bad or the device isn't powered by the phone.

To check on this thought, I flip the device over. Right away, I see a battery compartment that (thankfully) has a pull tab and isn't screwed into place. I pop the panel off and see a puffy 9V battery. If someone would have told me that this battery was 30 years old, I would have believed them. I promptly remove the battery from the unit for proper disposal, retrieve a new one from the supply area, install the new battery into the device, and put everything back in place. Now, when I pick up the receiver, I hear a dial tone that could be used to call whales living in the ocean on the other side of the country.

Satisfied with this solution, I walk down the stairs and run into the HR lead on her way back up the stairs. When I explained the solution, she smiled gratefully, saying, "See, now I never would have thought to look for a battery!" "That's what I'm here for," I reply while returning her smile.

With that, I sneak back to my stalagmite-encased desk, type up the resolution, and close the ticket. Sometimes, solving a simple problem can be extremely satisfying—especially when users show gratitude like that.