Welcome back everybody to ITPro.TV.
I'm your host Don Pezet and we are back again with more CompTIA IT fundamentals.
In this episode we're continuing on with part one of troubleshooting methodology.
So in the first episode we got a chance to see our eight step troubleshooting
process.
We got about half way through it, we still haven't fixed our problem.
That's kind of an important part of the process, and so we're continuing on with
that and here to help us resolve all of our issues, is Mr. Ronnie Wong.
Ronnie, thank you for joining us in the studio.
Well, thank you Don for having me as we continue on in this process, rgiht?
We've been taking a look at so much information and
as slow as it seems we wanna make sure that you have
an understanding of each of those steps as we begin.
So that way as we start to take a look,
we're now up to this point where we're ready to proceed on to the fifth step.
But before we do so, Don,
let's go through a little reminder of what we've actually done.
Sure, so we wanna recap this.
We've got eight phases that we're moving through.
And the first four phases we tackled in part one
are kind of the exploratory phases.
So if we pulled that up and what we got is we identified the problem, right?
That I complained about not having Internet access to my machine.
Ronnie did research, he had me run some commands to get some output,
we maybe Googled a little bit and we found that we are able to establish a theory.
We think that the DNS service might be configured wrong on my system.
Then, we tested the theory.
We ran the NS look up command that Ronnie told me to run
to test if I used a different DNS server, does it work?
And it did, right?
So once we're through those first four phases, which was all in part one,
now we're ready to move on to step 5 which is establish a plan.
So Ronnie, I'm thinking if this was an episode of A Team,
this is where we start welding plates on to the van.
That sounds almost right.
That is what it sounds like, but the very fact is we need to have, just like
the A Team, establish a plan of attack, is what we want to be able to do here, okay?
So making sure that we have a good game plan in mind is also key to everything
that we do because it's a part of that process that we go, look,
let's not just start, let's just implement this, let's just do this.
Let's just do this and then hope for a right solution is gonna come along.
Cuz even though that might work for
you, you're not gonna remember that in the future of anything that you end up doing.
And then you're gonna have to do it all again.
So we wanna establish a plan that's methodical, that will actually take us on
an approach that we can follow again and again if we actually need to.
Because the idea of not having a plan means you've just got to rely on hope and
luck to be able to do what you need to.
But at this point, once we actually get that plan that we're going to say,
here's what we believe is going to be resolved.
Here's the steps we know that we can take to try and make sure that it's resolved.
That's when we're going to also of course, implement that solution as well but
overall though, that's what we need to do,
is we now need to actually talk about this idea with the DNS issue.
What is our plan of attack going to be?
All right, so, looking at my machine, it's still broken.
I can't get to, really any website, any website I've tried,
I haven't been able to get there we've got some theories, so what is our plan?
If you had to,
to take a stab at what would solve this problem, what's it going to be.
Yeah, after taking a look at the information we're seeing,
I think what we're going to have to do, is we're going to have to check out
the network adaptor itself that's running on this computer to see what the actual
DNS servers are actually listed in that network at aura.
I couldn't remember what it was called there.
So let's go ahead and take a look at it.
So we'll full screen this that way you'll be able to see what we're
going to do here.
So there's a couple of ways to get access to the network adapter because that's
where all the configurations are going to be.
If we right-click on that icon, that's the network,
then we can select that second option that says Open Network & Internet Settings.
And once we select that option,
this is not a quick easy step thing that we can do, okay?
But now, notice that it has a little diagram and it shows No Internet Access,
which is fine.
You could probably run through that Troubleshoot, but right underneath that,
that's where I want to go.
Where it says Change Connection Properties.
I believe that's actually going to be the one.
That, not that one.
You know actually- That's actually in the loop.
This got moved around in the next verision.
[CROSSTALK] There it is.
Okay.
So I was thinking it was gonna be that adapter.
Yeah, so if you select, there it is, okay?
So he selected ethernet over on the left hand side.
And now the first network adapter which is ethernet0,
if we right-click on that one, go all the way down to Properties and
it's here that we want to take a look in that list of options.
It's like Internet protocol version 4 and
then the Properties button on the lower right hand corner.
And right here, these are the settings.
I can see a couple of options here that, depending on
what I was doing in network this may actually look normal or it may not.
So the very fact on a regular workstation computer.
If this was Don's workstation computer, I might have been a little bit surprised
that he actually had some information that was all listed here rather
than having that top option up there that says obtain an IP address automatically.
So if this is something different than what I was expecting to see that might
have just triggered me like I'm on the right track, okay?
Here's my plan I thought everything was as can be good, but that's all right,
that's all looks good,
looks like it actually is found as working on our network that's fine.
But now I take a look underneath since we're looking at DNS, I can see
the preferred DNS server and on this one it's listing my own machine as being.
The place where I'm going to go and say,
hey, here's where the name is gonna match up to the IP address.
And this is where I had the issue before is that we saw,
through testing, that there was nothing really actually getting resolved here.
So in My network, I might be able to point this to a proper DNS service,
at least to another one at this point.
So Don, let's just try one and see if this actually works here.
So we'll do the 8.8.8.8, I think I said too many 8s for one reason or another.
[LAUGH] So we'll just try that one.
Now, could we do an alternative DNS server if we want to, but let's say
that we're just testing this out for right now because now we have our plan.
Let's go ahead and click OK.
And once we click OK, we should now see if change begins to happen.
And what we'll end up noticing here is not gonna be in the upper,
it's not gonna actually be on this dialogue box, but it's gonna be right in
the lower right hand corner of the screen again, where we'll might see that change.
So if we're full screen, this will help us out to be able to do so
and- And
these changes can take a little while to show up.
It's still showing no Internet access, and I believe the diagram back here,
yeah, it's still showing no Internet here.
That's because it's not testing every couple of seconds.
It's test every couple of minutes, and so it may take a while to reflect.
We could probably test this another way though, right?
If we'd remember our regional complaint, I can't get to CNN so
maybe we'd give that a shot.
Right, so we can simply go over to the browser now and see if we can get access.
And now something at least has changed but this is the real proof in the pudding,
that somehow that DNS setting on my network adapter got changed.
Now if this was not my proper DNS server for
my network if had one internally, then I would need to go and
find out with the IP address to that and make sure it's actually set up for us.
But if this is working, fine, then you know.
So here it is Don, we've now established our particular plan and
we're now actually showing that it is working, and
so we've got a good plan here and the theory seems to have proven out.
Now here's where things start to get a little dicey, right?
Technically, as an end user, to me, the problem is done.
Hey, I can get on the web now, thanks Ronnie.
I hang up the phone.
But if we go back to our methodology, we were just doing step 5.
We established a plan, right?
But we actually kind of moved a little bit forward into phases 6 and 7.
But either way there is still an 8th, what have I actually done.
So walk us through that, Ronnie.
What's going on with the remainder, cuz it does look like we're done.
It does look like we're done.
The very fact is, even though we're done, I might have just set something
temporarily cuz I didn't remember what the proper setting was supposed to be.
So even though this is a solution it might be a temporary solution as well.
So what we want to do is on the idea of verifying functionality the way they want,
we might wanna let this test for a little bit longer.
But if I know that that DNS server is not the correct one that's supposed to be
there, I need to find the proper one and then make sure that that's set in there
and then run through the verification of the functionality again.
Say all right, even though it work by me kind of figuring out how to make it work,
does it work according to what is supposed to?
And if that now actually works then we can move into the remaining phase here which
is to make sure that we document everything else that we have and
that we're ready to go.
All right, so what we did is we did implement a solution, right?
And then we verify the functionality as solution.
We fired up web browser and solidly get to CNN.
Now instead of considering it done,
we might actually have to return way back to phase two research, right?
We just put in one of google DNA servers.
But if you're in a company organization,
you may have an internal DNS server that's supposed to be being used, right?
And so we might need to do a little research, pull up our documentation.
How should that workstation be configured?
Maybe we still have a problem here.
Which we statically assigned that DNS server, right?
If I go back into those settings, Ronnie mentioned.
It's unusual for a workstation to have a static IP like that.
Most workstations would be configured to obtain an IP address automatically
which would also obtain a DNS server automatically.
Why isn't this one configured that way?
We may still have a problem,
if somebody's been tampering with this network configuration.
We fixed the symptom.
We didn't necessarily fix the cause.
How did this get changed?
A regular end-user shouldn't have permission to be able to change this
setting, so somebody with administrative access changed it, or
maybe it was supposed to be set this way.
I called in complaining I couldn't get to the Internet, I might not ever
mention the fact that, I've actually never been able to get to the Internet, and
maybe I'm not authorized in the company to have Internet access, right?
That is something that we would have to look through our company or
corporate knowledge to find out.
But it may be that this whole this whole thing is configured is
configured improperly.
And if we change that to the way that our documentation specifies.
Now, does it go out and get an address and is everything working?
Well, I see it just identified the network.
And if we look way down here at the bottom right of the screen, the little yellow
triangle is gone, and now, this might actually be the correct configuration.
They both worked, so which one is right?
Well, we have to look at what our company is requiring, or
what our home is requiring, or what this environment is, there's a lot more to it.
And so that's where verify functionality comes in and doing the root cause analysis
that Ronnie, you mentioned way back in the beginning in the last episode.
So when we tackle a problem like this, there maybe more than one solution.
And we've got to find the best solution that meets our company's needs.
Now that last phase, document findings, our problem is solved now, okay?
If this problem affected hundreds of computers,
what we just did was a pilot test, and
now we would roll that out on the other hundreds of computers to fix them as well.
In this case it only affected one machine, so
we're ready to move To document findings.
Now, Ronnie, what does that mean, document findings?
Yeah, there's a couple of different things that we're taking a look at here.
Because most of the production networks that you're gonna work on,
workplaces that you'll be in, more than likely,
you're gonna follow these steps regardless of whether you want to or not.
Because you're gonna have to kinda follow a checklist of things that they want to
do, make sure that you get all the way through this.
Well, part of documentation is making sure that we understand the problem fully,
and that we ran through everything that we need to, and
in the end, it also includes what we have learned from this issue, okay?
So, it give us, and it helps us to build, essentially, a database so
that in the future, if we run across something that's fairly similar to this,
we'll be able to learn about this as well.
Instead of having to go through the process, we can now do research right at
the beginning, and maybe jump ahead here to do everything that we need to.
So the other thing about documenting the findings that it also helps us to do is it
may help us to establish a more streamlined process, even in identifying
the problem, as your company develops some of this stuff, in the documentation.
For example, Don, I was trying to take a look out there and realized that, more and
more, there are companies that are also creating their own internal FAQs.
Frequently asked questions.
And you can see some of those where it's like
are you having an Internet connection problem?
And then they go ahead and they just have a list of questions and
they show answers for you.
So it gives that person the ability even to start troubleshooting on their own
without needing that.
So you're seeing this basis of documentation
that will really help build this database for other people to troubleshoot.
But as well as your company, it helps streamline part of the process.
Now Don, I've also seen this where I've gone all the way to step number seven,
and then I've been wrong, okay?
[LAUGH] In other words, my theory, I thought no, everything is working out.
But then I was wrong.
Does that mean I need to start over?
It means I do, I might need to configure, or to think about a new theory and
start the process and making sure I work through that.
So it doesn't always have to happen just in the first four phases.
Sometimes you might get close to the end, and
I think Don actually kind of pointed this out of one of the ones that I did.
Which was I got through it and I fixed the problems.
But then Don said, well, when did this issue happen?
And I didn't realize that something that I had implemented caused something
else to break.
Now Don, that can happen at times and
that's something we got to be aware of too.
Absolutely and you might not even see those problems right away.
You might have the ticket completely closed out and it could be a full on
month later before some other symptom is noted and it comes back.
So not the end of the world, computers are incredibly complex.
There's a lot of different things that go on especially when you involve networking
and so we just have to be open to that.
Now, if you didn't document your findings and a month goes by and
then this problem pops back up, you might not realize there's a connection.
And let me give you a couple of stories on this.
I worked for a bank in Seattle, Washington, and we had fiber Internet.
Very high speed, very reliable.
And that connection went down one month.
It went down, for just about an hour and
we just chalked it up to the service provider having an issue and that was it.
Well, a month later, it went down again for about an hour,
and it was just kind of a random issue, but then it happened again a month later.
So three months in a row, it went down for an hour.
And because we documented everything we found, we were able to see this pattern.
We knew that each month, we can almost predict exactly when it was gonna happen.
And we were able to communicate that with the provider because the provider,
what they were doing, is they would have a switch that would have an issue, and
they would reboot the switch and then everything would be fine.
And so then they would just chalk it up.
They would say, rebooted the switch, problem solved, that's it.
But by tracking to see if that problem happened every month,
they were able to identify there was actually a memory leak in the software
that would slowly build up, and get worse and worse and worse.
And after about 28 days, it would run out of RAM and lock up and
they'd have to reboot it.
Well, you wouldn't know that unless you had a historical pattern to look at.
So that's one example where documenting your findings is really important if
you're doing trend analysis.
The other thing is, and I've had this happen, I imagine you have too,
Ronnie, where I see a problem, I troubleshoot it, I figure it out,
I solve it, I get it done, and then six months later somebody comes to me and
they say I'm having this exact same problem.
Six months, yeah.
And in my head I'm like
what did I do to fix that?
I spent four hours figuring it out before.
What did I do to solve it?
I can't remember, now I've gotta repeat that four hour process again.
So we don't want that if we can avoid it.
Building up a knowledge base a collection of your own information, can save you
time and make you more efficient so really kind of a useful thing to have there.
Yeah, there is no doubt that this is one of the most important outcomes that we
can have through the entire troubleshooting process,
because it not only helps us out, right?
Even though we might be the one going back to it.
But later on if I happen not to be there, or Don happens not to be there, or you
happen not to be there, that somebody else can go through that knowledge base and go,
okay, here's that same problem and
may even find out it's the same exact user that's having the issue.
So that way it actually makes it easier as you go back to and be able to do that.
So it is important that we include in that idea of what we did, okay, in other words,
the steps that we took to make sure that was resolved.
All the other things that your company may require you to enter in, and do, and add,
as well, so that we get through all this process.
But I have seen where these types of documentations, they do, they end up
essentially becoming a form, so that when there is a trouble ticket that's issued.
Have you done these things?
And this is why you're submitting it.
If you haven't done that then it tells you, submit this and
then if it continues submit the form.
So you'll see stuff like that, that really is helping to build a process,
making sure it's much more streamlined then we had before.
So there's a lot going on here.
So Don, it only took us almost about an hour to be able to fix your problem.
Now, it's a simple thing, but
we wanted to make sure that you understood how we broke it down to do that.
Even that, you might all of sudden be wondering,
is it gonna take me an hour to troubleshoot everything?
Not really, okay?
Sometimes we can streamline this process and
want actually take some time to make sure that you also see that part two.
>> Yeah, so in this section what we are doing was a busy walking through
the methodology.
And the DNS example here was just a story.
We wanna show you a practical example, so what we're gonna do is if you
watch these part one, part two you've seen methodology.
But in our next episode, we're gonna take a machine that's actually exhibiting
a real problem, and so we'll go through that troubleshooting process.
Not teaching all of the individual phases, but kinda show you what that real
world process is like, and you'll see where sometimes things can be very quick.
Sometimes they can take a long time.
It just depends, but giving you that kind of tangible example.
So definitely stay tuned for that, but Ronnie, we're probably just gonna wrap
this one and pick up with the troubleshooting example the next episode.
Do you have any closing comments?
Well just remember, if you're beginning, make sure you take time to
learn the steps not only for the exam, but at the beginning here.
It just ensures that you're going to cover everything you need to, and
not miss anything.
Missing the stuff can lead you, like I said,
out into the deep woods where you don't want to be.
So following the methodology right from the beginning is something that will serve
throughout your entire IT career, regardless of what you're doing.
Absolutely, all right, well, ladies and gentlemen, thank you for watching.
That's a wrap for this one, definitely tune back in though cuz we'll have that
physical troubleshooting episode coming up.
But that's it for this one, so signing off for ITPro.TV, I've been Don Pezet.
And I'm Ronnie Wong.
And we'll see you next time.
[MUSIC]
Thank you for watching ITPro.TV.