Novell Home

Deploying Mozilla using ZENworks 3.2

Novell Cool Solutions: Feature
By Anthony Ardolino

Digg This - Slashdot This

Posted: 11 Aug 2004
 

Contents

Introduction
All the Moving Parts
Watching the Parts Move Together
Conclusion

Introduction

Situation

North Central College staff and faculty use approximately 700 computers supported by 12 ITS members. All computers run Windows 2000 with service pack 4 and the latest patches. Each computer has Client 32 loaded and is usually logged into every morning. The college currently has three production NetWare 6.0 servers arranged in a cluster and all attached to a SAN. ZENworks 3.2 SP2 resides on the SAN; however, no workstations are imported into NDS. All users have local administrator rights granted via DLU. The supported Internet browser is Netscape 7; the profile is stored in the user's home volume which is f:\profile.

Objective

Move all users and computers to Mozilla 1.6. Retain all bookmarks and the home page from Netscape. Install the common plug-in applications. Remove obsolete profiles that are no longer needed from the user's home directory. Make it difficult for users to run IE by removing all icons. Remove Netscape (and Composer) from all workstations. Have Mozilla's profile stored on user's home directory at f:\mozillaprofile.

All the Moving Parts

Mozilla

Mozilla is pretty user-friendly as far as customization goes. Two files that are of most importance to the application are:

%USERPROFILE%\Application Data\Mozilla\registry.dat
Tells Mozilla where to look for a user's profile directory. This file is a binary registry file so it isn't the easiest thing to edit. You can use a program to edit this file; however, I found it easier to configure one and save it for further installs (described later).
More information about the registry.dat file can be found at http://www.alain.knaff.lu/howto/MozillaCustomization/find.html
Prefs.JS
This file resides in a user's profile directory (f:\mozillaprofile\prefs.js). It contains all the user-specific settings. This is what our default prefs.js looked like and an explanation of each part. http://www.mozilla.org/unix/customizing.html#prefs contains lots of information on configuring the preferences in Mozilla.
http://gemal.dk/mozilla/files.html has a great reference about the files Mozilla uses.

The Plug-ins

In addition to installing Mozilla, I wanted the users to not worry about manually installing plug-ins later. The following applications were installed after Mozilla:

Adobe Acrobat Reader 6
Flash 7
Java 1.4.2.03
QuickTime 6.5
Real player 10
Shockwave 7

Each application installed program and the plug-in files needed by Mozilla need to be in C:\Program Files\Mozilla.org\mozilla\plugins

ZENworks

Unique Challenges

As stated earlier, we have ZENworks 3.2 with no workstation objects imported. This brought about some unique challenges to overcome.

ZENworks 3.2 does not have application chaining or application dependencies like ZENworks 4 does. This means there isn't an easy way to have one ZENworks app launch another (either before it starts or after it is done). ZENworks 3.2, like ZENworks 4, does allow for the associating of applications to workstation objects, a really great feature. Unfortunately, North Central College does not currently have this feature working properly.

Since workstations are not imported into eDirectory, the number of applications and the complexity of a wrapper application sky rockets. Why? Because this project involves doing things on both a per-user basis, via configuring their profile, and on a per-machine basis, via actually installing Mozilla and the plug-ins.

If workstation objects were imported I would simply associate the installation applications to the workstations and the configuration applications to the user objects. Since this was not an option I was forced to associate both the install and the configuration ZENworks apps to the user, which adds a nauseating level of complexity. Another challenge I encountered was that ZENworks 3.2 (and ZENworks 4, as far as I know) do not support OR logic in their system requirements. This only became a limitation because no workstation objects were imported, but it too added to the level of complexity.

Mozilla Install Application

This ZENworks application was pretty straight forward to create. I took a snapshot of an install of Mozilla, and made sure that this install pointed to the f:\mozillaprofile directory (the registry.dat controls this). This application drops a file called mozilla.txt in c:\zen\apps; this is what is used as a flag to determine if the install has happened on a machine. After the snapshot was finished I created a ZENworks application called "Mozilla Install". This application was associated to all users; the requirements for this were NO existence of c:\zen\apps\mozilla.txt AND OS of Windows 2000.

Plug-ins

This was really 6 different applications, one for each plug-in. Like the Mozilla install, all of these were snapshots of the install. I tried making one big application that combined the 6 plug-ins and Mozilla, but this randomly crashed so I abandoned it for this approach. However, for simplicity sake, think of this as just 1 application called plug-ins. The application was associated to all users and set to force run. The requirements are: NO existence of c:\zen\apps\plugins.txt AND that application Mozilla Install has run AND OS of Windows 2000.

