I.T.@Chester, Willcox & Saxbe L.L.P.
From Precarious to State-of-the-Art
Transforming a house of cards into a stable, 'zero admin' system.
By Wayne E. Smith
LURED BY the challenge of overhauling the entire information system, I arrived at Chester, Willcox and Saxbe L.L.P. in the summer of 2000. The firm, fully aware of the precarious state of its system, hired me to assist with a ground-up transformation.
What greeted me was not encouraging. One tired old Compaq server (running Netware 4.1 and GroupWise 5.2) was functioning as the lone file, print and e-mail server for 65+ users. A workstation-grade PC with NT 4.0 server was operating Juris 1.42, and an ad hoc assortment of client PCs were running various iterations of Microsoft's Windows operating systems and its Office suite. Documents were stored in just about every known file format since personal computers first came on the scene.
A meager 64K leased line constituted the firm's Internet access; practically no security or anti-virus measures were in place. The server was dangerously low on disk space and had to be purged twice a day to keep it alive. Juris was very unstable, with critical accounting data at risk. Performing anything productive on the Internet was a pipe dream, and at any single moment the whole house of cards could be brought down by a virus.
Chester, Willcox and Saxbe L.L.P. traces its origins to 1884, when John J. Chester began his practice in Columbus, Ohio. Current senior partner, John J. "Jack" Chester -- a three-term state representative and special counsel to the President of the United States in 1974-75, -- became a member in 1948. Jack and sons, John, Jr. and James J., continue the tradition.
In 1971, the firm merged with Willcox, Park and Hoffman and considerably expanded the firm's business, real estate and probate practice. The addition of the Saxbe family in 1977 helped expand the litigation, legislative and government work.
Today, Chester, Willcox and Saxbe L.L.P. has 30 attorneys and about 70 users. Planning a new system that would serve real and perceived needs was not going to be easy. Buy-in from all departments, practice areas, and individuals was essential. Keeping the existing system alive long enough to roll out the new one was going to be a challenge, perhaps a miracle.
The following planning considerations were deemed essential: 1) Adherence to "zero administration" principles. 2) The introduction of a document management system that would bring information closer to each user. 3) Security and data integrity. 4) The new system must be stable, fast and scalable. 5) A budget target of no more than $4,500 per user.
The central imperative behind our planning decisions was a commitment to pursuing "zero administration" ideals throughout the system. Largely associated with Microsoft's formal network management program, "zero admin" is advanced by anything that simplifies the administration and maintenance of the network and minimizes support overhead. This includes a common user environment, remote desktop administration, software version control, group-based system policies, a managed log-in experience, and consistent hardware throughout. A system designed around zero administration principles, for example, may require only one support technician for every 75 users, compared to the industry standard of one to 40. Reductions in total cost of ownership is the driving force.
We considered all market leaders in the area of document management, including Hummingbird Ltd.'s Docs Open, iManage Inc.'s namesake iManage and World Software Corp.'s Worldox. Because we wanted a SQL-based back end, Worldox, although full-featured and seemingly offering the most bang for the buck, did not make the final cut. The ultimate decision to opt for Docs Open was based essentially on my experience at Squire, Sanders and Dempsey, and the fact that our service partner, BEC Legal Systems, had extensive Docs Open experience.
Then the real work began. First, we had to determine what version and feature set to go with: DocsFusion, PowerDocs, CyberDocs, Verity Indexer, mail integration or not, and that was before even tackling issues such as application integration methods and the document type architecture. It was enough to make your head spin.
Another question centered on Docs Open compatibility with SQL 2000, just out on the scene. Although Hummingbird indicated no problems, we were hard pressed to find examples of this combination in the field. After countless hours of testing on our lab network, we settled on a fairly conservative installation that included Docs Open 3.9.0 running on SQL 2000 Server, with the barebones Verity Indexer. Outlook integration was nixed, as we deemed it unstable and intrusive, and all of Hummingbird's Web-capable products such as DocsFusion, PowerDocs and CyberDocs were put on the shelf for now.
No part of the existing equipment base would go untouched. Servers, workstations, switches, and even printers would all be replaced. We wanted industry leaders in all sectors and for this reason we decided on Compaq servers and workstations, 3Com switches, Hewlett-Packard printers, and a Cisco Pix firewall box. Consolidating our sourcing around specific manufacturers would also reduce the number of support contacts required, consistent with zero administration thinking. Our desire to get the very best gear at below market prices was advanced by the general drop in hardware prices at the time, and the cut-rate, volume pricing we received from our primary vendor, CDW.
For servers, we went with Proliant ML370s and ML330s outfitted with 1 GHz processors, RAID 5 storage and the fastest hard disks money could buy. Our workstations were fully equipped DeskPro EX (convertible) Micro towers with PIII 733 MHz chips and 128 Mb of memory. The standard Intel NIC was upgraded to a comparable 3Com card to provide standardization across network connectivity devices. By settling for the one year depot warranty on the PCs, we were able to save $75 per unit up front.
I have always used 3Com networking gear and am dogmatic in the belief that they are simply the best. Certainly, other brands cost less, but I saw no reason to mess with success. The new network would deliver 100 Mpbs riding on 3Com 3300 switches; 3 TM models would connect each of our 3 floors, switch to switch at GB speeds. Up to four switches could be managed collectively as one, with a single IP address for the entire bank.
All printers were replaced with HP Laser-Jet 2100s (local) and 4050Ns (workgroup). Although other makers such as Xerox, IBM and Lexmark have been nipping at HP's heels, we opted for HP. One factor: most toner maintenance companies support the full LaserJet line.
To match our commitment to security, we chose a Cisco PIX 515R firewall appliance that Sarcom, our security partner, says is the best on the market for a network of our size. It supported unlimited and secure virtual private network access and offered management and monitoring features.
By far, choosing equipment was easy compared to the stress involved in sourcing software. As events would have it, the very time we were planning our upgrade (Spring 2001), Microsoft released new versions across all back office lines: Exchange 2000 (messaging), SQL 2000 (database), ISA 2000 (proxy), and Windows 2000 (Server and Professional). Although SQL 2000 was structurally similar to its predecessor, SQL 7, Exchange 2000 was a radical departure from 5.5, and ISA Server was nothing like Proxy 2. It can be perilous to go with untested products, but these new applications offered the management, automation and interoperability features we wanted; in short, zero admin. So we decided we would venture forth with the '2000' products, subject to extensive testing.
The wilderness was indeed a lonely place. Few, if any of the local support contractors had any significant exposure to the new products. I vividly remember one consultant ooh-ing and ah-ing over Exchange 2000 at our site. When asked if he had seen the product before, he said confidently, "No, but I've heard good things." I was not amused. "You can leave now" was my response, then I called our account rep and had someone else sent out.
Other issues involving E2K were serious. There were no truly compatible anti-virus or backup tools. Network Associates would not offer GroupShield 5.2 for at least six months, and Computer Associate's Exchange Backup Agent never seemed to work with E2K. As it turned out, ISA and SQL worked remarkably well right out of the box, and we have had few problems.
Another critical hurdle involved Juris. Although initially the Access-based Juris 1.42 was held over to the new system in the hope it would smooth out, it became even bumpier than before. So when we received the brochure for the SQL-driven Juris 2.0, we plunged in with a splash.
Finally, the ease of use and full feature set associated with Juris would be matched by a strong, reliable networking component. Our Juris support provider, Amicus Curiae, Inc. had much to do with the smooth transition to the new and improved application.
To advance zero admin in managing the client environment, we settled on a course using Group Policy features and ScriptLogic. Group Policies had come a long way since NT 4.0, and ScriptLogic, a tool for creating and distributing log-in scripts, was a godsend. Here we add printers, tweak the registry on remote PCs, create Outlook profiles on the fly, install OS patches, update virus signatures, and set a host of common MS Office settings. Although there was some overlap in what ScriptLogic and Group Policies could do, we quickly settled on a nice mix based on their respective strengths.
The End Game
With critical hardware and software in place, we still faced many questions:
1. Would a converging upgrade scheme be practical given the instability of the current network? How would we prep the workstations and deal with the miscellaneous practice-specific programs in use?
2. How would we get our 140,000 documents converted into Word and imported (and indexed) into Docs Open?
3. How would we set up Docs Open to accommodate all practice groups needs?
4. Was it possible to salvage GroupWise messages and import them in Exchange?
The list went on.
While our director of administration, Kit Murphy, and BEC worked with the practice groups on establishing document types, keywords, etc., we set about planning how to convert, en masse, 140,000 documents from all of the various document file types to Microsoft's Word. Conversion Plus by DataViz, was our tool of choice.
Once converted into Word format, we then imported the documents into Docs Open by assigning them common profile attributes, and used the description field to reference the original path and filename. This allows everyone to effectively find and re-profile their documents. Although we tested this extensively and were confident it would work, the actual process would have to wait until the final roll out. A dark cloud over our heads was the fact that we could only guess at how long this would actually take.
Using the new, improved GroupWise to Exchange Migration tool that shipped with Exchange, we were able to salvage e-mail messages from the old system. Attorneys were thrilled. I was skeptical at first and promised nothing. The fact that we had all users' e-mail waiting for them in Outlook that first day was, I believe, a significant symbol for them that all would be okay.
Well into the planning stages it became clear that it was unlikely the current system would survive any upgrade scheme requiring interoperability with the new system. Time and disk space were running out.
We had little choice but to do as much as we could in advance, then perform what I will call an 'off and then on again' system upgrade. The old system would be taken offline on Friday evening, and by the following Monday, users would be greeted with the new.
To this end, all of the new printers and monitors were installed ahead of the game to minimize the sheer physical overhead during the weekend.
All of the workstations were imaged from a master using Norton Ghost, asset tagged, and user assigned well before the weekend cutover. During the week leading up to that pivotal Friday, everyone in the office was starting to get a sense that something big was about to a happen.
And although we planned as best as we could to limit uncertainty, there was still that sense of uneasiness often associated with technology.
On the Friday of the roll-out weekend, absolutely everything had to work from the outset or come Monday I would be looking for work, and more importantly Chester, Willcox and Saxbe L.L.P. might not be open for business.
The margin for error was zero. Everyone closest to the project was stressed and exhausted. All of our plans, hard work and best wishes were heavily invested in the outcome. By the time the submit button was clicked to initiate the document import process, we all knew what was at stake. One of our project partners, Bob Reeves, of Onsite Technical Resources, is also a church pastor, and it was comforting to contemplate how he might just bring a bit of divine blessing to our efforts. Perhaps he did, for by exactly 7:45 a.m. on Monday, the last document had completed indexing, and everything appeared to go precisely according to plan. No more house of cards at Chester, Willcox and Saxbe L.L.P.
Wayne E. Smith is manager of information systems at Chester, Willcox and Saxbe L.L.P., in Columbus, Ohio.