Installshield debugging on a remote PC [SOLUTION]

This is the issue that prompted my starting this blog.  And as stated above, it may end up being the only post I make, only time will tell.

Due to no fault of my own, my organization uses InstallShield (currently 2010 premier) for package development.  Occasionally, an issue will arise that requires that I debug an installation on test machine, that is, I'll encounter an issue that I cannot explain via logs or even in-line debugging and am forced to run the installation in debug mode on the offending device.

Today, I lost nearly seven hours of what could have been highly productive time simply trying to get the debug mode started on a target.  When I began, I realized that I hadn't actually run a remote debug session since we upgraded our projects to IS 2010.  I wasn't terribly worried about that, and proceeded in the fashion described in all of the Flexera documentation (one example of which can be found here.)  I followed the instructions to the letter and yet the debugger simply would not come up.

I will refrain from describing my efforts in the registry editor, double-checking my Setup.dbg file, running Filemon and Regmon to see if I could figure out why ISdbg.exe was not attaching to my installer.  Suffice to say, I spent a ridiculous amount of time trying every command-line permutation, moving my installer source all over the filesystem, trying to run it off the network, and rubbing my temples until they turned into shiny red mirrors.

Finally I keyed in on one specific line in the various troubleshooting docs I'd been finding online and in the help:

Note that if your installation, script, and debug files are all in their original location on the development system, you do not need to specify the path to the debug file—use the following: setup.exe /d

I was at that troubleshooting stage where you stop checking if an idea is dumb, and so I changed the filesystem on the target so that I could place my installer source in the exact same location that it lived on my development machine.  My development directory lives on my D: drive, so that required changing the drive letter of the CD on the target, and creating a R/W filesystem on D: (this was a VM, so it wasn't terribly hard; you could probably do this with a mapped network drive or a USB stick, etc.)  

I created all the subfolders to match my development system, then copied the entirety of the installer source to the target system.  I opened a command prompt and navigated to the release image in the source, then ran the installer with the  "/d" switch:

D:\ISDev\Trunk\ProjectXInstaller\Main\Full Installer\DiskImages\DISK1>projectx_setup.exe /d

Success.  Frustrating, infuriating, teeth-grinding success.

It has taken me so long to get the damn debugger up that I only have a vague idea of what I set out to test, I reset the VM as part of the troubleshooting so I need to reproduce the issue all over again, it will probably take me another hour to get to where I should've been at 9:30 this morning.  Anticipating that something like this will happen to me again shortly after I've forgotten how I solved it this time, I decided to take a breather to make this post.  Hopefully someone else will find this while debating whether a new career in the custodial arts would be better than working with InstallShield and can avoid the horror that was my day.  

At least it's Friday.  After I make up all the time I wasted on this tomorrow, I'll still have Sunday to wind down...