On Not Assisting Remotely
I want to help my dear mother, who lives thousands of kilometres away, to set up her iTunes software and download the John Doyle lecture onto her iPod Mini. I guide her to the Apple site, and for whatever reason we can't download it.
In order to fix the problem I really need to see what's on her screen. I tried two different tools, and completely failed.
Microsoft Remote Assistance
Windows XP has a feature where you can request help from a knowledgeable person, and they connect to your computer, and remotely control it for a bit. Sounds like just the ticket, right?
Well apart from subjecting us to an infuriating wizard that asks a whole lot of useless information and provides no feedback on what it's doing, Microsoft Remote Assistance has one major flaw. It will not work behind a NAT. You can verify this yourself by generating a remote assistance request file, opening it in a text editor, and marvelling at the private IP addresses embedded within.
My conclusion is that Microsoft Remote Assistance is useless to just about 90% of users likely to need the feature. And I'm being kind, I should say it is a complete WOFTAM. It puts the Ass into Assistance.
Windows XP, and hence the Remote Assistance feature, came out in 2001, almost a year after RFC 2993 described The Architectural Implications of NAT. Who wrote that, you might wonder. Why, only someone at Microsoft. There's really no excuse for anyone to perpetrate this kind of NAT nonsense in this day and age, but surely you expect better from the guys who write the RFC?
Fog Creek Copilot
So when I read Joel's problem statment for his new Copilot venture some months ago, I initially wondered what the shortcomings were in Microsoft's Remote Assistance that justified building such a product. Now I know.
Anyway the Copilot product/service has been released, and we gave it a try. I have to say that it is very well-conceived. You pay-per-incident with a 2 minute free trial. The software is easy to download and run. I had the client software up and running quickly, and my mum had the server side running a few minutes later.
And when I say "running" I mean "producing error messages".
When she started the application it said (apparently) "detecting proxy settings" for a few seconds, then eventually decided that it couldn't connect to Fog Creek's servers, and produced an error message.
Fair enough, you might argue, there's something wrong with her computer. To which I would say "like, duh!" (or perhaps something more witty). Remember the use case here? The precondition for using the tool is that there is a problem!
Now I'm not expecting miracles. If the next-door neighbour's cat has chewed through the ethernet cable, there's not much any software can do to about that. But here's the thing I can't understand: my mum's computer, including the internet connection and whatever is wrong with it, was nonetheless working well enough to download the software in the first place. There was obviously some form of connectivity, so why couldn't the software to do what it said it would do?
So buggered if I knew what to do next. I gave up.
I'll be down at her place at the end of the year, and will hopefully sort everything out then. I don't know whether I want the problem(s) to be something really simple, or really difficult.
Update: As per Chris' suggestion below, we tried UltraVNC SC which didn't work. Gave no error message, just quit. At least that's what I was told.
Of course, this was after the horrific experience of emailing an exe file. In order to get around whatever anti-spyware and anti-virusware software my mum has installed, I ended up shipping an encrypted .zip file containing the .exe. For some reason she also had Stuffit for Windows installed which insisted on putting up the "associate file types" dialog box every single time it was launched.
Gee, remote debugging is fun.
Update 2: It turned out to be a rogue firewall.