Thursday, April 26, 2007

AJAX One: What it is, and isn't

Let me establish one thing first: Asynchronous Javascript And XML is just a codeword. It's not a technology - In fact, it's the combination implementation of a couple of technologies that have existed for a long time -, and it's not necessarily necessary (or even useful!) on many websites. What it can be is a very useful way to increase the interactivity of web based applications... when used effectively.

First, lets talk about the XMLHttpRequest, the driving force behind AJAX. W3C defines the XMLHttpRequest object (implemented in both JavaScript and JScript) as follows:
The XMLHttpRequest interface can be used by scripts to programmatically connect to their originating server via HTTP.
Basically, the XMLHttpRequest is a way for a script (generally executed on a client machine after the document has been fully loaded) to get information from its server without reloading the page. As far as the end user is concerned, this means the buttons and links are more "interactive". Also, as I'll discuss in "AJAX Two: Building a basic request", Microsoft and Mozilla have come up with different implementations of the XMLHttpRequest.

You'll notice there is nothing in W3C's definition of the XMLHttpRequest mentioning (a)synchronous execution. Frankly, this is because the execution style isn't a integral part of the object. "If that's true," you may find yourself asking, "why is the standard AJAX and not some synchronous brother? There's got to be something to this asynchrosity." You're absolutely right, the ability to make our requests asynchronously, or outside of time, makes everything faster for the end user.

Let me interject myself for a moment to distinguish between the two request styles: Simply put, a synchronous request (or operation of any kind for that matter) is one that must complete before the next operation begins. An asynchronous one is just the opposite: one that does not need to be completed before execution continues on the page. This is made possible via the response handler function (onreadystatechange) assigned to the request object before it is opened. Every time the request changes its ready state (eg progresses in retrieving the data) it calls the assigned function.

That means, though it may seem counter-intuitive, an asynchronous request can actually speed up a web page. Imagine a site that wants to display data about football players on over four thousand pee wee teams nationwide (for early college recruitment of course). Each record takes about two seconds to retrieve, but may take up to fifteen on slower connections. So, on a quick connection (two seconds) there's only a small potential difference between the synchronous and a- versions of this request... but on the slow connection (fifteen seconds!) the entire page halts while the request is processed if it's not asynchronous!

I do not mean to suggest that synchronous requests are useless, in fact, I use them almost as often as a-'s. A synchronous request should be used in any situation where the processing of the request must be completed before the next operation commences. Take for example a dialog box that needs to close after it processes an XMLHttpRequest POST operation. If this is attempted asynchronously, the request will have no way of calling its response function (which is destroyed along with the closed window) and will report a component failure.

