It's not what you Google, it's how you Google it. Even when interviewing now
I tend to try and look for people who can work problems out rather than
people who can simply rhyme off lists of stuff - and I'm always keen on
people who check the obvious things first. (Think how would you
troubleshoot
Another aspect of troubleshooting is the ability to keep track of what are
actual facts, and what are as-yet-untested-assumptions.
This includes knowing how to classify information that has been given you by
the end user.
*ASB *(My XeeSM Profile) http://XeeSM.com/AndrewBaker
*Exploiting
Wholeheartedly agree. I once had a case passed from first-line to me where
the user had reported that they were having a problem with sticky keys. I
spent two days working out how to disable StickyKeys, FilterKeys and
ToggleKeys via an AppSense rule pushing out the required Registry settings.
When
Agreed. Making random changes to servers based on gut feelings what are bad,
isn't my idea of a desirable troubleshooting strategy.
Gather facts
Isolate Issue
Identify Root Cause
Implement Fix
Cheers
Ken
From: Andrew S. Baker [mailto:asbz...@gmail.com]
Sent: Thursday, 23 September 2010 6:13 PM
I wasn't saying random based on gut feeling. It was more an inkling that
something was amiss with that particular function due to experience. Maybe I
should have been more clear about what I meant by didn't like the look of
it. When a system is down and you're the only one assigned to fix it,
Man! David hit it right on the head. Nice job.
- Original Message -
From: David Lum david@nwea.org
To: NT System Admin Issues ntsysadmin@lyris.sunbelt-software.com
Sent: Wednesday, September 22, 2010 7:17:21 PM
Subject: Kick Ass Sysadmin (was RE: It appears that the Symantec Virus
The most important of these is gathering the facts. This is not what then end
user issue seems to be, but what it actually it. Then you can decide to either
fix, mitigate, or investigate further.
I know of a number of IT companies where a server reboot is the fix to most
issues, while I know
I agree, but sometimes you only have time to gather the facts after you've
implemented a fix for the users screaming at you. I personally try to avoid
server reboots to fix, that comes from being judged on server uptime. I'm
not saying don't gather facts, I'm saying that sometimes, in the support
There is also some value in this looks out of place or suspicious, and
making a change and observing the results, and then reversing that
change as necessary.
Exporting a registry key before deleting it is a good example... if you
don't get the desired results, reimporting that key is often a
I would add to that list: Establish Risk
I can't tell you the number of times that someone has looked at two options
for mitigating (or attempting to isolate) a problem, and they're ready to
jump on the one which is harder to recover from.
*Them*: Possibly corrupt install? Hey, I know! Let's
Covering your backside should always be an inherent part of any action plan,
not just in IT. But we all have change control processes that we adhere to,
don't we? Actually I've worked with a few people who don't, and they are the
types that get IT workers a bad reputation by bringing services down
Definitely, balance is key.
My experience is that the more time you are able to spend educating people
while things are working, the more latitude you have to troubleshoot while
things are down.
I'm pretty sure we've all had to do a quick-n-dirty fix. The problem comes
when you have so many of
Yep, same thing here except after researching how to disable via GP and such,
when I went over they told me that they had spilled coke on their keyboard a
week earlier and the keys were actually just STICKY.. Upon further
investigation the tech employed with me at the time, had never heard of
Root cause analysis is essential, even after the quick fix.
-sc
From: Andrew S. Baker [mailto:asbz...@gmail.com]
Sent: Thursday, September 23, 2010 9:22 AM
To: NT System Admin Issues
Subject: Re: Kick Ass Sysadmin (was RE: It appears that the Symantec
Virus has affected PGP already)
I remember my second IT job, I was hired as the Network Administrator for this
small company. My boss, the CIO, was also one of the co-founders. Whenever
something came up, as I'm headed to the server room, to start troubleshooting,
I would find him there already, at the console, poking
I had a boss like that before. And then once I was driving, he'd stand
there, breathing down my neck.
Don Guyer
Systems Engineer - Information Services
Prudential, Fox Roach/Trident Group
431 W. Lancaster Avenue
Devon, PA 19333
Direct: (610) 993-3299
Fax: (610) 650-5306
don.gu...@prufoxroach.com
Maybe it wasn't his idea to hire you.
Or, perhaps, he just needed someone to handle the tedious parts of the role.
I worked for a micro-manager for a while who was otherwise a really cool
person, and I was always happy when multiple problems arose
simultaneously...
*ASB *(My XeeSM Profile)
You didn't happen to have a remote shutoff to some loudly screaming network
device to prompt those simultaneous *issues* did you?
grin
-Jeff Steward
On Thu, Sep 23, 2010 at 11:59 AM, Andrew S. Baker asbz...@gmail.com wrote:
Maybe it wasn't his idea to hire you.
Or, perhaps, he just needed
No, but there was a period of about 2 months where I gave *high*
consideration to doing something of the sort...
*ASB *(My XeeSM Profile) http://XeeSM.com/AndrewBaker
*Exploiting Technology for Business Advantage...*
* *
On Thu, Sep 23, 2010 at 12:11 PM, Jeff Steward jstew...@gmail.com wrote:
The place with the ad you mean? I don't remember, but here's one in NY that is
not completely different:
http://www.linkedin.com/jobs?viewJob=jobId=1007553
I do think I am generaly kick-ass, just don't call me an expert at anything. My
specialty is the near-vertical leanning curve that is
Sometimes I wonder if I'm just a good googler... Seems like 90% of my
issues have been tackled (and documented!) by someone else.
On Wed, Sep 22, 2010 at 7:17 PM, David Lum david@nwea.org wrote:
The place with the ad you mean? I don't remember, but here's one in NY
that is not
You are SO sweet.
Networking rocks. Just today, I had a client say Michael, you pulled another
miracle out of your a$$ because of something I learned from someone in Redmond
that I know...
Regards,
Michael B. Smith
Consultant and Exchange MVP
http://TheEssentialExchange.com
From: David Lum
That is kind of the nature of our business, you can never say you know
everything because the instant you think that, somebody is going to throw you a
curve ball. (oh heck, they throw them regardless)
Phillip Partipilo
Parametric Solutions Inc.
Jupiter, Florida
(561) 747-6107
From: David Lum
Some of the smartest and most talented people I know don't think they are
smart or talented. I think the fear of not being good enough drives a lot
of experts to become experts - even though they may not recognize themselves
as such.
-Jeff Steward
On Wed, Sep 22, 2010 at 7:17 PM, David Lum
24 matches
Mail list logo
