accessible view | jump to content | search | jump to site-wide navigation
Addendum —LSA Administration Network Pilot Subgroup Final Report
MEMORANDUM
TO: Joe Marino, Associate Dean
Mike McPherson, Director, Information Technology
FROM: Rob Wilke, Chair, LSA Administration Network Pilot Subgroup
DATE: November 28, 1995
The Steering Committee of the LSA Key Administrators Group raised a few questions and sought to clarify some omissions from the Final Report of the LSA Administration Network Pilot, dated November 3.
The Pilot group has met to consider the questions raised by the Steering Committee and wishes to append to the report the following for clarification. Attached please find the questions submitted by the Steering Committee, followed by the responses of the Network Pilot Subgroup, and regard them as part of the Final Report itself.
Note that the overall recommendations of the Pilot group have not changed. We are eager to see the services of the pilot expanded and made available to all departments in the College. We have recommended that this take place once the personnel resources are identified and in place, but not before. The Committee will be happy to meet with you to discuss the details of the report if need be. We anxiously await the establishment and communication of a timetable for moving ahead with these recommendations.
CC: John Cross, Associate Dean
LSA Administrative Computing Group
Steering Committee, LSA Key Administrators Group
Addendum—LSA Administration Network Pilot Subgroup Final Report
After review of the proposal by the LSA Administration Network Pilot Subgroup, the Steering Committee of the LSA Key Administrators raised some questions about the report that the committee wishes to address as an addendum. The following questions were raised, followed by the response of the Network Pilot Subgroup.
Comments from the Steering Committee regarding the Final Report of the LSA Administration Network Pilot Subgroup
- Overall, the Steering Committee was supportive of the network. However, a major philosophical question was raised in asking for more clarity on why we should go ahead with this project when IFS is in place to provide the same services and we lack staff in the college to manage a network. We believe that the problems with IFS/Windows should be spoken to more directly in the report.
- The Committee questioned the fact that the proposal does not discuss the network as a mechanism for sharing software—site licensing, etc. We thought this would be worth addressing one way or the other particularly with regard to software that is only used occasionally.
- We also talked about the issue of whether the network could be used as an e-mail option in place of IMAP. There was no recommendation one way or the other. We just felt that it should be addressed. (Questions 2 & 3 speak to the "purpose" of the network—is it primarily file sharing? The Pilot Group determined that file storage was not a primary function but did not spend much time on the issues in 2 & 3 above.)
- We also wondered about the role of a network administrator. If someone is to be hired, could part of their role be to manage departmental networks that exist in LSA? There was some suggestion that they might. It would be helpful to know how many LANs we have in departments. Are there any compatibility problems now or would we be creating any?
- There was concern about the short time allotted for files to be dormant before they are removed from the network given the cyclical nature of work. One suggestion was that the owner be asked before files that had not been looked at in 6 months are removed.
- There was a suggestion that the security and confidentiality section should be stronger. The wording in the second paragraph of the Compnet Access portion of the LS&A Policies section of the Key Administrator’s Handbook (2.2.13) was recommended.
Network Pilot Subgroup Response
1) IFS —The Institutional File System at U-M was designed and built with the goal of providing some of the services outlined in the Network Pilot final report. In the Macintosh and Unix worlds, the goal of a remote file server that is seamlessly available from one’s workstation has become possible, though the speed of file transfers to and from IFS, as well as navigating the multi-level hierarchy are quite slow. In the DOS/Windows world (in which a majority of LSA staff work), IFS has not yet shown it’s value. The IFS paradigm is individual ownership of filespace, while the Pilot server paradigm is departmental ownership. Lacking a DOS/Windows platform, and with slow access via Appletalk, it’s clear that IFS cannot meet the file sharing needs of departments of the College as well as Netware.
Netware enables sharing files between LSA departments, within LSA departments and could be set up to provide file sharing services involving other central offices, thus avoiding the need to hand carry documents via couriers. Netware is also able to manage print queues so that in many departments, printer sharing is now a viable option where it wasn’t before. And, finally, some central services are provided assuming Netware is available—for example, the printing of transcripts and degree audits within departments off of the DSC mainframe.
2) Software metering on the server—The proposal does not discuss the possibility of running shared versions of software on the server, metering their use, thus requiring fewer licenses of programs used by the College. In general, running software on a central server that is in another building from the client results in slow performance for the client. Departmental users are likely to choose to install software on their own local server or on their individual workstations. Additionally, widespread use of the most frequently used applications off of the network, such as word processing and spreadsheets, runs the risk of essentially shutting down the administrative work of the College in the event of a network failure. Certain specialized and expensive applications might be usefully provided on a central server with usage metered. This will require further analysis on the part of the network administrator and users.
3) Lan-based e-mail—A college-wide administrative network could support LAN email. The group did not address this as an option, however. Managing LAN e-mail can be quite labor-intensive: E-mail support is a 7-day/24 hour operation; e-mail requires services of a postmaster; e-mail depends on integrated directory services which are difficult to synchronize when multiple directories or systems are in place. These services are currently provided by ITD and shouldn’t be duplicated by the College. Discussions with ITD about an e-mail partnership might be warranted once the College-wide administrative network is in place, but as with item 2, this will require analysis by the network administrator and users. With the recent site license for Eudora, the advantages of LAN-based e-mail are somewhat less than they were if pc or Unix Pine were the only options.
4) Central support of departmental servers—The Pilot project did not consider the possible use of central support personnel to assist departmental networks that already exist. There already is some support provided to departments from LSA OIS, though departments need their own internal network administrator as well. In most cases, departmental servers provide services to faculty, in addition to administrative staff. Since the scope of the pilot was to focus on administrative computing, this issue was not addressed. The Pilot group feels that it is appropriate, from a management standpoint, for the College to look at resources allocated to network support and consider this in its entirety to ensure the effective use of IS support resources, but the group is not making any particular recommendations in this area at this time. The group as a whole has not inventoried networks in the College, though members of the group from the LSA OIS may have such an inventory.
For Macintosh and Windows users with TCP/IP network connectivity, there should be no compatibility issues. For other operating systems (i.e. Unix) or other networks (i.e. DECNet), it may be difficult to connect to the LSA Administrative network.
5) File duration on the server—The Network Pilot group recommended a fairly short period of time to keep files that haven’t been used or looked at—six months. The Steering Committee feels that due to the cyclical nature of much of the work of the College and Departments, that this is unnecessarily short. The Network Pilot group has reconsidered this issue and recommends changing this time span to cover 14 months to ensure coverage of the full calendar year. The Network Pilot group suggests that the Network Administrator and the Director of IT, together with departments, review this recommendation once more experience has been gained.
6) Security—The Steering Committee felt that the following wording from the Key Administrator’s Handbook more strongly reflected the security needs of the Network and suggests that it be added to the report:
"Access to this information carries with it an implicit bond of trust that each [Administrative staff member] will be a responsible user of the data, whether it be data relating to one's own unit or another unit. Federal and State laws, privacy rights of staff, and University guidelines governing the use of data prohibit misuse or general release of data. Abuse of access privileges can result in disciplinary action."
The Network Pilot group agrees with this wording and recommends adding it to the guidelines.