One final note on AJAX before I click the magic "PUBLISH" button (!). Adding it to a website because it's "cool" or a "fad" without understanding why, or how, is akin to adding a mortgage calculator to your sports blog for the same reason. Don't do it. There are many amazing applications of AJAX (Google's GMail for instance relies heavily on them in creating their UI), limited only by the ingenuity of the programmer. They do not include retrieving a script file or stylesheet which can just as easily be loaded with the original document.

If your website could be made better through the use of XMLHttpRequest's (AJAX or otherwise), by all means use them... but learn them and understand them first. Doing otherwise is like publishing an ASP/IIS programmer trying to publish an Apache/PHP website with no prior experience (in other words, laughable).

Labels: ,

Wednesday, January 03, 2007

Internet Explorer 7 - The Uninstall

This post relates to bug with uninstalling certain versions of Microsoft Internet Explorer 7 which leaves you unable to use Windows. Beta 3 seems to be the most affected, but other versions can experience the flaw as well. To see just the solution, scroll to the bottom of this post... otherwise, enjoy the story that led me to it!

Recently a friend of mine asked for help removing Microsoft's latest brain child, Internet Explorer 7. The program was causing links from other programs (Novell GroupWise for one) to misbehave (ie not open). No problem, for once in their lives, Microsoft actually provided a relatively straightforward removal process for the browser.

According to MSKB 927177, you either use the Add/Remove Programs tool or the provided uninstall utility to remove the new browser. In Add/Remove Programs it is listed as Windows Internet Explorer 7, Microsoft Internet Explorer 7, or Internet Explorer 7. The utility resides in %windir%\ie7\spuninst where %windir% is your WINDOWS directory (normally C:\WINDOWS) and ie7 is a hidden directory.

Now, the friend I was working for had already received the aid of numerous online blogs and forums instructing him to run the Add/Remove programs tool, and delete most of the IE7 directory structure. Unfortunately, this left him with IE7 still installed, and none of the necessary tools to perform a full uninstall.

IE6 installers will not run while any of the IE7 files exist on your computer, and rerunning the IE7 installer did not reinstall the necessary uninstall files. Assuming all versions of IE7 were created equally - and this was my first mistake -, I VPN'ed over to another client's network and snagged their %windir%\ie7 directory to perform the uninstall with. The uninstaller ran fine, and I figured that would be it.

Upon reboot I was greeted with a message from the Borland Wireless tray (and just about every other application that runs on startup) that iertutil.dll was not found. Explorer.exe (the user shell) wouldn't open, and none of the GUI was working particularly well. Luckily I was able to grab the iertutil file from another machine, burn it to CD and transfer it to the system32 directory of my friends computer. This made everything run correctly... mostly. The new version of iertutil.dll I had borrowed was apparently incompatible with my friends laptop. I received an error akin to "Ordinal 57 cannot be found in iertutil.dll". Great, all this work and I still was not done.

Finally, I was forced to rerun the IE7 installer, which, as promised, rebuilt the correct version of iertutil.dll. It also unfortunately reinstalled the IE7 I had worked so hard to remove. It did recreate the appropriate Add/Remove Programs entry, and the %windir%\ie7\spuninst directory, but after having spent almost two hours with the original fiasco, my friend and I decided to leave it as is.

THE QUICK FIX


You're probably looking at a computer with desktop, a working mouse and keyboard, and an error message that says "This application has failed to start because iertutil.dll was not found. Reinstalling the application may fix the problem." Don't panic, this situation is entirely fixable.

To start with, you should be able to launch a Task Manager (Ctrl-Shift-Esc). On the Applications tab, you'll see a "New Task..." button.

Click the button, type "cmd", and press Enter.


Type the following commands:

- cd \ <== Navigate to the root of your C drive
- dir c* <== Search for the directory where you unzipped your IE7 files... normally a long string starting in c
- cd c... <== Navigate to the directory where your IE7 files are
- copy iertutil.dll \windows\system32 <== copy the files you need
- copy normaliz.dll \windows\system32


Now, your directory structure might be a little bit different (eg, you may have \WINNT\system32 instead of \windows\system32). If you cannot find the IE7 unzip directory, I'm hosting a copy of the required dll's on this site. Feel free to download them, but remember, they may not be the right version for you.

Wednesday, December 27, 2006

How Not to Make Your Technicians Day

We've all had them. An irate customer calling at an atrocious hour with an ultimatum: "You have thirty minutes to have me back online or your fired, AND I'm telling all my friends to fire you."

Normally, the problem is caused by a - moronic at best - user error. Some new program update fried the server, somebody spilled coffee all over the most expensive printer, one of the employee's children decided it would be fun to unplug every patch cable in the office... the details may be different but the result is the same. Here's a couple of my favorite.

"MY PROFILE IS BROKEN!!!"
=============================
The Scenario: One of our more problematic clients uses a very difficult piece of software. In fact, updates seem more likely to damage the data and break the program than fix their intended error. As a result, every time this software is updated, we expect a slew of calls about all the errors it has caused.

On one such upgrade, we receive a frantic call from our client: one of the user's has lost her entire profile. This user was, of course, in charge of payroll for both the employees and investors and therefore had a LARGE number of irreplaceable, not duplicated, and not backed up files on the profile in question. No questions, no hesitation, we were on the scene.

The Real Scenario: For users who use the "Windows XP" style start menu, an option called pinning exists. Basically, this start menu is divided into two major sections. The right side offers shortcuts to programs most people use frequently (My Documents, My Music, etc) and DOES NOT CHANGE. The left side heuristically offers shortcuts to programs you use frequently and frequently changes. Now on the left, anything that you want to not move, you can pin. This moves the item from the bottom left (where Windows manages links), to the upper left.

To pin an item, you either right click it and choose "Pin to Start Menu", or simply drag and drop it. To unpin the item, you choose "Unpin from Start Menu" on the context menu. Intuitive, simple, and pretty self explanatory. Our user who had been suffering from a "broken" profile had accidentally unpinned an item, and pinned another its place. This resulted in her being completely unable to work until I gave her a brief primer on how the Start Menu works.

SCORE: Computers 1 | Users 0


"WHERE ARE ALL MY FILES?!?!?!?"
====================================
Automatic file organization has come a long way since the days of MS-DOS.
Everything will be installed to the root of C: or your computer will cease to operate. If you choose to store any file in a subfolder, you risk losing it.
Today, (most) programs conveniently install themselves in "Program Files" (a folder your average user doesn't even need to know exists), system files (critical to the operation of Windows) go in "WINDOWS", and everything else is stored in the user profile "Documents and Settings\>username<". Surprisingly, or perhaps inevitably, this automatic organization has done little, if anything, to combat file atrophy.

Most users consider files to be stored on their Desktop (actually located at "C:\Documents and Settings\>username<\Desktop". They place shortcuts to their files here and are terrified if anything happens to those shortcuts. I am frequently hailed as a genius when I restore these shortcuts, or in my clients eyes, perform a "miraculous file recovery".

Even with this error being so common however, I couldn't stop myself from laughing when I came across this. A user was approximately the fourth person to sit at a particular station. The computer was configured to use automatic login (to the Administrator account no less... GAH) and previous tech consultants hadn't bothered to create new profiles for each successive user. As a result, every user, not wanting to accidentally delete old files, had created a folder for themselves in the previous users folder then shortcutted it to the desktop. This resulted in the following file path being the location of basically every important file on the computer: C:\Documents and Settings\Joe\My Documents\Carol's Files\JL\Current Documents\Winery Files.

After the computer was upgraded and the files transferred, the previous desktop shortucut didn't work (the original owner had configured the hard drive to store profiles on a seperate partition). I get the phone call explaining that in our upgrade we've unwittingly deleted all the files. It honestly took me twenty minutes to find the files this user wanted because of the levels of nesting in My Documents that was going on.



"WHY CAN'T I ACCESS COMPANY DATA ANYMORE?"
=============================================
This is my personal favorite of today's three stories. All the bussiness networks we support have at least one central file server/application server/e-mail server (depending on the networks needs). Computers are configured to access data directly off the server so 1) They all see the exact same data, and 2) That data is backed up daily. Now, this does unfortunately some times cause data access errors.

A user called to tell us that she seemed unable to open any accounting files. We went through the basic troubleshooting first: is the program opened correctly, are your data paths set properly, are you connected to the internet, etc. Everything checked out and we still couldn't get at the data.

Time for step two: Remote Desktop so I can fix the problem. In general in scenarios like this which call for more advanced troubleshooting, RDC is a lifesaver. I RDC'ed into the server and was ready to nest to the user's laptop, but the connection wasn't working. For some reason I couldn't even ping her. This lead me to suspect firewall issues, so we spent about twenty minutes troubleshooting that with no luck.

At this point, I have no choice but to start walking the user through advanced troubleshooting using the command prompt. Her IP address is set fine, her DNS lookups are all getting replies, she can ping any website, it's just the company network that seems to be malfunctioning.

I have her run "netsh int ip show dns" and she tells me her DNS is configured via DHCP. Bingo, I think to myself, DNS error leads to local name lookup errors. No luck after we manually set it to the server. At this point I'm about ready to give up. We run ipconfig one more time and I have her read me all the data line by line. When she mentions that her connection specific DNS suffix is set to sbcglobal.net a red flag is raised for me. This particular company uses Charter Cable internet, not Verizon as their ISP.

I have her check her Wireless Networks and it turns out she's connected to "linksys", not "company" like she should be. I figure she must have picked up one of the neighboring offices signals and accidentally connected to it. "Go ahead and choose connect to 'company'" I tell her only to find out "company" isn't listed as an available network for her.

Odd. That means someone turned off the WAP at the office. That's not supposed to happen.
ME: "Go talk to Heather, the WAP is in her office, maybe she unplugged it."
USER: "Oh, Heather's at work right now."
ME: "Yes... and you are?"
USER: "I'm at home. I went home early but wanted to finish some work up now."
ME: (flabbergasted) "Your at... home?"
USER: "Yes. Is that a problem?"

Obviously, that's a bit of a problem. In case your ever wondering, files on your company network are... ON YOUR COMPANY NETWORK.

Monday, December 11, 2006

Google's Newest: Click to Call

I ran across a neat looking toy today on Google Maps. The service "Click to Call" works in tandem with the bussiness addressing and mapping features they already provide free of charge.

Basically, when you click "Call...", you enter your phone number. Google calls you, then automatically connects you to the company you've clicked call for. On both ends, Google's role is transparent, meaning:
a) Google's service only maintains your phone number for as long as is prudent to operate the service
b) When you get the call from Google, you see the companies phone number on your Caller ID
c) The company you call sees your phone number on the Caller ID

