NCP VPN not quite Windows 7 compatible

I got so frustrated with the NCP VPN client software, specifically a recent update, that I decided to let my frustration out by writing about it.


For a long time I used the, IT approved, Cisco VPN client to access our corporate network. And as the OS technology moved along, so did my systems, meaning Vista, Windows 7, and 64-bit. While, for the most part, our IT approved systems remained to be only 32-bit XP. Cisco, for some reason, maybe they are representative of IT organizations as whole, was late to support Vista, was late to support Windows 7, and for the longest time never supported x64.

The only Cisco compatible alternative on Windows 7 x64, was the NCP VPN client. But, at a cost, $144, per machine, very expensive.

I recently read that almost 50% of Windows 7 machines are 64-bit, and I recently read that Cisco announced VPN client support for x64 on Vista and Windows 7. I am sure this is not a coincidence.

But I digress, this post is not about Cisco, it is about the NCP VPN client.


Where to start?

The NCP software is intrusive, every time you login it shows a splashscreen, and the splashscreen remains topmost, blocking anything behind it, until it closes, by itself. I contacted NCP support, complaining about the intrusion, and they told me that it is necessary to run their software at login so that they can validate the license. I replied that validating the license need not happen at every login, and certainly should not interfere with my system. They said I could search the internet and find out how other people disabled their software.

This means a few things to me; they do not value usability, they acknowledge there is a problem, yet they do not offer a solution.

Imagine if every application you install on your system decides it is a good idea to show a splashscreen when you login.

Here is the splashscreen that pops up on every login:

In case you are wondering how to disable NCP from running at startup, they install three user session startup entries under [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run], delete or rename them


While we’re on the topic of usability, this application’s UI was probably not designed by Windows developers, or certainly not somebody that knows anything about standard Windows user interface design and principles.

In the main UI, shown below, how do you connect, where is the connect button, do you click the red button, no you need to click the gray area next to the red button. They probably though it looks cool.


Every time you login the application starts and shows its UI. How would you normally look for options in a windows app; probably [Options], or [Tools][Options], or [File][Options]. No, you need to click on [View][Autostart][No Autostart], what does the [View] menu have to do with [Autostart]?

And in case you were wondering, no, disabling autostart does not disable the splashcreen.


So what is it that made me mad enough to write this post?

I received an email that a new version was released, and the software offers a built in check for update mechanism by clicking [Help][Search for Updates]:

How big is that update? 23.792 kByte, really, 24 kilobyte, or what is a lowercase k in kByte? Or is that really 23,729 KB as in 24 megabyte?

Downloaded the update, now let’s apply it:

And then the Windows Program Compatibility Assistant pops up:


I contacted support, got an email that said no other users had reported this problem, and they asked if I am an admin on the system, but before I could respond, I got another email that said they reproduced the problem, and that I should download and install the update from the website.

Let’s download the update directly, and install it:

And then the Windows Program Compatibility Assistant pops up:


You may think it is a problem with my system, I repeated the same steps on a second system, that is how I captured the screenshots, and I ran Microsoft Process Monitor to record what is happening.


As a developer, that is familiar with writing Windows 7 compatible software, I know what is going on here.

The NCP software installs:
Three startup items: NcpBudgetGui, NcpPopup, NcpRsuGui
Three services: ncpclcfg, ncprwsnt, NcpSec
Two drivers: ncpfilt, ncplelhp


The NCP UI process is called NCPMON.exe, and is launched by explorer, runs non-elevated, at medium IL. It is the NCPMON.exe process that downloads and executes the update.

From the procmon log I can see that NCPMON.exe called CreateProcess() to launch the installer:
Date & Time:    7/21/2010 10:01:12 AM
Event Class:    Process
Operation:    Process Create
Result:    SUCCESS
Path:    C:\Users\Pieter Viljoen\AppData\Local\Temp\NCP_EntryCl_Win32_923_17.exe
TID:    6952
Duration:    0.0000000
PID:    6856
Command line:    "C:\Users\Pieter Viljoen\AppData\Local\Temp\NCP_EntryCl_Win32_923_17.exe"


