Orpheus Department Support - Requirements Revision 1What are the motivations for implementing this project? Orpheus Department Support - Requirements Author(s) Revision Notes 1 – Initial draft of the requirements. Last Updated: June 12, 2001 Revision # 1 2 – Revised draft 2 3 – Another revisiosn 3 June 12, 2001 1 of 9 Orpheus Department Support - Requirements Revision What are the motivations for implementing this project? 1. Project Overview Orpheus for Clusters was successfully deployed for the Fall Semester, Year 2000 to all Computing Services clusters. We are determining the needs of the department administrators on campus, to see how Orpheus can help them to maintain their cluster software and machines. The goal of the Departmental Orpheus project is to deploy a supportable, scalable, secure Windows 2000 based Operating System environment that provides the departments with an easier method of managing groups of systems in order to reduce the Total Cost of Ownership (TCO) for the departments. The current Andrew UNIX distribution is being used as a guideline for features that will be attempted under Orpheus (e.g. Operating System Installation, Operating System patches, Application installation and upgrades, distributed control to departments, distributed file access, and consistent user preferences on multiple machines). June 12, 2001 2 of 9 Orpheus Department Support - Requirements Revision What are the motivations for implementing this project? What are the motivations for implementing this project? 1.1.1 What user need will be satisfied by this project? What other services or projects will be enabled by the completion of this project? What resource savings will be realized? What strategic initiatives will be served by this project? In essence, why are we doing this? Interviews with Departmental administrators indicated that they would like to see the following Orpheus services: Automated Operating System and Patch (Service Packs) Installs via the network – Remote Installation Service (RIS) installation. Automated Installations of Common Applications – Microsoft Software Installer (MSI) distribution via Group Policy Objects (GPO). Distributed Departmental Control of Users, Groups and Computers Organizational Unit (OU) management. A single unified login (account integration) granting authentication access to both Andrew and Active Directory Windows Resources. Integrated file access to the UNIX AFS directories (OpenAFS). Consistent User Preferences on multiple machines (Roaming Profiles). Additional departmental system service requirements may include: Andrew.AD authentication for Microsoft Applications (e.g. IIS, SQLServer, etc.). This may also potentially affect Non-Microsoft products designed for Windows 2000/XP. Centralized Fileserver Space accessible via Windows 2000. Options for Desktop Backups to a Centralized Location. Centralized Security Tools. It is envisioned that the adoption of Orpheus by the departments will allow the departments to share the benefits of one central Active Directory (AD) and remove the necessity for each and every department to support its’ own Windows Domain leading to a reduced administrative cost and better access to information through implied transitive trust relationships. It will tightly integrate the current domain and Andrew user accounts. The Orpheus project may also attempt to allow the flexibility for departments to run their own domain within the Andrew.ad.cmu.edu forest (at potentially a reduced service capability vice the OU approach). 1.2 What is the goal of this project? 1.2.1 What, specifically, will be the end-result of this project? Software? A service? Technical infrastructure? Describe the results briefly. June 12, 2001 3 of 9 Orpheus Department Support - Requirements Revision What is the anticipated audience of the resulting service? A supportable, scalable, secure Windows 2000 based computing environment that gives the departments easy access to the above listed services. 2. User Requirements 2.1 What is the anticipated audience of the resulting service? 2.1.1 What is the profile of a typical user? Are the novice or expert users or the entire range? Are they a specific type of user (business administrators, departmental computing support personnel, programmers, system administrators, etc.)? Typical users will be departmental administrators supporting both “lab” environments and departmental desktop machines (staff and faculty). Most administrators will have previous skills supporting Windows Operating Systems. Some administrators may only do the job as a secondary assignment to other job functions. It is possible that some departments will only have student support. Given the wide range of skills and manpower that the departments are likely to have with Windows 2000, the departmental Orpheus deployment will need to be flexible enough to accommodate various integration models (e.g. Domain vice OU support). 2.2 What are the specific tasks that users will use this service to accomplish? 2.2.1 What, specifically, will the user be able to do with this service? For example, update machine and data outlet registration, add machines and outlet, query other users (for whom they have authorization) machines and outlets, etc. What types of information will they be able to view only as opposed to edit? This is more high-level than the specific interface or feature requirements below. Easier management of Departmental Computing Environments is the primary goal. Specific features include: Automated Operating System and Patch (Service Packs) Installs via the network. Automated Installs of Common Applications (MSI distribution via GPO). Distributed Departmental Control of Users, Groups and Computers (OU management). A single unified login (account integration) granting authentication access to both Andrew and Active Directory Windows Resources. Integrated file access to the UNIX AFS directories (OpenAFS). Consistent User Preferences on multiple machines (Roaming Profiles). 2.3 What are the specific interface or feature requirements? June 12, 2001 4 of 9 Orpheus Department Support - Requirements 2.3.1 Revision Are there restrictions on what users, or types of users, can Are there interface requirements, such as multi-platform support, a web interface, or some other requirement that affects how the service or software is presented? Are there features that the software or service must contain? All systems participating in the deployment of Project Orpheus (Andrew Windows 2000) must be capable of running the Windows 2000 operating system. The ability to perform an RIS installation via PXE boot is strongly recommended. In order to take advantage of the network features of the Operating System, the systems will be required to have a reliable, fast (10mb/s) Ethernet connection. It is not envisioned that Orpheus will support wireless, DSL or machines connected via modems. 2.4 Are there restrictions on what users, or types of users, can do? 2.4.1 Are there tasks that some users will have access to and others will not? Is there data that some users will have access to and others will not? Organizational Units (OU) will be delegated control and will have the ability to create objects (Users, Groups, Computers, Printers, GPO’s, OU’s, etc.). Specific guidelines for OU delegation are being drafted in another document. It is envisioned that these guidelines will include sections on: OS upgrades, Patch updates, Security, Naming Conventions, Object Creation and other items. 3. Technical Requirements 3.1 Are there any standards that need to be adhered to? 3.1.1 Are there technical standards that the software or service must adhere to? Are there standards with which it should not interfere with or not preclude even if it doesn’t employ those standards? In all cases, services should utilize operating system native utilities. Specific guidelines for OU delegation are being drafted in another document. It is envisioned that these guidelines will include sections on: OS upgrades, Patch updates, Security, Naming Conventions, Object Creation and other items. Specific guidelines for externally controlled domains within the Andrew.ad.cmu.edu forest are being drafted in another document. It is envisioned that these guidelines will include sections on: OS upgrades, Patch updates, Security, Naming Conventions, Object Creation and other items. 3.2 Is there a dependence on a third party? 3.2.1 Is the development reliant on a third party for development of a product or implementation of features in an existing product? Are there aspects of the project that should not be reliant on third parties? June 12, 2001 5 of 9 Orpheus Department Support - Requirements Revision Are there any other technical constraints? Orpheus is heavily dependent upon Microsoft in the release of OS upgrades, Service Packs, Hot Fixes and bug support. Orpheus also presumes that vendors will migrate to the Microsoft recommended application deployment method (MSI’s). 3.3 Are there any other technical constraints? 3.3.1 Are there other technical constraints on the software or service such as network bandwidth restrictions, integration with or at least non-interference with other software or services? Orpheus machines will be required to have to have a reliable, fast (10mb/s) Ethernet connection to support distributed logins and software installations over the network. It is not envisioned that Orpheus will support wireless, DSL or machines connected via modems. Due to the security implications of AD replication in the Andrew Forest, security of Domain Controllers (DC’s) may severely limit the ability to distribute control of DC’s. 3.4 Are there any maintenance considerations? 3.4.1 How will configuration be maintained or updates applied? Who will be responsible for them? Specific tasks will be divided between Systems and User Services. User Services consultants will maintain most services while the Systems Group will maintain server – side issues. The Systems Group will provide some support for developing MSI’s for required applications until a point in time when vendors have adopted this standard for delivery. User Services will provide product testing for the MSI’s. Service Packs (SP’s) and Hot Fixes will need to be applied in a timely manner. Operating Systems Upgrades (Windows XP) will need to be considered and applied where appropriate. Application Vendors will be asked to deliver applications in MSI format in order to prevent an ongoing maintenance issue with the development of application MSI’s. June 12, 2001 6 of 9 Orpheus Department Support - Requirements Revision What are the support expectations? 4. Deployment Requirements 4.1 What are the support expectations? 4.1.1 What will be supported? Will there be aspects of the software or service for which we won’t provide support? Will documentation, training, be needed? Will special Help Center support be needed (e.g., create accounts or administrate authorization)? Will the software be available in computing clusters? Will DSP support the software or service? Primary support will be provided through the Technical Services group’s consultants (formerly DWS). This will include providing documentation, consulting with departmental administrators, and may include training. DSP may become clients of this service. Application Support will be limited to applications that are covered under the Service Level Agreements (SLA’s). Machines will be expected to be in a clean state (no additional applications after a clean load). On-Line Documentation will be provided for common procedures. On-Site Training of departmental users will be offered where appropriate. 4.2 What are the policy issues? 4.2.1 Will any existing policies/guidelines be applicable to the resulting software or service or will changes in existing policies/guidelines need to be considered? Will new policies/guidelines need to be developed? Will these policies pertain to access to the service, potential abuse-related issues, etc.? Are there aspects of the software or service that will be banned or the use of which will be discouraged? Software, which will make any modifications to the AD schema, will not be allowed unless Computing Services approves the changes. Specific guidelines for OU delegation are being drafted in another document. It is envisioned that these guidelines will include sections on: OS upgrades, Patch updates, Security, Naming Conventions, Object Creation and other items. Specific guidelines for externally controlled domains within the Andrew.ad.cmu.edu forest are being drafted in another document. It is envisioned that these guidelines will include sections on: OS upgrades, Patch updates, Security, Naming Conventions, Object Creation and other items. 4.3 Are there current services that must be continued or phased-out? June 12, 2001 7 of 9 Orpheus Department Support - Requirements 4.3.1 Revision Does the software or service have a finite lifespan? Is there other software or another service that this project will replace? If so, are there aspects of the older software or service that must be continued? Are there aspects that must be phased out before this project is deployed? Does a migration path need to be defined for moving from an old version to a new one? There are no known phase-out dependencies for this project. Departmental Orpheus is a new ambitious project that intends to bring a secure, scalability, distributed computing environment to the Windows platform on Campus, and hence is not replacing any existing project. Although Orpheus isn’t dependent upon other project phase-outs, it is envisioned that implementing Orpheus will assist the Computing Services in replacing and/or augmenting other campus technologies (e.g. Netware Servers, WINS, AppleTalk, a unified printing solution, etc.) 4.4 Does the software or service have a finite lifespan? 4.4.1 Is this software or service a temporary solution? What are the conditions or dates which, once met, will require or facilitate the phasing out of this software or service? Departmental Orpheus is not intended to be a temporary solution, but the start of an effort for distributed Windows support. 4.5 Are there timing issues for deployment? 4.5.1 Are there issues with when the software or service is deployed? Must it be during a weekend or over a break? Is there a deadline before which the software or service must be deployed? Must the software or service be deployed in conjunction with another project? After another project? Before another project? We hope to be able to provide a set of specified core services (from Orpheus meeting minutes) to departments by mid-August of 2001. 5. Costs 5.1 Are there restrictions on Computing Services’ hardware/software costs? 5.1.1 If hardware or software will need to be purchased for this system or service, are there restrictions on the overall cost? There are potentially training costs for Systems Group and User Services Consultants. 5.2 Are there constraints on users’ hardware/software costs? 5.2.1 If hardware or software will need to be purchased by the user, are the restrictions on how much this hardware or software should cost per user? June 12, 2001 8 of 9 Orpheus Department Support - Requirements Revision Are there constraints on users’ hardware/software costs? All systems participating in the deployment of Project Orpheus (Andrew Windows 2000) must be capable of running the Windows 2000 operating system. The ability to perform an RIS installation via PXE boot is strongly recommended. One of the potential solution to the issue about DC security, would require Computing Services to buy/host DC’s in a secure operational area (e.g. within Cyert Hall). A rough estimate of cost is $9K/Domain. No estimate on the expected number of domains is known at this time. June 12, 2001 9 of 9