Josh Work CT Motorola Collective Technologies at Motorola

My first client for Collective Technologies was Motorola, Inc.

My tasks for Motorola were:


Daily Support & Operations

I was originally assigned to some smaller subgroups within the Worldwide Systems Development Division (i.e., Engineering) as their primary systems administration contact; my job, in short, was to keep their machines up and running with as little inconvenience to the users as possible. My initial tasks included building workstations (adding drives and installing the operating system and applications), installing workstations in users' offices and cubicles, wiping disks of no-longer-used machines prior to returning them, downloading and installing software, creating accounts for new users, fixing accounts with problems for existing users, and troubleshooting various hardware and software problems.

The client department (Engineering Information Technology) reorganized in January 1999 creating a two-tier support system. I was in the front-line support group, one of 10 or 11 people supporting the day-to-day operations and all primary support interactions for the entire 750-person division, with a focus on Unix-related problems. The second-tier group was effectively dedicated for the Y2K effort, and only available for escalation and assistance for first-tier support issues that we couldn't resolve among ourselves.

During the conversion from MacOS to Windows NT, in late spring of 1999, when most of the NT-savvy administration team was dedicated to migrating and educating users, I was one of half a dozen admins remaining to support the entire 750-person division. My duties expanded beyond the general Unix system administration tasks to include coordination of the backups and monitoring daily reports, writing a weekly general technical status report for the technically-inclined users and managers, assigning problem reports from the unassigned queue, and general resource management (hardware, software, and people).

After another reorganization (September-October 1999), I became part of a 4-person team in charge of daily support of three product groups, and provided assistance to the other 4 daily support teams. Basically, we had to clean out the old backlog of trouble tickets and keep the new tickets from being too overwhelming.

In October 1999, EIT reorganized again to better provide desktop, application, and infrastructure support to the user community. I returned to the Desktop Support team supporting two (later three, as they reorganized) engineering development groups with three other support team members. For two weeks in October and November when our team lead was out on medical leave, I was acting Team Lead for our group of three.

In January 2000, EIT began processing the backlog of trouble tickets and began working on issues deferred until after the Y2K rollover. I continued working on trouble tickets.

[Top] Up to top of page


Year 2000 Planning

In April 1999 the support area was again reorganized. Daily support and operations tasks were assigned to one group (based on skill areas instead of customer groups), and about a dozen people including me were dedicated to the Y2K effort. I became half of the Unix Server team. We had about 2 weeks to identify the scope of the effort and put together a project plan; when we started, there were about 180 servers and 100 applications that needed to be upgraded to the Y2K compliant standards. We went to pilot in May 1999 and planned to roll out to production in June and July.

In July 1999 the Y2K team went to second- and third-shift hours so we could do the documentation and be available to answer questions and rebuild servers outside the 8am–5pm production day. However, since management finally realized that the documentation effort would take as long as (if not longer than) the work itself, the documentation efforts were shelved and the entire Y2K server team did the work off-hours during July and into August (7 weeks of nights). We ended up with 237 identified servers, of which 217 (92%) were completed by our goal date (August 7th) and all of them were completed by the deadline (August 15th).

[Top] Up to top of page


Year 2000 Cleanup

After August 15th, the Y2K Teams began working on cleaning up the issues that we either caused (as part of the server and workstation changes) or ignored (as not related directly to the Y2K project). This entailed updating documentation, clearing out the problem report database, and working on the "post Y2K issues" list that had been built during the upgrade process.

[Top] Up to top of page


Year 2000 Rollover

I also worked the Y2K Rollover weekend. During the 5 days that Motorola was closed — Friday December 31st through Tuesday January 4th — I worked 3 shifts and was stand-by on 2 others. The rollover itself was uneventful; all prior planning had paid off. When we returned power to those machines powered down intentionally, everything came back up just fine, with only one disk needing to be replaced (and that disk was bad before the rollover weekend).

[Top] Up to top of page


Technical Education Meeting (TEM)

In February and March 2000 I put together a quick basic overview of how to administer Unix in our production environment to an audience of Windows NT administrators. Some had previous exposure to Unix but most hadn't. The course focused on the generally easy-but-time consuming tasks like making changes to DNS, NIS, resetting passwords, and a quick overview of the environment from an architectural standpoint, including how to get from one system to another using the trust relationships and where to find what kind of information.

The course was expected to be taught for 1–2 hours to an audience of about 10 people. 20 showed up. It went very well; virtually all feedback was positive.

[Top] Up to top of page


System Administrator's Guide

In my occasional free moments I compiled all the policies and procedures involved in administering systems in the Division and created a book, Motorola Systems Administration (282 pages in its first edition). The book covers working with accounts (adding, changing, and deleting) and hosts (building, deploying, reconfiguring, and decommissioning) and applications (installing, configuring, troubleshooting, and removing) in the Division-specific environment. It also documents the account and host naming standards and the IP address (network and host portion) conventions in use, as well as the Motorola- and Division-specific tools the administration team uses on a daily basis.

[Top] Up to top of page



On to my next CT client


Back to my CT page
Back to my work page
Back to my home page

Last update Apr05/22 by Josh Simon (<jss@clock.org>).