The service is accessible from any current Google Maps page.

Monday, November 20, 2006

User Accounts VS User Profiles

Perhaps one of the most common questions I'm asked is: "Can I move my user from one computer to another?" or "Can I change my username?". The simple answer is to both is yes... but the mechanics providing that answer are, I dare say, more complex.

In Windows NT Architecture there are two concepts that control a user's experience with the operating system. The first one, the account, is responsible for security settings, password management, Access Control Lists (ACLs), Domain Membership, and most other security related tasks. The second, the profile, stores user data (files, cookies, backgrounds, etc) and settings (preferences, e-mail settings, themes, start bar configuration, etc).

While they are interelated, the account and the profile are two DIFFERENT things. That is to say, a user can have only an account on a computer (the profile should automatically be created at first logon), or only a profile on a computer (the files and settings exist, but the user cannot logon to access them). They are connected via an SID (Security Identifier) which is stored in the registry. Should this connection be severed (which can and does happen), restoration can be a long painstaking process to the user who doesn't understand the profile and the account.

The SID


This portion covers a more technical approach to the user account by explaining the SID. While interesting (and something I hope you'll enjoy reading) it is not critical to your understanding of the Account versus the Profile. I explain the relationship between the two (which occurs via SID) in the last paragraph before the section titled "The Account".

When a Windows XP computer is first configured, it remains non-uniquely identifiable until it passes the graphical portion of Windows XP setup. At that point, the domain SID is randomly generated for the computer in the format S-1-5-[32 bit key]-[32 bit key]-[32 bit key]. This SID becomes the integral component of Windows NT security on that machine. It is used to establish trust relationships between Domains and the computer, to propogate security settings across the computer, and to establish simple file sharing in a workgroup environment.

At the time of the original SID generation there is also a series of accounts created, where the last portion of the SID is an RID (Relative Identifier) unique to the user:
   S-1-5-18: Local Service
   S-1-5-19: NT Authority
   S-1-5-domain-500: Administrator
   S-1-5-domain-501: Guest
   This is an abbreviated list. MS Provides a full list.

It follows then that each time a new account is created, a new SID is generated for that account. Unlike the generation of the domain SID, this only involves iterating the RID by one, and atatching it to the domain SID. For example, your "personal" user accounts on a computer might be:
   S-1-5-domain-1003: Joe
   S-1-5-domain-1007: Fred Johnson
   S-1-5-domain-1012: Mom
   NOTE: The potential gaps between RID's exist because Windows uses the SID for security objects other than users as well.

Any security request or operation made on the machine is done with the SID. The process which allows queries based on SAM Account Names to be made (or queries to be returned via their SAM Account Name) is called SID/Name translation. Basically, internally Windows refers to everything by it's SID. ACL's are created and destroyed by SID's, foreign computer's expect an SID, etc.

For convenience's sake, Windows uses the SAM Account name to refer to user objects externally. This can create a potential security hole if Anonymous SID/Name translation is enabled (it is disabled by default on all XP SP2 systems). If an anonymous user is granted access to your machine at any point (Windows file share, IIS Share, FTP service, etc) an anonymous SID/Name translation attack could be launched. Once the domain SID is obtained, the system's security would be completely compromised.

I mentioned earlier that Windows uses the SID to maintain the relationship between an account and a profile. Remember, the SID is, quintessentially, the account meaning the link only needs to be between the SID and the Profile. This link is stored in the Registry Value (REG_SZ): HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\[User SID]\ProfileImagePath. The ProfileList key contains a key by SID for each user account on the machine (excluding certain special accounts).


The Account


In Windows XP there are four ways to view and edit User Accounts. The first approach uses a simplified GUI to present your average user with only commonly used options regarding User Accounts. This screen is accessible by default from the Control Panel (User Accounts button), or by typing "control userpasswords" into a run box. This interface is the easiest way to enable/disable Fast User Switching (the ability to have mulitple users logged on simultaneously) and/or the Welcome Screen (required for Fast User Switching; A simplified logon GUI).

It also provides a simple way to create and delete accounts, but it does so in a very limiting fashion. First off, following with the prinicipal of least control, you must have at least one administrator account (other than "administrator") on the computer. Second, the only options available for groups are "Administrator" (Full System Control), "Power User" (very extended system control), and "Restriced User" (enough control to do most common tasks).

Interface number two is really just a glorified version of the simplified user accounts panel. It is accessible from the "Classic Control Panel", or by typing "control userpasswords2" into a run box. There are two differences between the first two interfaces. First, this second interface displays all enabled accounts (including Guest and Administrator) and second, it does not use wizards.

The third interface is the most popular among sysadmins. Unfortunately, it is only available to user's of XP Professional (sorry XP Home guys, you'll have to wait to here about this tool's command line partner). You can access it from the "Advanced" tab of "control userpasswords2", or by opening a new MMC (type "mmc" in a run box) and adding the "Local Users and Groups" snap-in. This tool gives you full graphical access to Windows accounts, enabled, disabled, and otherwise. It also allows you to create your own security/distribution groups, and allows a more intricate level of control over their membership.

The fourth tool "net user"/"net accounts" is not technically the final way to edit user accounts, but it is the final common way. To use it, open a command prompt (type "cmd" in a run box) and type "net user [command]". This tool can do everything the MMC Snap-In can do, but is obviously a bit more complicated. Help on it is available via the command "net help user" or "net help accounts".

It's great that there are so many ways to edit accounts in Windows NT, but what exactly do those accounts do? The account is a security principle. It supplies credentials for a user to access system resources (files, programs, open processes, etc). It allows you to setup NTFS permissions on files and folders explicit to that user. A user with only an account would be able to FTP or Windows File Share access your computer.


The Profile


User profiles are automatically created the first time a user account is logged into a computer. At that point, the appropriate registry entries are created to associate the account and the profile. All profiles (by default) are stored in the Documents and Settings folder at the root of the Hard Drive (C:). There are ways to change this (including an undocumented pseudo-hack of the shellfolders registry key), but unless you're in a domain environment, I wouldn't.

The name of the folder created use done heuristically. Windows will first attempt to use the username (EX: C:\Documents and Settings\John). If that is unavailable it will add .DOMAINNAME (computer name for non-domain computers) (EX: C:\Documents and Settings\John.JOHNSCOMPUTER). Barring that, Windows will add .xxx being a three digit number incremented as many times as necessary (EX: C:\Documents and Settings\John.JOHNSCOMPUTER.001). You don't have to know your profile path though, simply typing "%userprofile%" in the address bar automatically takes you there.

By default, the NTFS security descriptors grant full control to the owner (the user account) and the local administrators group. This means User's cannot access each other's documents if they are stored in My Documents or on the Desktop. MS provides a basic solution to this with "Shared Documents". Shared Documents is really the All Users My Documents folder, which by default has Full Control to Everyone security permissions. As a result any file in the Shared Documents folder is accessible to everyone.

The user registry hive (HKEY_CURRENT_USER when logged in, HKEY_USERS\[User SID] otherwise) is also stored here in the file "ntuser.dat". This is a hidden system file which you should not edit unless you are absolutely confident you know what you are doing. It contains settings such as where your desktop icons are located, what them you're using, etc.

Many program data files and settings are hidden within he user profile as well. For example, two of the most popular e-mail programs, Outlook and Outlook Express store their e-mails/address books in the profile. Outlook has both of these in one database (Personal Folder File format: .pst) located at %userprofile%\Local Settings\Application Data\Microsoft\Outlook\Outlook.pst. OE seperates them. Every folder has it's own .dbx file in the OE store directory: %userprofile%\Local Settings\Application Data\Identities\OE Identity String\Microsoft\Outlook Express. The Address Book for OE is stored sperately at: %userprofile%\Application Data\Address Book\username.wab.

Cookies, Favorites, Temporary Internet Files, Temp files, Installer Data, and a whole mess of other stuff is also hidden within various levels of the user profile. If your lucky, the program whose data you want will reference it's location somewhere... otherwise you could be searching for quite a long time.

Friday, October 27, 2006

Windows Vista: User Accounts Control

Windows Vista will introduce a "new" concept into Windows: User Account Control. No, surprisingly, this isn't another new way for Microsoft to regulate what you do online. It's not the beginning of a Big Brother program. Actually, it's designed to make the programs you already have installed on your computer work better. Surprisingly, for the first time, Microsoft may have done just that.

Priveleges and The Principle of Least Control


One of the core concepts in computer development is security. Actually, the reason for this is twofold. While it may be readily apparent that a would be intruder will have more trouble with a system designed to block his attempts to alter your critical files, protecting those same files from the user themselve isn't so obvious.

The simple fact is, your average user knows very little about how to use a computer effectively (at maximum productivity) let alone how it works its magic. Unfortunately, that means users are their own worst enemies. Just like a car manufacturer provides a simple ignition/accelerator/brake and encloses the pistons, rods, hoses, and other components in an inaccessible area, computer manufacturers provide a user interface. Unfortunately for the computer world, that interface is expected to be upgradable, changeable, and generally fully accessible.

To this end the principle of least control was born. At any given moment a user needs only enough control (access) over their computer to perform the specific task they are trying to do. Normally this doesn't include setting the clock, installing a program, or editing a system file. Accordingly, the principle dictates the user (in that moment) should not be allowed access to those system areas. This would in turn prevent an unauthorized agent (for example an Internet Active X control, a Trojan, or a Hacker) from performing the same task pretending to be the user.

Because we don't keep our computers exactly the same all the time, we likewise need a way to edit system components at any given time. Linux/Unix clones give us the "su" (super user) command for this task. The command prompts the user for a password (generally the "root" password) and if it is authenticated grants unrequited access to the machine (within the su session area). When the user is done, they simply type exit and return to normal access. This means that for all of eternity, Linux users have been more secure in principle in their computing environment. They don't run as administrators.

Don't be an Administrator, use "Run As..."


I know I pretty much just covered this with the bit on the principle of least control, but I can't reiterate it enough. When you run your computer as an administrator, you give yourself unaudited access to your machine. Good, right? Wrong. The fact is your not the one who's going t use that access, the website which is trying to hack you is.

The ActiveX control, when installed, can impersonate a user and perform operations on a machine. Granted, post XP SP2 ActiveX controls no longer automatically and without prompting install and run themselves, but most sites will advise users of this anyway. In actuality, a well written scheme can easily find its way onto a users computer... yes, even a "power users" computer.

If your running under non-admin priveleges this scheme is entirely powerless. It can only do what you would otherwise be able to do. On the other hand, if you're running as admin, you've handed your computer over on a silver platter.

So, for all the Windows users out there, what are your options? The su command is available under Linux clones only, although even if it were, the command line eludes most Windows users. Windows does fortunately have a similar, albeit almost more friendly version of the same.

First off, you need to create yourself an account with limited priveleges and run under that for normal, day to day operations. Then, whenever you need to do something that would normally require admin priveleges, instead of logging out, loggin in as admin, doing it, logging out, and loggin in as you, use the "Run As..." command. By holding the Shift key while you right-click something, you access the Run As... option. When you click it, it will prompt you for the credentials you want to run the command as.

Beautiful. If you enter "Administrator" for example, that process AND ONLY THAT PROCESS will be run with full admin priveleges. It works using the Secondary Logon service, which coincidentally also provides "Fast User Switching" capabilities to many users. When you finish your task and close the window, the administrative priveleges dissappear, and your free to behave irresponsibly again.

User Accounts Control


Windows Vista (as of Beta 2 without the Technicial Refreshes) expounds upon Windows XP's introduction of "Run As...". User Accounts Control is a built in required feature of the Operating System in fact. Basically, any user, including an adminstrator, is restricted from root level (su) priveleges. Whenever they try to access a component that would require those priveleges they are prompted for appropriate credentials.

As per Microsoft's general modus operandi, the UAC console kindly informs you that if you're not sure, you should probably choose to cancel. In fact, the average user who doesn't remember having seen this in their XP computer may do just that and wonder why their program never opened.

There are some limited options allowing the custimization of UAC screens and blockings, but in the beginning it will be little more than a hindrance for users. As I recall the message UAC greets you with informs you that "a request has been made to access a restricted component. Windows needs to verify that you made this request. If you made the request, please enter the password to continue now, otherwise, you should not continue." As I said, cryptic at best.

What exactly is a system component? Especially considering one may be accessed for something as simple as scheduling an appointment (depending on how the program you use works). How do you know if it's an appropriate request? What harm could happen if you just entered the password (which I have already addressed in this entry)? Most importantly, how many more damn times are you going to have to dismiss the UAC console to try and get your work done.

I mentioned as I started this blog UAC is designed to help make what you already have installed work better, and surprisingly, it does. As my next entry will explain, most programs are not written with a terrible amount of concern for how things are done, they only want the result. That unfortunately means a lot of programs commonly perform tasks normally reserved for Administrators. UAC will force these programs to run in a bubble where they can continue to execute their potentially dangerous code without endangering the rest of your computer.

Wednesday, October 18, 2006

Hard Drive Failure

No matter what you use your computer for, or how often you interact with it, odds are you've seen a symptom of HDD (Hard Disk Drive) failure at least once in your life. This could have been something obvious - a famous Blue Screen reading "UNMOUNTABLE_BOOT_VOLUME" - or something a little more elusive - certain files and folders seeming to "disappear" without warning. No matter your experience, you know that when it happens, it's not fun.

As a technician, I would estimate one of the scarier things to be told is "your hard drive has crashed"... a message which I give countless times a month. Normally, it's not as dire as it seems, but the message is still the most effective I can give. While the specifics vary, the general situation is this: I respond to a client reporting a "computer that turns off as soon as it shows the Windows XP logo". Upon arriving I disable the automatic reboot setting (this is made possible at the Advanced Boot Options Menu thanks to a recent Microsoft Update) and am greeted with a blue screen message along the lines of "UNMOUNTABLE_BOOT_VOLUME" or "NTLDR Is missing or corrupt".

Stop. At this point, I know only one of two things: a) The NT Boot Sector is corrupt or missing; b) The MBR Is corrupt or missing; In and of themselves, neither one is indicative of a crash, yet I'll inevitably tell my client they are. Why? Well, before demonizing me, realize that the basic reason is to benefit the client.

