Alex Scoble's IT Notes - An Information Technology Blog

Uninstall Windows Live Essentials using command line on Windows 7

As you may or may not know, Microsoft is discontinuing support for their MSN Messenger/Live Messenger service in favor of Skype soon.

Since Live Messenger is no longer needed on my system and this is part of Live Essentials, I tried to uninstall Live Essentials using the uninstall option of Programs and Features.

This repeatedly failed with error code 0x8007064c.

I did some searching and found this page which supplied the following solution:

Below are the steps on how to uninstall Windows Live Essentials via CMD line parameter.

a. Go to Start->All Programs->Accessories
b. Right click on Command Prompt and select Run as Administrator
c. Run the following commands to uninstall Windows Live Essentials:
· (64 bit) "c:\program files (x86)\windows live\installer\wlarp.exe" /cleanup:all /q
· (32 bit) "c:\program files\windows live\installer\wlarp.exe" /cleanup:all /q
d. A dialog box shows status until uninstallation has completed
Note: The uninstaller for Windows Live Essentials 2011 can also be downloaded fromhttp://g.live.com/1rewlive4arp/wlarp.exe if the local copy is corrupted.

The command worked successfully.

A few months ago Microsoft released security patch MS12-034 Because of this patch and the way that it installs, I ran into problems installing it on Win XP and 2003 systems.

Specifically, the patch does a check of a system's keyboard layout registry keys and makes sure that each layout key has a resulting dll file. If no file is found, it adds the missing dll to a file named C:\Windows\faultykeyboard.log and stops the install until either the registry keys are removed, or the missing dll is readded to the file system.

In my case, I found that all of the systems having problems installing the patch were failing because kbdsf.dll and kbdcr.dll were missing from C:\Windows\System32. The offending registry objects are:

Value: HKLM\System\CurrentControlSet\Control\Keyboard Layout\DoskeybCodes, value 0000100c
Key: HKLM\System\CurrentControlSet\Control\Keyboard Layouts\0000046e
Key: HKLM\System\CurrentControlSet\Control\Keyboard Layouts\0000141a

The two files, incidentally are for the "Luxembourgish" and Slovakian keyboard layouts.

Since we use neither layout here, the simple fix was to remove the registry keys before running the patch.

Because we use a patch management system and because that system is able to run VB scripts in order to do things like remove registry keys, it was a fairly simple matter of researching the VBScript code required to delete the keys.

I made a custom patch in the system that first checks to make sure that the offending registry objects are not in the registry, and if they are then proceeds to run the following VBScript to remove the keys:

Const HKEY_LOCAL_MACHINE = &H80000002

strComputer = "."

Set objRegistry=GetObject("winmgmts:\\" & _
 strComputer & "\root\default:StdRegProv")

strKeyPath1 = "System\CurrentControlSet\Control\Keyboard Layout\DoskeybCodes"
strKeyPath2 = "System\CurrentControlSet\Control\Keyboard Layouts\0000046e"
strKeyPath3 = "System\CurrentControlSet\Control\Keyboard Layouts\0000141a"
strValueName = "0000100c"

objRegistry.DeleteValue HKEY_LOCAL_MACHINE, strKeyPath1, strValueName
objRegistry.DeleteKey HKEY_LOCAL_MACHINE, strKeyPath2
objRegistry.DeleteKey HKEY_LOCAL_MACHINE, strKeyPath3
ReportRepairResult True,"nice job!"

Here's a quick rundown of what the script does... It sets up a constant &H80000002 as HKEY_LOCAL_MACHINE (go here to find out what constants apply to which registry hive)
It then sets up a number of variables to be used later, including the registry keys and value to be deleted. It then deletes the registry objects one at a time using the previously defined variables to complete the function. Lastly we echo True and nice job! out so that the system running the script knows that the script completed successfully. Without that last bit, our patch management system would keep reporting that the custom patch failed.

We then set up a custom patch cloned from the patch management system's own definition for MS12-034 and add our registry fix as a dependency so that it runs before MS12-034 is installed.

And there you have it. The things we go through to fix Microsoft's messes, eh?

Dear Bill Gates, features and fixes I'd like to see in next Windows

This was originally posted to my ComputerWorld blog back in 2005, but as some of it is still pertinent today, I'm recreating it here. 

I'm sure that anyone who's used Windows has at least one pet peeve that they'd like to see fixed. As much as I like Windows (at least in its latest incarnation), I'm no exception.

