John W Powell : .Net

RV-AIR: A Five-Step Process to Troubleshoot and Fix Just About Anything

johnwpowell — Mon, 01 Jun 2009 02:10:00 GMT

Effective troubleshooting is an important skill not only in the information technology field, but in many other professions. Auto mechanics, electricians, counselors and doctors are essentially professional troubleshooters. They identify problems, theorize solutions from their knowledge and experience, and systematically test them whether they be a new alternator or a prescription for high blood pressure medication. I’m not a doctor, but being a good troubleshooter makes me feel like one. In this article, I’ll share an age-old process for troubleshooting, “RV-AIR,” that was taught to me as an electronics engineer in the armed forces.

Recognize

The first step of effective troubleshooting is to recognize that a problem exists. Obvious, yet often ignored, problem recognition is the single most important troubleshooting step. That’s because the way in which we discover a problem impacts how we fix it, and can be the difference between treating the symptoms and curing the “disease.” Problem recognition can be categorized as reactive or proactive, and describes our capability on a continuum from immature to mature respectively. Reactive recognition is discovering a problem only when someone reports it. Some might call this “fire fighting.” When we are in a reactive state, we don’t know when or from where the next problem will arise, and the time we spend “putting out fires” takes us away from what we want, or need, to work on. On the other end of the spectrum is proactive recognition in which problems are identified as soon as or before they occur. Using the doctor-patient analogy, proactive recognition is a preventative checkup that identifies high blood pressure and prevents a heart attack, and reactive recognition is discovering high blood pressure after having the heart-attack. For software systems, proactive recognition is a health monitoring solution such as Microsoft System Center Operations Manager, but the key concepts of proactive maintenance and health monitoring transcend systems and disciplines.

Verify

Once a problem has been reported either by a person or a system, the next step is to verify it. It is very difficult to troubleshoot a problem that cannot be reproduced, and it is equally frustrating to waste time troubleshooting something that was never broken in the first place. As much as we like our customers, the PEBKAC (Problem Exists Between Keyboard and Chair) factor applies. I’m not saying that user’s are stupid, but experience dictates that you should trust your customers, but not their problem reports. Let me illustrate this point with an example. Your newly licensed teenage daughter calls you in a blind panic that the expensive car you lent her won’t go into gear. What could be wrong? You begin theorizing, “maybe she ran over something,” “maybe when I got my fluid changed, they didn’t put the plug back in.“ Then you jump to a diagnosis and a decision, “The transmission is broken, so I better call a tow truck and make an appointment at the dealership.” You have the car towed to the shop and spend hundreds of dollars to discover that nothing is wrong; your daughter simply forgot to press the brake pedal before putting it into gear! The moral of the story is that problem verification saves time, money and relationships.

Analyze

After a problem has been recognized and verified, the next step is to analyze it. During this step, the symptoms of the problem are analyzed and a set of possible causes, or theories, are identified. The result is a ranked list of potential solutions that will be systematically proved or disproved in the next step. Knowledge and experience plays a large role in how you arrive at your theories and the more troubleshooting you do, the better you will get at it. Strive to identify root causes and permanent solutions. Leverage the experience of others by thoroughly researching the problem on your own first before asking others. Effective troubleshooters are effective researchers, and they know where to look, how to filter out noise and identify useful nuggets of information. From your research and analysis, you will have a list, at least in your head, of the potential causes. Rank the causes from most to least likely and identify a solution for each.

Isolate

After analyzing the problem and identifying the most likely causes and solutions, the isolate step is a systematic process of elimination. For each of your theories, from most to least probable, test the solution in a non-production environment (if possible) so that you don’t introduce new problems. Go slow and apply only one change before each test. Beware of false positives and validate the root problem is solved and not just the symptoms. If you are unable to find a solution, then you may need to collect additional data and return to analysis. Once you find a solution, the next step is to create a plan for applying the fix.

Repair

The final troubleshooting step is to permanently repair the problem by applying the solution identified in the isolate step.

Conclusion

RV-AIR is a proven process for finding and fixing problems and is equally effective for tracking down a memory leak as it is for finding a shorted electrical outlet in your house. The key to effective troubleshooting is to recognize, verify, analyze, isolate and repair. Happy troubleshooting!

Subscribe to SharePoint Web Parts using Internet Explorer 8 Web Slices

johnwpowell — Mon, 02 Feb 2009 00:34:00 GMT