Hard drive crashes are something most people feel they can relate too. They know it means nothing they did caused the problem, which in many cases is just as important as the fact that the problem is resolvable. Ultimately, it gives them enough information to provide a brief synopsis of the problem without overburdening them with the gory details. The unfortunate tradeoff for this solution is the fear of data loss. I know, it doesn't seem fair, but based on consumer expectations, it's easier for both myself (who doesn't have to have a client watching my every move) and the client (who at least feels like they know whats going on).

The Symptoms


Hard Drive faiulre is not only one of the most potentially detrimental problems I see, it's also the hardest to spot. Allow me to tell two stories to demonstrate my point. While both ended in Hard Drive failure (and fortunately complete data recovery), only one was caught before the failure occured.

SITUATION ONE: An irregular client of mine called reporting printing trouble. After walking him though the common troubleshooting steps over the phone, I agreed to come out. I was greeted by one of the strangest printing errors I had ever seen. The Windows Print Spooler service absolutely refused to stay active. The couple of times I did get it working it didn't work properly. Printer drivers would report strange errors, anything that did print was garbled, nothing really seemed to be working.

Finally, I decided to run a slew of system tests. My intention was actually to isolate a possible motherboard or cable error. Luckily for the client, included in that standard set of tests was a Hard Drive integrity test. When the drive gracefully failed, I realized what had been happening all along. Immediately, we RMA'ed the drive, backed up the data, and rebuild the machine. The next day, printing was up and running.

SITUATION TWO: One of my client's is rather problematic. Since she decided to replace her desktop with a Dell Lattitude (on account of problems with the desktop), we have been there to fix something frequently. The problems range from not knowing there's a physical "On/Off" switch for a wireless adapter to not being able to connect to the network.

This particular case a connectivity issue; one that started immediately after another technician (not affiliated with my company) had tried to connect the laptop to home wireless. Because the computer is a bussiness machine first, and then a personal computer, anything the other tech had done seemed null and void.

I sat down, ran ipconfig and immediately saw there was no default gateway set. Unusual, especially considering another tech had just serviced the machine. Not worrying about it too much, I statically configured the gateway, IP, mask, and DNS servers. Voila, the machine was working.

The next morning, like clockwork, we received a call from the same client. Her hard drive had just crashed and she couldn't work. Incidentally, this was the second hard drive failure in this machine since purchase, and we ended up RMA'ing the entire box.

THE ANSWER: So, what caused the strange symptoms in both cases? Well, the answer to that has to do with what actually happens when a hard drive fails. A hard drive is a magnetic disk divided both pyhsically and logically into sectors. A physical sector is, without getting to complicated, a definition of a magnetic region. When a physical sector goes bad, it becomes entirely unusable, and any data stored on it becomes inaccessible.

Conversely, a logical sector is a file system's (eg FAT, EXT3, NTFS, WFS, EFS, etc) description of a where data is stored. when a logical sector goes bad, it's really just the file system information having a problem. Tools such as chkdsk can (and do) often fix these problems. When they don't, performing a low-level format (indiscriminately writing all 0's then 1's across a drive) almost always recovers them.

So, when a Windows based hard drive fails, the data sectors start becoming inaccessible. Being the "user-friendly" operating system, Windows tries to compensate. In the case of the printer, when the service became inaccessible (physical bad sectors existed where the services files were stored), windows reported it as failing. With the networking, the data on the gateway, DNS, etc was inaccessible, so Windows reported it as missing (unset).

While this may make things easier for a user in the short run, in the end they're relatively useless.

The SolutionKeep a regular backup. In a future entry, I'll be covering the usage of Microsoft's free backup utility "NTBackup". When used with the built in Windows Task Scheduler, this utility gives you the ability to automate a daily backup of any file, every file, your entire file system, or even the system state.

My only other advice is to be attentive. While you may be graced with an odd clicking sound prior to a crash, you're just as likely to only get some unexplainable behavior. Most computers come with built-in diagnostic software these days. Check your documentation to see if you have a "drivers and utilities" cd. You might even have a built in diagnostic boot sequence, usually accessed via F12 or F10 at boottime. Maxtor, Western Digital, and Seagate also provide free tools for use with their hard drives.

Hard drive failure suck, no question, but with appropriate care, they can be made to cause minimal damage.