3.1 BGSU

Public Workstation setup was a three-stage process. First, Windows was installed, and a BIOS bootup password was enabled. Second, public and restricted use desktops were created, and finally, access to all computer functions and software were removed from the public desktop except for a web browser.

After all of the appropriate security and application software was installed and set up on the primary public workstation, it was thoroughly tested, and an image of this workstation hard drive was then created on the network server, using the Norton Ghost software. This image was then restored to the second public workstation to guarantee that both computers would be identical.

1. Install Windows 98 or newer.
2. Install printer drivers.
3. Edit the BIOS settings to require a password when the computer is booted. Since many windows programs require rebooting the computer after a program is installed, this effectively blocks users from successfully installing many personal use programs (chat, streaming media, mp3 sharing etc..)
4. Create two user desktops:
5. A public desktop with no password. (named: Public Access)
6. A password restricted desktop (named: Restricted Access - Password Required)
7. Log into the public access desktop, and load X-Setup, (and/or) the Tweaking Toolbox for Windows, and use their many options to disable all features from the public desktop except the ability to load a web browser.
8. Tweaking Toolbox for Windows and Xteq Systems X-Setup program are both menu-driven Windows Registry Editing Programs. By selecting appropriate items from their many menu options, even casual windows users can gain a great deal of control over the appearance and security of the Windows desktop.
9. Using these tools, the following changes were made to the public access desktop:
10. All extra writable drives on the computer were disabled (Zip Drive, CD-R Drive).
11. All icons were removed from the desktop including: Network Neighborhood, My Computer, Recycle Bin.
12. All standard options were removed from the start menu including: Documents, Favorites, Settings, Find, Run.
13. All options were removed from task bar except 'Show Desktop' and 'web browser'.
14. The Screen Saver was enabled and an appropriate screen saver was selected.
15. Ability to run command.com was disabled.
16. We also disabled the ability to press 'Esc' when loading either desktop.
17. Note: One of the really notorious breaches in Windows system security is the ability to load any password protected user profile (desktop) by selecting that desktop on the menu, and then simply pressing the escape key.
18. Installed the web browser as the only program available to the user, and placed shortcuts to it in both the startup and programs folders on the start menu.

• Setup and configure both desktops,
• Adjust security settings with Tweaking Toolbox and X-setup,
• Install new software as it is received, burn CD-ROMs
• Update the html menus on the web browser to provide access to the installed documents CD-ROMs.

First, a prototype computer was brought down to a non-public area and all of the CDs that were decided on were loaded via the VirtualCD emulation software. Once all the titles were on, working and ready, guides were created.

When the guides were complete, the prototype was taken upstairs to the University Libraries ITS department. They did all of the above and then cloned the prototype to create the other four computers for a total of 5 identical workstations.

1. Create emulated CD
2. Install from the emulated CD
3. Install the disc as usual
4. Create VCD Shortcut
5. Create New File Type
6. Edit the Registry entry for the new file type.
7. Create the Executable Link

5. Processing New CD-ROMS

1. Determine if it is to be mounted on the workstations or checked out.
2. Catalog and link it into our library OPAC
3. Enter the CD into our local CD-ROM database, print and upload the updated pages.
4. Install the CD on the master office workstation, create all of the appropriate html pages, and verify that the software and web links are working properly.
5. Create the appropriate W3Launch files for that program, and verify that W3launch loads the software correctly.
6. Install the Software onto the primary public workstation and copy the html and w3l files to that workstation.
7. Create an updated disk image using Norton Ghost on the department server
8. Promote this image to the second public workstation, again using Norton Ghost.

• Provide complete inventory control of the CD-ROM collection.
• Provide bibliographic information external to the OPAC with ability to create web pages showing holdings by title, department, SuDoc Number, and subject.
• Provide enhanced descriptive information about each CD-ROM including:
• URLs for online information
• Whether or not CD is mounted on workstations.
• Complete description of contents
• Help file about how to use each CD-ROM.
• Provide an easy method of browsing the collection by title, department, Sudoc number, or simple subject.
• The ability to print the additional web pages and all of the necessary w3launch information files for each CD-ROM mounted on the workstations.
• Ability to update database through a password protected web form on an intranet server to provide a central database available to any staff member.

