So I thought I’d try and make them start faster, the biggest improvement seemed to occur when I deleted the %FONTS% directory from my capture (I also got rid of some other folders I didn’t think should be there, such as the driveC and so on, they had almost nothing in them. My .dat files are only about 200MB lighter now, but the speed up in starting times is drastic, down to about 30 seconds as a result.

As all three applications had the same “standard” fonts I decided to just make the fonts available to each machine as an installable MSI following instructions much like these ones. I also had a quick look over here: http://blogs.vmware.com/thinapp/2010/01/thinapp-troubleshooting—repost.html and followed their advice about turning off the automatic services.

There is an open bug on this issue: 53996.
Essentially, Adobe programmers were expecting this file to be located in the Program Files\Common directory and as such did not see an issue with modifying these file rights.
One way to workaround the issue is to manually change file rights for the Thinstall folder or make the users type in a serial number the first time they launch the app.

So that’s what I did, I used icacls to run a quick command on the folders in questions during user logoff, and because we’re rolling out RES at the same time I just added this as a task for all users, it’s a one line command that looks like this:
icacls %APPDATA%\Thinstall\* /T /C /grant %USERNAME%:F

So, there are quite a few bits and bobs out there about CS5 but none that tell me all the things I want to know in once place.

Let’s start by point out the useful “thinapphelper” tool for those of you who aren’t aware of it: http://www.cis.nl/thinapphelper – it’s a nifty tool that allows you to inspect everything that’s going into a build, the most useful part of this for me is that it allows me to delete any temporary files that I may not want to be within the package.

There are several different “prompts” that I ran into when using Adobe Creative Suite 5 thinapped:

1. The customer experience / improvement programme, or whatever you want to call it – no, I don’t want to participate
2. The “Adobe Live” registration screen, no, I don’t want an Adobe Live ID
3. Updates and update reminders

Disabling updates is quite well documented by Adobe, and it’s nothing harder than creating an .xml file in the right place for each of the applications, you can read about that here: Adobe help, disabling auto-updates for Creative Suite.

The annoying prompt to register the application seems to be linked to having a file, \%AppData%\Adobe\com.adobe.118.registration, which contains some nonsense – I probably should have had this file created as part of my initial capture but for some reason I didn’t so I had to pull it out after running on a client machine and just add it back into the build, worked perfectly after that.

The much more annoying Adobe Live registration screen is much harder to fix though, and I googled for a while before finding this blog post which indicated that the issue lay within some private database files! You’ll need to download SQL Lite to open them and change the keys in question.

I additionally had to ensure that the following registry keys were being populated,

HKEY_CURRENT_USER\Software\Adobe\CommonFiles\Usage
HKEY_CURRENT_USER\Software\Adobe\CommonFiles\Usage\Demographic
HKEY_CURRENT_USER\Software\Adobe\CommonFiles\Usage\Exchange-Pro 9

Again, I missed this as part of the initial scan / post-scan setup so I probably should have been able to capture these, but in the end I just hacked open a Registry.tw file on a client machine and guessed as to which keys I needed to put back into the image – it worked.

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 .

I have been looking for a way to encrypt data on my ReadyNAS NV+ for the last couple of weeks and there’s nothing built in, and as of yet, no-one’s written a third party add-on that allows it to happen.

Having previously used TrueCrypt I thought I’d investigate options with that, and due to the fact that you can’t encrypt just a network share the options you’re left with are:

1. Make a TrueCrypt container on your NAS box and put all your data in that
2. Somehow hook up something iSCSI and encrypt that entire drive.

So, it turns out there is a third party iSCSI initiator, great, it’s published as a ReadyNAS plugin with instructions here, so I downloaded it and gave it a go. You need the EnableRootSSH Plugin too as you’ll need to run commands at the linux prompt to get this running properly.

I followed the instructions and tried to make a 2.7TB iSCSI drive (the size of the box) – this failed due to the fact that dd has a 2TB restriction (which I probably knew but didn’t remember) – you can in theory make larger ones using gpart but I couldn’t find it on the ReadyNAS I had.

Anyway, I tried both the options above, firstly I just made a TrueCrypt container on the NAS box (writing straight to the CIFS share) and then secondly I set up an iSCSI drive (without too many issues, mainly my own typos causing me grief) and connected to it from Windows 7, then used TrueCrypt to format it, I then did the classic iometer tests.

The results were interesting: using firmware 4.1.8 for the NV+ the difference between no encryption and TrueCrypt encryption is minimal, about 1MB/s – this is due to the fact that TrueCrypt will be doing all the work on my client machine rather than on the ReadyNAS device. Unfortunately, the iSCSI initiator performed really badly, offering speeds of approximately half that compared to just accessing files over CIFS:

You can see here that although the difference between TrueCrypt and not using TrueCrypt isn’t that huge (with TrueCrypt the results are on average about 7% slower); the difference between using the iSCSI initiator and the plain CIFS access is huge: anywhere from 38% slower to 51% slower.

The reason that I was initially concerned about using a TrueCrypt container is that I thought “oh no, it’s one file, if it becomes corrupted then I’ve lost all the data”, although realistically this is exactly what the iSCSI initiator does too, you use dd to create a single file and then share that up as an iSCSI drive, so not all that different after all. My conclusion is that I’ll just create a TrueCrypt container the size I require and use that via CIFS to achieve the encryption I’m looking for with my NV+.

Update: Just played with beta firmware 4.1.9T2 and the improvement speeds are drastic, the “normal” (no iSCSI, no TrueCrypt) CIFS speeds rose from 25MB/s to 45MB/s, using a TrueCrypt container the speed improvements aren’t quite as good, but the speeds rose from 24MB/s to 33MB/s.

Update: There is a slight bug in that the “stop” command does in fact not stop the daemon – a “ps” still shows the daemon running – from what I can tell this is because the PIDFILE is wrong, the script specifies /var/run/iscsi_target.pid the output is actually /var/run/ietd.pid – I changed the service script to match and it now starts and stops correctly.

For one of my first projects this year I’ll be looking at Application Virtualisation – streamlining application deployment by creating single executable files which can then run on any workstation, there are some obvious advantages to this such as centralised deployment and maintainance, as well as the speed at which new applications can be provisioned using such methods.

1. See all posts relating to this project

A project never really finishes, if you’re lucky you complete the initial requirements and get those signed off, and if you’re good at managing your project you’ll refuse to allow the scope creep in and mark any additional feature requests as “phase 2″ and evaluate them at a later date. One of the nice-to-haves with the deployment of iPhones was a VPN system so that you could access the internal systems when out of the office, and to date this has been in a very “test and dev” environment with access only for IT staff in a completely non-supported way.

However, I’ve found myself with a bit of time and so I started delving into the SCEP world for issuing certificates to iPhones which I would then later use to authenticate an SSL VPN connection, and here’s what I found.

Firstly, Apple’s documentation on the process is shocking, luckily Microsoft have been the better man in this instance and posted an entirely useful blog post on the subject which is available here: http://blogs.technet.com/b/askds/archive/2010/11/22/ipad-iphone-certificate-issuance.aspx.

In the section “NDES Configuration settings” on that blog post they make mention of Microsoft Patch 959193, as I have 2008R2 SP1 installed I already had the fixes available, but you should definitely consider using the HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\MSCEP\UseSinglePassword setting as it will mean that you can put your challenge password into an iPhone/iPad profile and not need to change it every time.

More importantly (for me) is that there’s an additional hotfix required from Microsoft if you’re trying to do what I was trying to do, and it’s here:http://support.microsoft.com/kb/2483564. Specifically I found this because even though everything was set up correctly I kept getting an error in the NDES server’s even viewer that said: “The Network Device Enrollment Service received an http message without the “Operation” tag, or with an invalid “Operation” tag”

Do create an extra user account for your NDES service / application pools when the opportunity is given. If your NDES server isn’t your CA (and I imagine in many cases it won’t be) you’ll have to follow the post-installation instructions on 2008R2 that tell you how to use setspn.exe to delegate authority for your user account to access the CA, this is often achieved by simply bringing up a command prompt and writing:

setspn -s http/NDESSERVER domain\useraccount


If you get an error saying there’s multiple instances (which happened to me after I failed this installation the first time) then you will need to delete the old delegation before re-creating the new ones, this blog post on MSDN has a useful list of setspn commands which you can use for this purpose.

I had one additional error which was much harder to catch, after following all these guides perfectly I logged onto my server and got this in the event viewer: “The Network Device Enrollment Service cannot be started (0×80070002). The system cannot find the file specified.” as well as a nasty server fail message when I browsed to the website. If this happens to you then hopefully it’s the same issue as me and to fix it you need to log onto the machine using the account you created for NDES (i.e. not just the Administrator account).

Anyway, assuming you’ve followed the guide properly you’ll be able to navigate to http:///CertSrv/MSCEP_Admin/ and see a screen that looks a bit like this one:

And from here you can go ahead and fill in the profile on something like the iPhone Configuration Utility:

I had one remaining niggle after all of this, the thing kept failing and the event viewer KEPT showing me that “The password in the certificate request cannot be verified. It may have been used already. Obtain a new password to submit with this request.” – obviously nonsense, we know I’m using single passwords…. Turns out that when I was copying and pasting the key from the webpage it was bringing an extra white space character with it. I should have known better…

I hope I don’t get sued to high heaven for this sort of thing…

I recently translated the Portuguese subtitles from the Roam DVD (it’s a mountain biking film by The Collective) into English for a friend so I thought I’d upload them on the off-chance that one day someone happens to be looking for them, they’re not perfect but anyone’s welcome to them:

The Collective – ROAM – English

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.

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.

How much more expensive? Well, I paid about £900 for an iomega ix4-200r and about £4,000 for the equivalent-size netgear. For the larger units, a fully populated ix12-300r would set you back about £4,000 whereas the equivalent netgear cost more like £9,000. The netgear 3100s come out of the box with two power supplies and two NICs, whereas the iomega only has one of each, so all together it sounds like it’s much more aimed at enterprise level customers. In addition, the netgear 3100 allows for creation of LUNs over 2TBs which was my initial complaint about the small iomega boxes.

These tests were all performed using the Microsoft iSCSI initiator from within a Windows Server 2008 R2 machine, accessing a 512GB LUN created on the devices.

So, onto the results. Using the classic iometer config file I tested for 100% read, 100% write and the Real Life 60% Random, 65% Read setups (you can download the iometer config file here), the numbers are MBps:

So, the Netgear 3100 vs the ix4-200r:

Next, the Netgear 3200 vs the ix12-300r:

I know. I’m as shocked as you are – with the smaller NAS box comparison, as you’d expect, the more expensive and reliable netgear wipes the floor with the iomega device, but when you scale up to the larger models the iomega devices start responding better again. Very strange! To make matters worse, the netgear 3200 units only have two network ports in them whereas when you upscale to the larger iomega boxes they come with four.

To illustrate the point here I’ve run the same comparison with the iomegas using 1, 2 and 4 bonded uplinks:

As you can see, tragically allowing more NICs to share the load means you can get increasingly better throughput (the iops rise in a similar fashion) whereas with the 3200 this will only be possibly with a maximum of two (yes, this is a touch unfair because I haven’t done the same test using both of the available NICs on the netgear and I should have) – but you know what? I’m still going to buy the netgear units over the iomega units just because of the horrible time I’ve had up until now.

So, in summary:

1. The 3100 is significantly better than the ix4-200r but there’s a cost implication – for on-site backups I think the 3100 will certainly become the standard choice
2. The 3200 performs well, but not as well as the ix12-300r
3. I will never buy another ix12-300r due to the history of issues I’ve had