ThinApp CS5 and RES – fixing the permissions issue

In a previous post I talked about ThinApp’ing Adobe Creative Suite CS5 and how to disable all the prompts so that end users aren’t bothered all the time. I then ran into a different issue, due to the way that Adobe code their products they write a file to “Program Files Common”, which of course with ThinApp is redirected, without read/write access for the current user. This then breaks roaming profiles as the file can’t be copied to and from the server.
Continue Reading →

ThinApp – Discovering vregtool.exe to examine .tvr files

Note: There is a bug in ThinApp 4.7.0 (update expected end of April 2012) that stops this from working.

As part of my deployment of Adobe Creative Suite 5 via ThinApp I had to capture an installation of Adobe Acrobat Pro 9.3 – the project pages on this were helpful, and I deleted the locally installed PDF printer before completing the capture but I obviously missed something because each time I started the application as a new user I got a prompt for the Customer Experience / Improvement programme or whatever. No amount of using procmon could lead me to the file that was being changed, until I realised it was a registry key. And then I realised that I should have made sure this didn’t happen before I finished my capture, and then I was sad.

But, all was not lost, I noticed in the roaming thinstall directory that there was a file called “Registry.rw.tvr” and I thought “that sounds like it might contain registry information”, and sure enough it DOES. It contains the incremental sandbox changes to the registry, so all I needed to do was inspect it, identify the relevant value and then put that back into the ACTUAL thinapp build. I found this blog post which guided me in the right direction and I also found I guide for vregtool.exe in ThinApp 4.6, which provided some more info.

So, once I’d established that I just threw the .tvr file out into a text file (which is the same format as the HKLM/HKCU files in the root of the build directory) and copied across the relevant stuff, rebuilt and voilla!

vregtool.exe "..\Captures\Adobe Acrobat 9.3.0\Registry-CustomerImprovementProgram.rw.tvr" ExportTxt .

Quick: vmware tools on freebsd

I’ve never bothered installing vmware tools on my freebsd systems, but as it’s Christmas and we’re doing various pieces of maintenance I thought, “why not?”

In order to do this I first needed to install the compat6x port:

cd /usr/ports/misc/compat6x/ && make install clean

I then mounted the freebsd.iso from the vmimages folder, mounted the cdrom into existing folder (/cdrom) and copied the folder to the temporary directory before extracting and installing:

mount -t cd9660 /dev/acd0 /cdrom
cp /cdrom/vmware-freebsd-tools.tar.gz /tmp
tar -xf /tmp/vmware-freebsd-tools.tar.gz
./vmware-tools-distrib/vmware-install.pl

Upon completion the installer then runs the first time required config to set up the installation.

NAS comparison: iomega and netgear

As you will know, I’ve had no end of problems with iomega NAS boxes (and customer support for that matter), and so with a recent purchase decided to test the market again and purchase a different product.

Back in the day we had some Netgear ReadyNas boxes, little desktop units offering 2-3TB of network storage which was ideal for backups. The ReadyNas boxes weren’t special in any way, the interface was decidedly average and the software had a few quirks, but they did have one brilliant feature – they hardly ever stopped working.

So, I decided to give them a go again and have since done a direct comparison between the previously-complained-about iomega units and the newly-purchased netgear ones. There are a couple of differences you should know before you worry about the performance though: 1) the netgears are considerably more expensive; 2) the netgears come with a much better warranty.
Continue Reading →

Quick: vCMA (vCenter Mobile Access Server)

VMware vSphere client for the iPad

If you’ve not seen it yet, VMware have have flung out a product called vCMA – it allows you to manage your VMware estate from a mobile device, and although only in first release and officially a “power toy”, it’s pretty neat.

What’s even more neater* is that you also use the free iPad application to connect and then administer remotely with a shiny interface (no, you can’t do it on the iPhone I’m afraid).

Anyway, the point of this was to note the default options, after downloading the OVF file and installing it,

  1. the default URL is https://ip-address/vim
  2. the management URL is https://ip-address:5480
  3. the management username/password by default is root/vmware

*yeah, why not?

Quick: Why not to buy the iomega ix4-200r for veeam backups

In previous blog posts (Using veeam to backup the new virtual infrastructure to Iomega NAS boxes and Backup Strategies with Virtual Machines in VMware using Veeam) I mention my purchases of the iomega ix4-200r, generally I haven’t been impressed with them because they’ve been a little unreliable.

Looking at use around the net I decided that the best way to have a target for my veeam backups would be the iSCSI initiator from Windows straight onto the device, so I should provision a LUN, add it to Windows and write to it.

I tried and failed, after about a week of to’ing and fro’ing with veeam, vmware and iomega support I got to the bottom of the issue: these nas boxes are software locked to provide LUNs that are <= 2TB in size* – bearing in mind my 8 file servers each serve up anywhere between 500GB and 1TB worth of data this means that my first backup file from veeam is always going be over 2TB, making the device pretty much worthless in my environment.

*I’ve been assured that a LUN that’s exactly 2TB will work, although I can’t actually get that working in my test lab having tried it on two separate devices.

snapshot February 2011

To advertise the success of the IT Service Desk in the last year we have producted a newsletter for internal circulation, it’s a high level overview of all of projects that we’ve successfully completed and I’ve been the owner and runner of almost all of them!