One of the new features of Internet Explorer 8 is Web Slices. This feature enables you to subscribe to a section of a web page and notifies you when the content changes. By design, SharePoint Web Parts are a natural fit for this feature, and in this article I’ll show you how to build a Web Part that does just that. I’ll also show you how easy it is to develop a web part using the CTP release of Visual Studio 2008 Extensions for Windows SharePoint Services (VSSWse) 1.3.

About Web Slices

Web Slices enable you to have a very narrow control over the content you subscribe to. When you browse a page that has Web Slice sections, they “light up” when you hover over them:

In addition, the new Web Slice icon on the toolbar lights up, and the menu is populated with all the slices on the page:

When you subscribe to a slice, the web page section is added to the toolbar and is periodically refreshed. The refresh interval is completely customizable and can also be refreshed manually:

Defining a Web Slice Section

Web Slices are defined with HTML tags that have certain CSS classes. You can read the full specification, but here’s all you need to know to build your first Web Slice:

To define a Web Slice section, use the hslice class name:

<div class="hslice" id="1">…</div>

To define the slice title, use the entry-title class name:

<p class="entry-title">Game System - $66.00</p>

To define the slice content, use the entry-content class name:

<div class="entry-content">This auction closes in 4 hours.</div>

The end result looks like this:

<div class="hslice" id="1">

<p class="entry-title">Game System - $66.00</p>

<div class="entry-content">This auction closes in 4 hours.</div>

</div>

Build a SharePoint Web Part

For this example, I’m using VSSWSE 1.3 which you can read about here. I would recommend it not only because it’s easy to use, but also because it is sure to become the de-facto standard. To get started, create a new Web Part project:

Choose if you want to deploy to the GAC or bin directory. We’ll use GAC for this example:

A solution is created with a default web part named WebPart1. Rather than renaming it, delete the WebPart1 folder and add a new Web Part to the project with a more descriptive name:

Next, configure the url of your SharePoint site you want to use to test the Web Part. On the Debug settings, set the start url:

In the Web Part, override the CreateChildControls method:

This code generates the needed HTML and is pretty self-explanatory. I chose to hide the Web Slice entry-title as it would be redundant beneath the Web Part title. To test the code, right-click the solution or project and select Deploy. This will package the Web Part as a feature and deploy and activate it on the site:

Next, add the Web Part to a page in the site and test it.

How I Wished It Worked

Web Slices are powerful, but I don’t really want to develop a bunch of new Web Parts to use that feature. I wish every Web Part were capable of wrapping its content in a Web Slice div tag. I’m sure there is a way to inject this functionality (and there might even be a supported method), but I wish it were built in to the Web Part framework. Every Web Part could then have a Web Slice category with relevant settings:

Wouldn’t that be powerful?

Summary

In this article, I demonstrated how to build a Web Part that users can subscribe to using Web Slices. I also showed you how easy it is to build a Web Part using the CTP release of Visual Studio 2008 Extensions for Windows SharePoint Services version 1.3. Happy slicing!

References and Additional Reading

How to Copy an Assembly From the GAC to the File System

johnwpowell — Wed, 14 Jan 2009 04:20:00 GMT

Sometimes you need a local copy of an assembly from the GAC and here is a quick tip on how to do it. The GAC can be found in the c:\windows\assembly directory, but if you try to browse it, the following custom shell extension appears:

This view does not provide the ability to copy assemblies, but it does provide some very useful information such as the strong name details. Here are some options to get around that feature to copy an assembly from the GAC.

Option 1: Disable the Shell Extension in the Registry

One possibility, but not the best one, is to disable the shell extension. I don't like this approach because it involves editing the registry and I like the information provided by the shell extension. Here's how to disable the extension if you want to. Open the registry editor and add/set the HKLM\Software\Microsoft\Fusion\DisableCacheViewer DWORD value:

Set the value to 1:

Once you make that change, you can browse the directory:

Option 2: Go Command-O

Another option is to copy assemblies from the GAC from the command line. This approach works well if you prefer working from the command line, but if you like to right-click with a mouse, this might not be the choice for you.

I highly recommend PowerShell, but you can use Windows Command Prompt. Find your way to the c:\windows\assembly directory and copy the file you need:

Option 3: Use the SUBST Command

The SUBST command allows you to create a shortcut to a path on your file system and assigns that shortcut a drive letter. I really like this approach because you have the option of using Windows Explorer without having to disable the shell.

Suppose you want to create a G Drive (G for GAC), use the following command: SUBST G: C:\WINDOWS\ASSEMBLY

Then in Windows Explorer you are free to double-click and right-click to your heart's content and still use the shell extension.