Some tips all IT pros should remember: Troubleshooting Tips

Takeaway: Donovan Colbert describes a recent frustrating issue on a project that reinforced some of the tips IT pros should remember when troubleshooting technical problems.

Thanks to : techrepublic

===================================================================

Recently I was building a Citrix Xenserver test lab to create a Citrix XenApp farm. During the build process, I ran into difficulty several times with the order and steps necessary to make the systems available via RDP instead of the Citrix XenCenter console. It isn’t the easiest or clearest build process to set up a Citrix XenApp server as a VM in Xenserver. You’ve got a lot of little details you’ve got to get right — and the default build of W2k8 and W2k3 has some additional initial steps you’ve got to go through before it’ll open it up for RDP connections. This is all compounded by the fact that you’ve got to get the Xentools installed correctly and get the right .net framework installed prior to installing Presentation Server on your Windows base build.
Additionally, I’m not on the most robust test server for this build (a Dell PowerEdge T110 tower quad core with 4GB of ram). I’m also introducing myself to setup, configuration and administration of XenApp with this lab. My lead Citrix engineer is assisting me when I hit snags, but he has his regular job to keep him busy. Altogether, it has made it a relatively difficult lab for me to get running. This lab is built off our main LAN — and it replicates the naming policy of our production network so I have to be careful to ensure that it remains isolated. In order to get online to download updates and components, I am using our public guest network — and I’ve got the host machines and VMs configured with non-routable IP addresses. I’ve changed the IP range a couple of times as I’ve built the machines.
Because of all of this complexity, getting these machines up and running has been a start and stop process with several sets of frustrations along the way. We’ve kind of cheated and bent the rules at a couple of points; for example, we did not create a SQL server to house the database because of the limited hardware resources on the Xenserver, and we created the original set of XenApp VMs as a workgroup, without a domain controller. We encountered strange behavior with this model. Among the problems was getting the machines into Terminal Server mode and reachable from my lab console where I am running XenCenter (a Lenovo laptop). I missed steps during the configuration and initial Windows update process and the Firewall was left enabled on one VM. The other had a similar issue. After all was said and done, we still had problems with one of the Citrix servers being registered correctly in the farm, and my engineer told me I should just create a domain rather than a workgroup so I would be working with something more similar to a production model. Rather than build a server up from scratch, I borrowed a VM image from another engineer’s lab that was already set up as a DC.
After importing the image I logged in and found that this engineer uses a different password than our normal test-lab password. I’m okay with that in general principle, but I had to wait until I could talk to that engineer to get the correct password. He was out for a couple of days, then very busy, so my project got put on the back-burner. When I returned to it and had him change the password so I could get into the machine, I found that it also failed to connect via RDP once I had it all set up. I could only access the machine from the XenCenter.

A second set of eyes is often all it takes

Frustrated, I went in to My Computer properties to enable Remote Desktop, but it was already enabled. Normally my next step would be to go into security or services and ensure that the Windows firewall was disabled, but my intuition told me that this wasn’t the problem in this case. Puzzled, I went to another engineer who works daily with AD and W2kX domain controllers and asked him to come fix my problem for me. I figured I was just rusty from too much time behind a desk and not enough time hands-on working daily as a forward engineer (which is undoubtedly part of the problem). He came in, sat down, and of course, his first step was to do exactly what I had just tried. “Get out of my way and let someone who knows what they’re doing fix this probl- er… wait, Remote Desktop is activated.”
He asked, “What is the IP address this machine is assigned,” and opened a command prompt to run an ipconfig - and that is when it hit me.
My previous issues and challenges had put me in a mindset where I was approaching the problem with a particular bias on what the solution was. I was applying previous experience specific to this particular lab and not attacking this issue as a separate, unique challenge. I was mistaking cause for correlation.
This was a great example that reaffirms some of the concepts and skills I constantly stress with my team and that all successful IT engineers should constantly revisit.

1. Do not mistake cause for correlation.
2. Do not assume that past experience is any indication for resolving current issues.
3. Seek out another set of eyes when you’re experiencing issues.
4. Be humble in understanding that asking for help is not the sign of an inexperienced engineer; it is the sign of an experienced one.

It turned out that the issue was that the image I had used to import the DC had an IP on a different subnet assigned to it. It was a simple and logical mistake that was easy to overlook. Having another engineer come in and look at the box and ask a simple question instantly provided me the solution. I felt silly and a little stupid that I had overlooked such an obvious mistake - but I would have felt far worse if I had sat trying to troubleshoot the issue by myself for any length of time. My mindset was oriented toward chasing down the wrong set of causes based on my previous experiences - and that is a very common mistake for IT employees to make when troubleshooting. It doesn’t matter if you’re at the help-desk or enterprise engineering, everyone who works in IT eventually encounters a situation like this. I’ve been on both sides, too. I’ve been the engineer barking up the wrong tree, and I’ve been the engineer that pointed a co-worker in the direction that helped resolve their trouble.
Sometimes it is the soft skills that are most important to being successful in this industry. We spend a lot of time focusing on the technical knowledge and training. A comprehensive knowledge of a platform isn’t going to help you avoid spinning your wheels over an issue like this, though. Having both the hard and soft skills is the difference between being stuck in a position and being a star performer who is recognized in your organization and among your peers.
Do you have a similar experience or perspective to share? Let us hear your examples in the forum.