• Security incident: ISF was recently accessed by intruders. Please change your password, and change it anywhere else you used it. Read more

Dear Users... (A thread for Sysadmin, Technical Support, and Help Desk people)

Status
Not open for further replies.
"I just got a quick question about my setup when I connect from home using my laptop. The remote connection seems to keep the sides of the screens as I was working from my office but I need that the side of the screen just get what is available in my laptop – double click the top of the screen I am working on seems that doesn’t work.

Appreciated your suggestions,

Cheers"

I have absolutely no idea what this person is asking.

Maybe meant 'size' rather than 'side'? They want the remote session to use the laptop screen resolution as the maximum screen size, not scroll around the larger screen of the remote system?

That would be my guess, and it's pretty easy to do with mstsc, and probably Citrix (I haven't use Citrix enough to be familiar with its settings.) Then again, that's a message that makes you wonder how the sender ever manages to communicate anything to anybody in writing.
 
How is it in 2018 people don't understand that their monitor isn't their PC and vice versa?

Okay so to over simplify it somewhat the health care company I contract out to for IT support has two types of workstations in general use for their office, personnel, human resources, insurance, claims and billing and other general admin type workers. HP Small Form Factors (Elite Desk 800s mostly) and HP Thin Clients (T520s mostly).

Most of the worker bees get the Thin Clients because literally all their work is done in the company's web portal or various insurance and medical websites so all they need is a functioning web browser and very basic office and productivity software (MS Office, Adobe and.... and... hell that might actually be it) and the thin clients are substantially cheaper with lower overhead.

But... 10-20% abouts of the general admin/office workers for some reason or another, usually support of older legacy software, need to us a specialized piece of equipment (various scanners and mail postage scales and assorted other frippery), or other reasons require a full PC.

All pretty bog standard.

Anywho this one lady was getting moved from one position to another and in the process was being upgraded from a Thin Client PC to a full workstation.

It took me a legit hour to convince her that she could still keep her big dual monitor setup before she would let me swap out the machine. And again this is replacing her thin client with a full PC that would have all the capability plus some of her original machine.
Part of it is our fault, because we steadfastly refuse to refer to the computer as the "hard drive". As far as some people are concerned they have a computer, and they have a hard drive.

It's even worse, because a lot of our staff now have a DTA laptop, a docking station, and external monitors. Some of them still insist that they have a laptop and a computer. The screens attach to the computer, and they plug the laptop into the computer. They don't have a hard drive.

Yes, I've had this conversation. Several times.
 
Cue User: "Screen shot? How do I do that? I'm not a computer person I don't understand all these techie terms..."
Easy: take a picture of your screen with your smartphone, and send the picture via whatsapp to yours truly.
 
Easy: take a picture of your screen with your smartphone, and send the picture via whatsapp to yours truly.

I’ve certainly had that in trouble reports (and sometimes it was the only way to get a screenshot of the boot screen on a server in a data centre).
 
Did my Post Grad Dip in CS in 83/4 so another old fart here. I've used Jackson structured programming, cleanroom, "it'll be fine in a few more 30-hour debugging sessions" etc and Agile really is the best. The problem is that like other paradigms someone reads a half-assed description which they misunderstand half of and then work with and/or criticize that.
We had to take ages to train our PM as he was old-school. He protested that what we were doing allowed users to sneak in new requirements. And we said yes and if they are needed we can fit them in the workstream. You run in short "sprints" where you have clearly defined achievable deliverables. It assumes a higher standard of programmer - not just someone who churns specs into code. I sometimes make the analogy like the difference between an old-fashioned infantryman with no idea of the big picture standing in line and doing what he NCO tells him and modern elite doctrine where every trooper knows the goal, understands his teams role, and improvise and adapt to changing circumstances in pursuit of the main goal. In contrast I remember meetings in IBM where developers were shocked to find what their code was used for.

One of the things you'd hear me saying on a regular basis working in a big banks mainframe world "So let me get your bug report straight. Your application worked. We changed nothing. You did a new release. Your application stopped working and you don't know why but somehow it's my fault?"
One interesting thing I noticed. Almost never did you see a competent guy working in a team of numpties. You'd find whole areas where nobody had a clue. How anything got done in some areas baffled me.
In IBM terms, this was called the "Mongolian Hordes" programming method. Every low-level dimwit programmer did just one tiny module in isolation, and was supposed to make it perfect and unbreakable. A "smarter, higher" programmer then used these tiny modules to build more complex components. And the top level smarty-pants assembled these components into application-specific programs.

All fine...until one or two of the multitudinous tiny sub-sub-modules used "everywhere" was found to be less than perfect and was bug-fixed, or was changed to do something else slightly different. Then the house of cards collapsed!
 
