In a series of articles written by Yuval Kossovsky, manager of digital media systems for Hunter College’s Department of Film and Media Studies, Computerworld is following that City University of New York school’s ongoing efforts to integrate new Apple hardware and software. This is the second of those articles, which are designed to offer a hands-on view of integrating Macs and Apple software in what is largely an Intel and Windows world.
|<?php virtual(“/includes/boxad.inc”); ?>
(see story), I introduced you to our planned system upgrade project for the Film and Media Department at Hunter College in New York. The first three milestones in this initiative were moving the Academic Lab computers from Mac OS 9 to OS X, implementing Gigabit Ethernet on the backbone and creating a NetInfo/Lightweight Directory Access Protocol catalog to centralize authentication and account management.
Here, I will focus on the operating system software upgrade process. The migration was performed in two stages: Last fall, we standardized 45 seats on OS X 10.1.5; now we’re pushing ahead to implement the newest version of the operating system, 10.2.3, which is known best by its code name, Jaguar. Companies not already sitting on Version 10.1 licenses will move directly to Jaguar, something that should be considered a blessing. Jaguar contains many improvements in the administration and user management area for networked machines that are not working from an authentication server/domain architecture. (For the purposes of this article, I’m assuming you are working from a file server without using domain authentication, and all machine accounts are local.)
First, make sure your hardware is compatible with OS X and has sufficient RAM to run it, along with your particular software suites. The first consideration in migrating a public lab to OS X is performing a full inventory of applications and determining the total cost to upgrade your productivity suite to make it run OS X natively. If the cost exceeds your total budget, you’ll have to prioritize the essential apps and/or determine which programs must operate in native OS X mode and which applications can run acceptably in the “classic” or OS 9 environment.
I found that in the graphics and printing suites, there’s still a lack of native compatibility for OS X. You may need to allow certain end users to switch between OS 9 and OS X system boots. Unless you have the very latest hardware from Apple, which no longer boots directly into OS 9, this should not be difficult. Consider how many user groups you will need locally, and remember that without a domain, these will be separate from network accounts. Questions to ask: Do you want a single configuration with access to all applications? How about separate graphics or word processing log-ons? Planning is essential, since adding these accounts postdeployment is a nightmare.
The next step is to build a prototype system to test for stability and user acceptance. I cannot overstate the importance of testing your configurations for stability and usability. I would have moved the academic labs directly to Jaguar last September, right after Mac OS 10.2 was out, but it was released only a few days before the start of classes and we wouldn’t have had enough time to test. There will always be issues that crop up in testing, and even in the best deployments some bugs invariably pop up. Deploying without thorough testing is the fastest way into the unemployment line.
Step 3 involves setting up account preferences. Jaguar added some nifty admin tools, making it much simpler to ensure a consistent user experience. (If the user isn’t designated as an admin, then he or she can’t run most of the utilities.) Under 10.1.5, we either deleted the admin tools or used SuperGetInfo to make them invisible. This method is widely know as “security by obscurity,” and works only for a while. Jaguar tools make this process much simpler. You can now set how a desktop looks, what applications are in the tool bar and what applications a specific user will be allowed to operate. You can also limit user access to any or all of the system preference panels. Using this method, we have locked down the tool bar, and so far, none of our lab users have been able to break it. In fact, in addition to the speed and stability benefits offered by OS X, being able to control the user environment without the use of third-party tools such as Intego’s FileGuard or PowerOn Software’s OnGuard is the best reason to migrate.
Finally, you’ll want to create a master image, which means nothing more than taking the prototype system operating system and apps and “cloning” them in one image. There are many tools for doing this: In the PC world, Symantec’s Norton Ghost with SID walker has been the method of choice when deploying image clones. With previous Mac OS versions, you could simply copy all of the files, move them to another partition, “bless” the system folder and voila, you had a clone. In OS X, however, this doesn’t work. Various issues with permissions and ownership of files has made cloning a more complicated scenario.
To clone in OS X, you can use shareware tools such as Carbon Copy Cloner or commercial — and, thus, more robust — tools. I chose Retrospect from Dantz Development Corp. It will back up a disk partition and then drop it anywhere else, maintaining all permissions and rights without error. The product is also useful in a network deployment scenario. And yes, I also use it to back up all of my Mac and Windows servers and desktops as the product was intended to do.
Once you have an image, simply restore it to all of your machines. Reboot, change the machine name in the sharing preferences and the Dynamic Host Configuration Protocol (DHCP) ID, if you use DHCP. It’s that simple, and it’s almost as easy as in OS 9. But the results are more stable and user-friendly.
In my next installment, I’ll explain how to set up a NetInfo domain and the best way to structure permissions and groups. Until then, feel free to e-mail me with questions about our deployment at
For more enterprise computing news, visit
Computerworld.com. Story copyright (c) 2003 Computerworld, Inc. All rights reserved.