Google Earth is a great program for schools, as it allows teachers and students to explore the worlds geography and use layers to examine history, socio-economic information and many other areas.
It used to be fairly easier to deploy on your network, but after version 4.2 it became significantly more difficult if you use a deployment program like Zenworks. A new MSI test was introduced to determine where to install Google Earth. If the current user is not an Admin User it would redirect to [LocalAppDataFolder]Google\Google Earth (usually C:\Documents and Settings\username\Local Settings\Application Data\Google\Google Earth) which made it inaccessible to other users.
As Zenworks uses the System account, which is not an admin user, this would happen when the installer was launched by a student.
To fix this problem there are a few different techniques. You can use either ORCA or Admin Studio Tuner (from Zenworks) to create a transform file that ignores these checks. Alternatively you can use ORCA to edit the msi file directly, I had to use this technique for V5 due to some exisiting problems in the Google Earth MSI.
First download the full version of Google Earth, (V5.0.11337). You should be able to find later versions through Google.
To find what you need to edit you can do a search in ORCA for AdminUser you should find around 3 entries.
The major entries are:
InstallExecuteSequence: ChangeInstallDirForNonAdmin: NOT AdminUser (Delete this row)
InstallExecuteSequence: setALLUSERS: AdminUser (remove the word AdminUser so it applies to all installs)
InstallUISequence: ChangeInstallDirForNonAdmin: NOT AdminUser (Delete this row)
You may also wish to remove AdminUser as a Condition from Component: Plus_Registry_wavdest.ax
Once these are removed or modified it should install in C:\Program Files\Google\Google Earth regardless of which user is logged in.
When you install Internet Explorer 7 (IE7) on Windows XP or Windows Server 2003 it may display a security warning when you access applications and files stored on Novell drive mappings if it does not consider them part of your local intranet.
It may also prevent MS Access from opening databases from the network as they are considered a security threat.
To see if your mapped drive is considered as either Internet or Local Intranet: first make sure Status Bar is on (View -> Status Bar), then browse to a sub folder of drive and look in lower right hand corner. or
Testing Security Settings or Configure for Individual PC
Open the “Internet Options” control panel
Click Security Tab, Local Intranet, Sites
Untick Automatically detect intranet network then tick Include all local (intranet) sites not listed in other zones and Include all network paths (UNC). I find these are the minimum required. However I find these still occasionally don’t work so I add the server names and server IP range to intranet list.
Click Advanced and add the names and IPs of your servers. This should be in form MyServer, and IP ranges as 10.1.1.2-10.
Browse to network location and check if Explorer shows Local Intranet in lower right of screen.
Check if files and applications now open without requiring verification.
Deploying Settings using Group Policies
If performing the above has fixed the problem you probably need to deploy these settings to all users, which can be done using Group Policies.
Open the Group Policy for machines affected (this may just be local GPEdit.msc on a terminal server or the Zenworks Workstation Policy in ConsoleOne).
Make sure the IE7 version of inetres.adm is loaded (~2.3MB). If not it can be download from MS IE7 ADM.
Go to Computer Configuration -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page and set the following:
Site to Zone Assignment List:
Add your server names with a value of 1 to list.
You can add your server IP range with name “10.x.y.1-30″ and value of 1.
You may want to add the Windows Update entries with a value of 2.
In ConsoleOne it is relatively easy to change the path to an MSI but much more difficult to change the file name of the MSI itself.
A trick is to install a second copy of ConsoleOne without any plugins. (I just have link to Clean ConsoleOne.) Using this version you can then Open the App Object and go to the Other tab, and expand zenappPackageName, double click the filename to change.
I use this quite regularly when updating FrontMotion’s Firefox MSI’s. I just keep two object and alternate between them. One production and one testing.
To change the location of an MSI you need to change 2 locations in ConsoleOne (with Zen plugins):
When using Group Policies with Zenworks and Windows XP you may find users are able to create folders and files in root of C:.
This is due to the change in default security settings for drives on Windows XP from 2000.
You need to use the Security Template editor to create a template restricting rights to the C drive and deploy it with your group policies. The same procedure can be used to create a Security Template for use with Active Directory.
I use it constantly when writing scripts and need the full path, or with Zenwork applications needing the UNC path. Just a simple right click gets the complete UNC path.
or 
