There's a lot of things we can shoot from the hip, but 2 2
troubleshooting servers is not one of them. 3 3
Let's go ahead and jump into the idea that CompTIA troubleshooting model. 4 4
>> You're watching ITProTV. 5 5
[MUSIC] 6 6
[BLANK_AUDIO] 7 7
>> That's right, a methodology is always gonna be very important when it comes down 8 8
to troubleshooting because if not you may miss some different things. 9 9
So Wes Bryan is gonna actually help us out as he actually walks us through 10 10
the official CompTIA troubleshooting model, so 11 11
that we don't miss a single step when it comes down to it. 12 12
All right Wes, by this point in time, right, 13 13
most people have probably gone through, let's say A+, Network+, Security+. 14 14
And this model has been pervasive throughout those when it comes to 15 15
troubleshooting. 16 16
And I think what you're about to tell us is still pervasive even here- 17 17
>> [LAUGH]. 18 18
>> In Server+, right? 19 19
>> [LAUGH] Absolutely yes, 20 20
and I wanna touch on two things right going out the gate. 21 21
One, I like how Ronnie said it, it is the CompTIA troubleshooting model. 22 22
Depending on which exam you are, just change it to a plus troubleshooting model. 23 23
Change it to to Net+ troubleshooting model, here in our slides, 24 24
I might go ahead and I'd call it Server+ troubleshooting model, but 25 25
I think Ronnie hit the nail on the head. 26 26
It is the same model across all of their exams, 27 27
that's the first thing I wanna tackle. 28 28
The second thing I wanna tackle is what Ronnie said initially, a methodology, 29 29
all right. 30 30
In the real world, okay, I don't care what troubleshooting model you use, 31 31
do what Ronnie said, apply a systematic approach, all right? 32 32
I'll give you an example where Ronnie has been doing this with me for 33 33
the last seven years or so. 34 34
All right, Ronnie, we're having a network issue, all right, 35 35
I need some help with this. 36 36
Where did you start? 37 37
Where do you start looking? 38 38
Did you look at the physical layer? 39 39
All right, Again, just some of that OSI model coming back. 40 40
No I was thinking it was a routing issue. 41 41
I got your plug right here in my hand, 42 42
probably has an issue is why you don't have network connectivity, right? 43 43
So it's important to have that approach and have a method to the madness. 44 44
So that every time you apply the troubleshooting methodology, 45 45
it'll become second nature. 46 46
Now let's bring it back to CompTia, and since this is a CompTia exam, 47 47
you need to know their way, all right. 48 48
And it's not a bad model and I'm certainly not talking it down, 49 49
it is a systematic approach to applying. 50 50
Well, actually, I should say identifying diagnosing and 51 51
resolving issues and that's what we wanna focus on in this episode. 52 52
All right, so they break it down in a series of steps and what you really need 53 53
to know for the exam is know the steps, know some of the functionalities. 54 54
Be able to identify if you will some of the functionalities, be able to explain 55 55
back to Ronnie and I if you were sitting in the studios or standing in 56 56
the studios with us and you were blocking that camera off, looking back at us. 57 57
Do the same thing that we're doing in this episode and 58 58
know the adjacencies of the ideas. 59 59
You should be doing well regardless of which the CompTIA exams that you approach 60 60
the troubleshooting model. 61 61
And that's good, that's ones that we can say you get a four for one [LAUGH] why? 62 62
One model Four different exams. 63 63
It should be second nature just like Ronnie said, but if it's not, 64 64
that's what we're here for. 65 65
>> All right, so Wes let's go ahead and jump into this and let's start identifying 66 66
that very first issue that we have, which is identifying the problem. 67 67
This may be a little bit harder, especially for 68 68
someone that's not used to doing it, but what steps would we take to begin? 69 69
>> All right, Ronnie, when it comes to identifying the problem here 70 70
we are going to be doing a little bit of detective work, all right. 71 71
Really, when it comes down to it, 72 72
you can boil down the identification of the problem to information gathering. 73 73
All right, for instance, what is the current state of the network, right? 74 74
Like for instance, if I have to go to Ronnie, Ronnie I'm having network issues. 75 75
That internet is acting slow, that was one of the most vague statements that 76 76
you'll get somebody saying when it comes to employees. 77 77
The internet is slow, what does that mean? 78 78
[LAUGH] Where does that rely? 79 79
How is that happening? 80 80
Can I recreate the problem? 81 81
Can I look and monitor the monitoring software right now and 82 82
determine where are we currently? 83 83
So you start to get some ideas of what the issue is, is the land, 84 84
is it online, is it down? 85 85
Right, do we have local services that are available? 86 86
Can I query you if you [UNKNOWN] an internal DNS server, but 87 87
I can't query an external DNS server, right? 88 88
So local versus land services, right. 89 89
Is my gateway generic for the default gateway? 90 90
Your router, is it online? 91 91
That might be a reason, I can't hit external resources, right. 92 92
Is there a connection via the land to the carrier's network? 93 93
Did you pay your internet service bill? 94 94
I know one thing that we have to worry about here is route redundancy and 95 95
one of the things that they've implemented here at ITProTV is two internet service 96 96
providers. 97 97
We have one that we use primarily and if that one goes offline, 98 98
we fail over Ronnie and the text here at ITProTV. 99 99
He's got it set up to it fails over to second line, right? 100 100
So we have to understand what is the current state of the land, 101 101
the land links is likewise, all right? 102 102
So how do we go about doing that? 103 103
All right, these are some of the questions that we need to ask, but 104 104
we also need to ask our end users the questions, why? 105 105
Why do we ask the end user questions? 106 106
Well, there the boots on the ground, You've heard that term? 107 107
The boots on the ground versus the people in the comfy office dictating what to do. 108 108
You got to go to the people that are in the field when experiencing whatever 109 109
the issue is. 110 110
So, that's why the end user feedback is absolutely essential. 111 111
>> Now, you also have to ask the right questions. 112 112
All right, I say something like Ronnie, 113 113
your network connected, right, now yes or no. 114 114
Well, that really didn't help Ronnie. 115 115
Have you noticed anything that has changed since you had this issue? 116 116
That's an open ended question. 117 117
Right, it still might be yes or no, but 118 118
at least I've given him the chance [LAUGH] that he could say, yeah. 119 119
You know what? 120 120
So, last week we implemented this new service and now I've noticed that at five 121 121
o'clock every day after the service was implemented. 122 122
We have some issue again, just throwing, spit balling here, if you will. 123 123
Right, shooting from the hip like Ronnie said, 124 124
but we're trying to put some method to the madness. 125 125
Right, so that is the very first thing is identifying the problem. 126 126
It's about the information gathering and how you go about. 127 127
>> Yeah, now, once we have that information gathered, 128 128
we have multiple possibilities here. 129 129
What should we do next? 130 130
All right so, the next thing we're gonna do is then we're going to start to think 131 131
about things [LAUGH] we say. 132 132
Think about things now. 133 133
It's time to start establishing a theory right now, 134 134
member that little story I gave you about Ronnie to ask me about 135 135
the physical layer cable question the obvious simple fixes first. 136 136
Alright, consider multiple approaches. 137 137
Don't just stop with one. 138 138
I don't have network connectivity. 139 139
I'm not gonna just stop with what I think is the physical layer and 140 140
a cable connection. 141 141
Maybe I should look at my IP address. 142 142
Do I have Ip address? 143 143
I have an IP address that might let me know that hey, 144 144
I might have an issue with the DHCP server. 145 145
Right, notice that I'm not stopping with a single approach. 146 146
It might be the cable maybe switch ports turned off. 147 147
Probably not, but it could be Right. 148 148
So, I'm doing multiple potential things that could cause this issue right? 149 149
now I keep mentioning the OSI model. 150 150
All right, indirectly. 151 151
Alright, layer seven. 152 152
Right, the open systems interconnection model in your troubleshooting model? 153 153
They come to troubleshooting model. 154 154
They call out a couple of different approaches. 155 155
Alright, three different approaches to be exact. 156 156
Alright, the last three are how you apply it to the USI Model. 157 157
All right, Ronnie. 158 158
And and correct me if I'm wrong. 159 159
Ronnie. Right here, live here. 160 160
I didn't, this isn't scripted. 161 161
>> You're wrong. 162 162
>> Okay. >> There we go. 163 163
Let's move on. 164 164
Perfect, you use it seems like a lot of times you use the bottom to top. 165 165
>> I do approach Right. 166 166
Absolutely, right. 167 167
And that's kind of what's been ingrained in me, you know, 168 168
just through working with the other agitators over the years and stuff. 169 169
And I thi I I do the same thing. 170 170
I do the bottom the time. 171 171
I look at the network portion. 172 172
Right, I don't I don't really worry about the application portion yet. 173 173
Right, what's the application portion? 174 174
Well, those are the upper layers. 175 175
Right, application presentation session. 176 176
Right, you might say we'll start there. 177 177
I think I have a DNS issue. 178 178
Right, that's up there at the application layer. 179 179
So maybe we're starting there and that's not a right or wrong way. 180 180
It's just where are you starting? 181 181
And then you work your way down through the layers saying, 182 182
okay, now I'm at the network layer. 183 183
I know that's where the routers happen. 184 184
I have been a routing issue. 185 185
Right, and I have a route convergence issue. 186 186
Maybe routes are converging. 187 187
That's not that. 188 188
All right, well, let's go ahead and move down to the data link layer. 189 189
Right, let's talk about ethernet. 190 190
All right let's talk about the, the ethernet standards and protocols right. 191 191
Or divide and conquer says, Hey, you know what, I don't have an I. 192 192
P address, I have an EpiPen address. 193 193
That's a D H C P option. 194 194
I already know where I need to start. 195 195
So that divide and conquer doesn't necessarily mean it's right in the middle, 196 196
divided and split it up. 197 197
It just means start at the layer you think it is and work your way either way, right? 198 198
So those are the establishment of the theory. 199 199
Now, Ronnie, once we've established that theory next time now, 200 200
it's time to do a little bit of lab work. 201 201
All right, and what I like about this picture is it essentially sets the stage 202 202
for everything that the testing theory does. 203 203
Testing a theory does right? 204 204
You've got your multiple approaches. 205 205
Now you're gonna start to systematically and don't do what I do. 206 206
And I'm gonna humble that Ronnie, I will let Ronnie talk on this one here. 207 207
Don't do what I do. 208 208
I tried seven different approaches all at one time, one of them worked. 209 209
Didn't mark him down. 210 210
I have no clue what fixed it. 211 211
Have you ever done that? 212 212
[LAUGH] >> Yeah, more than one. 213 213
Yeah I'm not trying to throw you under the bus. 214 214
Roddy, I've done that many times. 215 215
I have no clue what the heck fixed it. 216 216
Right, Yeah. 217 217
>> So the goal is to isolate and only do one thing and if that doesn't work, 218 218
put it back. 219 219
>> YES. so that you know, 220 220
because that's the problem is you fix it. 221 221
>> that didn't work and you continue on and now you don't know if it's 222 222
a combination of both things that made it work or was one thing. 223 223
or the other and it becomes too, 224 224
you know, there's no way then to use that knowledge again in the future. 225 225
>> Most definitely. 226 226
So that's why you have to keep in mind that this step is important, but 227 227
this step can also be detrimental to the success of the entire the entire model. 228 228
So just that definitely be aware of that. 229 229
So, when you're testing a theory, 230 230
just use the resources that you have at your disposal, right? 231 231
If it's a misconfiguration issue, 232 232
what is the interface that you're going to use potentially to investigate that? 233 233
What's the interface that you would use to do the configuration, right. 234 234
Do you have to defective hardware? 235 235
If you have defective hardware, 236 236
we need to be able to run some kind of hardware utility that can diagnose that. 237 237
So, for instance, maybe we're in the bios and we're looking at smart errors, 238 238
you know, from our hard drives. 239 239
Right, so use what you have available? 240 240
There's a cable issue. 241 241
Do you have a cable tester, Right. 242 242
If you don't have a cable test, do you have the ping utility, 243 243
do you have a crossover cable? 244 244
So you have things use the things that are at your disposal. 245 245
If it's software issues, What software do you have, 246 246
What vendor documentation do you have? 247 247
Right, so you have to use a lot of the resources that you have available. 248 248
Ronnie mentioned documenting down those steps of the theories, 249 249
not knowing which one. 250 250
And I said I didn't do that. 251 251
So I couldn't tell you which one it is. 252 252
Those are important to write because they help to tell you and 253 253
point you to where you're going to go as a part of testing that theory. 254 254
So, far what we have is identification of the problem establishing a theory and 255 255
testing the theory. 256 256
>> Yeah, so west, once we actually have this test and we think that everything is 257 257
going right in the test, it's now time for us to move on from that. 258 258
But the hard thing is this, is that what once you actually do that, 259 259
it's very easy to jump in and go. 260 260
I'm just gonna apply this thing and then you apply it and it really didn't work. 261 261
Sure what do you do at that point? 262 262
>> Sure, Ronnie. 263 263
And you know, I would have probably done that same thing. 264 264
And why is that? 265 265
Because if you come from the perspective of a home user, it's your network. 266 266
Maybe you got 10 devices highly optimized home automation system. 267 267
Maybe you've got 50 devices, I don't know, but you don't have many. 268 268
Right, and any change is probably not going to bring down your entire house and 269 269
shut down operations. 270 270
If it did. 271 271
If it does [LAUGH] you might, you might need to hire somebody that can do it. 272 272
But in an enterprise level environment where issues, lack of configuration 273 273
misconfiguration an outage could cost you millions of dollars an hour. 274 274
I'm gonna go through a process of planning when you're going to implement what 275 275
the solution is and that's what we need to know on this step here. 276 276
Planning and 277 277
implementing a solution is planning before acting right plan before doing something. 278 278
And that's important to understand. 279 279
Right, at this point, we haven't even made any changes. 280 280
All right, If I'm going as part of that plan, I'm going to say, you know, 281 281
what do we have backups? 282 282
All right, yes, our back we have backups are backups run nightly good. 283 283
We need to do this in the middle of the day. 284 284
Where do our backups stand now? 285 285
Do we have to do an out of cycle back up right now because it could be important. 286 286
You might not be able to wait. 287 287
So do we have backups in place? 288 288
Right, the other thing to keep in mind too is sometimes it's a single step. 289 289
Right, Ronnie. 290 290
I'm having issues with the network. 291 291
Did you look at the physical layer, plug the cable in fix the problem. 292 292
Right, but then it also sometimes could be multiple steps. 293 293
It could be multiple steps that also and you need to implement some kind of 294 294
interdepartmental you know, coordination right. 295 295
between maybe development and operations while we have that term devops today. 296 296
Right, so is there a single step or multiple steps? 297 297
All right, when should this be implemented? 298 298
The time frame isn't important to sometimes the timeframe is now or 299 299
the time frame is yesterday. 300 300
Right, and maybe we typically will have some kind of policy in place that 301 301
would escalate this quickly. 302 302
But do we do this in off hours or do we do this in peak hours? 303 303
Do we do this during business hours where our potential employees are, 304 304
employees could potentially lose valuable productivity. 305 305
Right, there's again, there's not a right or wrong answer. 306 306
These are things, some of the things that you need to consider before you actually 307 307
implement the solution. 308 308
>> Now, once we actually get to that point of implementing the solution, 309 309
I put things in place. 310 310
I think everything is going right and so I should be done with it. 311 311
I'm just kind of washing my hands of it. 312 312
Is there anything else I need to do? 313 313
>> No, walk away from it? 314 314
>> [CROSSTALK] No, don't do that. 315 315
Right [LAUGH] what Ronnie is alluding to here and rightfully so 316 316
is the fact that once we have, what we think is fixed it. 317 317
Right, we have to follow through a little bit. 318 318
We have to verify system functionality. 319 319
That's important. 320 320
A lot of times what that happens is we implement the change and then we monitor. 321 321
All right, monitoring is definitely important. 322 322
The other thing, 323 323
remember how we started this process with asking our users those questions because 324 324
they are the ones with the boots on the ground experiencing whatever the issue is. 325 325
Not only should we monitor the hardware, but 326 326
we should also listen to our user feedback. 327 327
Users are going to tell you if it's fixed or not. 328 328
Right, so it's important to get some kind of user feedback as well that 329 329
the system has been fixed and it's functioning according to what the user or 330 330
the company that you work for within those expectations. 331 331
Alright, so verifying full system functionality is ensuring that when you 332 332
implement a solution, that the solution did resolve the issue. 333 333
>> Now that sounds like everything should be done at this point. 334 334
So shouldn't have to worry about this. 335 335
So Wes am I done now? 336 336
>> No, still. 337 337
>> Still, unfortunately in in Wes world, I'd be done and walk away and set it. 338 338
>> Forget it. 339 339
And then a month later, if we have a recurring issue in another server, 340 340
that's the exact same thing. 341 341
I'm starting all over again. 342 342
Right, why? 343 343
Because I forgot one of the most important all of these. 344 344
All of these are important. 345 345
But this is a very, very important process. 346 346
We have to document the journey. 347 347
How did we get to the resolution? 348 348
What were the steps that we took? 349 349
In fact, I've got bullet points for these. 350 350
I guess we could put them up here, but 351 351
I can tell you at the same time what was the journey right. 352 352
How did we get to the resolution? 353 353
And what were the steps, What were the theories, what, what didn't work? 354 354
Right, that's it. 355 355
As is important for the next person fixing this problem. 356 356
I well, maybe Ronnie says the same things. 357 357
I thought it was XY and Z. 358 358
Ronnie comes in and sees that problem and says, you know, 359 359
that looks like that would be the problem too. 360 360
But if he looks at the documentation that we had and said, it wasn't X. 361 361
Because of this, It wasn't Z because of this. 362 362
You could say, all right, well maybe it's why or 363 363
maybe we it's none of these right documentation is important. 364 364
The other thing that is important too is not only to have a working 365 365
record of what you have fixed and how you fixed it, but 366 366
also it's a blueprint of the experience of your knowledge in fixing stuff. 367 367
Right, now, you might have a ticketing system. 368 368
I know that we here at ACI Learning and ITProT V. 369 369
If you will, we have a ticketing system. 370 370
All right and the ticketing system is tickets can't be closed until there's 371 371
documentation on them. 372 372
The level of the documentation, what you actually document is going to be 373 373
probably tailored specifically to the company's policy. 374 374
All right, but if you can document the journey, 375 375
what were the symptoms that were identified? 376 376
What were the theories that did not work? 377 377
What actually worked? 378 378
What resolve the issue at the end of the day, 379 379
you're gonna have a collection that we typically call knowledge basis. 380 380
Right, And as that knowledge base increases now, 381 381
hopefully you don't get the same issue over and over. 382 382
You might have to implement a different technology and 383 383
that could be the solution to this. 384 384
Just isn't working the way we have it. 385 385
But at least you have that working knowledge that you can reflect on. 386 386
You can review you can use for further training for 387 387
additional people who come on to your company. 388 388
Right. So the documentation process is important 389 389
as well and it's certainly not one to forget if I would have documented half of 390 390
the stuff that I've done in my career. 391 391
I have a pretty thick book. 392 392
But the problem is I didn't So now I'm always reinventing the wheel and 393 393
problems that I've had. 394 394
So I have to be I have to be transparent and 395 395
that's why it's important to have that method to the madness. 396 396
That methodology that Ronnie set the whole stage for this episode. 397 397
On apply a methodology, apply that systematic approach. 398 398
You're in a cop t exam, you apply their approach, you're in the real world. 399 399
Just apply approach and follow it. 400 400
>> All right, well, you heard it there from Wes. 401 401
The very fact is any methodology is better than none of the methodologies. 402 402
So make sure you choose one that you stick to it as you go through whatever it is 403 403
that you're troubleshooting for the comp Tia server plus exam. 404 404
Make sure of course you follow the comp TIA model because that is the methodology 405 405
that will help you on the exam as well. 406 406
These are things that we actually use just about every single day in the lives of IT 407 407
professionals. 408 408
And it's nothing that you should just go out. 409 409
Don't worry about that. 410 410
It's something you should actually have ingrained into your mind and 411 411
into your memory. 412 412
Well that will wrap it up once again for us today on the CompTIA Server+ show. 413 413
But it doesn't mean once again that there is not another one coming up and 414 414
you want to see us to again and one join us in the very next episode. 415 415
>> Thank you for watching ITProTV. 416 416
[MUSIC]