What You Won’t Know; What Hurts You.

Tech Support is You: A Scenario

Suppose, upon arrival at work next morning, you find yourself engaged in the minutia of the illustrious role of Systems Analyst; PC Tech Support; IT dude / IT chick: whatever the term used to summon your attention, your duties are essentially to save-the-day for all you survey, as the one-and-only, all-purpose, resident computer guru.

Sir! Ma’am! Uh, I can’t find the “any” key!

Through the din of finger-snapping atop raised arms waving, you hear pencils and pens, tap-tap-tapping from various cubicles, surrounding you on arrival as if in a tick-tock mockery, these subjects grow impatient with your attempt to assist others, one-by-one.

Regardless of each User’s private Operating System of choice; whether he is a PC, she is a Mac, or the group is Linux, as half are devout Debian, and half are faithful Fedora followers (each of the latter, a contemporary Unix derivation), let us assume this enterprise runs on a basic LAN, where each user is accommodated with his or her own Microsoft Windows XP system, and associated, assigned login ID’s.

One at a time, over the course of the morning, each user on the LAN seeks your assistance with a system problem. With an unusual coincidence of problems, you deduce each individual system on the network is suffering from a malfunction at the primary access point, since the symptoms appeared to propagate throughout the network in a uniform manner.

Go Right to the Source: Ask the Horse!

With productivity impacted, slowed, or even stalled completely, you jump into action, searching the vast Microsoft Knowledge Base for a hint of a solution to the problem. After scanning several redundant, cross-referenced, often cryptic texts (devoid of the concrete solution desired– as to download a hotfix, or other software related resolve for the problem), a bit of sidebar text catches your eye. The details are enough to make one’s jaw drop, yet somehow the revelation comes as no surprise:

The following is an excerpt from one such KB items of my recent perusal. Maybe, in another ten years, I’ll feel 100% confident about how to run a secure [ Win Xp ] system.

You must be logged on as an administrator or a member of the Administrators group in order to run the computer in Recovery Console. If your computer is connected to a network, network policy settings may prevent you from completing this procedure.

My question: if my system is connected to a network (which it is, of course), does this mean

  1. I may be unable to complete the process of logging in as an Administrator
  2. I may be unable to run the computer in Recovery Console

My second question: how do I find an answer to my previous question?

I came across the article while searching for some peace of mind, as I contemplate how I might best handle a problem with my Win XP system in which my user, a member of the Administrator’s group remains unable to perform tasks with require administrator privileges.

What then is the Systems Administrator to do, in order to solve the problem, if the system(s) do not recognize the user (and associated actions) as being of the Administrator group? In other words, if the Administrator hasn’t the permission to initiate processes to lead to resolving the problem, what possible alternative might there be?

I realize that, to imply generalities about Windows is to do little more than jump aboard the same, tired old bandwagon. As well, my text isn’t entirely clear as I cite nothing specific, but this entry is bourne of my own frustration as I believe I’ve reached a dead-end in an attempt to repair my own system; a system which is a part of a simple home network.

  • Where are the real answers?
  • What solutions might a real Sys Admin employ, if he or she were responsible for the productivity of the entire (small) enterprise?

Note: it is not recommended to operate a Windows [XP] system under a username which has administrative privileges.

Whatchu do


Leave a Reply

Your email address will not be published. Required fields are marked *