Tuesday, June 29, 2010

Forcing Google Apps to use Chrome instead of Internet Explorer

Continuing on with our roll-out of Google Apps for Education here at school, we have been struggling a little with browser compatibility.

First off,  it's obvious, and it's inevitable, but Google Apps is much better in Chrome than it is in Internet Explorer, hands down. I'm not entering into the browser debate, and in lots of ways I don't really have a browser preference but Google Apps simply looks, feels and functions better in Chrome, and as new features become available in Apps, we are finding that IE won't even run some of those features anyway (Wave, Drawing etc.). There is a plugin available from Google (Chrome Frame for IE) that enables Chrome functionality within IE, but as with most things Google, there doesn't seem to be any offline installer that we can use to push out to all of our client workstations. We will keep looking though, because if we find one, it will solve most of the issues we are having.

Another simple solution would seem to be just to roll-out Chrome to all of our workstations right? Wrong. Again, Google doesn't make this easy. Although there is a standalone installer for Google Chrome it installs itself into the user profile directory rather than the common 'Program Files' and for a few reasons this simply won't work on our network. Again, no easy fix for this yet either.

Having spent a few hours on this, I went and did something else to clear my mind, and I then remembered 'Portable Apps'. Portable Apps is a collection of applications that have been packaged up to run on portable media (i.e USB keys) but they often run just as well on a network, without many of the hassles of applications that need to be 'installed'. We use Audacity and WinFF as portable Apps here and students run them seamlessly across the network. There is a portable apps version of the latest Chrome browser and I'm pleased to say it works a treat. I simply installed it to a network share, then created shortcuts in the student profile that run the portable version of Chrome, and call up the particular address for each Google Apps component on startup. So the students now have separate shortcuts on the desktop to Google Docs, Google Sites and Google Calendar that force run Google Chrome. Job done so far. We still have links on our Intranet page that point directly to the web addresses of Google Apps, and these will open in the default browser (which is IE on most of our workstations) so that is the next problem. We'll keep looking for the Google Chrome Frames installer, and maybe an easy way to push Chrome out to workstations, but for now, it will do.

18/11/10 Update on this, the Google Chrome Frame installer is now available as an msi which can be pushed out via Group Policy

Tuesday, June 8, 2010

More livin' and learnin'..

It was a 'teacher only' day on Friday and as most of the staff were in a PD session I used the time to tidy a few things that had been niggling at me for a while.

One of those things was to increase space for my virtual 'Windows Deployment Services' server so I could store more images on it. In order to do this, I decided to change the VHD file (Virtual Hard Drive file) of my virtual print server from a fixed disk to a dynamic disk, to claw back some of the 64Gb of space from the print server to use on the deployment server. The print server was only using 11Gb of it's drive space anyway, so I figured that space was probably better allocated somewhere else. Although I had never converted from a fixed to dynamic disk before I have gone the other way a number of times and it's always worked well. So I went ahead and did the conversion, but in doing so I ignored the error message regarding the snapshot that I had loaded against my print server telling me that there could be a loss of data. Stupid move. The conversion went well, I booted up the print server, but I couldn't logon to the domain. Strange I thought, but maybe something to do with trust relationships etc. (?). So I logged on as the local administrator, removed the server from the domain, rebooted, rejoined the domain and hey presto that fixed that problem. As far as I was aware that was it all sorted.

I had a days leave planned today and yesterday was a public holiday. I had a text message from a teacher yesterday telling me they were having printing problems and although alarm bells started to ring somewhere in the distance, after logging in from home and running some basic checks I assumed it was just error between keyboard and seat and left it at that. After my technician had texted me this morning in a state of distress that everyone was having print problems, I began to regret ignoring those basic checks. I won't go into everything but it turns out that by ignoring the snapshot error I had basically reset the printer to a state of 6 months ago, when I first set it up. I had used the .vhd file of the print server and ignored the .avhd snapshot file when I had done the conversion. In itself this wasn't so much of an issue but what was screwing things up was that the databases that handle our print cost recovery (Papercut and Monitor Business Machines) had gone back to as they were six months ago too. Nobody had any credit and none of the new printers I had put in since six months ago existed.

Luckily, I had made a manual backup of the original .vhd and .avhd files and after restoring and merging the snapshot back into the .vhd things are back to as they were. Phew. Again, so many lessons learned. The main thing I think is that although living in a Hyper-V world has made SO many improvements to things, it's also made me a little blase about what I do with my servers. I have to remind myself that even though they are virtual servers they can still stuff things up just as well as a real server when I get it wrong  ......