This will not work, the NCP_EntryCl_Win32_923_17.exe is an installer it has to “Run As Admin” (this is an InstallShield installer, and although it does not contain a Run As Admin manifest entry, the Windows Application Compatibility subsystem recognizes InstallShield installers, and automatically runs them with elevation required), this means that when you launch this EXE using ShellExecute(), or using Explorer, you will get a UAC elevation prompt, and if approved, the installer will run elevated, and the install succeed.

There is only one explanation of how NCP could ever have shipped this, their developers and QA test with UAC disabled on their test systems.


What about the appcompat warning after the install?

Microsoft requires that Windows Vista and Windows 7 compatible applications mark their compatibility in the installer manifest.

By inspecting the resources in the installer EXE, there is a manifest, but there is no compatibility manifest, as such, this error will always show on a Windows 7 system.

I have no explanation for how NCP could allow this to ship, ignorance?


It makes me mad that an ISV advertises Windows 7 compatibility, and ships software like this. It is companies like NCP that gives Windows a bad name, and drives companies like Apple, to enforce rigorous, sometimes draconian, quality and usability standards in order to protect their own brand.

DELL 2408WFP loosing settings on power cycle

In my last post I discussed the calibration of my DELL 2408WFP monitors.

After calibration, and changing the monitor settings, the monitors looked pretty good, but I later found that the monitor colors looked all weird again.
It turns out that the monitors reverted to their default settings, invalidating the calibration.
It seems to me that as soon as my PC goes to sleep, or the monitors go into power saving mode, or powers off, that on turning back on they revert to default settings.
I found a relatively simple solution using EnTech mControl, not completely automated but close.
mControl allows you to save the current monitor settings to a profile, and allows you to restore those settings.
Here are the steps:
  1. Install and run mControl.
  2. Set mControl to automatically load when you login. Right click on the mControl tray icon and enable auto-load. This will add an entry in the startup program group.
  3. Calibrate your monitor, adjusting the monitor settings using mControl.
  4. Save your monitor profile. Open a command prompt, change to the mControl directory (“C:\Program Files (x86)\mControl\”), and run “mControl.exe /saveprofile Calibrate”. This will save the current monitor settings to a profile called “Calibrate”. You can use any profile name, I just used “Calibrate” as an example.
  5. Edit the mControl startup item so that it automatically restores the monitor profile when mControl starts. Right click the mControl entry in your startup programs group, and edit the commandline to include the “/restoreprofile Calibrate” option. E.g. “”C:\Program Files (x86)\mControl\mControl.exe” /restoreprofile Calibrate”
Every time you login mControl will start and restore the monitor settings.
If you change the monitor settings, simply run “mControl /saveprofile Calibrate” again to save the updated settings.
Unfortunately this only works when you login, but if the monitors power down while you are logged in, e.g. sleep, you have to manually restore the settings.
I solved this by creating a text script file called “Monitor.Restore.Profile.cmd” on my desktop, and putting the restore command in the file, “”C:\Program Files (x86)\mControl\mControl.exe” /restoreprofile Calibrate”.
Now whenever the monitor settings need to be fixed, I just run this script and the settings are restored.
This seems to be a problem with the DELL 2408WFP monitors, and I would like to know if this is specific my to my setup, or if this happens to other people, leave me a comment and let me know.

[Update: 17 July 2009]

EnTech has enhanced mControl to support profiles right in the UI, including an “Autoexec” profile that will automatically restore the monitor settings on login and wake from sleep.
It works great.

Amazon Unbox on x64 Vista