Launcher Application

This is a very simple ZENworks Application that runs the program Mozilla.exe which is located at c:\program files\mozilla.org\mozilla\mozilla.exe. The requirements are: Files c:\zen\app\mozilla.txt AND f:\mozillaprofile\prefs.js exist AND OS of Windows 2000. This is associated to all users (since they all should run Mozilla).

Batch File

This was what put everything together. Most of this file was not necessary if we had workstation objects imported into eDirectory. This Bat file actually became 3 separate ZENworks applications, each with a specific system requirement (this due to no OR logic). Click here for a full listing of the Bat file and an explanation of each part. The three applications this became are named:

Mozilla Script Install and Profile
Mozilla Script Install only
Mozilla Script Profile only

Each of these applications has a specific set of requirements that will be explained in the outcome matrix. They are all set to force run on all users.

Watching the Parts Move Together

The Matrix

Using the two files of c:\zen\apps\mozilla.txt and f:\mozillaprofile\prefs.js there are 4 possible outcomes that can happen when a user logins in with regards to file existence. They are as follows?

Outcome 1: Mozilla.txt YES       Prefs.js YES
Outcome 2: Mozilla.txt YES Prefs.js NO
Outcome 3: Mozilla.txt NO Prefs.js NO
Outcome 4: Mozilla.txt NO Prefs.js YES

What do we want to happen?

First we have to figure out what we actually want to happen before we can make it so. Below is the logic that explains what should happen when a user logs in and what ZENworks application should run. The outcomes are what the ZENworks application object should have set as their requirements.

Outcome 1: YES to Mozilla.txt and Prefs.js

This means the user already has a Mozilla profile and that the computer already has Mozilla installed. In this instance we want to give the user the ZENworks application that launches Mozilla.

Outcome 2: YES to mozilla.txt and NO to prefs.js

This outcome would happen if Mozilla has already been installed on a computer but the user logging in does not have a Mozilla profile, new users and people sharing a PC. Here we would like to only give the Mozilla profile to the user and not reinstall the Mozilla program. The application that would run is Mozilla Script Profile only.

Outcome 3: NO to mozilla.txt and NO to prefs.js

This is the initial login for everyone. They do not have the program Mozilla and they do not have a Mozilla profile. We want to install the program and give them a profile to use it. The application that would run is Mozilla Script Install and Profile.

Outcome 4: No to mozilla.txt and YES to prefs.js

This outcome would happen if a user logged into a PC that lacked Mozilla but they already have a profile configured. In this instance we want to just install Mozilla to the computer. The application that would run is Mozilla Script Install only.

Note: Even though there are three install applications, they all point to the same bat file. The bat file is the part that actually determines what parts to configure or install. The reason that there are three install applications is because of the lack of workstation objects in eDirectory and no OR logic in ZENworks.

Conclusion

Work Stations in eDirectory

If workstations had been present in eDirectory, and not just users, the overall process would have been much, much simpler. If this was the case you could associate the profile app to users and the Mozilla/plug-in installs to the workstations and set them all to force run once (at least that's my quick assessment of what you could do).

ZENworks 4 Enhancements

With ZENworks 4 there is the option to link applications together. This would have also been helpful and would have eliminated much of the complexity that surrounds the bat file; mainly, it would eliminate the loops in the bat file.

Notes since implementation

The rollout of the application seemed to go very smoothly; it was installed to over 700 PC's and over 2000 users. The problems that we have run into are related to Mozilla not being a widely accepted browser. Some critical websites refused to run on Mozilla and some reported that they would not work; but in fact they did work, if you changed the agent string though a program found at http://chrispederick.com/work/useragentswitcher/.

An unforeseen side effect of running Mozilla's profile on a network drive was that it will not allow multiple instances of Mozilla to run on different machines. This is not a flaw "per se" as it makes sense that you would not want two machines trying to update the same files on a network drive, but this behavior was not in Netscape 4.x or 7.x. It may be that this was an oversight in the previous versions, but it was something that our users expected in the new version. If a user tries to launch Mozilla on a second PC they are presented with the "choose your profile" window. I am trying to think of a workaround for this that involves creating a default profile on the local drive and launching the Mozilla through Novell with the proper switches, so it does not ask for a profile unless the main one is in use. This will involve changing all the PC's and mild education of the user, so it may be a while before it happens.

If you have any questions you may contact Anthony at adardolino@noctrl.edu


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell