“CBS randomly mutes itself” Tech Support |
- “CBS randomly mutes itself”
- The New Guy Chronicles - Episode 2: The Betrayal
- A case of impeccable timing
- Never forget to check the basics
- New User Nightmare
| Posted: 30 Aug 2021 10:34 PM PDT In addition to my professional career, I'm the family technician especially to my grandmother's boyfriend. Feels like every time I come here, he's calling me over to help him with something. I come by once a week to do laundry and hang out with my grandmother and tonight was that night. My grandmother's boyfriend, Hank, calls me into the other room where it's super warm, like I'm sweating in seconds of walking in, to ask me for tech support tonight.
I agree rebooting sounds like a good start so I unplug all of the fairly hot cable boxes around the house and leave them unplugged for a good 30 or so minutes while I talk with my grandmother. I come back and plug in everything and they get to watching all these awful shows like Young Sheldon and whatever else was on while I browse Reddit and play mobile games. But I peek my head up every so often and start to notice what Hank was talking about. Randomly throughout commercial breaks, mostly, the sound just goes dead silent. Pretty wonderful to me, but I could understand this was their entertainment. Then I started noticing that throughout all of these shows…there was this really weird narration. I thought it was a strange move by CBS to have so many shows from comedy to drama have this woman in the background describing what's going on in each episode. Maybe their new trademark? Then I started picking up on it during NCIS when it was clearly out of place and realize this is definitely not CBS' doing. I asked Hank for the remote and checked the Accessibility settings and saw someone enabled some setting for narration that was only showing on CBS, not on any other channel we were watching. Disabled that setting and so far over the last few hours, all is good again. This isn't uncommon at my grandmother's house. Someone is always enabling some weird setting on the TV and everyone just puts up with it until I come around. [link] [comments]  |
| The New Guy Chronicles - Episode 2: The Betrayal Posted: 30 Aug 2021 10:33 AM PDT These are the stories of the New Guy. All of what you are about to read is true. I write you these tales of mirth and woe, of entertainment and anger with as much accuracy and as little embellishment as I can manage. Many conversations are written as best I can remember them from my notes and memories about the incidents they describe, but the heart of what you are about to read is as true as I can make it. Names have been changed to protect the innocent. And the guilty. The cast:
DAY 10 - The Betrayal A little over a week has come and gone. Jordan remains steadfast in his attempts to drive me and my other two reports to the brink of insanity. Thus far he has failed a stunningly easy test I devised to assess his problem-solving skills, admitted to underage drinking, attempted to build camaraderie in a conversation with us all by saying "you guys know how hard it is to pull one over on my mom", and argued with me about the importance of locking computers when leaving them unattended. While he was away from his desk performing a task and I was talking idly with John and Daniel, I walked over to inspect the clutter Jordan had already amassed and noticed a password written on a sticky note. Ah, an opportunity to teach an important lesson. I mentioned it to John and Daniel, and then waited. "Jordan, what's wrong with your desk?" I asked upon his return. "Uh, I forgot to lock my computer?" "Well yes, but there's something else." "I don't know," he declared after looking around. "What's on that sticky note?" "Oh! That's the password that Daniel gave me." Daniel, who had been listening to the exchange from his desk, poked his head out from behind his monitors. "I'm sorry, what?" "Yeah," Jordan replied. "It's that [anti-virus] management password you gave me. You told me to write it down so I wouldn't forget it." "I didn't tell you to write any password down." "Yeah, you-" I cut in, stopping the conversation and telling Jordan not to worry about it right then. I again explained the importance of locking unattended computers, and let the issue drop until later in the day when I called him into my office. "Close the door behind you. About that password." "Daniel gave me that password." "I spoke to Daniel and he said he doesn't remember giving you that password and definitely wouldn't have told you to write it down. You're sure?" "Absolutely. That's not like me." Intent on giving Jordan every opportunity to come clean I tried again. "Like I said, I talked to Daniel and he's certain that he didn't give you that password. I have to agree; it wouldn't be like him to tell you or anyone to write down a password." "I'm positive he gave it to me and told me to write it down so I wouldn't forget." "You're sure?" "Yes." deep sigh "Jordan, I know for a fact that Daniel didn't give you that password." "What do you mean?" "I gave you that password. In an email, which also explained that you should change it when you log in the first time." "Oh." "Listen, Jordan. I've known the whole time what was up and I've been trying to give you the chance to be honest, but you chose right from the start to throw Daniel straight under the bus. That's not the way to build a good working relationship with your coworkers. If you keep that up no one is ever going to trust you." "OK." The conversation ended. No apology, no remorse, no assurances it wouldn't happen again. I reported this chain of events to my director, knowing that such a claim of dishonesty on the part of the HR director's son would best be handled between the two directors. My cries would fall upon deaf ears. The chronicles would continue. [link] [comments]  |
| Posted: 30 Aug 2021 12:31 PM PDT I'm a full stack web dev, mostly working on developing and maintaining eCommerce sites using my company's in-house platform. We do support and maintenance as well as new sites and features, but aren't expected to support end users directly. However we occasionally (or in the case of the site that features in this story, not so rarely) get end user issues forwarded to us if the client's helpdesk can't fix it. This particular site is healthcare-adjacent. I'm not in the US so HIPAA doesn't apply but data security is still a particularly big deal for this site compared to some of our other clients - and security of customer data is a big deal for everyone these days. In the far-off days before the pandemic, I'd been working for months on a Major New Feature that allowed customers to use the site in a different way than before. It touched almost every part of the site and presented some fairly unique problems. We had to request a new feature be added to the in-house platform just for this, which necessitated deferring the Major New Feature's completion until after a separate project to migrate the site through a major version of the platform. Finally, everything is completed, tested, and signed off. The big release goes fairly smoothly, the Major New Feature appears to be working, and we pat ourselves on the back and relax. Cut to shortly after we get in the following morning A customer who placed a single order is receiving dozens, no, hundreds of order confirmation emails. He provides a screenshot of his flooded inbox. Virtually all eCommerce sites have transactional emails - and this has more than many, along with optional text message notifications. One of the implications of the Major New Feature is that it's no longer completely trivial to decide who should be notified by what method about updates to a given order or account. I've written a nice new piece of code that abstracts away all this decision making into one place. Obviously, I've got something terribly wrong. Are we sending every email update to the same person, this guy? Worse*, are we sending every update to everyone, and this guy is just the first to report it? Either way, it sounds like a significant data security breach, on the site that I would least like to have a data breach on, and it's definitely my fault. It's panic stations. I start looking frantically at my new code and the database, while our senior dev gets into the logs. I've just found the mildly reassuring information that the number of emails the customer appears to have received doesn't match up with orders taken since the release of the Major New Feature, when the senior reports that the order confirmation page for this customer's single order is being requested ten times a minute. He's refreshing the page ten times a minute. For an hour. We assume that it's some kind of browser extension or something. A quick proof of concept confirms that you can indeed generate multiple confirmation emails by refreshing that page. Which I hasten to add is not ok, and we immediately put a ticket in to fix it. But this bug appears to have been in the site for years, since before I joined the company. Of all the days for it to come to light... *Actually, that probably wouldn't be much worse, because at that time we had another issue in the system that would have caused nearly all emails to fail to send in that case. [link] [comments]  |
| Never forget to check the basics Posted: 30 Aug 2021 05:27 AM PDT I work for a company that provides a cloud communications platform as a service — developers can use our web service APIs to do a lot of neato stuff. I'm a tier 3 technical support engineer/developer — usually when a ticket makes it to our queue, advanced troubleshooting is needed. I suppose that's how sometimes the team forgets to check off the basics of troubleshooting, and something like this goes over our heads. Got a user who couldn't get our programmable chat API to work. By the time I got the ticket, two of my team members had already done some troubleshooting which included verifying and updating their SDKs, combing through our backend logs, and attempting to debug a snippet of their code. So far, no luck. I'm reading through the ticket history and one of the very first replies we got from this user was that everything had been working prior to their account being suspended. Now, I re-route a lot of account suspended tickets — I know that it happens a lot and usually account administration handles it without any fuss. It was totally fair to assume that they had gone through that team already and taken care of that puzzle piece. I did think it was odd however that neither of my team members had responded to that bit of information or referenced it again. My brain starts churning the gears — what exactly happens to our API keys when an account is suspended? It makes sense to me that they would become invalid, which would prevent future attempts to generate access tokens or to use our API services. I run this by the team and, with none of us having tried it before, get the suggestion to suspend+reactivate my own test account and see for myself. Cool. We have a game plan! I start opening some browser tabs, pulling up my own account info as well as the users so that I had everything I needed … Right there. At the top. In huge, bold letters. 'ACCOUNT SUSPENDED' Welp. Mr. Owl, how many developers does it take to notice that an account is inactive? The world does know, unfortunately, and the answer is embarrassing LOL [link] [comments]  |
| Posted: 30 Aug 2021 08:15 AM PDT Hello all, it has been some time since my last post on here. Since that last post I have left the service desk job that I had and thought my time at the help desk was over. However much like an ex texting you at 3 in the morning, you can't help but get pulled back in. This particular day was my first real day out of training, and it should've been a fairly easy day being a Friday and all. However, the IT gods above did not seem to want to give me an easy day. Thus began a multiple call saga, that spilt over into today. So sit back, relax, and enjoy my suffering. The characters in this story are: Me: Your storyteller for the moment, and the hero of this anime. New User: My eternal rival, and the best/worst part of my day. As our story begins I am just logging in for the day, and within a minute or so I get a call.
Now before we go any further I should explain something. When a user is sent a computer we send them a fairly in depth list of instructions on setting up their device. These instructions are, in my opinion, very easy to follow with one or two issues that most users have. They are so easy in fact that the only thing that would make them easier is if they included pictures. With that little info dump out of the way lets continue.
From this point the call goes on and I get his password reset and in the instructions it says that an initial password reset can take at least 30 minutes so the user says he'll call back in 30 minutes to continue setup. 15 minutes later... I receive another call from who else but New User.
The call gets disconnected and this would be another good time to provide some information. The reason I didn't continue to help is because the "at least 30 minutes" isn't an exaggeration, 30 minutes is the quickest that the password will synchronize for first time users in our system. Not sure why though, but that's just how it is. Back to the story again though. 15 more minutes later... Of course the guy calls in again, and at this point I just recognize the number.
The user then proceeds to basically tell me his life story, culminating in a summary of his issue. A very incorrect summary mind you, but still a summary nonetheless. I work with him for the next 45 MINUTES!! On something that the users are expected to do by themselves mind you. Getting a number of questions that would be answered if the guy actually read the instructions that were given to him. I finally manage to talk him into working through it himself, and he agrees stating that he'll call back if he has any other issues. I end the call and pray to any god that will listen that I don't have to deal with him again. Later that day he does callback, and is very promptly taken care of by a coworker. I was hoping this would be the end of my interactions with him, at least until some point far down the line... Today has unfortunately rained on that parade. I'm just going to give you the cliff notes of this call, as I don't want to transpose it. He called back in because only the default password was letting him sign into his computer, the new password he created wasn't working. His new password would work when in the computer however, this was caused by him not locking and unlocking his computer while on VPN. This was odd to me, since, you guessed it, a step in the setup for the computer! When I mentioned this he of course got defensive because, and I quote "I followed them steps on the paper". Luckily the call didn't last that long and I, hopefully, won't have to deal with this guy for a nice loooooong while. I hope you all enjoyed my little story. [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