Clone Google Mini Drives

The Google Mini Search Appliance is wonderful, a 1U server hosting the Google search engine, a solution in a box. It is a plug and play solution aimed at indexing corporate networks, intranets or extranets. It is assessable via a http web forms user interface for admin and search or a XML web services API interface. It is able to continuously crawl corporate data, then indexing it with a simplified version of the Google magic algorithms. These days there are solutions like Microsoft Search Server, but this solution is supposed to be an appliance, it is ready to go configured in a sealed box, no tinkering folks!

Two Google Mini obtained from ebay

The Mini is no longer available to purchase. These days users are encouraged to use the big Google service in the cloud or the larger much more expensive Google GSA appliance.
Users of the Google Mini might find themselves buying a couple of Google Mini servers from eBay, for spares. This is useful should production units fail for spare hardware parts. Having bought the servers the problem then becomes testing that they will actually work when they become needed. No doubt the previous owners would quite correctly remove the hard drive or wipe it clean before offing it for sale, however the removal of the Google operating system renders the units useless to test.

Clone Drives

To test the Google hardware a working operating system needs to be back on board. It is reasonable to assume that the operating system in the Google Mini would be protected with a hardware fingerprint, tying an install to an exact hardware. Instinct says that simply cloning a disk from a working mini to the purchased blank would not work.  That assumption turns out to be wrong…

  1. With a spare, empty SATA hard drive in hand drive to the data centre where resides the working Mini
  2. Power the Google Mini Down
  3. Peel back the sticker that covers the whole of the top lid, taking it back by six inches
  4. Jam a small flat head screw driver into the anti-tamper head screws and undo them (really!). Alternatively use a hack saw to cut a notch in them (see my post about the Google Mini
  5. Slide back the top lid
  6. Undo the four small screws under the hard drive that hold it in place
  7. Remove the black plastic shroud used for air flow  next to the drive
  8. Carefully slide out the drive, taking care not to knock any components off the motherboard. Mark the drive as original.
  9. Take the drive and add it into another machine with two SATA cables and the empty drive already connected
  10. Identify which drive is mounted to which mount point in Linux after powering up the machine by issuing, in the Terminal, the command lshw, the drive make size etc should identify which disk is which
    lshw -class disk.
  11. Copy the drive from one drive to the other by opening terminal shell prompt and writing…
    sudo dd if=/dev/sdb of=/dev/sda bs=4096 conv=sync,noerror

    Where if is the input file and of is the output file in this case /dev/sdb is the source drive and /dev/sda is the destination, your hardware may differ! (bs is the block size to speed it up)
  12. Wait hours with no progress feedback…
  13. Errors may show in the terminal, these may be genuine bad disk sectors or some kind of copy protection sectors, who knows!
  14. Once command prompt is back power down and remove the drives, replacing the original Google Mini drive back into the server
  15. Refit and replace screws lid etc
  16. Now fit the copied drive into the test Google Mini – it should boot up as if it were the original production machine!

Note: When tested a 2nd copy was made from the 1st copy, it was this copy that was then placed in the server and worked, as for some reason the original 1st generation copy did not boot, it may have been a faulty hard drive?...
Also note that the the copy hard drive may be larger than the original.

Performing the above is at your own risk, it is easy to make a mistake and loose your working mini if you damage the hardware or accidentally wipe the original drive.

Thanks to my team for the work they put in finding Google Minis on ebay, helping with some of the commands and physically lugging machines around.

Irish Tax Registration Number in Dynamics GP (continued)

The previous post GP2010 SP3 Enhanced Intrastats VAT number format wrong IE (Ireland) and others…identified an issue with the validation on the Tax Registration Number in the Intrastat Setup Window for Dynamics GP addresses. Ireland have introduced a new format for VAT numbers that allows two alpha characters, the following is the full specification:

1234567X, 1X23456X, 1234567XX, (8 or 9 characters. Includes one or two alphabetical characters (last, or second and last, or last 2))


If a VAT number is entered in the format 1234567XX, GP will not accept it, preventing the user for leaving that window until a valid format is entered. This was raised with Fargo, but nothing came back from them and it is still a problem today in version GP2013R2. One would expect a SQL table keyed on country code, that holds regular expressions to feed this validator, thus they can be easily changed when this sort of event occurs. Instead it looks like the validation is hard coded in the Dexterity scripts.

Well, if you can’t get a job done properly, do it yourself. Our sales team are starting to hit this issue more often now that the new codes have been available for a little while and more new companies have been allocates these new format codes. This ear ache called for a fix…

Fixing it

Script logging tells us that the validator function is:

'eiProc_IsValidFormat_GBTaxRegNumber()', 0, "IE", "1234567RH"

Wonderful - this looks like a quick and easy fix…

Run the DAG against the Intrastat module to get the.NET assemblies, in my case and with my install that is:

'Advanced Intrastats
"C:\Program Files (x86)\Microsoft Dynamics\GP2013 VS Tools SDK\DAG.exe" 2788 /M /O
"C:\Program Files (x86)\Microsoft Dynamics\GP2013 VS Tools SDK\DAG.exe" 2788 /F /O

Reference the assemblies in the addin project,


Now create an after script “trigger” (.NET event handler) against this script in GP on the init of the addin.

'----------------------- EnhancedIntrastat -----------------------------
AddHandler EnhancedIntrastat.Functions.EiProcIsValidFormatGbTaxRegNumber.InvokeAfterOriginal, AddressOf AfterEiProcIsValidFormatGbTaxRegNumber

Write a regular expression to validate the field. Try the regular expression tester extension for Visual Studio, go to the gallery (extensions and updates) to install it, then test the expression.



This is not a optimum expression, but this post is intended for audience that may not be familiar with regular expressions, so it has been left in a form that may be more understood by onlookers.

Finally write the override method called by the after event of that script to change the result to true or false for IE based on the corrected regular expression validation.

Private Sub AfterEiProcIsValidFormatGbTaxRegNumber(sender As Object, e As 
'Override the built in check and replace with the correct checking
If e.inParam1 = "IE" Then
If System.Text.RegularExpressions.Regex.IsMatch(e.inParam2,
"^(IE){0,1}[0-9]{7}([0-9][A-Z]|[A-Z]{2})|(IE){0,1}[0-9][0-9A-Z][0-9]{5}[A-Z]$") Then
e.result = True
e.result = False
End If
End If
Catch ex As Exception
End Try
End Sub

Compile, deploy, test and the form will now correctly validate the new numbers. The regular expression will actually go into a SQL table as the next iteration of this code, the network support team will then be able to add more exceptions to the validation rules in the future without a deployment, should any other countries change formats.

GitHub can't sync “pre-receive hook declined”

For my Makerfaire .NET Microframework embedded work I’ve been using the wonderful Git integration within Visual Studio. For my repository, I’ve been using GitHub as I don’t mind it being public.

It has been a great experience so far, as I’ve been brought up on Visual Source Safe then Team Foundation Server, the way Git works has taken me some time to get used to, but the integrated tools has made the learning easier.


The other day I put some documentation into my project, one file was a Microsoft Publisher file that was extremely large as it held the graphics for my printed displays at the faire. I innocently committed the files into my local repository, then tried  to push it to GitHub. I got the

“pre-receive hook declined”

Error when trying to sync. It seems, quite reasonably, that there is a file size limit on what  can be added. However i’d made another commit since adding the file.

So for the future I document for myself how I got out of the problem.

First you have to get the command prompt git working. Go to Git Settings, on your version of the screen below it will have hyperlink to install 3rd party tools. Follow the link and install them.


Right click around the various windows and some of them have the option to open the command prompt, do so.




I ran the git rm command but using a directory filter to remove all instances of .pub files from my repository, going right back through all my history. The HEAD command says go to now and I could have specified a commit ID to limit the activity to one commit, but this was not needed. Git rewrote all my commits and so I finally pushed the changes back.


Job done!

Git is syncing ok now and I can move on with my prep for Makerfaire uk 2015.