It's official, the end users are now asking for straight up magic Tech Support |
- It's official, the end users are now asking for straight up magic
- Accidentally causing "screen damage" to every device on campus.
- Customer brings backup. Backup backs the F up.
- It's not network-related.
- "The weather this weekend is going to be hot and humid."
- Psychic software
- Calls forward to voicemail after three rings
- Finally went OfficeSpace on a desk phone
- I don't want to do that.....
| It's official, the end users are now asking for straight up magic Posted: 30 Aug 2019 10:56 AM PDT I run a small VoIP company, so most of my day is spent working on systems, with the occasional support request, usually via tickets/email. Everything is pretty easy to use, so it's rare to get questions like this. But one day, a user asks me how to set up a conference. I can't post links/images here, but I'd love to show you the big bold letters that say "Schedule Conference" right on the end user's screen. So I send screen shots and a how-to. Then she replies with: "I don't have everyone's emails or phone numbers (and due to vacations I will not be able to get them before the call) - is there a way to give send them a number to call?" That's right, she wants to know if we can notify people of an event, without knowing the person's phone number or email address. [link] [comments]  |
| Accidentally causing "screen damage" to every device on campus. Posted: 30 Aug 2019 01:59 PM PDT I work in the Walk-In area of my University's Tech Support Center. Today I was watching the support requests and saw that multiple people were coming in with the same issue, at the same time. They were all "Blue line on screen". I walked out to the lobby and asked the front desk what was going on. He told me that all these laptops have a line going down the side of the screen. There were about 5 people in the lobby with the same issue, so I took them all back. It looked just like an LCD issue. A 1 pixel wide blue line going down the side of the screen. I tried restarting the computer, and the line went away, but it quickly came back upon rebooting. At this point, I knew it was a bigger software issue, So I went to the Device Administration Office. As I was walking over there, I could see a line of people going out the door, and the techs in phones were getting a bunch of calls. I showed him the laptop and asked him if he knew what it was. He said it looks like the screen was damaged. I said "Yeah it does, but there's 20 people waiting in the lobby with the same issue" He kind of freaked out for a second, but he quickly knew what was causing it. There was a program on all the University devices that is used to notify students and staff of safety issues, fires, weather, etc. It's brand new and has never been used before. The security department had just sent out a test message. That meant that all 10,000+ devices on campus now looked like the screen was broken. He quickly called the IT Security Officer. The Security Officer said they just sent out a test, but didn't notice anything wrong. We had to tell him that every device on campus has a blue line on it now because of that program. The Security Officer was able to revert the alert and resolve the issue. For the next few hours, we had to tell people to restart their computers to make the blue line go away. [link] [comments]  |
| Customer brings backup. Backup backs the F up. Posted: 30 Aug 2019 03:36 PM PDT Context: I work for a computer sales/repair store in my local area. As of the last couple of years we have also been offering repairs on most major phones like iPhones, Samsungs and more recently Huawei. Characters: M: Manager C: Customer CF: Customers Friend (I am not a character in this story as i merely observed from the back of the store) When we book in a phone for repair we ask the customer to provide us with their password so that once the repair is complete we can ensure things like the camera and spearkers are in working order. If they dont want to provide the password thats fine, we just have them sign in upon collection to let us test. This particular customer was happy to give us the password when he left his phone with us. There starts the tale. So, earlier on an average Tuesday shift we had repaired a customers iPhone screen (7 iirc) and they had since collected and paid for it. A few hours later, the customer, a lad of about 17 i would guess, comes back in to the shop, this time accompanied by a female friend. My manager recognises the customer. M: "Hi, is everything OK with the phone?" C: "Actually, i am having an issue with unlocking my phone, i am entering my password but its keeps saying its incorrect, now its locked for 15 minutes" As soon as the customer finishes his sentence, it happens. The female friend (Also about 17) slams her palms onto the counter and snarls at my manager. CF: "It's because you've changed the f---ing password!" Total silence while my manager takes in what she has just said, then he addresses the boy. M: "It is likely that you are just entering the password wrong, but if you have all of the details we can help you reset your phone if you are certain you are entering the password correctly. Also, we would never change your password, we have no reason to, we only use it to ensure the work is completed correctly and it is not worth our reputation as a business to misuse your information" My manager then turns to the girl. M: "As for you......YOU CAN GET THE F OUT OF MY SHOP RIGHT NOW!" The girl looks so stunned i think she might be about to break into tears. CF: "You cant speak to me like that i'm only 17!" M: "Just did....BYE!" The girl, clearly out of her depth actually just turns around and leaves. The boy scoops up his phone and quickly follows, apparently forgetting about his problem. We then hear the girl talking about how my manger is "Lucky i dont spark his lights out right now". All of the staff burst out laughing. The next day the boy returns, this time with his grandfather. We then learnt that the boy HAD infact been entering his passcode wrong and that the phone was fully functional. However the grandfather was here to complain about how we had spoken to his grandson and his friend. Young lad looked pretty smug until my manager explained the situation from the previous day. Immediate 180 from the old guy, apologised for his grandsons behaviour and assured us the girls parents would be notified of her actions as well. My manager assures him its no problem and he bears no ill will. Grandfather and Grandson leave the shop together, Grandfather wearing the face of a man about to explode and the Grandson wearing the face of a boy who knows that explosion is going to be directed at him. Final Note: Been a lurker here a while and finally decided to post. I dont post much on other subs either so sorry for any formatting issues, spelling etc. [link] [comments]  |
| Posted: 30 Aug 2019 05:29 PM PDT So my company deals with web software, you can install it on a VM or HyperV or Azure or whatever. Customer calls in, "Hey, we can't get to the server. The website is down." I check. Website is up, but a bit slow. Me: "Huh, looks like it's still up for me. Maybe this is a local problem. Can you get to other websites?" Them: "No it's the server, it's down. No one else in the office can get there". I was working from home, so I use my work laptop to VPN into the office and check through that. Sure enough, no website comes up. Me: "Huh, this seems like a weird network problem. You should talk to your network guys and see if they can resolve this. I'll keep the ticket open.." blah blah blah 30 minutes later, the call in, they have an Azure dude (they're hosted in Azure), a network dude, and the administrator. Them: "It's not network related. I get a login prompt when I SSH to the server. That means it's not network related" I check some things out, and so do they. We determine that it's a 50/50 shot of the website being able to load, but if it doesn't load on a specific machine, it's consistent. Unless they change the network the machine is on, it will consistently either not load, or consistently load. So, obviously, this is pretty weird, but I can't imagine any universe where it is the server. Eventually, they find a server within the network, and I ask them to load the admin interface to see resource usage. Surprisingly, they can. Everything is running. All the services are go. The CPU usage is nominal. Ram is fine. Storage is running low, so they add half a terabyte in Azure. Other than that, it's fine. Me: "So this is really looking like a network issue" Them: "This is 100 percent NOT a network issue! Yell scream scream!" I try to ask probing questions to figure out how they think it could be a server issue (I don't fix networks, I fix servers, the customers network is none of my business). They're evasive. They mention F5 load balancers but assure me "It's not that". They think it could be NTP, and try to debug the NTP server in their domain until I point out that the server uses pool.ntp.org and that the time is correct. They troubleshoot everything except the network. I try to zone out of the situation and work on something else while still on the phone with them, but they keep trying to wrap me back in even after it's pretty much 10,000 percent confirmed it was the network. They demand I get into the backend and poke around. Services are fine. Everything is fine. Server is fine. I hand it over to the later crew, even though this is definitely not our problem, but keep an eye on chat just because I'm curious how this goes. At the end of it all: 1: They are using the company's static IP as the a-record for the domain 2: Requests made to the static IP are NAT'd to Azure 3: They get there through a VPN Apart from this being absolutely mind-blowingly stupid, it actually worked, but before it did, you know what ended up fixing it for them? They re-started their OTHER firewall. There were over 5 hours logged in that call when I was already pretty sure what the problem was in the first 5 minutes. [link] [comments]  |
| "The weather this weekend is going to be hot and humid." Posted: 30 Aug 2019 12:57 PM PDT I'm not sure where this tale belongs, but since it happened during my tech support days, it may as well go here. Also, my original submission was rejected due to content, so I've had to disguise some of the content of this post. So, if you can figure out what 890 + 10 means when it is an area code in the United States... well, let's just pretend that's reserved for calling <Weather Services>. No TLDR because I think this story is worth the read. This took place in the early 90s, and I was the head of a two-person computer department. The company was a boutique management consulting firm with many of our clients being the middle management and C-suite executives for a considerable number of the Fortune 500 firms. We had a decent computer system setup in those days. A bevy of Macs for the graphics department making the presentation slides for the consultants, and 8-10 PCs in a dedicated room for number crunching. This was a few years before a Cat-5 run to each desk was commonplace, so a central computer room was pretty much the norm for a professional services firm. While my primary responsibilities were for the PCs and my #2 (hereafter MacDude) was responsible for the Macs, there was one system that was largely left to its own devices with minimal intervention; the AT&T Unix-based PBX in the phone closet. We had about 75-100 people in that location and had acquired the system when moving into that space. I'm pretty sure it was leased, as that's how AT&T worked back then, but billing was never my strong suit, so I didn't pay much attention to such details. Whenever I got an email telling me an AT&T tech was coming in to perform an upgrade or some such, I'd meet them in reception and walk them over to the phone closet and let them do their thing. Once or twice we'd had some urgent issues, and I had called AT&T tech support and they'd walked me through logging in at the console and checking some stuff, so at least I knew the customer admin password and could login if needed. So one day I'm sitting at my desk, probably programming HyperCard to update the phone directory, when our Comptroller Guy (Compie) walks in holding that month's phone bill. "Hey Jack, do you know anything about the phone system?" "I know how to make a call and answer a call. What would you need beyond that?" "Funny. Can you tell me who made a specific phone call?" "Maybe. The PBX has a console and I can probably figure something out. Let's go take a look." So, we wander over to the phone closet and I log in. I spend a few minutes exploring menus and eventually find the reporting system. It's actually pretty straight-forward, and I take the number from Compie and enter it into the search field. "Yeah, it looks like it was called about 12 times from these three extensions." "Whose extensions are those?" "Let's see... looks like Conference Rooms 6, 8 and 11." "So there's no way to to tell who called that number?" "Not unless there are video cameras that I don't know about." "Okay... thanks." "Why are you asking?" "I can't tell you." Even as early as that in my career, I knew when not to pry. "Okay, let me know if you need anything else." I think two or three months went by before Compie was back at my desk. "Hey, Jack; can we go look at the call log again?" "Sure, which number this time?" "Same one and two others." He gave them to me and back we went. "Looks like a total of 43 times in the past three months." "Damn it. What the hell?!" I looked at Compie. Normally a pretty laid back guy, he was genuinely upset. "What's going on?" "Let me go ask Dave if I can tell you. I'll be right back." Dave was the president (and one of four founders) of the firm and my boss. If he was involved and making Compie keep it quiet, there was something serious going on. Five minutes later, Compie comes back, closes us into the phone closet and tells me to dial one of the numbers on speakerphone. "<Hey there, are you making plans for the weekend? Well, I can't wait to tell you just how hot the weather is going to be.>" As the intro spiel goes on, I look up at Compie with my jaw gaping open. "Someone's calling a <Weather Service>? We have a block on <WS> numbers." "But it's not a <WS> number in the US; it's somewhere in the Caribbean." Compie shows me the phone bill. Sure enough, the call detail listed the various call destinations as being in Costa Rica, Honduras and, if I recall correctly, the Dominican Republic. "Huh." "He's been doing it for three months now." "And charging it to the firm?" "No, the calls are only for a minute, and that's how long their introduction is. It's the long distance charges that are starting to pile up." Sure enough, the call detail log showed that all calls to a specific number were all the same duration, roughly a minute. "Dave wants this person tracked down. Can you do it?" "Yeah, sure. Give me a bit to look up all the source extensions." But every single one was from a conference room (except for a few from Compie's line obviously). This guy knew to cover his tracks. Reluctantly I told Compie no luck. This went on for months. Every month Compie would bring me the new phone bill log so that I could note the new numbers being used. The guy started out fairly modestly (compared to later), but as time went on, he seemed to get emboldened by his getting away with it. The calls became more frequent, and he got to the point where he would hang up and call the same <Weather Service> multiple times in a row. I think his record was one number 15 times in a row. And there was no pattern to it, other than always being from a conference room phone. Not once did he slip up and call one of the numbers from his desk phone. Another thing that puzzled us was that there would be days where dozens of calls were made, but none on the next day or the day before. It seemed totally random. It took so long to find out who he was that we discovered that the PBX only stored a month or two of log data (hard drives were expensive back then), so I had to figure out how to export the records to a floppy disk and save them on my computer. I used FileMaker Pro to store the data and later used it to analyze the records.* After nine months of this, Dave was not happy. One of the few times we discussed it he told me his biggest concern. "Jack, if I knew this was absolutely confined to calls made from this office, I'd be less concerned. But I am going to be pissed if this is a consultant and he's making these calls at the client. The last thing I need is a CEO asking me why my consultants are calling <Weather Services> from his office." "The days when there aren't any calls made here; I hadn't thought of that." "That was the first thing that occured to me when I saw those gaps." There was a reason he was the boss. "Okay Boss, we'll figure it out." And we did. Once the light bulb went off for how we would catch him. If he never called a <Weather Service> from his desk, maybe we could tie him to calling a different number that no one else in the firm ever called. And that was how we caught him. One thing we knew about conference rooms is that they were in short supply and it was not uncommon for calls to run over and the next person/team to be knocking on the glass wall pointing at their watch(es) to indicate to the occupants that their time slot was up and they needed to vacate the room for the next team to use it. We actually watched and timed multiples times how long it took for a call to end and the people inside to pack up and leave and the next call to start. We settled on a maximum gap between calls of 8 seconds. Any longer than that, we couldn't assume the call was made by the same person. While this methodology certainly cast our net wider, all the numbers that we could positively tie to having been dialed by the same guy were either client main numbers or local businesses, etc., that were also called from many personal desk phones throughout the firm. We were beginning to think he would never slip up. But, like all bad guys, he eventually did. I think it was a year after Compie first came to me that we hit paydirt. Two calls to a local <meteorologist's clothing store> with a <humid> message on the answering machine in the same month, one from a conference room tied to a <Weather Service> call, and one from a personal desk line. Once we had a suspect, we knew what we had to do, as we had spent a good amount of time over the months brainstorming how to verify who the culprit was. I would try to visually verify that this guy was in a conference room while a <Weather Service> call was being made. If I recall correctly, I could flag a number and have the system send a notification to me once a call to a specific number had ended. But I think I was limited to a set number of numbers to monitor, so I was guessing if he would stick to the current crop of numbers or being trying out new ones this month. I would get a notification, run to the phone closet, run the search to figure out the conference room, run to the conference room to see who was in there, and then run back to verify another <Weather Service> was called during my running around. It took me a week to visually verify that it was the guy we thought it was. MacDude, a really laid back guy and very non-confrontational decided that he would try to prove innocence, because he didn't want it to become a witch hunt. He went to Compie and requested all the guy's timesheets, trying to see if any call was ever made while when the guy had in his timesheets that he was at a client. Ironically, this was the nail in the coffin for the guy. The timesheets and the call logs lined up perfectly. Not once was a <Weather Service> line called when the guy was at the client. It turned out we both finished on the same day. We compared notes, agreed we were right, and went to Dave's office. "Hi Dave, thanks for seeing us on such short notice. We know who it is; it's GQ**. We can walk you through the proof if you want." "Are you absolutely sure?" "No question. It's GQ." "Okay, I'll handle it from here. Tell no one about this." And that was it. About three or four weeks later, that standard exit email went out from GQ: "Thanks for the memories and good luck in your future". It seemed that GQ had decided it was time to move on to greener pastures and was taking a position with a different company in one of Boston's suburbs. But, man, I wish I had been able to be a fly on the wall when Dave confronted GQ. As Dave was ex-military, it would have been an epic dressing down. -=-=- * God I miss FileMaker Pro; what a great little personal database app. ** Why did i use GQ? This was also one of the big puzzlers to us. GQ was just that; a guy who could very well have been on the cover of GQ. Very attractive, one of the sharpest dressers I've ever known (French cuffs/cuff links and matching collar pin every day, the primary shirt color matching tie and pin-striping, the whole ensemble clearly from a high-end men's fashion shop), hair and beard meticulously maintained, a genuinely good guy who never treated the support staff badly. And he was literally married to a <meterologist>. A smoking-hot, regionally-known <meterologist>. Yet he was compelled, obsessively so, to call these <Weather Service> lines. I haven't checked on him in years. I hope he found help and ended up in a good place. [link] [comments]  |
| Posted: 30 Aug 2019 02:50 PM PDT I work in a financial services company, where we write custom software for vehicle loan/lease origination. There are in-house customer support reps, who deal directly with the end users (auto dealers). When they find a problem in the software they enter a ticket and here is where I come in. ------------------------------------- TS == Ticket from user in customer support. TS : (paraphrased) Dealer called to say that the sales tax was incorrect, and it wasn't letting them enter a different amount (it was zero). Me: I open the application, and look at the customer address, and they are in Oregon. I google "sales tax in Oregon" to get a clue as to why it might be zero, and it says there is zero sales tax (go Oregon!). I reply to the ticket saying that they are in a state where it's zero, and it's not supposed to be editable. TS: But the customer lives in New Mexico! It's not zero in New Mexico, I looked it up. Me: .... The address entered is in Oregon. If they enter an address in New Mexico, it'll calculate the tax for New Mexico. TS: Well, their address is in Oregon, but they LIVE (they capitalized it) in New Mexico! Me: ... There are two options, change the address to one in New Mexico, or move forward with the Oregon address with the appropriate sales tax. ------------------------------------- I get that the customer support reps get frazzled if they get in irate dealer on the line, but as hard as I try, I have yet to make my software psychic. The ticket is still open, just "waiting for customer" as they stopped responding. Most likely will close today as "won't do". [link] [comments]  |
| Calls forward to voicemail after three rings Posted: 30 Aug 2019 08:27 PM PDT Your intrepid contract field service tech goes out for another service call today. Issue: "restore primary internet connection". It's 100 miles from home at a restaurant in a major US city. That turns out to be simple. The broadband provider Ethernet cable is unplugged from the modem. But it's complicated by the fact that our MSP (my customer) hasn't recorded that we updated the solution on site a few months from a brand "C" router and VoIP provider #1 to a brand "F" UTM device and switch and VoIP provider #2's service/equipment. That eventually gets sorted out (I sent the support line a photo to prove that the new equipment was there). The manager mentioned that since the phones were replaced, they don't have time to pick up before it stops ringing. The phones are a VoIP DECT system. One base station, up to four handsets. Site is configured with a main number that has an auto-attendant that is supposed to transfer to a busy message or some such if they're too busy to answer after nine rings, but it isn't going anywhere near that long. It turns out that the base station has its own internal logic for call handling. The base station was provisioned with a "call forward no answer" rule and timeout of 18 seconds, which was just about enough to emit three rings before forwarding to VM using its internal rule. We adjusted that to the max of 120 seconds, so the auto-attendant's rule prevails. I would argue that 40 or so seconds still isn't long enough, but it's twice what they were getting. [link] [comments]  |
| Finally went OfficeSpace on a desk phone Posted: 30 Aug 2019 09:44 PM PDT Not exactly a proud moment but it doesn't mean I won't post it. I WFH and take calls and help people w tech things (hance the general description and using a throw away cuz I still need money). On and off Customer Service and IT support since 2000. I can usually only last around 2 years before I crack dealing w problems all day even w not "taking it home" at night. It's time to get a new job again : Call #1 of the day: customer wants to do something in latest version of a product that is a normal function just slightly different than the previous version, it is not hard to learn at all. I explain him calmly 4 times he just doesn't get it. I show him even w a remote session super nice about it. This 22ish sounding kid (in my opinion) keeps pushing my buttons by re asking the same thing because he doesn't know how to retain information. I say hang on a sec, mute my phone, start the fist pounding on my stupid voipdeamon, I think about 6 times total the stand breaks , but I almost give myself a boxer fracture. Took rest of the day off. Keep anger thoughts just that , don't hit stuff that shouldn't be hit. I should take a boxing class. Thanks for reading and letting me vent. Happy Labor Day Weekend.? [link] [comments]  |
| Posted: 30 Aug 2019 06:22 AM PDT TL;DR Developer with a little knowledge of sysadmin wanted me to clone another machine to fix a problem instead of adding code that would give me the information needed to fix the problem. Back story: I was a Windows programmer in the days of "n-tier" and "R.A.D." I did Java/DB and VB/DB work. I hated it so I became a Linux sysadmin instead. I've been a Linux sysadmin now for about 20 years. Now I'm a Senior Linux sysadmin for an unnamed contracting company in an unnamed city. One of my jobs is to help developers diagnose problems with their applications. On one of the teams the lead is a very quiet, very polite lady that does Java/Tomcat development. One day she comes to me after an application stops accepting uploads. Me: Ok, I'll tail the logs, you try the upload. Dev: [does so] Me: Ok, I see the error, but it is really vague. (It's just a generic java error about a particular module) Dev: Well, you can see it doing the same thing on my local. (English is not her first language.) Me: I understand, but that is the same error. I need more information before I can troubleshoot the error. Not to mention that your laptop is a Windows 10 machine and the QA server is a Linux box. (I wish the company would get the developers to do their development work on a Linux machine, but I suppose that would mean training them and having to support it, but on the other hand....) Dev: But its the same error on my local. Me: I know, but before I can diagnose, I need more information. Try adding a statement to do this. [I describe the idea] Dev: [makes some minor changes that are not what I suggested and runs it on her laptop] See, there is the problem! Me: Again, this is a Windows laptop and the server is a Linux box. I *need* more specific information from the Linux box itself, not your Windows laptop. Please, add the appropriate logging code. Dev: Um.... I don't want to do that because it will generate a Jira ticket. Me: (Internal Facepalm) Um... Ok, but I can't diagnose it without more detailed information. ( She doesn't want to do the work to fix the problem because it will generate a ticket in the ticketing system that tracks bug fixes and new feature development.... huh? ) Dev: Can you check the permissions? (Often, the problem is just a simple permissions issue. The developers know this, and it's their first line of questioning when something breaks. However, I have already done this.) Me: I checked the permissions before you came over. They are what they are supposed to be. Dev: Could you check again? Me: Sure. (Internal eyeroll. I do the appropriate commands to set the permissions in full view of the developer, and kindly and patiently show her the results. I check SELinux just to be sure. It's in permissive mode.) Dev: Ok, Let me try...... No... still broken. Me: As a test, I'll run the application as root. (This is a bad idea, but it will prove the permissions aren't the problem) Dev: I'll try.... no... still broken. Me: Well, it's not a permissions issue. The application is running as root. Dev: But it's not working. Me: I understand, but root has access to *everything.* It's not a permissions issue. Dev: Can you check the permissions again? Me: The permissions aren't the issue. They were correct before we started and now the application is running as root. Dev: Well, can you clone the staging machine, which is working? Me: (Internal Facepalm!!! At one point we had a problem with a server and after checking everything to the smallest detail, like settings for each application, permissions, boot settings, a partridge in a pear tree and also checking the settings between the broken machine and the working staging machine. we solved it by cloning the working staging machine. I wish the developers didn't know we could do this! ) Me: Um, no. The SAN that holds the VM Image is nearly full. There isn't enough space. Dev: Well, it's this on my local. Me: I understand, but that is a Windows box, and I need to see more detailed information........... After going round and round like this for a couple more minutes, she leaves, defeated. I haven't heard back from her. I don't know what the resolution was. Since the problem affected one of the core functions of their application, it would be a major problem for them to not be able to test it. I would be very surprised if they left it broken. I can only assume that they found that it was a code problem and fixed it and didn't tell me. Also, if they had gone to my boss and he fixed it, I would have heard about it. What frustrates me most is that I don't come to their desks and dictate code to them. I *barely ever* suggest anything like logging code. Ugh.... [link] [comments]  |
| You are subscribed to email updates from Tales From Tech Support. To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
| Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States | |
No comments:
Post a Comment