Cisco VPN Client (5.0.01.0600) does work on Vista x86.
It only seems to have problems on localized versions of the OS.

I know this because I installed it on a native english version of Vista and had no problems.
However, my localized (Dutch) version of Viste does throw out some errors during the installation process.

The problem comes from the translations of the user groups in Windows. The installer searches for the "Users" and "INTERACTIVE" usergroups, but is unable to find them because they exist under a different (localized) name. So the solution is to manually make these groups in Vista.
Not a single problem, but Vista Home Premium (the localized version I’m testing on) doesn’t have the GUI components to manage usergroups.
Luckily, we still have the good old "net" command which can do lots of things.
Right before the installation, enter these commands in the command prompt:
    net localgroup Users /add
    net localgroup INTERACTIVE /add
This will create the needed usergroups for the installer.
Now install you VPN client and after installation enter the following commands to remove the groups again. (The client itself works perfectly without these groups.)
    net localgroup Users /delete
    net localgroup INTERACTIVE /delete

The VPN client shouldn’t have any problems running on Vista x86 (tested on Business and Home Premium).

On to the next hurdle! x86_64
(But I’ve heared some rumors on the internet saying I’ll need AnyConnect for that…)

Needed command set:
tw_cli
    start the commandline

info c0
    display information about controller 0

rescan
    Detect new drives

maint remove c0 p1
    Remove the drive on Controller 0 Port 1

maint deleteunit c0 u1
    Remove the Unit 1 from controller 0

maint rebuild c0 u0 p1
    Rebuild Unit0 of Controller0 on Port 1

info c0 u0 rebuildstatus
    display status of rebuilding

New harddrive procedure (c0 u0, new drive in p1):
start the command line
    tw_cli
View controller information
    info c0
remove old drive if necessary
    maint remove c0 p1
Scan for new drive
    rescan
Delete default unit from new drive
    maint deleteunit c0 u1
View controller information
(p1 should not be in any unit, if it is, chances are you’ve done something terribly wrong)
    info c0
Add the new drive to Unit0
    maint rebuild c0 u0 p1
View controller information
(Unit0 should show up as rebuilding now)
    info c0
Exit the CLI
    quit

In short:
tw_cli
    info c0
    maint remove c0 p1
    rescan
    maint deleteunit c0 u1
    info c0
    maint rebuild c0 u0 p1
    info c0
    quit

———————————————————–
Warning:
    Please pay attention during this procedure.
    Failing to do so may result in massive data-loss!
(Nor FirstServed, not the writer, takes any responsibility for the content of this article or any result that may come from using it.

In our Xen confidurations, we like to configure different VLANs on the Dom0 network interfaces, which are then bridged to the DomU guests.  Not only is this more secure than configuring the VLAN interfaces on the virtual machine, it’s also the only way we know of that will work with Windows guests, since on Windows you need proprietary software for Broadcom or Intel NICs in order to configure VLANs, and the Xen Virtual Network Adapter NIC certainly doesn’t provide any software to this end.

We were pretty annoyed to say the least, when we found out that the brand new XenServer 4.0 - which costs five times as much as it’s predecessor XenServer 3.2 - doesn’t allow one to add VLANs to the host interfaces.  Both the XenCenter console and the xe vlan-create command return ‘This operation is not allowed with your current license’.
Hope was not lost, however, since we figured out the following workaround:

In /etc/sysconfig/network-scripts, comment out the following line in ifcfg-eth0:

Add a new VLAN interface, called ifcfg-eth0.142:

Add the following line to /etc/sysconfig/network:

You can now test the new setup without restarting by using the following commands:

You should now have connectivity on your newly created VLAN interface.