What's more annoying is that some issues have been around for several versions of Windows (Office too).

OK, so let's get to it! Here's my list of things I'd like to see changed in Windows Mountain View (sorry, still can't call it what Microsoft wants to call it -psst...Windows Vista-...hurts my fingers just thinking about typing it).

1. Focus, focus focus! 

The way Windows changes focus, or how it designates what is the current active window, has been an annoyance of mine for a while now. 

For example, you are working on something, a Word document for instance, you need to reference a web page, so you click on the Firefox icon (or IE) in the Quick Launch bar and get back to typing your current thought stream on the Word document, when all of a sudden mid-sentence, you realize that you are now on your homepage in Firefox. Exasperated, you sigh, click back on your Word document and retype the thought stream from the point where Windows, thoughtfully, changed the active window.

Hey Microsoft, here's a hint for you in as plain english as I can make it: Never, ever, never, ever, ever, ever, never, ever, ever, ever, ever change focus from the window that I'm WORKING on until I EXPLICITY COMMAND Windows to do so!!!!

I don't CARE what your usability testing shows you, I work in specific ways and it would be MOST APPRECIATIVE if I was given the choice on how Windows handles change of focus.

2. I'm the boss!! 

I'm trying to delete files, a lot of them, from the Temp directory for instance. Windows pops up an error window telling me that the file is in use and can't be deleted. It doesn't tell me the specific app that is holding the file open. It doesn't ask me if I want to delete it anyways and it doesn't give me the choice to continue the file delete with the next file. LAME! 

Give me the choice, I don't care how hidden it is, as long as it's there and documented. Unless the file is a required system file, ask me if I want to disconnect the app's connection to the file and delete the file. 

Let me continue the delete from the next file chosen. 

Give me choice! Give me control! Give me more information! Gimme, gimme, gimme!

3. Major Tom to Ground Conrol.

An error comes up when I'm running an application. An error is in the event viewer. I'm having problems performing a specific task (such as trying to connect to console session of a Windows 2003 Server using RDP).

Where's the info in the event logs? Why are you making me click on a link to find out what the error means? Why is there nothing in the event logs at all? Why is the error not listed anywhere in the knowledge base with the same context as my error?

Windows should do a much better of job of telling the user (and an even better job of telling the admin) what's going on under the hood. What does the error mean, why is that application not starting, what's causing my inability to connect to another system's event logs.

I shouldn't have to download support tools in order to drill down to the lower levels of what's going on in Windows. It should tell me.

All error codes should translate into real english messages in the event viewer. All problems should be logged somewhere, or Windows should ask the user if they'd like the problem to be thoroughly added to the event log and Microsoft should at least let customers know that their problem is known even if there's not currently a fix.

Microsoft could even go the extra mile and ask the user if they'd like to be notified if a fix is created for their particular issue.

4. Welcome to the land of a thousand reboots.

So you install a new app, Windows asks you to reboot. You install a new driver for your printer, Windows asks you to reboot. You install a new security update, Windows asks you to reboot. You sneeze, Windows asks you to reboot. You run into a problem, so you reboot. Reboot, reboot, reboot after reboot.

I think you get the idea even if I have exaggerated the issue, but not by much. Sometimes it feels like I spend half my life waiting for systems to reboot. Perhaps it's not quite that much, but it's still too much. 

Even with all the improvements that Microsoft has made in this area it's still not enough. Linux only needs to be rebooted for kernel updates (as far as I know, perhaps Martin MC Brown could shed more light on this), in other words, very very rarely.

With the amount of updates, patches and security fixes that Microsoft puts out for Windows, the reboot requirements are way too high. The only way to get ultra high reliability with Windows currently is to run it in clusters. This is simply not acceptable for small businesses that can't afford double the servers and licenses.

Because we can't afford double the hardware and software is no excuse for us not to have high levels of uptime.

These are just 4 of the issues that I have with Microsoft. To some they might seem minor, but in my line of work, I am bumping up against these problems almost every day.

Microsoft is starting to bump up against competitors in the consumer sector and business sector. In light of this, I would suggest to Microsoft and all of its employees, that good enough isn't. New features aren't enough. You have to be better than your competitors, some of whom offer their products for free, far better. You just about have to be perfect.

You have a long way to go. And Windows Vista better be the next big leap instead of the next small step.