Click the thumbnails below for the two-page .pdf (~700kb).

Page 1 imagePage 2 screenshot

Using the Dell EQL MEM Module to simplify my backups (also, thanks again, veeam!)

Many posts cover the installation and performance benefits that come from using the Dell Multipathing Extension Module (MEM) on EqualLogic arrays (check the spoonapedia.com one), but the big difference for me was a bit of a pleasant side-effect in terms of handling backups! I’ve covered off this strategy from a high level in my previous blog post, Backup Strategies with Virtual Machines in VMware using Veeam, but I wanted to explain in a little bit of detail how I actually got there: it was down to the MEM!

Before – accessing data from within the OS

Because the file servers I’ve been working on access a lot of data (8TB worth), the original setup involved using the EqualLogic Host Integration Tools (HIT kit) from within the file server OS to access LUNs on the EQL array – this provided valuable multipath access and proved to be a very successful way of handling access to the data. The problem was that is complicated backups quite significantly, I could use veeam to backup the OSs (and I did), but I had no way of backing up the actual file data.

With various bad experiences from using market-leading backup software such as BackupExec in the past I wasn’t in a rush to go out and spend money on a software solution to handle all this file data, so I resorted to a very low-tech solution: I bought a nas box and did a nightly robocopy.

This was simple, but it was awful: the backups didn’t finish in time (they’re being taken over a 100mbit LES), they never caught up with themselves. It was a waste of time and it basically meant no backups were worth having.

After – install the MEM and let ESXi deal with it

But then the MEM came out, and essentially claimed to offer the same (if not better) performance via ESXi – no messing around with the HIT kit any more, and more importantly, a chance to re-evaluate my first decision about not using .vmdks… I changed my mind.

The first time round I did thick LUN straight into Windows, formatted as NTFS, simple. This time I re-evaluated and did a thick LUN on the EQL and then allocated thin disks in ESXi and mounted them to the file servers… This gives me greater flexibility if a disk gets close to its limits but it also now means that the extra .vmdks are picked up by veeam allowing me to replicate my previously successful backup strategy.

In summary…

Veeam now handles the file data as incremental .vmdks which means it only transfers the changes in the .vmdk files – the entire series of backups finishes over the 100mb LES in about 12 hours (which, bearing in mind I run it once a week at the weekend is ideal); the previous robocopy never finished in that amount of time: the size of the data transferred is obviously the same, but because robocopy iterated through every single file and folder for a comparison it took much longer whereas now veeam just… does it, and it was a product that I already had so didn’t require any extra spend (not to mention the money that could now be saved on not upgrading the LES to 1GB purely for the purposes of backup).

Next?

Now being quite satisfied with this setup I’m going to investigate the series of advice from ErikZandboer on optimising his ix2-200 backup speeds, specifically the post that looks at jumbo frames to target storage.

Backup Strategies with Virtual Machines in VMware using Veeam

A recent tweet from @win2ksrv and then retweeted by @veeam reminded me that I was going to write about the most recent backup strategy that I’d put in place using Dell EqualLogic SANs, VMware and of course, veeam, it went like this:

What is everyone’s Veeam backup strategy? What do you backup to & how do you get it offsite? Where do you place Veeam itself?

The basic setup looks like this:

The Production site has a Dell EqualLogic array and a local NAS box (that’s the black thing), the backup site which is connected via a 25mbps internet-based VPN simply has a larger NAS box (it deals with multiple sites). VMware has been used to create all the file server disks (they are .vmdks) and veeam is installed in another virtual machine using appliance mode to access the SAN.

There are essentially two main risks that we want to mitigate against here:

  1. Accidental deletion / corruption of files
  2. Complete site wipeout (i.e. full blown disaster)

Continue Reading →

Quick: Installing vCentre Update Manager 4.1 on a 64-bit OS

I had an “interesting” day today rooting round the VMWare Knowledge Base articles. It started off simply: I wanted to move my local SQL Express Edition vCentre database onto the much larger, more powerful, centralised SQL server. The KB that describes this, Moving the VirtualCenter SQL database, makes the process simple and flawless, until…

I go to uninstall the local instance of SQL Server and notice there are two, a 32-bit installation and a separate 64-bit version, quickly writing this off as a stupid glitch I uninstall both only to realise why there were two: for some reason Update Manager 4.1 (which can be installed on a 64-bit OS) needs a 32-bit DSN, a 32-bit database connection, to work. It achieves this by default by installing a local copy of 32-bit SQL Express Edition.

Some of you will already be familiar with the joy of using the 32-bit ODBC driver in Windows 7, and this is no different, but the KB, Creating a 32bit DSN on a 64bit Windows machine explains it all for those of you that haven’t.

Finally I was in a position to open up the UI again – but wait, another error message, what now?! A tiny bit more digging pointed me towards the first fix in Enabling Update Manager fails with the error: database unavailable or has network problems, which advises changing the account that the update service starts with to an account with administrator rights.

Once that was done it worked perfectly, so there you have it, a cleverly disguised list of links to VMware KB articles that I had to use when installing update manager 4.1, or more specifically, Moving the SQL databases for vCentre 4.1 when update manager 4.1 was already installed.