Like most veteran Windows users, I balked when I first encountered the User Account Control (UAC) mechanism in the latter BETAs of Vista. The constant interruption of nearly every system or maintenance related task was unbearable. Finally, after one particularly frustrating bout of "move the file/yes I really want to move the file/please let me move the file/sorry, do dice buddy," I did what many early Vista users did: I turned UAC off.
Hint: For those of you who haven't figured it out yet, the option to disable UAC is buried under the User Accounts sub-section of the Control Panel.
Ah, the bliss of no UAC! I could now do whatever I wanted, whenever I wanted! It was just like Windows XP, but with a cooler UI!
I operated this way for over six months, and while I relished the freedom, I couldn't help but wonder if I had done the right thing. Despite my confidence in my own ability to weed-out threats (e.g. 20 years in the industry makes me a poor target for social-engineering attacks), I still had this nagging feeling that I simply wasn't being smart about the whole UAC thing. Add to this the nearly constant deluge of pro-UAC comments and articles from every Microsoft source, and I found myself slowly gravitating away from the "rebel yell" mentality and towards the "boundaries are a good thing" camp.
But in the end, it wasn't Microsoft or any of its products that pushed me to re-enable UAC in Vista. Rather, it was my recent round of Linux-hosted virutalization testing. Under Linux, it seemed like every other task required a "sudo" qualifier/login or equivalent Gnome dialog box. Suddenly it dawned on me that this is in fact the way things *should* be. Running as "root" (to use a UNIX/Linux term) was simply bad policy. You're all but asking for some malicious script or rogue executable to have its way with your system.
So I did the unthinkable: I turned UAC back on and rebooted my primary Windows development system. And then...nothing. The sky didn't fall. My desktop icons didn't vaporize. In fact, other than one minor startup glitch (the Bluesoleil Bluetooth stack I use got flagged as being an "unknown" startup application by Windows Defender), I couldn't see much of a difference.
Eventually, I ran into my first UAC prompt (I was trying to launch the Windows Services applet) and simply clicked through. Later, I noticed that Task Manager would no longer let me Start/Stop Services (normally a real time saver when debugging new code). I got around this by clicking the "Show Processes For All Users" button and confirming the elevation to UAC. Task Manager then restarted in unrestricted mode and I was able to access all of my favorite functions (hint: just remember to minimize it instead of closing it and you can run unrestricted all day).
Another great find: Michael Murgolo's Script Elevation Power Toy, which is available from Technet Magazine's code archive. In addition to providing new context menu options (e.g. running Windows script files as Administrator), it also introduces a new command line tool: elevate. Just type "elevate" before whatever command line tool you want to run as an Administrator and then confirm the elevation to UAC. Think Linux "sudo" for Windows, only with better GUI integration.
Armed with these tools, and a somewhat healthier perspective (thanks, ironically, to my work with Linux), I now look at UAC as more of an asset than a liability. And as I continue learning to live with UAC, experience is showing me that if and when I do encounter an elevation prompt, there's usually a very logical and legitimate reason why Windows is requesting user confirmation.
Next Up: Lessons learned while adapting some of my legacy Windows apps to work with UAC. Stay tuned...