ProfileUnity Shortcut Creation Bug

I was deploying Liquidware Labs ProfileUnity for a customer last week and we came across an interesting bug that I wanted to make a quick note of.  It's a cool tool for managing the general user experience; pretty much everything that lives in the user's profile.  It largely obviates the need for using the Group Policy editor and wading through the pages and pages of GPO settings that can apply to desktops by putting many of the most common settings into a much easier interface.

One of the things that you can configure with ProfileUnity is shortcuts.  They can go on the Desktop or the Start Menu or any of the other places that you might want a shortcut to sit, and you can point them at pretty much anything that you'd like a shortcut to point at.  Great!  It's much easier to manage through their interface, as they allow you to filter who gets what shortcut and can automatically create them based on AD Group membership, etc.  It's great!  We did run into a small problem, though.

This customer is mapping a bunch of drives to network shares and one of their applications runs directly off of the file server.  The mapped drive is the G:\ for this customer and the path to the executable has quite a few folders with spaces in their names.  The bug that we ran across was that ProfileUnity was replacing all of the space characters in the string (G:\Folder 1\Folder 2\exectuable.exe) with underscores (G:\Folder_1\Folder_2\executable.exe).  As you might imagine, this had a fairly negative effect on the functionality of the shortcut that we were creating.  We tried putting the whole path in quotes and ensuring that we didn't have any weird characters in the path, but no dice.

It turns out that it is a bug, but that it's limited to shortcuts that point at drive locations other than the C:\ (incredibly specific, I know!).  So, that same path, had it been on the C:\ would have worked fine.  Fortunately, this presented us with an easy workaround, as the bug only affected drive paths that weren't the C:\... so UNC paths worked fine.  We replaced the text in our shortcut target field with the UNC path to the executable and it worked just fine (fortunately, the executable didn't seem to mind being invoked via UNC path).


Popular posts from this blog

Orphaned VMDK Files

Migrating from one vCenter to Another, Improved

Copying VM Folders and Permissions from One vCenter to Another