Dropping rights when running as an Administrator

I am eagerly awaiting the arrival of Windows 7, because when it comes preinstalled on systems I am going to buy a new laptop. In the meantime, I am still operating mostly on Windows XP.

On my "main" machines, I run as a regular user, as detailed in my RunAsAdmin post. However, on some of my ancillary machines, it feels like too much effort to only be able to install programs after logging in as another user. However, I still want to protect these machines from web attacks.

The solution, I've found, is to selectively drop my Administrator rights from my login account when I do anything that connects to the Internet. This includes web browsing, instant messaging, and email clients. This way, the Internet-facing application only has normal user rights. This has the effect that even if some nasty program tries to get past my browser or email client onto my computer, it can't install itself because it is running in a process that doesn't have the rights to do so.

Microsoft used to have a program called DropMyRights that would do this on an individual application basis, and you can probably still find it, but they don't seem to promote it any more. It took a little while for me to find it, but the program that I now use for this is Psexec.exe, which is part of Microsoft's Pstools kit. This program has the ability to drop Administrator rights when it runs a program.

How to use Psexec to drop Administrator rights

1. Download Pstools to your computer.
2. Find the file you downloaded, right-click on it, and select Extract All.
3. On the first screen of the Extraction Wizard, click Next.
4. On the second screen, under "Files will be extracted to this directory," enter "C:\Program Files\Pstools" (assuming that "C:\Program Files" is the path to your Program Files directory; modify as necessary). Click Next.
   

5. The files will be extracted. On the last screen, leave checked the option "Show extracted files." Click Finish.
6. The directory containing the PsTool files will be opened. You should see Psexec.exe in the list of files. Double-click Psexec.exe. You may see two dialogs. The first one will be a Security warning that says "The publisher cannot be verified. Are you sure you want to run this file?" Uncheck the option "Always ask before opening this file." and then click Run.
   
   The second dialog will be the license agreement for Psexec.exe. Click Agree.
   
7. Now that we have Psexec.exe downloaded, we need to create a shortcut to your web browser that will open with limited user rights. For this example, find one of the shortcuts for Internet Explorer in the Start menu. Don't use the shortcut for Internet Explorer on the desktop if you have one - in many cases, this is a "special" icon that doesn't behave like a normal shortcut. Find a shortcut in the Start > All Programs menu, right-click it, select Copy, and then paste it to the desktop. 
8. Rename the shortcut to indicate that it runs the program as a limited user; I like to follow the application with the text "(Limited)", so that "Internet Explorer" becomes "Internet Explorer (Limited)".
   
9. Right-click on the copied shortcut and select Properties. On the Shortcut tab, click in the Target edit box. If you are using Internet Explorer, the Target will probably be something like
   
   
   
   "C:\Program Files\Internet Explorer\iexplore.exe"
   
   Click in the Target box at the beginning of the text that is there, and type the following:
   
   
   
   
   "C:\Program Files\PSTools\psexec.exe" -l -d
   
   so that the Target now reads something like:
   
   
   
   
   "C:\Program Files\PSTools\psexec.exe" -l -d "C:\Program Files\Internet Explorer\iexplore.exe"
   
   This runs Internet Explorer as a Limited user (-l), and psexec.exe doesn't wait (-d) until Internet Explorer has finished running.  Of course, if your path to either psexec.exe or iexplore.exe is different, substitute those paths for the examples given above.
   
   
   
10. Still in the shortcut properties dialog, change the Run dropdown to "Minimized window". This will prevent the black DOS box that Psexec.exe runs in from being seen.
    

Now you have a shortcut that will allow you to run Internet Explorer as a limited user. Use the same principle to make any program run as a limited user. Note that while running as a limited user, you will not be able to install any programs directly from your browser, including any ActiveX controls. This is generally what you want to do, but sometimes you will need to install some addons such as the Adobe Flash add-on. For those cases, I like to keep around a copy of the original Internet Explorer shortcut that I can run as an Administrator. I make sure that I only use it to navigate to the trusted site (like Adobe.com) to install the add-on, and then I quit it and relaunch the limited user version.

This brings up another issue: how can you be sure that you are running as a limited user? In Firefox, you can get the IsAdmin add-on, which conveniently displays an icon in the status bar that shows whether you are running as an Administrator or not. For Internet Explorer, Aaron Margosis has thoughtfully provided Privbar, which similarly shows whether Internet Explorer is being run as an Administrator or as a limited user.

Running Internet-facing programs such as web browsers as a limited user will allow you to keep most of the advantages of running as an Administrator while greatly improving your protection against malicious programs and web sites.

How to recover the File-Based Write Filter files from the WAIK

The File-Based Write Filter (FBWF) files allow you to build a bootable Windows XP or Vista disk that appears writable. This allows you to build a BartPE or Winbuilder boot disk that you can add drivers to at run time. The changes you make will be written to RAM, rather than to the disk itself, and will be lost on reboot. This is great for adding NIC drivers for your specific system at run time.

