Ths article was written when I tried to install the CiscoVPN client on windows 7, and found that many other instructions out there were either based on a version of XP Mode that no longer applies, or were never checked to see if the instructions actually worked.

Firstly, you will need to install Windows 7 XP Mode to your PC. As of today (late September 2009), it is the RC. You will need a copy of Win 7 Ultimate or Professional, which is unfortunate for the Home users not willing to fork out the mre than doubling of cost between Windows 7 Home Premium and Ultimate.

http://www.microsoft.com/windows/virtual-pc/download.aspx

Select your installation type – here I selected 64 bit system, and English language (A generic English).

Step 2 is a 7 meg msu file (the new hotfix installer file type created since Vista), but XP Mode is a slightly larger 470 meg executable. Thank you ADSL 2+.

Install the two packages, and start “Windows Virtual PC” “Windows XP Mode” which is a pre configured Windows XP virtual machine.

The machine kindly maps all your local drives as networked drives.

The default browser installation is IE 6 ... yuk. Not too secure, although I would recommend using your host machine to do the heavy browser lifting.

I then navigated to my host c:\ drive (C on THUNDER) and tried to install the Cisco client ... The following error message came up when I ran the installer: “The Windows Installer does not permit installation from a Remote Desktop connection.”

Trouble in paradise.

I copied the entire Cisco folder that was extracted from vpnclient-win-msi-5.0.04.0300-k9, and pasted to the Virtual PC’s c:\ drive. 

I then tried running the cisco vpnclient_setup.exe, which just seems to launch vpnclient_setup.msi.

SUCCESS ! Lucky break. Not very obvious, Microsoft.

The client software is installed into the start menu under “Cisco Systems VPN Client”.

The application that was installed under the XP Mode VM automagically is installed into the Win 7 Menu under the “Windows Virtual PC” folder, in a new folder called “Windows XP Mode Applications”. Nice blend of terminal server 2008 style remote desktop serving an application, with a back end VM server.

Rebooting your machine after installing the Cisco VPN Client

Some weird windowing issues still in the RC. This is a truncated WGA installation that popped up automatically after the reboot.:

I tried running the “VPN Client (Windows XP Mode)” menu item.

Running an XP Mode application whent he vm is running is verboten, and results in the following message: “To open a virtual application, the virtual machine must be closed”

I then closed down the XP Mode VM, which hibernated it.

And ran the Cisco client again.

Which resulted in a new message: “’Windows XP Mode’ was closed with a user logged on”.

Clicking Continue will log the user off and run the application.

And the application starts. The windows have Win XP borders – not Win 7, so are easy to spot the difference.

When connected, the Cisco icon appears in the taskbar as a normal application.

Remote Desktop is already installed on the XP Machine, but does not show up as a “Windows XP Mode Application”. This is because of a new exclude list in the registry of the XP VM.

Start regedit, and navigate to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtual Machine\VPCVAppExcludeList". Delete the mstsc.exe key.

Reboot the VM (I used the “Ctrl+Alt+Del” menu at the top of the VM)

And the menu shortcut automatically appears in the Win 7 machine.

Some automagic stuff performed when the XP Mode VM reboots creates a shortcut in the “C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows Virtual PC\Windows XP Mode Applications” folder. Here’s a shot of my folder – the Remote Desktop connection was not there a moment ago.

Start the VPN client, then start the remote desktop from XP Mode. Not sure why it has the window scheme of Vista / Win 7, but it just does.

Some outstanding issues

On my XP VM, the Cisco client kept on being uninstalled whenever I rebooted.

For the best candidates from an interview, test for the corner cases

This article deals with interviewing for corner cases. The outliers that help make a good organisation capable of being the best.

This blog entry was inspired by an actual interview. An interview in itself is not so unusual ... for at least half the year I sit in on about three or so face to face interviews a week.

This coder looked good on paper ... twelve years coding, the last three years hands on C# - and self rated at 7 through 9.5 out of 10 for technical skills.

Our first icebreaker exam question is designed to settle the candidate's nerves by being nice and simple. It's a property. “Tell us about it” I ask.

This guy proceeds to tell us in no uncertain terms that our three line code snippet was plain bad coding. I was intrigued, so I gave him the keyboard.

The keyboard I use for the interviews is a weird wireless Microsoft one. It has a super sized delete key that invades the space where the Insert key should be, and has the added bonus of weird key spacing. It's pretty horrible really, unless you are forewarned and expecting it, or have one just like it at home. I'm just starting to get used to it. It's taken me close to a year. The really great coders we interview never seem to have much trouble with it.

Well he starts fumbling away and out it comes – I recognise three different languages and some new form of pseudo code. There's not one identifiable C# keyword (admittedly there is a semicolon that is in the right place). It's a mashup of sorts. It's not Web 2.0. It's not the sort to get you hired as a senior coder. Well, certainly not for a C# role. Well, not _this_ C# role.

Terminating the interview within five minutes is unfortunately far from uncommon. Lots of coders with brilliant CVs bomb out on the warm up questions – questions even those cramming C# for dummies while sucking on Red Bull the night before should get right.

The reason for this is that lots of coders lie through their teeth on their CVs. There must be a reason – and I know that in the past someone's rewarded these time thieves with a job somewhere along the line.

For both your and the common good, you should never, ever interview candidates without the aid of a standardised exam that allows you to compare previous answers to gauge exactly where this candidate fits on the totem pole. This applies to every type of candidate I have helped to hire - accountants, office managers, junior network engineers etc. You Need An Exam.

This exam should be pitched for the corner cases. It needs to be interactive – rather than having them fill out the answers and then you marking it, you need to be there, listening and prompting them for more clarity. It should be as close to real world as possible.

The test results should be:

• The really bad candidates should fall out immediately.

• The OK ones should be guided swiftly though to the end; and

• The really really seriously talented coders should make the exam so much fun you miss dinner with the kids.

The exam should be first cab off the rank - no time wasting chit chat or bonding before hand (you can do this if they are a good match) – my order of proceedings is offer freshly ground coffee, tea or iced water, remind them that they were warned about the tough exam, then hand it to them and provide instructions on how to navigate it.

This way they get to show us just how good they are. All the guys we have hired since I started at MaxSoft have gone through this exam, and _all_ of them loved it. For the right person, it's a blast ... a bunch of techie guys rabbiting on about code and objects and heaps and more code stuff. I learn a lot from these interviews, and am sometimes amazed at just how smart and quick and good some coders actually are.