• Design issues involved the development of a database structure that would parallel, but not emulate, the OPAC. The result was a relational database that preserved the bib record/item record relationship.
• Once the database structure was established, all of the government documents records in the OPAC were exported to a data file, and then imported into the new database.
• After importing, all records were checked against the actual CD-ROM collection, and any discrepancies were corrected in both the database and the OPAC. As part of this process, additional information not found in the OPAC was added to each of the bibliographic or item records in the CD Database. Tracking information includes:
• Date received,
• location of the CD during each stage of processing,
• final physical location of the CD-ROM (i.e. is it in Jerome or Science Library), whether it is mounted on the workstations, and any restrictions on use or checkout, etc.

• Many databases now allow the generation of reports in html format. In order to create web pages that could be easily loaded on the campus server, the reports, each consisting of a single web page, were printed to a file rather than to a printer.
• Reports are currently generated to create web pages which allow browsing by title and department.
• Additional indexing and report generating routines are being written which will allow browsing by SuDoc number and simple subject headings as well.
• Page style and layout is controlled through the use of template files, so the appearance of the pages can be changed without having to reprogram or edit the report generator.
• All appropriate URLs and page links are generated automatically by the report generator out of the information stored in the database or in the template file.

• While the implementation of an open access CD-ROM search engine was not feasible because of the university restrictions on their web server, setting up a locally accessible web server on the documents office LAN server to create an office intranet provides some unique advantages.
• Generally, web services provided through well written CGI programs will be more secure than sharing drives, folders, or files on a LAN (under Windows, almost anything is more secure than sharing resources using their networking system.)
• Additionally, setting up a small web server provides a wonderful platform for testing pages, etc., before uploading to the main university server.
• Finally, using forms-based access to a database has the advantage of providing full control over the entire process of access and data entry. The entire database system can be password protected to allow only approved users, and each user's activity can be controlled by allowing them different levels of access - some users may be restricted to only viewing records, some to editing current records, while others may be allowed full privileges including adding new records. Some users can be restricted to working only on item records while others may be allowed access to both item and bib records.
• Careful page design to control all phases of user activity can greatly simplify the entire process of data entry and editing, reduce the amount of staff training required, and reduce the number of user errors.
• The CGI program for the intranet database engine is currently in development. Like the program used for the page generator, all of the web pages and forms used by the system will be stored as a set of template files. This design allows great flexibility for future growth, since the CGI program is data driven - if additional data fields are needed, they can be simply added to the database, and the web forms can be edited to display/edit them. No change is needed to the CGI program itself in order to handle alterations in the database structure.

• The structure of the database is being expanded to include many new fields, some suggested by the "GITCO" project. (many thanks to their efforts.)
• Data entry into these fields is progressing, although at a slower pace than anticipated.
• Data entry into these additional fields is being performed first on those CD-ROMS which are mounted on the public workstations.
• After those CD's are complete, the rest of the collection will be updated.
• Stage 5: W3Launch file generator.
• The final phase of the project will be to add several additional report functions to the web page generator. These functions will write all of the files used to access the CD-ROMs mounted on the public access workstation. The main menu page, all submenu pages, the program startup page, the w3launch startup file, the program listing file, and the w3launch initialization files will all be generated automatically from the database.

7. Those Pesky Titles, or Some Challenges

8. Summary of Steps to Create Public CD Access

1. Decide which titles are to be made available.
2. Decide on the desired form of access: local/mediated, local/unmediated, remote, etc.
3. Decide on the user interface, perhaps by doing user testing or based on user comments at the reference desk.
4. Go to your IT department, tell them 1-3 and ask about institutional policies and constraints.

• If you are in a small institution without an IT department, then you will be constrained only by what you feel you can do.

1. Make an equipment request.
2. When the equipment arrives, set up a prototype with everything you might want on it.

• A rule of IT is that it's always easier to remove than add. Paradoxically, this is true of security software too: you lock the computer completely, then selectively remove restrictions.

1. Duplicate and backup the prototype.
2. Customize as needed.
3. Put them out for the public to use.
4. Fix the minor problems that will come up until they're stable.