You can find several plugins for FBWF (like here), but the files are not included because they are Microsoft files. They are freely available, but it is somewhat tricky to retrieve them. Here is how to do so:

Tools you will need:
ISOBuster

1. First, download the Windows Automated Installation Kit (WAIK). This is a DVD ISO image that is just under 1 GB in size.
2. Install and run ISOBuster. Using the File > Open Image File command, open the image file that you downloaded in Step 1. Note that this file has an extension of ".img", so you may need to change the image selector in ISOBuster to All files.
   
3. In the root of the image, select the files WAIKX86.MSI and WINPE.CAB. Extract these files from the image, either by dragging them out of the ISOBuster folder to your local hard drive or by selecting them and then choosing File > Selected Objects > Extract Objects. For this exercise I will extract them to C:\Temp.
   Note: I chose the file WAIKX86.MSI because it matches my architecture. If you are on a 64-bit system, choose the appropriate "WAIK*.MSI" files instead. In each case, you will also need the WINPE.CAB file.
   
4. Run the following command at a command prompt:
   
   C:\> msiexec /a C:\Temp\WAIKX86.MSI TARGETDIR=C:\Temp\WAIK /qb
   
   This will extract all the files from the WAIK into the directory C:\Temp\WAIK.
5. Open the folder C:\Temp\WAIK\Tools\<architecture>. For most people, <architecture> is "x86".
6. Right-click the file "wimfltr.inf" and choose Install. This is necessary for the WIM mount later on to succeed.
   
7. Create the directory C:\Temp\winpe. Then run the following command:
   
   C:\> C:\Temp\WAIK\Tools\x86\imagex.exe /mount C:\Temp\WAIK\Tools\PETools\x86\winpe.wim 1 C:\Temp\winpe
   
   This will open the contents of the winpe.wim file in the directory C:\Temp\winpe.
8. Now you can find the FBWF files in the following locations:
   
   C:\Temp\winpe\Windows\System32\fbwflib.dll
   C:\Temp\winpe\Windows\System32\fltLib.dll
   C:\Temp\winpe\Windows\System32\drivers\fbwf.sys
   C:\Temp\winpe\Windows\System32\drivers\fltMgr.sys
   
   Copy them to a location outside of C:\Temp\winpe.
9. Once you have the files, unmount the winpe.wim file with this command:
   
   C:\>C:\Temp\WAIK\Tools\x86\imagex.exe /unmount C:\Temp\winpe
   
   
10. You can then uninstall the filter you installed earlier by running this command:
    
    C:\>rundll32.exe setupapi,InstallHinfSection DefaultUnInstall 132 C:\Temp\WAIK\Tools\x86\wimfltr.inf
    
    

How to host MP3 files on Blogspot

Here is a step by step tutorial on how to host MP3s on Blogspot. These instructions are based on the information from the Google Operating System blog. The basic overview is to upload your MP3 file to Google sites, and then use an embedded Flash audio player from Odeo to make it available to your readers.

1. Go to Google Sites at http://sites.google.com/. Sign in to your Google account.
2. Give your site a name. Fill out the rest of the information as you see fit. Click Create Site.
   
3. You will be brought to your site page. At the bottom of the page is an Attachments section. Click the little plus sign icon to the left of Attachments, then click the Browse button.
4. Browse to your MP3 file and then click Open.

5. Wait while Google uploads the file. If you want to, you can also edit the page to include explanatory information about the attachment, but it isn't necessary.
   
6. Once the file is uploaded, right-click on the link to the file under Attachments and select Copy Shortcut.
7. Paste the link text into a text editor. Remove anything that appears after ".mp3" in the link text. You should end up with something like this:
   http://sites.google.com/site/bluebearrblog/Home/FourSeasonsSpring.mp3
8. Now copy the code below, and paste it into your text editor.
   <embed src= "http://www.odeo.com/flash/audio_player_standard_gray.swf" quality="high" width="300" height="52" allowscriptaccess="always" wmode="transparent" type="application/x-shockwave-flash" flashvars= "valid_sample_rate=true&external_url=[MP3 file address]" pluginspage="http://www.macromedia.com/go/getflashplayer"></embed>
   Replace the text [MP3 file address] with the actual link to your MP3 file. In the case above, here is what it looks like:
   
   <embed src= "http://www.odeo.com/flash/audio_player_standard_gray.swf" quality="high" width="300" height="52" allowscriptaccess="always"
   wmode="transparent" type="application/x-shockwave-flash" flashvars=
   "valid_sample_rate=true&external_url=http://sites.google.com/site/bluebearrblog/Home/FourSeasonsSpring.mp3" pluginspage="http://www.macromedia.com/go/getflashplayer"></embed>