USER: Please create the path, "PathName" in Service.

ME: Please confirm you want "PathName" and not "pathname".

USER: Is there a convention I should follow? If not, I'd like "PathName", please.

ME: No convention, but Service path names are case sensitive... Ok, I've created "PathName" and given you permissions to put stuff there.

[Time passes.]

USER: I keep getting a permissions error when I try to store stuff at "pathname". Please make sure you did your job right.

ME: ...
 
USER: Please create the path, "PathName" in Service.

ME: Please confirm you want "PathName" and not "pathname".

USER: Is there a convention I should follow? If not, I'd like "PathName", please.

ME: No convention, but Service path names are case sensitive... Ok, I've created "PathName" and given you permissions to put stuff there.

[Time passes.]

USER: I keep getting a permissions error when I try to store stuff at "pathname". Please make sure you did your job right.

ME: ...
ME: Would you like me to spellcheck your emails before you send them to me?
 
Dear users.

I'm not sure how this concept is so difficult for you to understand but I can't work or fix an issue when I'm standing in front of you listening to you complain about an issue not being fixed yet.

The more people who feel the need to walk up to me to "vent" about the issue, the less time I'm working on the issue.

I'm IT Support, not IT Therapist. I'm not going to sit you on a couch and ask you how the e-mail server being offline makes you feel.
 
Oh god and the people who have to tell you the whole ******* back story about how without the thing fixed they can't do this thing that is apparently important to them and they tell you what they saw 10 times and what they think the problem is 6 times and what their manager is going to say 8 times and how they wore an onion in their belt because that was the style in those days.
 
Oh god and the people who have to tell you the whole ******* back story about how without the thing fixed they can't do this thing that is apparently important to them and they tell you what they saw 10 times and what they think the problem is 6 times and what their manager is going to say 8 times and how they wore an onion in their belt because that was the style in those days.

Oh god. Thank you...you just undid years of memory repression.

I had one project I worked on, where every time there was an issue, the project lead would go over the entire history of the project, from the beginning, to build up to the current situation. EVERY time. And the project started about 3 years before I was assigned to it. It was like a 45-minute rant that happened EVERY TIME there was any issue, and if she wasn't satisfied when I couldn't immediately do whatever impossible thing she asked she would send the full story to my manager to complain.

I HATED that project.

Luckily, it got moved to another team during our re-org. So, aside from the odd twitch, the trauma is containable now that you've brought it back.
 
Actual event I just had to deal with:

User: All of a sudden I can't print.
Me: Okay let me take a look at it. Okay there's... *pause. Hard blink. Read it again* 78 jobs stuck in the print queue.
User: Print queue?
Me: Errr... stuck at the printer (not about to try and explain what a print server is and how it works at this point.)
User: What does that mean?
Me: It means something's probably wrong at the printer. Where do you print to?
User: Admin Printer at the front desk.
Me: Gotcha be right back.
*As soon as I step into front desk area I am alerted to an odd insensate beeping from a particular printer shape object.
*Looks at Printer* "UNEXPECTED PAPER SIZE. PLEASE PRESS OK TO CONTINUE OR BACK TO CANCEL THE JOB."
Me: How long has this thing been beeping?
Front Desk staff: Oh about 20 minutes now.
Me: I see. *Swallows back the slight stroke I'm having*
*Presses OK. 78 print jobs immediately start spewing out.*
 
Last edited:
Oh and afterwards she made me stand there and watch "to make sure she got it right" as she printed out 12 more reports.
 
Yup, I remote to people's desktops and they want to make sure 'it works' after the fix.
Getting paid to reassure people

Because it probably took a while before they got someone talking to them about their problem, and they don't want to go to the back of the queue if it turns out the fix didn't work.
 
Because it probably took a while before they got someone talking to them about their problem, and they don't want to go to the back of the queue if it turns out the fix didn't work.

That's fine and a normal part of the IT process when there is actually a problem.

In my case there was no problem. Neither the computer nor the printer was malfunctioning or working outside normal perimeters. The entire issue was she just kept sending the job to the printer over and over because it wasn't printing (You figure around print job... 30 or so you'd give up) and never once glanced at the printer to see if it need interaction.
 
Because it probably took a while before they got someone talking to them about their problem, and they don't want to go to the back of the queue if it turns out the fix didn't work.

there is no queue to calling me, I am the one who answers the phone, it doesn't bother me if it provides them reassurance
 
Status
Not open for further replies.

ISF - Join now!

Every member here is approved by hand. No bots, no spam, just people who care about evidence and honest debate.

Membership is free!

Create your free account

Back
Top Bottom