Critical Evaluation of End User Information

WrCombs

FYI-
I'm here trying to help him with his shit and getting nothing but push back.
I gave you all the information I was given.

scottalanmiller

@WrCombs said in Finding product Key:

@JaredBusch said in Finding product Key:

@WrCombs said in Finding product Key:

The answer was already given that it can't be retrieved.

No, the problem is that you are mistaken in the entire question.

I asked the question with the information I was given.
FFS

Push back more. When people give you...

Obviously incomplete info or...
Obviously trying to hide something or...
Fail to state a reasonable goal...

push on them to provide useful info for troubleshooting. In this case it was really clear that the info was incomplete, somewhat suggestive that he's probably trying to hide pirating Windows, and never is a true "goal" stated (to get Windows fully updated.) Just little things, but rather than just passing them on, think about what we are likely to want to know... what's the end goal, but are the basics, etc.

scottalanmiller

@WrCombs said in Finding product Key:

FYI-
I'm here trying to help him with his shit and getting nothing but push back.
I gave you all the information I was given.

We understand that, the frustration on our side is that you tend to take obviously BS info and just pass it on. This is where you should be stepping in as the "first line of helpdesk", and thinking of your friend (or your coworders) as end users and work to try to get useful information out of them.

This is good practice, most of us do this every day with regular end users. End users always give you bull shit information - whether because they are clueless and just don't know what to tell you (generally results in a lack of info, or too much), or because they are trying to bull shit you (filling you with obviously false information) - it's the norm. And our jobs are to sort out what is obviously missing, filter out the obvious smoke, and do our best to record what is accurate and useful.

If you take data like this (either too little, or inaccurate) and just pass it on without critically evaluating it, it will make it almost impossible for you to do your own troubleshooting. Because we have to filter it to figure out what is reasonable before we can start, you would have to two. So practicing doing that in these cases now is how you figure out how to troubleshoot.

It's sad that SO much of IT troubleshooting is trying to figure out what "seeing the world through the customer's eyes" actually means, but it is how things are. In certification tests, the tests are always based on truth. Things like "Error message says: X" or "the computer sounds like ....", but in real life, we don't get accurate info, we get bits and pieces with half those pieces being false or misleading.

scottalanmiller

So in this case, I'd like to look at the original post in this context:

"Coworker ... is looking for his [Windows] product key; When he puts the one from System in it says "0 is not a valid Character" and "1 is not a valid character"

is there a way to pull that via Command line? I tried pulling using wmic bios get productkey but it said there was an error.."

So in this statement we have some questions and some implications. The first bit is the general questions...

What's the end goal? No business goal stated. We need this for lots of reasons - to verify the action being done, to understand what a viable workaround is, etc. What's being asked for her is a means, not an end. Nothing wrong with wanting to know how to do means, but if there is a business problem to be solved (and it turns out that there is - to update a Windows 10 install) we need to know what that is to truly help. Otherwise, we are just spinning our wheels in many cases because the most likely reason for a process to fail is that it is the wrong process in the first place.
What is the key for? We can guess that it is for Windows, but which Windows? There's no reason to be left guessing here. It might feel obvious, but it isn't quite. Close, but details like this should be provided. Given the lack of goal, for all we know someone is looking for an MS Office key and just in the wrong place for it. wmic doesn't provide the Windows key, so given that it's not the tool for any license job, why would we assume a specific one? We can't. So fill in the specifics.

And then we have a couple implications...

There is no valid use for a Windows product key today, so if we assume that it is the Windows product key that is desired we are forced to assume that either someone is very confused, or doing something that they shouldn't be (presumably pirating the software.)
Why is so much basic information withheld? This feels like a situation where the end user knows that they are doing something wrong and are omitting necessary details because they believe that it will hide their wrong doing.

And then the big obvious question...

For issues like this, you just call MS support if you didn't pirate anything and they just fix it. These aren't issues for IT to solve. So, why hasn't MS licensing support been looped in, they would solve it in minutes, because that's all that they do.

scottalanmiller

In a case like this, it can be hard if you are new to helpdesk or feel like you want to trust your coworkers to be professional and to feed you all relevant information that they could have. But they rarely do, even other IT people. The nature of end users (the coworker becomes an end user in this scenario) is to hold back the info, or to attempt to "interpret" it through their vision of what's happening.

But here is the problem: the person stating the problem (that they cannot solve) is the one person we are sure can't tell us everything that we need to know because, if they could, they'd be able to solve the problem (in most cases.) So the person who most wants to "filter" what is said, is the person least likely to be able to determine what a good filter is. Even a well meaning person in that position isn't useful.