9. Open a new window, and go to Blogger.com. Open up a new post, or edit an old post.
10. Once you get to the point where you want the music file to appear, click the Edit HTML link at the top of the screen.Paste in the text ("<embed>...") from your text editor. Then click on Preview. You should be able to see a music player like the one below.

From Hyderabad with love

My current position means that I am "interacting" with IT people in India. I put interacting in quotes, because any interacting occurs via email, which doesn't much have "inter" in the "acting."

Anyway, I thought that it might be interesting to detail the path that a file that I received last week traveled from India to me.

This particular file was a 750 MB file that installs Microsoft Outlook 2007. My job was to get it from India and test it to see if it worked as desired.

The file started in Hyderabad, India. A lovely little place.

View Larger Map

Some bloke in Hyderabad copied it to a server in Preston, England:

View Larger Map

This is where I found the file. Since there is a bandwidth issue with the server in England, I had to wait until after 5pm UK time to copy the file down. But then I could copy to my little heart's content. It took somewhere over two and a half hours to copy down the file - really not too bad, considering.

Once I had the file on my computer, I copied it to a file server 50 feet away. From there I copied it to a laptop sitting on my desk. I suppose that I could have copied it directly between my two machines but, alas, I was dividing my attention between this task and several others and didn't consider this option.

Once I had the file on the laptop, I connected this computer into the client's network with a VPN connection. Then I copied it to a secret location in Arizona.

View Larger Map

OK, so it wasn't really secret; I just don't want to tell. On the server in Arizona I did a little processing of the file to ready it for installation. Then I copied it to a server in Indiana.

View Larger Map

Get it? India to Indiana? Cool, huh?

