[26437] in resnet
FW: Teaching how to troubleshoot . . .
daemon@ATHENA.MIT.EDU (Andy Voelker)
Mon May 30 13:05:38 2011
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <CA0945B8.AB72%avoelker@wcu.edu>
Date: Mon, 30 May 2011 13:03:27 -0400
Reply-To: Resnet Forum <RESNET-L@listserv.nd.edu>
From: Andy Voelker <avoelker@email.wcu.edu>
To: RESNET-L@listserv.nd.edu
In-Reply-To: <CA09437F.AB62%avoelker@wcu.edu>
I did something similar actually. I created a document for common problems. Than I created a document for common tools and repairs. Then I created a document to link them together. It was a bit messy. Doing the "choose your own adventure" book sounds like a great idea to tie it together! Thanks!
I always create an "obstacle course" where we infect and break an image and deploy it to one of our labs. We then go behind the image and break a few things independent of all the other machines. This way they have some things in common that they can work together on, and some things they won't. The scary part is how different the infections end up even being deployed from the same original infection. It amazes me how the same virus can act differently. We've had some years where the image ended up being consumed beyond repair and some where it wasn't very hard. We usually pair up the newbies with the veterans and let them learn from each other. Students constantly rate this as being one of the most valuable parts of their training.
Also, it is important to reinforce the separation between symptoms, such as hardware, software, OS, account, network, etc. Many newbies are fluent in software or hardware but not both, so that line has yet to be drawn in their minds yet.
-- Andy Voelker
Manager of Student Computing in the Technology Commons
Western Carolina University
Be sure to check out the WCU TechTips Podcast at http://www.youtube.com/WesternCarolinaU!!
Check the status of your IT requests at any time at http://help.wcu.edu/ !
From: Ben Fielden <fieldenb@gwu.edu<mailto:fieldenb@gwu.edu>>
Reply-To: "fieldenb@gwu.edu<mailto:fieldenb@gwu.edu>" <fieldenb@gwu.edu<mailto:fieldenb@gwu.edu>>
Date: Thu, 26 May 2011 09:55:51 -0400
To: Resnet Forum <RESNET-L@LISTSERV.ND.EDU<mailto:RESNET-L@LISTSERV.ND.EDU>>
Subject: Re: Teaching how to troubleshoot . . .
I've always wanted to write a "build your own adventure" style script of sorts to use for the newest folks.
"Are there any indicator lights? Yes - p2, No - p4"
"Do you see the manufacturer's startup screen? Yes - read on, No - p4"
I think the new folks would have a lot more confidence knowing that they can sit down with the book and get through a fair number of steps on their own. It also would provide instructions for what information to gather in case they cant figure out the information and need to have one of my FT techs look at it.
Of course I haven't had the time to actually write it...
-Ben
--
Ben Fielden
Manager of Technical Support
Student Technology Services
Division of Information Technology
http://it.gwu.edu/sts
202-994-2597
Division of Information Technology staff members will NEVER ask for your password!
On Thu, May 26, 2011 at 9:50 AM, WILLIAM J. CAMPBELL <wcampbell@fordham.edu<mailto:wcampbell@fordham.edu>> wrote:
I do not have any formal training as most organizations. But, I do have about a half dozen old Pentium's stacked in the corner. When I get a rookie first thing they do is take apart each one and put it back together. Most newbies have never done anything remotely like it and the experience itself is enough to build confidence that if they touch the innards of a machine, it won't explode. I don't really care whether or not the machines they reconstruct actually work, it really more for the just the experience of ripping the guts out of a machine.
Bill
--------------------------------------------
William Campbell
Computer Teaching Lab Coordinator
Rose Hill Campus
Room 303 JMH
Fordham University
441 East Fordham Rd
Bronx, N.Y. 10458
718-817-4467
WCampbell@Fordham.Edu<mailto:WCampbell@Fordham.Edu>
Fordham IT's standing maintenance window is every Thursday and Friday from 5:00 AM thru 8:30 AM
From: "Randall K. Kouns" <kounsra@earlham.edu<mailto:kounsra@earlham.edu>>
To: RESNET-L@LISTSERV.ND.EDU<mailto:RESNET-L@LISTSERV.ND.EDU>
Date: 05/26/2011 09:44 AM
Subject: Re: Teaching how to troubleshoot . . .
Sent by: Resnet Forum <RESNET-L@LISTSERV.ND.EDU<mailto:RESNET-L@LISTSERV.ND.EDU>>
________________________________
Yes please make these public comments
________________________________
From: "John Shatzer" <JSHATZER@wooster.edu<mailto:JSHATZER@wooster.edu>>
To: RESNET-L@LISTSERV.ND.EDU<mailto:RESNET-L@LISTSERV.ND.EDU>
Sent: Thursday, May 26, 2011 9:37:26 AM
Subject: Re: Teaching how to troubleshoot . . .
I'm in the midst of putting together a new student employee program and I'd love to see how others are handling this as well.
John Shatzer
College of Wooster
>>> Erin Nettifee <erin.nettifee@duke.edu<mailto:erin.nettifee@duke.edu>> 5/26/2011 9:26 AM >>>
Hi all,
We're starting our planning for training our new staff in August (here before you know it!)
One of the things that we see as an area of improvement in our training is the idea of teaching how to troubleshoot. It's something that's implicitin all of the training that we do, but we're interested in making much more explicit. We want people to be comfortable not just with "Here's how you fix ____", but also with "The customer says they have no idea what's going on, how do I figure it out?" We have students who work in multiple areas (public schools, help desk, printing, multimedia, communications, training) but we feel like all of them can benefit from this kind of generalized, higher-level training.
Has anyone ever taught a "Troubleshooting 101" class like this before? If so, would you be willing to share your thought process on it, and maybe some course materials? Right now, we're thinking that the best way to structure this would be some introductory lesson / lecture type, and then a LOT of active roleplaying . . . but we want to make it as interactive as possible.
Thanks in advance!
Erin
-----------------------
Erin Nettifee
Coordinator of Academic Support / Link Liaison
Duke University Office of Information Technology
erin.nettifee@duke.edu<mailto:erin.nettifee@duke.edu>
(919) 668-4829 (desk)
___________________________________________________
You are subscribed to the ResNet-L mailing list.
To subscribe, unsubscribe or search the archives,
go to http://LISTSERV.ND.EDU/archives/resnet-l.html<http://listserv.nd.edu/archives/resnet-l.html>
___________________________________________________
___________________________________________________ You are subscribed to the ResNet-L mailing list.
To subscribe, unsubscribe or search the archives, go to http://LISTSERV.ND.EDU/archives/resnet-l.html<http://listserv.nd.edu/archives/resnet-l.html> ___________________________________________________
___________________________________________________ You are subscribed to the ResNet-L mailing list.
To subscribe, unsubscribe or search the archives, go to http://LISTSERV.ND.EDU/archives/resnet-l.html<http://listserv.nd.edu/archives/resnet-l.html> ___________________________________________________
___________________________________________________ You are subscribed to the ResNet-L mailing list.
To subscribe, unsubscribe or search the archives, go to http://LISTSERV.ND.EDU/archives/resnet-l.html ___________________________________________________
___________________________________________________ You are subscribed to the ResNet-L mailing list.
To subscribe, unsubscribe or search the archives, go to http://LISTSERV.ND.EDU/archives/resnet-l.html ___________________________________________________
--
___________________________________________________
You are subscribed to the ResNet-L mailing list.
To subscribe, unsubscribe or search the archives,
go to http://LISTSERV.ND.EDU/archives/resnet-l.html
___________________________________________________