While shopping on Amazon I noticed that they were offering the Pilot of the Showtime series Nurse Jackie in HD for free, so I decided to give it a try.
The install (version went smoothly, and the 1.3GB downloaded also completed pretty quickly, and I watched the show.
Ok, now I wanted to stop the Unbox player service from running and terminate the tray icon application, I have no need to have it running all the time.
I went to [Settings][Preferences], and unchecked the [Run the Amazon Unbox service when Windows starts] option.

I then right clicked on the tray icon and selected [Exit], the tray application launched “Amazon Unbox Config.exe stop” application, requiring UAC elevation, and promptly crashed with the following message:

An unhandled exception of type ‘System.BadImageFormatException’ occurred in Unknown Module.
Additional information: Could not load file or assembly ‘ADVWindowsClientAppRoot, Version=, Culture=neutral, PublicKeyToken=091de1773ddefdbf’ or one of its dependencies. An attempt was made to load a program with an incorrect format.

I contacted Amazon support, and they provided this response:

Hello from

I sincerely apologize for the trouble you’ve had using the Unbox Video Player. From your message, I understand you received an error relating to Windows being unable to load the correct file path.

I’ve researched the issue and suggest that you update the security components of your Microsoft operating system.

Please visit the Microsoft website listed below and follow Microsoft’s instructions for updating your security components. Microsoft may require you to use Internet Explorer to access all of the functions of this page and enable Active X controls in your Web browser.

If using Microsoft’s update does not resolve your playback issue, I recommend uninstalling and reinstalling your .NET Framework.

The Microsoft .NET Framework includes a large library of coded solutions to common programming problems and a virtual machine that manages the execution of programs written specifically for the framework. The .NET Framework is a key Microsoft offering and is intended to be used by most new applications created for the Windows platform.

I hope you found this information useful.

I gave them the benefit of the doubt and tried to update the DRM components, it did not work.
I suspected I know what the problem was, and this problem reminded me of a similar problem with the Google Email Uploader on Vista x64.
My suspicions were confirmed after I used CorFlags to inspect the binaries:

CorFlags.exe “C:\Program Files (x86)\Amazon\Amazon Unbox Video\Amazon Unbox Config.exe”
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 3.5.21022.8
Copyright (c) Microsoft Corporation. All rights reserved.

Version : v2.0.50727
CLR Header: 2.5
PE : PE32
CorFlags : 9
32BIT : 0
Signed : 1

CorFlags.exe “C:\Program Files (x86)\Amazon\Amazon Unbox Video\ADVWindowsClientAppRoot.dll”
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 3.5.21022.8
Copyright (c) Microsoft Corporation. All rights reserved.

Version : v2.0.50727
CLR Header: 2.5
PE : PE32
CorFlags : 11
32BIT : 1
Signed : 1

The output indicated that the EXE file was compiled to run natively on any platform, i.e. x64 on x64 and x86 on x86, but the DLL was compiled to be x86 only.
Thus the EXE runs as x64 and tries to load a x86 binary, not allowed, causing the crash.
The CorFlags output and x64 migration is discussed in this MSDN blog post:

anycpu: PE = PE32 and 32BIT = 0
x86: PE = PE32 and 32BIT = 1
64-bit: PE = PE32+ and 32BIT = 0

To fix the problem I have to change the EXE attributes to only run in 32bit:

CorFlags.exe “C:\Program Files (x86)\Amazon\Amazon Unbox Video\Amazon Unbox Config.exe” /32BIT+ /Force

The “Force” flag is required because the binary is Authenticode signed, and after the header change the Authenticode signature is now invalid.
“CorFlags” is parts of the .NET / Platform SDK and can be downloaded from Microsoft.

After I made the changes to the EXE, I repeated the original steps, and no more crash.
I replied to Amazon with my findings, and I hope they make the necessary, and easy, changes to fully support x64.

DxO Optics Pro and Adobe Lightroom on Vista x64

I bought my first SLR camera, a Canon EOS 20D, and my first wide angle lens, a Canon EF-S 10-22, several years ago. Amongst the many articles and reviews I read, online and in magazines, I came across a product called DxO Optics Pro, a product that would supposedly correct, amongst other things, lens distortion. This seemed like the perfect tool to help me with my wide angle pictures that looked very “fishy eyed”. And since DxO, then version 4, was receiving good reviews, I decided to trial the product. In those days the DxO licensing model was to pay per camera body and per lens module, not a cheap investment, but I really liked the results and so I purchased the product.
Not too long after I purchased DxO, they changed their licensing model, and instead of paying per module, they came up with a Standard and an Elite product, with the distinction being the camera bodies that are supported. The Elite version typically supports more high end cameras, I am sure there is no technical difference in the calibration techniques, this just seemed like a way to get more money from professionals that own high end cameras.
In the mean time I switched to using Adobe Lightroom version 1, and DxO fell in disuse. Every now and again I did come across an article or forum post with less than flattering reports of the poor product quality in DxO version 4.5, and very poor quality in version 5. The other thing I read, and confirmed with DxO tech support, is that DxO did not support x64 editions of Vista, and since I had switched to Vista Ultimate x64 edition, this would be a problem.
I switched from taking mostly JPG images to mostly RAW images, and manual correction in LR became very time consuming, so I was again interested in DxO. By now I was using LR 2.2 x64 edition, and by now DxO 5.3.2 did support Vista x64 editions. I purchased an upgrade for DxO, I bought the more expensive Elite edition, since I have dreams of one day owning a 5D Mark II.
In standalone mode DxO 5.3.2 worked great, but the integration with LR was not so great. The problem is that DxO does not support integration with the x64 edition of LR, when calling DxO from x64 LR nothing happens. The DxO installer is also not fully x64 compatible, it creates a start menu shortcut to the “DxO Download Manager v5”, but it sets the path to “C:\Program Files\DxO Labs\DxO Download Manager v5\DxODownloadManager.exe” instead of “C:\Program Files (x86)\DxO Labs\DxO Download Manager v5\DxODownloadManager.exe”, obviously a hardcoded path instead of dynamically discovered path.
Before I get to DxO, I think Adobe should have supported in-process DLL based plugins in LR, just like they do with Photoshop. For whatever reason this type of suggestion seems to make Adobe very uncomfortable, and they go to great lengths to defend their position, reads more like marketing firefighting, and say why the LUA based scripting and external process launching is so much better than plugins, at least when compared to Apple Aperture. I am a software developer, there is no way that anybody can convince me that a scripting language or launching an external process is better, or as good, as a native DLL based plugin with a rich integration API.
So how does DxO integrate with LR in light of the lacking plugin model? When you edit an image using an external editor, LR launches the editor with the image path specified on the commandline. LR provides three options for what file is passed to the external editor; the original file, a copy of the original file, or a copy of the LR processed version of the file. The problem is that when the file is a RAW file, LR only allows a copy of the LR processed version of the file to be passed, and this processed file is useless to a RAW editor.
DxO, being a RAW file processor, obviously needs access to the original RAW file, and they go about it in a clever, but cumbersome way. LR allows for configuration of the file type and file name of the new file it generates, and DxO exploits this file naming scheme to infer the original filename. E.g. the original RAW file is called Test.CR2, LR creates a copy of this file and names it Test-Edit.TIF, DxO infers the original filename is Test.CR2, opens Test.CR2 as the input file, and uses Test-Edit.TIF as the output file.
DxO can run in one of two modes; “plugin-in” mode (their spelling, not mine) or normal mode. When launched by LR, DxO runs in plugin mode. In plugin mode DxO only allows processing of the images passed in on the commandline, and the output processing automatically replaces those same input files. 
Since DxO does not have a way of explicitly launching in plugin mode, they infer the mode by interpreting how they are being launched. DxO looks at their parent process, and if the parent process is called Lightroom.exe, and the Lightroom.exe has version information that looks like LR, then DxO automatically enters plugin mode.
So why does DxO not work when launched from the x64 edition of LR? When launching DxO from x64 LR the DxO process starts and immediately terminates without showing any UI. It appears that DxO fails to determine information about the parent process when the parent process is a x64 process. I am speculating, but this is probably related to the technique that DxO is using to determine information about the parent process. Typically one would use the PS API or ToolHelp API’s, along with NtQueryInformationProcess(), but when mixing x86 and x64 process types, they do not provide consistent information, and extra handling is required by using IsWow64Process(). A more portable, but less reliable, alternative is to use WMI. DxO is not a native application, it is written in .NET, presumable C#, but it apparently still suffers from some x64 related problem.
So how do we solve the problem? You can install both the x64 and the x86 editions of LR on your x64 system, and when you want to work with DxO you can use the x86 edition of LR. This however is not very convenient. My solution was to create a x86 proxy process that looks like LR, is discoverable by DxO, and convinces DxO to enter plugin mode. LR is then configured to launch the proxy process instead of DxO, the proxy process launches DxO and passes the same commandline parameters as passed by LR to DxO, waits for DxO to terminate, and returns the exit code to LR.
Instead of inferring the mode of operation by looking at attributes of the parent process, it would have been much simpler, and it would have avoided the x64 problem, if DxO had a stub executable that always launched in plugin mode. And, it would have been even better if LR supported DLL based plugins with programmatic access to image information instead of inferring it. But, DxO would then have had to write a native x64 DLL, and if they can’t even write WoW64 compatible x86 code, I don’t know if that would have been a solution.
So how did I figure this out? 
At this point I have to remind you that I have absolutely no connection with DxO, nor insight into the coding of DxO, nor did I reverse engineer or disassemble DxO, my analysis and solution is purely based on observing LR and DxO behaviors by using Microsoft Process Monitor.
I compared the behavior of DxO on a x86 system with the behavior on a x64 system, and I noticed that on the x86 system the DxO process opens the LR executable file on disk. Looking at the call stack I noticed that DxO calls the.NET runtime calls the GetFileVersionInfoW() API. On the x64 system DxO never attempts to open the LR executable. I installed the x86 version of LR on the x64 system, and noticed a similar behavior to the x86 system. 
I created a C++ project in Visual Studio 2008, and wrote code to take the input commandline parameters and call the DxO executable with the same parameters as passed in by LR. I built a x86 binary, renamed the output file Lightroom.exe, and when I run “Lightroom.exe c:\test\test-edit.tif”, DxO would open in plugin mode, but would not load the original test.cr2 file. I added version information to the proxy project, and matched the version information contents to that of the real LR binary. Repeating the test, DxO now believes that it was called by LR and it opens in plugin mode and it finds the correct RAW file.
The source and binary file is available here
Please remember that I provide no warranty at all, I did minimal testing, so use at your own risk.
To install simply extract, rename DxOProxy.exe to Lightroom.exe, and change the LR configuration to point to the proxy Lightroom.exe instead of the DxO binary.
In closing, and in light of my previous post related to my trouble with the Google Email Uploader on x64; with all the available programming documentation, and free compilers, and free virtualization testing environments, why is it so difficult for some ISV’s to produce quality and compatible software?

Google Email Uploader on Vista x64

I am currently importing a few thousand email messages from Outlook 2007 to my email account hosted on Google Apps. Google provides an Email Uploader utility, and it is easy to use, but getting it to work with Outlook 2007 on Vista x64 was less than trivial.

The utility installed fine on my Vista x64 system, but it found no mailboxes to import. A little research showed that several other people using Vista x64 and Outlook 2007 have exactly the same problem.

Since Google kindly publishes the source for the tool, I decided to have a look. Turns out it was a relatively simple fix to get it to work.

The main application is a C# .NET application, with the build properties for the target set to “Any CPU”. This means that on a x86 / WIN32 system it will be a 32bit process and on x64 / WIN64 system it will be a 64bit process.

The problem is that the application also uses two mixed mode DLLs, and these DLLs are compiled for x86 / WIN32. When running the main EXE on Vista x64, the process is a 64bit process, and that fails to load the 32bit DLLs. The fix was simple, change the build target from “Any CPU” to “x86”.

I also had to fix a couple other small things in order to get the “Release” build to compile correctly. The DLLs are written in C++, but for some reason the developers used .MH and .MCC extensions instead of the standard .H and .CPP extensions. The “Debug” build had set custom build properties for .MCC files, and associated the files with the C++ compiler. Once I did the same for the “Release” build, the project compiled.

The last change was to set the Outlook import DLL linker options to delay load MAPI32.DLL.

You can download the binaries from here, simply extract and run.
Please remember that I provide no warranty at all, I did minimal testing, so use at your own risk.

I hope Google makes these easy changes to the main source branch so future official versions also support Outlook 2007 on Vista x64.

Getting Vista to go to sleep

I noted my troubles with the Intel GMA drivers, the Intel DG33TL motherboard, and Vista SP1 blue screen crashing in my earlier post.

Since I was running the 15.8 version of the Intel GMA drivers, and Microsoft KB948343 indicates that, based on the driver version numbers, these newer drivers should not be affected by SP1, yet the crash details were clearly the same, and no new driver was forthcoming to correct the blue screen crash, I decided to take the GMA drivers out of the picture.

I am currently using an ATI HD 26000 XT card in my HTPC, and this is a great card. I looked for the same model, the one I was using is from VisionTek, but I found a Sapphire brand card for significantly less. I am actually happier with the Sapphire compared with the VisionTek, the VisionTek fan was really loud, and since I was using it in my HTPC, I ended up buying a Zalman VF900-Cu replacement fan for the VisionTek card. The Sapphire card has no problem with a noisy fan.

I installed the ATI card, installed the drivers, and put the machine to sleep. This is where the GMA drivers would normally crash. This time there was no crash, but the machine also immediately woke up again, I could not get it to stay in sleep mode.

At this point I had had enough of the DG33TL board; it had given me more trouble than I was willing to put up with and I wanted a replacement board. Since I already had the machine open, while replacing the VGA card, I wanted a new board now, which meant instead of ordering online and waiting a few days I had to take a trip to my local Fry’s.

I knew my in store choices would be limited, so I did some research and selected a few models from Asus, Gigabyte, and Intel, with the primary requirement being ICH9 support so that I would not lose the RAID-0 configuration of my drives, and the motherboard swap would not require an OS reinstall. My first choice would have been a Gigabyte GA-G33-DS3R, unfortunately, as I suspected, it turns out that of all the options I was hoping for the only board that came close was an Intel DQ35JO.

Of the three boards on the shelf, all of them had been returns and were resealed, so this was even more of a risk, but they were marked down a few dollars so that did make me feel better, and I could always return the board.

The DQ35JO is very similar to the DG33TL. The DQ35JO is from the Executive series, and the DG33TL is from the Media series. The DQ35JO has no multichannel audio, but does have TPM and AMT. The component layouts are almost identical.

I replaced the board, powered on, the POST screen came up and then nothing. On reading the Intel support documents they recommended a BIOS reset. I removed the battery, waited a few minutes, replaced the battery and rebooted. This time the POST completed, and I could boot. I assume that since the board had been used, and I just replaced the memory and CPU, that this may have caused the initial boot failure. Before booting into Vista I first booted to my DOS bootable USB key and updated the BIOS to the latest version, then reset the BIOS configuration to defaults, and again made all the required changes, most importantly to restore the RAID drive configuration.

I booted into Vista Ultimate x64, waited a few minutes for the new drivers to load, and eventually the keyboard started working and I could login. The ATI control center application complained that there was no ATI driver installed, so I reinstalled the ATI driver, rebooted, and this time everything seemed fine. Not quite, Windows told me the hardware had changed and I had to reactivate. Activating over the internet failed, and I had to activate over the phone, that worked. I also noticed that Windows Update wasn’t working, the KB article for the error code told me to check the PC time. Since I had reset the BIOS without resetting the time, the time was off by years, on correcting the time WU started working again.

Now for the ultimate test, can the machine go to sleep? I press the sleep button and the machine sleeps, I touch the keyboard and the machine wakes up. I leave the machine idle for an hour, it goes to sleep, I touch the keyboard and the machine wakes up. Success!

There is one thing that is still not 100%, and this seems to be a problem on both the DG33TL and the DQ35JO; the case power light is not always on. E.g. after removing mains power and powering on the case power light will be on and stay on until the first sleep, and then the power light will turn off, and even resuming from sleep or rebooting will not turn the light back on.

Maybe I should have been more patient and ordered the Gigabyte GA-G33-DS3R instead, but for now I am happy.

Microsoft Expression Media / iView Media Pro to Adobe Photoshop Lightroom converter

This article was originally posted here.


Because of severe performance problems I experienced with both iView Media Pro and Microsoft Expression Media, I decided to switch to Adobe Lightroom.

Unfortunately Lightroom does not understand catalog sets nor does it understand people tags, so the transition is not that simple.

After I could not find a simple, or even complicated solution, I decided to write my own conversion application.

This application will convert hierarchical catalog sets into keywords, and will add people tags to keywords.

I considered directly converting to Lightroom’s native SQLite database format, but the reverse engineering effort did not seem justified.


I am providing this utility and the source code as is, no warranties are provided, use at your own risk.

Backup all your data, validate the conversion results, do not discard your backups.


I wrote the utility in C++ using Visual Studio 2005 SP1.

I tested on Vista Ultimate x86.

I tested with Microsoft Expression Media 1.0.8104.0, and iView Media Pro

The code utilizes the COM API’s exposed by Expression Media and Media Pro.

Unfortunately neither application’s COM API’s work reliably, I can only hope that the quality of future versions will improve.

See the source code comments for problems I encountered.


  1. Download the archive and extract the contents to your folder of choice.

    The archive contains the source, and two binaries, one for Expression Media
    and one for Media Pro.

    The binaries are compiled to use either the Expression Media or the Media Pro COM type libraries.

  2. Run Expression Media or Media Pro, and open the catalog you want to convert.

    Make sure that only one catalog is open.

    Make sure you have a backup of your catalog and of all your media files.

  3. Open a command prompt and change the directory to where you extracted the files.

    Run: ExpressionMediaExport.exe [Full path to the catalog file you opened in
    Expression Media or Media Pro enclosed in double quotes]

    E.g. [ExpressionMediaExport.exe “c:\media\catalog.ivc”]

    The utility will convert catalog sets to keywords, and will convert people to

    You can close the command prompt.

  4. The catalog sets will be converted so that each catalog node is a keyword and
    the keywords are assigned to all items in that catalog.

    E.g. if you have “Travel” and “Travel\Someplace”, the keywords will be
    “{Root}{Travel}”, and {Root}{Travel}{Someplace}”.

  5. People are added to keywords.

    E.g. if you have “John Doe” as a person tag, then “John Doe” will be added to

  6. Sync the updated information to the media files.

    In Expression Media or Media Pro [Edit][Select All], [Action Sync
    Annotations][Export annotations to original files].

  7. Import the images into Adobe Lightroom.

    Use the category keywords to create new collections.

    Select all images containing a category keyword e.g. “{Root}{Travel}”, create a
    new collection called “Travel”, and add all selected images to the collection, do
    the same for child collections.

Known Problems:

  • If you are using Expression Media, you first have to fix the COM registration
    that is not correctly set during installation.

    On Vista [Start][All Programs][Accessories][right click the Command Prompt icon
    and select Run as administrator].

    On XP [Start][Programs][Accessories][Command Prompt]

    Change directory to the Expression Media folder: [cd “C:\Program
    Files\Microsoft Expression\Media 1.0″]

    Register the Expression Media COM interfaces: [media.exe /regserver]

    You can close the command prompt.

  • If you encounter failures writing keywords to media items, try adding
    keywords to all items that fail using the main application.
  • If you get an error “Active catalog does not match requested catalog”, it means the catalog you specified on the commandline did not match the default catalog. The problem is that the Open() API always fails, and I have to use the Attach() API to connect the active catalog, and for integrity reasons I make sure the catalog on the commandline is the same as the active catalog that will be modified.
  • Complain to Microsoft that the COM API’s are not fully functional.



  • Added people to keyword export.


  • First release.


Printing from the network

I have made various attempts at sharing my printer over my home network. The criteria for sharing are simple; the printer must be available over the network and I must be able to print from Windows and Mac machines.
In practice this turned out to be a little more difficult.

The simplest solution would have been a network enabled printer, but I had no luck in finding an affordable consumer grade home printer that can directly connect to the network.

My first implementation was to connect a Canon i960 to my Windows XP machine using USB, and then sharing the printer. This had a few problems; my machine had to be on all the time, the Windows XP x64 Canon i960 driver crashed when connected to a network shared printer, and the Canon i960 Mac driver could not print to a network shared printer.

The Canon i960 had given me good service, but I was now looking for a better photo printer. I decided to upgrade a few systems at the same time; I upgraded to Vista, I bought a HP D7360 Photosmart printer, and I bought a Belkin F5L009 network USB hub.

The F5L009 is a USB hub that you connect to your network, and then by installing a USB driver on any computer on the network, the USB devices connected to the hub appear to be directly connected to your machine.

At this time I was running Windows Server 2003 R2 x64 as my home server, and since the server was on all the time, I wanted to share the printer from the server. I installed the USB hub driver on the server, and I installed the printer driver. It turns out that the hub software only connects the hub as long as you are logged in, as soon as you log out the printer disconnects. This is in my opinion a fatal flaw in the F5L009 implementation.
I resorted to installing the F5L009 driver on all my client machines, a less than ideal solution.

I recently noticed that HP released the D7460 printer, basically the same as the D7360 except it has native network printing support, great. With a $25 HP online store discount I paid less for the D7460 than what I paid for the D7360.

Since the D7460 is a network printer any machine can directly print to the printer, but sharing the printer from my server has the advantage of a much simplified installation for client machines, and greater manageability.

I had recently upgraded my server to Windows Server 2008 x64, but I thought no problem, the D7460 comes with Vista x64 drivers, so installing the driver on W2K8 x64 should not be a problem. It turns out the driver installer does an OS check and does not allow the driver to be installed on W2K8.

I proceeded to install the driver on my Vista x64 machine, the install utility found the network printer, and automatically installed the driver. On investigation I found that the installer had simply configured a custom printer port to print to TCP port 9001 on the printer. I also found that the printer has a web based management portal that showed status information and allowed the network properties such as device name to be changed.

I changed the printer network device name, made sure that the entry showed up on the DNS server, added a new printer port in W2K8 pointing to the printer, and when asked for the driver pointed to the driver directory, and everything worked fine.

I wanted to add the x86 drivers to the print server so that clients can automatically get the printer driver without neding access the the driver media, but when I tried to add the drivers I got a message asking for the x86 print processor file from the install media. I tried to add the x86 drivers to the server from an x86 Vista machine, but the option to add additional drivers was grayed out. After searching I found users with similar problems, and KB927832 describing a solution for Vista. I could not get the solution to work.
I ended up remotely installing the x86 drivers from W2K8 x86 running in VMWare, not very elegant but it worked.

I now have an elegant network printing solution.