Anyway, after a while the server in Indiana was all done with whatever the heck it was doing up there with the file (it's complicated; suffice to say that it was processing) and it was ready to go. This took about 45 minutes. So I told the server in Arizona to take the file in Indiana and send it to my test machine in Arizona, so I could see if the package worked. Incidentally, I think I know what town the server and the test machine are located in. Are they in the same building, in the same block, in the same zip code? No idea.

Sending the file down from Indiana to Arizona took about three hours. And then it was ready to test. I issued the command to install the file, and off it went. And it worked!

This entire process took a good bit of two work days. Fun, eh? Ain't modern technology amazing?

So what was it that traveled from India to Arizona? Nothing physical; the actual physical "things" that traveled from one place to another alternated between light (over fiber optic cable) and electrons (over copper wire). Who knows, there might even have been some wireless or semaphore connections in there, for all I know. But the changing media means that only information flowed over all that distance. So no physical thing came from India to Arizona, only information.

Now imagine similar transactions occurring thousands of times a day, all over the world. Quite stunning to think about.

Batch file to return UNC drive

I have a client environment where installation packages are installed from a server through a service account. Users have a drive mapped to their local distribution server. However, the service account doesn't map any drives. This improves portability amongst the servers, but can trip up packages (and packagers) that assume that the drive mapping is there.

Consequently, I wrote this little batch file that will determine where the package is running from and will return (in the variable _uncshare) the UNC path of the drive. This works whether the batch file is run from a mapped drive or a UNC path. If the batch file is running from a local drive, it just returns the drive letter.

set _drive=
set _uncshare=
set _drive=%~d0
if "%_drive%"=="\\" (
for /f "tokens=1,2 delims=\" %%a in ("%~dp0") do set _uncshare=\\%%a\%%b
) ELSE (
for /f "tokens=2,3" %%a in ('net use') do if /i "%%a"=="%_drive%" set _uncshare=%%b
)
:: Below handles case where we are not running off a mapped drive - 
:: just return drive
if NOT DEFINED _uncshare set _uncshare=%_drive%
echo %_uncshare%

How to obscure passwords in batch files

I came up with this one the other day for a client. Suppose you are creating a user account from a batch file, as follows:

  net user NewAdmin MyPassword /ADD

Now, of course, having such a line in a batch file is a Really Bad Idea^TM because you have the password in clear text. The client asked if there was a way that I could obscure the password. I told him that it wouldn't be really secure, and he replied that that was fine; he just wanted to "keep honest people honest."

So here, then is the KHPH method of obscuring passwords in batch files:

Tools needed: Microsoft Script Encoder.

1. Create a one line VBScript that echoes your password, like this:
   wscript.echo "MyPassword"
   Save it as “Pass.vbs”
2. Encode Pass.vbs using the Microsoft Script Encoder:
   screnc.exe Pass.vbs Pass.vbe
   
3. Open Pass.vbe in Notepad. Copy out the entire line. Here is what it looks like for the script I wrote above:
   #@~^GQAAAA==Akm.bwDR+1tK~JtXKlk/AGMNJVgkAAA==^#~@
   
4. Now, go through the string and find all the DOS reserved characters. According to this page, the DOS reserved characters are
   & | ( ) < > ^
   For each of these characters, you have to escape them out with a carat (^) symbol, like this:
   #@~^^GQAAAA==Akm.bwDR+1tK~JtXKlk/AGMNJVgkAAA==^^#~@
5. Now take this string, and add it to the echo command in this batch file fragment:
   

   set _data=%TEMP%\~dt%RANDOM%.vbe
   echo #@~^^GQAAAA==Akm.bwDR+1tK~JtXKlk/AGMNJVgkAAA==^^#~@>%_data%
   for /f %%a in ('cscript "%_data%" //NOLOGO') do set _t=%%a
   del %_data%
   net user NewAdmin %_t% /ADD
   set _t=

   
   

What this does is echo the encrypted VBScript to a file and run it, capturing the output to the variable “_t”. The //NOLOGO is important, so that you only get the output of the Wscript.echo command. Remember to set _t= at the end to clear the value.

Note: This isn’t real secure – all someone has to do is create and run the vbe file themselves to see what the password is. But it should keep out the non-technical curious.

Migrating Gmail to Google Apps for Domains

I own a domain name for my family. I have found it to be a fairly good spam protector for my kids, as the spammers don't seem to generate lists of possible account names like they do for major services like Gmail and Yahoo email. Plus, it's nice to have a "vanity email" account that matches your last name. Anyway, I recently migrated the accounts from my domain registrar (GoDaddy; hate the commercials but like the rates) to Google Apps for Domains. This is a great deal - free, 6 GB email accounts, with Gmail spam filtering, at no cost.

The trick for me was to migrate my email from my old gmail account to my new Google Apps for Domains account. I mostly followed the instructions given by Scott Hanselman, but found that using the IP address for the mail server worked for a while, and then stopped. See, the issue is that you can't use pop.gmail.com, because Google Apps balks at pulling emails from this address.

Instead, I did an nslookup on pop.gmail.com, and this is what I got:

C:\>nslookup pop.gmail.com *** Can't find server name for address 192.168.1.2: Non-existent domain *** Default servers are not available Server: UnKnown Address: 192.168.1.2 Non-authoritative answer: Name: gmail-pop.l.google.com Address: 64.233.171.109 Aliases: pop.gmail.com

Notice the Name "gmail-pop.l.google.com". Google Apps for domains accepts this server, and it doesn't seem to "expire" the way the IP address did. It took several days for all my email to migrate over, but eventually it did.

Fixing profile permissions in Windows XP Home

If you log onto Windows XP Home under an account with Administrator privileges and try to access the files in the profile of another account, you will get an Access Denied error. This is because of how the permissions are set up on the directory tree. In one recent example, I found that the Owner of the directory tree couldn't be displayed, and that the Account that used that profile and the SYSTEM account had Full Control, whereas no other account had any control.

What I would like the permissions to be is for the profile user to be the owner, but for the Administrators group to have Full control. You can't do this (at least, not easily) using the security tab interface in Windows XP Home (either through the Security tab hack for XP Home, or through logging in in Safe Mode) nor through CACLS, XP's built-in command line tool for file permissions.

Instead, I used SetACL, a great tool that I have been using more and more lately. It took me a while to figure out how to accomplish what I wanted, but eventually I came up with the following method of changing the permissions for the whole tree:

1. Change the owner of the profile directory to the Administrators group.
2. Give the Administrators group Full control, and enable permissions propagation for the entire tree.
3. Reset the owner to the account holder.

The syntax of SetACL can be pretty obscure, so here is an example batch file to do the above. The account affected is the Owner account.

setacl.exe -on "C:\Documents and Settings\Owner" -ot file -actn setowner -ownr n:Administrators -rec cont_obj

setacl.exe - -on "C:\Documents and Settings\Owner" -ot file -actn ace -ace "n:Administrators;p:full" -actn rstchldrn -rst dacl

setacl.exe -on "C:\Documents and Settings\Owner" -ot file -actn setowner -ownr n:Owner -rec cont_obj

The above lines wrap, so note that each line starts with setacl.exe.

RunAsAdmin: Living with Limited User Account

The Problem

Most users of Windows XP run as local Administrators all the time. Everyone knows this is not the best way to work from a security standpoint After all, most nasty stuff (viruses, worms, spyaware) gets onto a computer because of either email or malicious web sites, and these nasties can only get installed on the system if you read your email or browse web sites as an Administrator. People know this, but they still run as an Admin because running as an unprivileged user is inconvenient. If you do run as a User and you need to do something as an Administrator, you either have to use runas from a command prompt, or log out/switch users to a privileged account. Kind of a pain. Also, this means that you are making changes under a different account - you can't access your network resources, and changes that affect the profile are touching the profile of the Administrator account, not the profile of your "regular" account.

Solutions

There are basically two approaches to solve this problem. One is to run as an Administrator and to selectively drop down to a regular User for "risky" actions (like web browsing). This is the solution offered by the program DropMyRights. The solution I prefer is to run as a regular user all the time, and then selectively elevate your current account privileges whenever you need to run as an Administrator. Aaron Margosis discusses a tool to do this in his MakeMeAdmin blog post. MakeMeAdmin takes your current account, adds it to the Administrators group, opens a DOS prompt under this elevated account, then removes your account from the Administrators group. Thus, you run your normal account as an Administrator, but only in the context of that DOS prompt.

His solution is good, but it still leaves you with only a DOS command (unless you choose to run each Explorer window in a separate process, which I found can chew up memory). Also, I didn't like the way the batch file prompted me for passwords twice. I wanted a graphical window to enter both passwords at once, and then have it take me to graphical environment in which I was a member of the Administrator's group.

I solved this problem by extending Aaron's concept with an AutoIt script. The script prompts me for the name of an Administrator account, the password of that account, and the password of my current account. It then searches for something to run. It can run a batch file named <scriptname>.bat or <scriptname>.cmd, where <scriptname>is the file name of the RunAsAdmin executable, minus the extension. This allows you to use it to run any program that requires Administrator access.

Alternatively, RunAsAdmin can run the A43.exe executable. A43 is a file management utility. I first learned about this program through the excellent BartPE boot disk, which uses it as an Explorer substitute.

Click the image below to see the effect of running RunAsAdmin with A43 on your computing environment.

The Script and how to use it

You can download the compiled executable from here:

RunAsAdmin.zip

Move the file RunAsAdmin.exe into a folder. If you want to use RunAsAdmin with A43, download A43 and extract it into the same directory as RunAsAdmin, so that the file A43.exe is in the same folder as RunAsAdmin.exe. Otherwise, you can create a batch file called RunAsAdmin.bat in the same folder and RunAsAdmin will run that. If you rename RunAsAdmin, you must rename the batch file to match its new name except for the .bat extension.

Once you have it set up, just run the RunAsAdmin.exe program. It will prompt you for the name of an account that is already a member of the Administrators group. (If you click the check box, it will store this account name in the registry so that you don't have to enter it the next time). It will also prompt you for the password of the administrator account, and your current account's password. Once you click OK, it will add your account to the Administrators group, run either the batch file or A43, and then remove you account from the Administrators group.

One other thing to note is that if you use this method for making changes to your system, you should make the Administrators group the Owner of new files that you create while you are an Administrator. Otherwise, malware could affect changes you made while your privileges were elevated. See Aaron's discussion of this issue in this blog post.

The ZIP archive above also contains the source code for the script, so you can edit it to your needs. You'll need AutoIt to run or compile it. The script as written requires a splash screen, so I also included the one that I used.

Final Thoughts

Since my first version of this script, I have been running for months as a regular user on several of my production boxes. I don't find it very inconvenient. After a while I have learned to run RunAsAdmin once and then to leave it open for when I want to run Admin tasks. I also use it to run a program that refuses to run as anything other than as an Administrator, and that requires network access.

I have found using the script to be a minor inconvenience compared to the risks of running as an Administrator. I say this as someone who has not seen a virus on his system in years and who has never had a problem with spyware. However, I don't doubt that someday, someone would eventually come up with a way to trip me up if I continued to run as an Administrator. That's why I want to run as a regular user - I just think that this is a better way to run.

HP Security Mess

I got pulled into an issue at work. Seems that one of my clients is moving to HP hardware, and they ran into a security issue [hp.com] with the software that is driven by the special keys on the laptop.

Here is the gist of the security issue [securityfocus.com]. The HP Info Center basically puts a shell around an Internet Explorer instance, which calls javascript that creates some ActiveX objects in the page. The ActiveX objects launch HP control panels stored on the machine. The DLL (HPInfoDLL.DLL) that contains the ActiveX object is the source of the security problem.

So what is HP's solution? A security update. Pretty straightforward, right?

Well, not so much. The updater that they supply doesn't check that the original file - or even the HP Info Center software - is installed on the system before installing the update. And if the software is installed, it doesn't do any version checking on the DLL. It just writes right over whatever version of the DLL is on the computer.

You might think that this last is a problem, right? What if another security issue is found? Well, here is why it isn't a problem. The updated DLL - doesn't do anything. Well, OK, maybe it does something. But it sure doesn't create the ActiveX objects that the original did. Consequently, when the HP Info Center is run, instead of showing icons to launch DLLs, users see an Internet Explorer Script error. See it here.

When the desktop manager for my client saw this, and I explained that it was the documented behavior of the update, he flipped out. And I can understand why. With the update installed, when users press a key on the laptop, what they will see is an error. They'll think the software is broken. And what do users do when they have a problem on their computers? Yes! they call the Helpdesk! He was envisioning having to explain to dozens or hundreds of users that the error they were seeing wasn't really an error.

Here is how I fixed the problem. I poked around, and found the Javascript that was driving the vulnerability. It is contained in a file called HPInfoCenter.js. I then found the file that was calling this JavaScript file. It is called HPInfoContent.html. I looked in the latter file, and found that it was calling the JavaScript in the <body> onload event. So, I just removed the onload reference to the JavaScript file. Then I edited the HTML of the HPInfoContent.html file to basically tell users that the Info Center doesn't do anything and that they should look for the HP controls in the Control Panel. Voila! No more script error!

The real question, though, is why HP felt compelled to create such an application. Why not just create a folder with shortcuts to the control panels? Wouldn't this accomplish the same thing?

Not as cool, I guess. Plus, if they had done this, I wouldn't have had the chance to be clever over this!

Sorry that this post is kind of complaining, but I do enjoy finding clever solutions to such problems.

The real problem with Vista

So I've been trying out my company's preview ("beta" - in quotes, because, it isn't really beta except in the sense that the deployment method is beta) version of Vista and Office 2007. I've had it running for a while, and I am getting a sense of why people dislike Vista. It isn't just that I had to go all over the place to find out why it wouldn't work with the NT4 test domain that the machine sits in (Lan Manager vs NTLM2) or that UAC is a pain.

As an aside, UAC (User Account Control) is a pain, but not because I dislike clicking pop-ups that ask if I know what I am doing. I find this an acceptable annoyance for security's sake. No, I dislike it because it breaks almost all of my scripts. I didn't realize how much I rely on scripts until they started failing with no error messages. I can't use AutoIt to drive Internet Explorer on my Vista machine (yet). I haven't figured out how to debug VBScript scripts on Vista (yet) - it took me a while to glom onto the fact that it was probably UAC that was causing it to fail.

What bugs me about UAC is all the ways that it blocks actions with no error messages. I understand that the reason for this is probably because Microsoft wants to avoid a denial-of -service type attack with a never ending stream of UAC messages - but come on, some indication of why things are failing would help.

No, the Real Problem with Vista that I have seen so far is that it looks like stuff was changed in the GUI just for the heck of it. Just because they could. And it looks like the decisions of what to change were made by poll - the asked a group of people "which of these changes do you like the most?" and then they went with the one that 55% of the people said they wanted. It certainly doesn't look like someone with a grand plan sat down and made consistent decisions about what to change.

For example: when you go to save a file (in Notepad, or Internet Explorer), you don't get the usual Browse window that we have been seeing for the last 15 years. No, you get a minimalist couple of lines that list paths. You have to click a button to get the file browser window. This is progress?

You can't drag copy files to a command prompt and have the path show up on the command line.

Folder icons have changed. Folder icons changed from Windows 98 to 200 to XP - they got prettier, they got cooler. But they basically stayed the same. Now the folder icons have turned sideways (so, if it was a real folder, the papers would fall out), and, in the Classic theme at least, they are blue instead of yellow. Blue? Why? Folder icons may seem like a minor gripe, but I noticed that in Regedit, I can no longer tell which is an open folder, and which is closed, so when I lost my place in a long list of registry keys, I couldn't tell where I was by looking at the icons.

Explorer is ... weird. Even in small icon view, the column headings show like it is Detailed view. Very strange.

And all the paths have changed, some in weird ways. Why has Microsoft, after over a decade of promoting spaces in critical path names, finally gotten religion about no spaces in common directory names? Is it really possible that after all this time, some developer still can't figure out how to use double quotes in path names? Why, in AppData, do I have Roaming and Local? Is it because Microsoft finally realized that dumping all kinds of critical stuff in Local Settings in Windows XP (like Outlook files) and then ignoring those files when the profile was backed up or migrated was a Bad Idea? Or was it just because they developers could?

Well, enough bellyaching for now. It really does look like someone said that Vista had to be Different, and that is why these changes were made.

Bootable Vista DVD

OK, so I managed to take my broken Vista DVD and make a bootable version from it. How, you may ask? With CDIMAGE GUI and some info from the Internets.

CDIMAGE works like mkisofs (the Linux utility), but this GUI utility has, well, a GUI. So it's better. Maybe :).

Anyway, I copied the contents of the DVD to a folder on my hard drive and then ran CDIMAGE GUI. The link has a nice little walkthrough. All I needed to worry about was the boot sector file (\boot\etfsboot.com), the volume name (which I made something like "VistaBizUpgd") and where to save it. Then I tested it in Virtual PC just to make sure. Voila! Works like a charm.

Trying to get to Vista

So, after a bit of thought, I decided to move to Vista on my home machine, rather than Linux (specifically Ubuntu). I do want to become better at Linux (having only installed and used it for short periods), but I think that professionally that Vista will become more of an imperative soon. Sad that no one really likes this OS, but that it will get adapted anyway because Microsoft will force businesses to migrate from XP.

Anyway, so I backed up my machine with the excellent DriveImage XML (excellent because it works and is free) using a BartPE boot disk and an external USB hard drive. I then tried to install Vista using a Business Edition Upgrade DVD. However, the DVD wouldn't boot. I tried to boot using a CD and then switch to the DVD - but that wouldn't work, either. It appears that the ISO image from which I had gotten my Vista DVD wasn't bootable. I will have to have a talk with the guy who imaged the original disk. I suspect that it was imaged with ISObuster, and wasn't imaged with the correct option.

(As an aside, the correct option is "extract CD Image, Raw2User *.tao", then rename the file to have a .iso extension - see this page.)

In the midst of this I had wiped the hard drive (because I wanted to do a clean install of Vista, not an upgrade), so I restored the DriveImage XML image so I could sort out the Vista DVD boot issue. The image came back successfully, but then the computer wouldn't boot. I tried running a Windows XP CD and going into the Recovery Console and running the commands FIXMBR and FIXBOOT, but no go. I booted back into BartPE and examined the boot.ini - it looked fine. I booted into a basic boot floppy disk whose image is on my boot CD so that I could run Ranish Partition manager to examine the partition table and confirmed that the image that I wanted to boot from was active and the first partition.

Finally, a Google search led me to a page where someone described having to change their BIOS settings to get the computer to boot from their hard drive. So I went into the BIOS, and changed the hard drive from Auto to LBA. Viola! It worked!

What a mess! Always, when I go through something like this, I wonder how people manage who don't have the technical skill to do this stuff, or even two computers to do a search on one while the other is down. I find it tough enough, and this is my job!

Where is COMCTL32.OCX?

Yesterday and today, I spent a lot of my time convincing someone that it wasn't my fault that Windows XP doesn't have Comctl32.ocx installed.

Comctl32.ocx is an ActiveX library that contains Microsoft Common Controls - in other words, the objects that lets programs display controls like treeviews, listviews, etc. It was included with versions of Visual Basic prior to version 6. Version 6 and later use a different file, and in Windows XP the functioanlity of this file is included in Comctl.dll, which is installed in the system.

Anyway, this person (a nice person, by the way) is an engineer that creates application packages for a particular business unit for one of my clients. They got a complaint that one of their installation packages didn't work on the latest image because Comctrl32.ocx was missing. The conversation, in email, went like this:

• She: Your latest image doesn't have Comctl32.ocx.
• Me (after checking): The old one didn't, either. I think you need to add it to your package.
  
• She: Well, how did it get on the image, then? I didn't install anything on the image before I captured the installation.
• Me (after a lot of investigation): I don't know. I tested every standard program we install, and none of them install that file. The only thing I found that installed it is this package management utility.
  
• She: Oh, well, I did install that.

Honestly, I wasn't upset. I was glad that I was able to convey the idea "this isn't my problem" without ticking off anyone, since the engineer doesn't even work for the same company I do. It's always a little dicey trying to tell the client that they need to fix their problem.

Someday, I'll post my rant on why I dislike application captures, but this is a good example why.

Desktop engineering, part three

Desktop engineering is the set of activities that strive to create a broadly used baseline desktop environment that is consistent and verified.

A couple of other things I wanted to say about this definition before moving on to other topics:

Consistent: One of the goals of desktop engineering is consistency. Consistency may be boring when it comes to suburban crackerbox houses or mainstream pop music, but it is great for computers. In IT support, boring is your friend, because boring means that your support costs go way down. This is because your process makes new machine set up a practical no-brainer, and every machine is a known, familiar quantity. When faced with a problem, your technicians don't have to worry about whether the tech who set up the machine remembered to add this software or tweak that registry setting. You know that it was done, because it is part of your documented, enforced setup procedure. Your support technicians consequently spend so much less time checking that the basics have been covered, and can move directly to solving the real problem.

There are levels of consistency. There is apparent consistency, and there is true consistency, and you should strive for the latter and avoid the former. True consistency is having machines that have the same software installed the same way, with the same configurations. Apparent consistency enforces things like a common screensaver, desktop arrangement, etc. Forcing desktop conformity can backfire. I think that if you enforce conformity in the desktop customizations, some people will feel a need to express their individuality and will lobby for Administrator rights just in order to be different. I say, let the users have their unusual wallpaper, and focus on making sure that all of the DLLs match.

Consistency does have its downside. When all of your desktop computers are the same, a problem seen on one computer is more likely to be seen on all of your computers. This means that a larger percentage of your problems will be enterprise wide, and so they will be the responsibility of the engineers to fix. This is where verification comes in.

A bigger issue (to my engineer's mind) is the perception that all problems are the responsibility of the engineers to fix. This can mean inappropriate escalation of problems to your most experienced (and expensive) staff. Procedures must be implemented to ensure that only problems that are related to the engineering of the desktop "make it" to the desktop engineers.

UltraVNC SC (SingleClick)

Being the de facto computer support person for most of my family and friends, I am always on the lookout for tools that will make it easier. I especially look for low cost and no cost tools.

UltraVNC is a great free software tool that allows you to remotely control a computer. Unlike other VNC flavors, it offers an encrypted data channel in its freeware version. Other VNC variants make you pay for encryption.

UltraVNC also has a tool called UltraVNC SC (SingleClick) that allows you to create a single executable file that you can give to a remote user. When the user runs the program, it connects up to your computer, where you have the VNCviewer running in listen mode, and initiates a remote control session with you as the host. Since the remote user initiates the contact, the traffic passes easily through most firewalls - usually, it takes some setup to get server (or listening) programs to work well with firewalls.

I created an UltraVNC SC program to connect to my home router (which I set up on a free dynamic DNS service) and now my in-laws can double-click this program and allow me to work on their computer from afar. It's even workable over dialup (on one side).

Desktop engineering, again

Let's look at the definition I proposed for desktop engineering a little more closely:

Desktop engineering is the set of activities that strive to create a broadly used baseline desktop environment that is consistent and verified.

Broadly used baseline - Though there are some situations where you want to engineer for special cases or "one-offs," in general, it isn't cost effective to engineer something that you are only going to do one time. Also, since one of the goals is consistency, you want to focus on what is similar across the enterprise, not on what is different amongst pockets of users. Therefore, the primary focus of desktop engineering is to engineer for the entire enterprise, or a significant portion of it. If you believe in (or, perhaps, misuse) the 80-20 rule, then you want to engineer the environment that 80% of the people use all the time, and leave as one-offs the other 20%.

Different companies use different measures of when and when not to engineer a desktop component. Some might say that they will engineer a component if x number of users use it. Others will do a cost/benefit analysis, balancing how much time an engineered environment saves in terms of user and support technician time versus the money it requires to create that environment.

I said above that "in general" that you wanted to engineer the common components. When might you want to engineer the unique items? Desktop engineering makes sense for unique items when the benefit is great enough, such as avoiding a desktop visit by a technician or allowing for greater security. For example, if your users run with limited user rights so that they cannot install applications, and you have a system that allows these applications to be installed remotely (like SMS), you will need to engineer every application that users need installed if you never want to have technicians visit a desktop to install an application. Some companies will do this, even if only one user uses the application.

What is desktop engineering?

Desktop engineering - which happens to be my day job until I start getting mega-thousands of hits a day on this blog ;-) - is the act of engineering the desktop (duh).

No seriously, what it means is to give as much thought to planning and building the desktop environment as you might to, say, the server environment or the network. By desktop, I mean the computers and peripherals that end users actually touch, like Dell Latitudes with Windows XP, and HP printers down the hall.

Why would you want to do this? Think about a small business. First, the owner and sole employee might buy one computer. Maybe he goes out to Dell and buys their cheapest underpowered machine (not such a good deal, until you add memory to it) because they have onsite support (a pretty good deal). Then he hires a few employees, and they all need computers. Maybe he still buys from Dell, but now they are different models and have different bundled software. Now he hires some more employees, and TigerDirect has good deals on refurbished eMachines this week. The owner hasn't ever used Dell's support, so he's thinking to save a few bucks and gets the eMachines. The eMachines have even more differences than the second round of Dells.

Who supports all of this? If a hard drive crashes and you have to rebuild it, what software is it licensed to have? How do you rebuild it? If the machine of a critical worker is down, can she move to another machine and be productive? What if Specialized Software #1 works on the eMachines and not the Dells - how do you figure out why that is?

This kind of inconsistency might be tolerable in a small business of 20-50 employees. But what if you have thousands or tens of thousands of employees? In this case, it makes business sense to spend the effort to reduce the complexity of the desktop environment. Preventing the kind of mess described above is the justification for desktop engineering.

Desktop engineering is the set of activities that strive to create a broadly used baseline desktop environment that is consistent and verified.

In a later post I'll explain this definition a little more.

Farecast in public (sort of) beta

TechCrunch:Use Farecast To Find Flight Deals: "Seattle-based Farecast, now in private beta, is an airfare pricing comparision tool that also uses a predictive algorithm to recommend when you buy your ticket."

In other words, it determines the best time to buy based on price. Verry cool stuff - though I can't use it because it's in beta and there is apparently a waiting list.

Link to Farecast.

IE7+

Microsoft is calling Internet Explorer 7 on Vista "IE7+" to distinguish it from the IE7 that will be available for Windows XP. The Plus version will have some additional features - "Protected Mode, parental controls, and improved network diagnostics."

I'm no huge fan of IE, though I have yet to review IE7. I'm glad that it will be available for Windows XP, though. Link

First Post

Initially, this is going to be for my own benefit. It will mostly be about technology. We'll see where it goes from there.